Das Reuse-Release Equivalence Prinzip

Das Reuse-Release Equivalence Prinzip setzt physische Einheiten in Beziehung zu Wiederverwendung und Release. Diese drei Konzepte stehen in einer komplexen Wechselwirkung.

Betrachten wir jede einzelne gerichtete Beziehung in diesem Diagramm, so ergeben sich insgesamt sechs Beziehungen:

1. Physische Einheit → Wiederverwendung
2. Physische Einheit ← Wiederverwendung
3. Physische Einheit → Release
4. Physische Einheit ← Release
5. Wiederverwendung → Release
6. Wiederverwendung ← Release

Physische Einheit → Wiederverwendung

Die physische Einheit ermöglicht eine applikationsübergreifende, native Wiederverwendung. Die Wiederverwendbarkeit einer physischen Einheit ist applikationsübergreifend, weil die Einheit verteilbar (deployable, [Knoernschild2012]) ist. Sie ist nativ, weil die Einheit in die jeweilige lokale Anwendung integriert und innerhalb des Prozesses der Anwendung aufgerufen wird (intraprocess reuse, [Knoernschild2012]).

Physische Einheit ← Wiederverwendung

Da die Wiederverwendbarkeit ein wesentliches Entwurfsziel bei der Konstruktion der physischen Einheit ist, beeinflusst sie die Größe der physischen Einheit. Dabei gilt:

• Je kleiner die physische Einheit ist, desto wahrscheinlicher ist sie wiederverwendbar.
• Je kleiner die physische Einheit ist, desto schwieriger ist sie wiederverwendbar.

[Knoernschild2012] bezeichnet dies als das Use/Reuse Paradox und schreibt:

"Maximizing reuse complicates use."

Die Wahrscheinlichkeit der Wiederverwendung hängt davon ab, ob die Einheit genau diejenige Funktion erfüllt, die ich benötige. Tut sie wesentlich mehr, so wird es unwahrscheinlicher, dass ich sie einsetze, da ich keine Abhängigkeit zu Funktionen aufbauen möchte, die ich gar nicht benutze. Tut sie weniger, so kann ich allerdings denjenigen Teil, den die Einheit nicht abdeckt, durch eine andere Einheit erledigen lassen.

Die Schwierigkeit der Wiederverwendung wächst mit der Zahl der Einheiten, die ich zusammensetzen muss, um die gewünschte Funktion zu erhalten. Je mehr Einheiten beteiligt sind, desto komplexer wird das Geflecht der Abhängigkeiten und die funktionsgemäße Komposition der Einheiten.

Eines der Ziele des physischen Designs besteht darin, die optimale Balance zwischen der Wahrscheinlichkeit und der Einfachheit der Wiederverwendung der konstruierten physischen Einheiten zu schaffen.

Physische Einheit → Release

Die physische Einheit ist der eigentliche Gegenstand eines Releases. Sie ist das verteilbare Endprodukt, das von Benutzern in die eigene Anwendung integriert und dort ausgeführt werden kann.

Physische Einheit ← Release

Durch ein Release wird eine physische Einheit um Eigenschaften ergänzt, die für den Nutzer der physischen Einheit erforderlich sind, um sie sinnvoll wiederverwenden zu können:

• Die Einheit erhält einen eindeutigen Identifizierer (eine Nummer oder einen Namen), unter welchem sie jederzeit zum Zwecke der Verteilung bezogen werden kann.
• Die Veröffentlichung eines Releases hat keinen unmittelbaren Einfluss auf bereits verteilte ältere Versionen der physischen Einheit.
• Der Nutzer der Einheit wird über neue Versionen informiert und entscheidet auf der Grundlage der Neuerungen eines Releases, ob er das Release in die eigene Anwendung übernehmen will oder nicht.

Wiederverwendung → Release

Der Sachverhalt der Wiederverwendung und das Streben danach, die Wiederverwendbarkeit zu vereinfachen und wahrscheinlicher zu machen, beeinflussen die Eigenschaften von Releases:

• Der Release-Zyklus wird davon beeinflusst, welche Wartezeit auf Fehlerkorrekturen, Änderungen und neue Funktionen den Nutzern zugemutet werden kann.
• Häufig werden Releases danach gekennzeichnet, wie hoch die zu erwartenden Aufwände sind, um eine ältere verwendete Version durch die Release-Version zu ersetzen. Ein Beispiel für eine derartige Kennzeichnung ist das Semantic Versioning.

Wiederverwendung ← Release

Ein neues Release hat keinen unmittelbaren Einfluss auf die Verwendung älterer Versionen der physischen Einheit. Soll ein neues Release verwendet werden, so entstehen dem Nutzer jedoch Aufwände. Der Nutzer wird diese Aufwände gegen den zusätzlichen Nutzen des Releases abwägen und dann entscheiden, ob er das Release verwenden möchte oder nicht.

Warum Äquivalenz?

Der im Namen des Prinzips enthaltene Begriff der Equivalence wird am ehesten in folgenden Fassungen des Prinzips anschaulich:

"The granule of reuse is the granule of release." [Granularity1996]

"The unit of reuse is the unit of release." [Knoernschild2012]

Dies kann entweder als Gleichsetzung oder als logische Äquivalenz interpretiert werden. Gehen wir einmal, dem Namen des Prinzips folgend, von einer logischen Äquivalenz aus. Dann lässt sich die Beziehung

"unit of reuse" ⇔ "unit of release"

auflösen in

"unit of reuse" → "unit of release" ∧ "unit of release" → "unit of reuse"

Spätestens hier wird offensichtlich, dass es sich bei "unit of reuse/release" aber nicht um logische Aussagen handelt. Um hier sinnvoll von logischer Äquivalenz reden zu können, müsste etwas hinzugefügt werden wie

(1) Wenn eine physische Einheit wiederverwendet werden soll, dann muss muss sie ein Release sein.

Das ergibt Sinn, aber wie lautet die umgekehrte Richtung?

(2) Wenn ein Release veröffentlicht werden soll, so muss es auch wiederverwendet werden.

Das erscheint entweder fragwürdig oder trivial, so dass eigentlich nur (1) als Kurzfassung übrig bleibt. Der Begriff der Äquivalenz erscheint insgesamt unangebracht.

"Package cohesion"

In [Martin2002] zählt Martin das Reuse-Release Equivalence Prinzip zu den package cohesion principles. Es soll in diesem Sinn einen Beitrag zu der Entscheidung leisten, welche Granularität für eine physische Einheit angemessen ist. Nicht umsonst trägt die ursprüngliche Artikelserie Martins auch den Titel "Granularity".

Wir haben oben (Sichwort Use/Reuse Paradox) gesehen, dass Granularität ein schwieriger Balanceakt zwischen der Wahrscheinlichkeit der Wiederverwendung und der Einfachheit der Wiederverwendung ist. Das Reuse-Release Equivalence Prinzip leistet bei dieser Abwägung allerdings nur wenig Hilfe.

Die Tatsache, dass eine physische Einheit nur dann wiederverwendet werden sollte, wenn sie als Release verfügbar ist, beeinflusst allenfalls auf subtile Weise die Granularität einer physischen Einheit. Für bereits veröffentlichte oder fremde Releases können wir uns diese Diskussion ohnehin sparen, da in diesem Fall die Granularität fremdbestimmt ist. Also gehen wir davon aus, dass das physische Design unter unserer eigenen Kontrolle steht. 

Welche Entscheidungshilfe liefert uns dann das Wissen, dass physische Einheiten immer als Releases verwendet werden? Hier können allenfalls Aspekte des Releasemanagements in die Abwägung einbezogen werden wie z. B. Release-Zyklen, Anforderungen an die Versionierung der Einheiten oder Ähnliches. Der ursprünglich formulierte Anspruch, eine Hilfestellung bei der Wahl der geeigneten Granularität zu bieten, wird also vom Reuse-Release Equivalence Prinzip nur schwach erfüllt. Seine Einstufung als package cohesion principle erscheint daher nicht angebracht.

Katalogeintrag

Name, Kurzform	Reuse-Release Equivalence Prinzip
Synonyme	Reuse/Release Equivalence Prinziple, REP
Beschreibung	Eine physische Einheit, die wiederverwendet werden soll, muss als Release zur Verfügung stehen.
Erläuterung	Die ursprüngliche Fassung des Prinzips von Robert C. Martin lautet noch etwas anders: „The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package.“ [Granularity1996] Das ist unnötig lang und bezieht sich zudem auf den Package-Begriff, den ich [wie angekündigt] hier vermeide. [Knoernschild2012] gibt eine kürzere Version: „The unit of reuse is the unit of release.“ Im Deutschen klingt diese Version allerdings ziemlich sperrig („Die Wiederverwendungs-Einheit ist die Release-Einheit.“ Oder hat jemand eine bessere Idee?) Zudem ist in dieser Form, für sich genommen, nicht klar dass es sich nur um physische Einheiten handeln darf, was z. B. die fälschliche Übertragung des Prinzips auf Klassen oder andere logische Einheiten erleichtern würde. Ich habe mich daher für die obige etwas ausführlichere Version entschieden.
Beispiel(e)	Versionierte Bibliotheken, Frameworks, usw. Tags oder andere eindeutige Version-Identifier in Quellcodeverwaltungs-Systemen wie CVS, Subversion, Git usw.
Historie	Die erste Formulierung des Prinzips erfolgte in der C++-Artikelserie [Granularity1996]. Er spricht hier von „granule of reuse“. In [Martin2002] spricht Martin nicht mehr von „packages“ und „package cohesion“, sondern von „components“ und „component cohesion“. In [Knoernschild2012] ist an Stelle von „granule of reuse“ von „unit of reuse“ die Rede.
Art des Prinzips	Grundlegende Einteilung: Produkt. Technologiebezug: Übergreifend. Entwurfsgüte: Bausteineigenschaft. Handlungsbezug: Erleichterung von Wiederverwendung, Build und Verteilung. Kognitionsbezug: Komplexitätsreduktion. (Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation	Mäßig. Einerseits handelt es sich eher um ein „polititsches“ Prinzip. Andererseits sollte sich meist gut bestimmen lassen, was ein „Release“ ist.
Vorteile	Führt eine klare Regel ein, welche physischen Einheiten zur Wiederverwendung in Frage kommen. Eines der wenigen verfügbaren Prinzipien im Kontext physischen Designs.
Nachteile	Hilft bei der Bestimmung einer guten Granularität oder Kohäsion von physischen Einheiten kaum bis gar nicht, obwohl genau das von Martin behauptet wird. Irreführende Bezeichnung: Mit Äquivalenz hat das Prinzip nichts zu tun.
Übergeordnete Prinzipien	Modularisierungsprinzip
Abgleitete Prinzipien	-
Qualitätsmerkmale	Wiederverwendbarkeit (+), Wartbarkeit (+)

Zusammenfassung

Die Beziehungen zwischen den Konzepten "physische Einheit", "Wiederverwendung" und "Release" lassen sich wie folgt zusammenfassen:

Zudem ist festzuhalten, dass das Prinzip weder eine Äquivalenz ausdrückt, noch einen nennenswerten Beitrag zur Bestimmung der richtigen Granularität einer physischen Einheit liefert. Der Kern des Prinzips besteht in der einfachen Regel, physische Einheiten nur dann wiederzuverwenden, wenn sie in der Form eines Releases bereitstehen. Weitergehende Interpretationen erscheinen unangebracht.

Quellen

[Granularity1996] – Granularity, Robert C. Martin, in: IEEE Software. Dezember 1996, S. 4, siehe http://www.objectmentor.com/resources/articles/granularity.pdf

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

[Martin 2002] – Agile Software Development. Principles, Patterns, and Practices, Robert C. Martin (2002)