In der objektorientierten Softwareentwicklung ist seit langem das „Open-Closed-Prinzip“ ein Begriff: Ein System soll geschlossen für Veränderungen sein, aber offen für Erweiterungen. Speziell in gewachsenen Anwendungen ist dieses Prinzip nicht immer leicht umsetzbar. Für fachliche Erweiterungen und neue Abhängigkeiten müssen bestehende Module oder Klassen häufig umgebaut, also verändert werden. Das „Open-Closed-Prinzip“ wird verletzt, der Entwickler gerät in die „Dependency-Hölle“. In seinem Artikel beschreibt unser Mitarbeiter Dr. Reik Oberrath die klassische Situation anhand eines Fallbeispiels und zeigt Wege auf, wie ein fachlich offenes Dependency Management aufgebaut werden kann. Als Fallstudie dient die Webanwendung „OHO“ für einen Anbieter von Online-Horoskopen, die mit wachsendem Geschäftserfolg mehrmals erweitert werden soll.

1. n-
Java
le t 8 te AUSGABE 6 · Dezember / Januar ’13
el k 4
St ar ite ebo
06
D / 6,40 · A / 7,30 · SFR 12,50
m e g
S n e
ab re A lin
4 194156 106405
te n
w
ei o
mit Integrations-
SPEKTRUM
www.javaspektrum.de
Magazin für professionelle Entwicklung und Integration von Enterprise-Systemen
OpenJDK
Retrospektive und Ausblick
OpenJDK – und auch Kanban und Big Data
Profiling und Optimierungen
Der OpenJDK-Erweiterungsprozess
KanbanFlow
Build-Prozess mit Apache Ivy C K
D RU
R
N DE
Data-Warehouse-Infrastruk- SO
tur zur Codeanalyse
G30325

2. Fachthema 
Raus aus der Dependency-Hölle
Das fachlich [include]
2. Auftraggeber-
Daten erfassen
offene Dependency-
1. Neuen Auftrag
erfassen
Kunde [include] 3. Daten der Ziel-
personen erfassen
Management 4. Horoskop [include] 5. Rechnungsan-
ab V 1.2
erstellen weisungen erfassen
Astrologe
Reik Oberrath
Unter den beiden Paradigmen komponentenorientierte Architektur 6. Rechnung [include] 7. Rechnung
erstellen verschicken
und fachlich getriebene Komponentenbildung ist das Dependency-
Management häufig schwierig. Bei wachsender Funktionalität und 8. Zahlungs-
zunehmender Komplexität hat man es schnell mit einem dichten eingang prüfen
Buchhalter
Netz von Abhängigkeiten zu tun, in dem es immer schwieriger wird,
gegenseitige Abhängigkeiten und Abhängigkeitszyklen zu vermei- 9. Horoskop [include] 10. Kunden
den: die Dependency-Hölle. Dieser Artikel zeigt, wie fachlich ent- freischalten informieren
worfene Komponenten voneinander entkoppelt werden können, Abb. 1: OHO Use Case Diagramm
sodass technische Beschränkungen die fachliche Komponentenbil-
dung nicht mehr beeinträchtigen: das fachlich offene Dependency- Abb. 1: OHO-Use-Case-Diagramm
Management.
Fallstudie: Online Horoskope Das klassische Dependency-Management
E Dieser Artikel basiert auf den beiden Paradigmen Zunächst ist das Abhängigkeitsgefüge klar: Sowohl für die Er-
H komponentenorientierte Architektur [KE] und stellung des Horoskops als auch für die der Abrechnung wer-
H fachlich getriebene Komponentenbildung [Sinz99]. den Auftragsdaten benötigt. Aus diesem Grund referenziert
Die Dependency-Hölle, die mit diesem Ansatz häufig verbun- sowohl ein Horoskop als auch eine Abrechnung den dazuge-
den ist, sowie der Ausweg aus dem Abhängigkeitswirrwarr hörenden Auftrag. Die OHO-Version 1.0 beinhaltet die in Ab-
wird anhand der fiktiven Webanwendung Online-HOroskop bildung 2 gezeigten Abhängigkeiten.
(OHO) dargestellt. Die grundlegenden Begriffe dieses Artikels
werden im Kasten „Begriffserläuterungen“ zusammengefasst.
Abrechnung Horoskop
Die Webanwendung OHO, Version 1.0
Die Astrologin „Starlet“ macht sich selbstständig und möch-
Auftrag
te online einen Horoskop-Dienst anbieten. Sie beauftragt eine
kleine Software-Schmiede namens „GutGünstig“ (GG), die
Webanwendung OHO zu entwickeln. Diese Anwendung soll
es Kunden (Auftraggebern) ermöglichen, die Erstellung eines
Horoskops online sowohl zu beauftragen als auch das erstellte
Horoskop nach erfolgter Zahlung abzurufen.
Stammdaten
Im Auftrag muss ein Auftraggeber alle nötigen Angaben
zum Horoskop angeben: Kontoverbindung des Auftraggebers
und persönliche Daten der Zielperson, für die ein Horoskop Abb. 2: OHO 1.0-Abhängigkeiten – Die beiden Komponenten Abrechnung und
HoroskopAbb. 2: in der1.0 Abhängigkeiten: die beiden Komponenten Abhängig-
stehen OHO Dependency-Hierarchie ganz oben. Rot: diese
erstellt werden soll. Der Auftragsteller kann zwischen vollstän- keit wäre für OHO 1.1 nötig, ist aber technisch nicht möglich
Abrechnung und Horoskop stehen in der Dependency-
digem Horoskop und verschiedenen Teilhoroskopen (z. B. nur Hierarchie ganz oben. Rot: diese Abhängigkeit wäre für OHO
Ratschläge in Sachen Liebe, Finanzen, usw.) auswählen. Aus 1.1 nötig, ist aber technisch nicht möglich
den persönlichen Daten der Zielperson wird ein Horoskop er- Das Geschäft mit OHO 1.0 läuft gut und Starlet kann viele Ho-
stellt, das in der Datenbank der Anwendung gespeichert wird. roskope online erstellen und abrechnen. Die Arbeit wird bald
Außerdem wird mit OHO die Rechnungsstellung abgewickelt so viel, dass sie sich ganz auf die fachliche Arbeit konzentrieren
und nach Zahlungseingang das Horoskop online zur Verfü- möchte, d. h. auf die Erstellung der Horoskope. Sie stellt den
gung gestellt (Abb. 1). Buchhalter „Billy“ ein, der sich um die Abrechnungen küm-
Die GG-Entwickler realisieren OHO mit Java, Spring und mert. In der Zusammenarbeit mit Billy gibt es aber immer wie-
Maven. Um die Qualität der Software zu testen, schreiben sie der Reibungsverluste, denn aus Starlets Sicht sind die Abrech-
sowohl Unit-Tests als auch Integrationstests. Letztere leiten nungen nicht immer korrekt. Außerdem beschweren sich die
von der Spring-Klasse AbstractTransactionalSpringContextTests ab. Kunden über mangelnde Transparenz der Kosten bei der Auf-
Diese Klasse löst die Abhängigkeiten zwischen den Spring- tragsstellung.
Beans verschiedener Komponenten automatisch auf. Die Aus diesem Grund sollen die Rechnungspositionen im Auf-
OHO-Anwendung besteht aus den vier Komponenten Stamm- trag angezeigt werden und damit sowohl für den Kunden als
daten, Auftrag, Horoskop und Abrechnung. auch für Starlet leichter einzusehen sein. Technisch bedeu-
42 JavaSPEKTRUM 6/2012

3.  Fachthema
tet das, dass die Komponente Auftrag eine Abhängigkeit zu
Begriffserläuterungen Abrechnung benötigt, um die zum Auftrag gehörenden Rech-
nungsdaten einzulesen. Das führt allerdings zu einer wechsel-
H Komponentenorientierte Architektur [KE]: Vorgehens- seitigen fachlichen Abhängigkeit zwischen den Komponenten
weise, den Quellcode in separate Bestandteile bzw. Auftrag und Abrechnung (s. Abb. 2, roter Pfeil), die technisch
einzelne Bausteine zu unterteilen, mit dem Haupt- nicht realisiert werden kann (s. Kasten „Begriffserläuterun-
ziel, durch die Einhaltung des Prinzips „Separation gen“, Technische Abhängigkeiten). Die GG-Entwickler dis-
of Concerns“ [CCDSoC] die strukturelle Qualität und kutieren mehrere Lösungsmöglichkeiten:
damit die Wartbarkeit des Quellcodes zu verbessern. H Die Gemeinsamkeiten der Komponenten Auftrag und Abrech-
Weiteres Ziel ist außerdem, mehr Möglichkeiten zu nung werden aus den beiden Einzelkomponenten heraus-
schaffen, Quellcode wiederzuverwenden. gezogen und daraus eine neue Komponente erzeugt. Zwei
H Komponente: Komponenten sind die großen Bausteine Nachteile dieser Lösung führen zur Ablehnung. Erstens wür-
einer deploybaren Softwareeinheit (z. B. jar-Dateien in- de aus technischen Gründen eine neue Komponente gebaut,
nerhalb einer ear-Datei). Dieser Artikel unterscheidet die fachlich nicht gut zu begründen ist. Zweitens würden
bewusst nicht zwischen Komponente und Modul [Mo- die Komponenten Auftrag und Abrechnung dadurch so klein,
dul], da beide Bausteinarten die gleichen Dependency- dass sie ihre Existenzberechtigung verlieren.
Probleme aufweisen. Komponenten bestehen aus klei- H Die Komponenten Auftrag und Abrechnung werden zu einer
neren Bausteinen wie kompilierten Klassen und ande- verschmolzen. Auch diese Lösung wird verworfen, um dem
ren Ressourcen. Eine OHO-Komponente wird durch Paradigma der komponentenorientierten Architektur treu
die pom-Datei ihres Maven-Projekts definiert. zu bleiben und eine beginnende Monolithen-Architektur zu
H Fachliche und technische Komponenten: Fachliche Kom- vermeiden.
ponenten stellen separate Funktionsblöcke dar, die H Die bisherige Vorgehensweise wird geändert: Statt eine lee-
sich aus der Geschäftslogik ableiten und damit fach- re Abrechnung zu erstellen und von dort einen Auftrag zu
lich begründen lassen. Technische Komponenten sind referenzieren, wird für einen selektierten Auftrag eine neue
Bausteine des Softwaresystems, die keine fachliche Abrechnung erzeugt und von dort werden alle für die Ab-
Bedeutung haben und für die Bewältigung von tech- rechnung nötigen Auftragsdaten in die neue Abrechnung
nischen Problemen entworfen wurden. kopiert.
H Fachliche Abhängigkeiten: Logische, rein konzeptionelle Der Nachteil der letzten Alternative ist redundante Informa-
Abhängigkeiten einer Komponente von einer anderen, tionen im Auftrag und in der dazugehörenden Abrechnung.
z. B. der Komponente Auftrag von der Komponente Der Vorteil aber für das Dependency-Management besteht dar-
Stammdaten, weil letztere Kundendaten zur Verfügung in, dass die Komponente Abrechnung technisch nicht mehr von
stellt, die in Auftrag benötigt werden. Fachliche Abhän- der Komponente Auftrag abhängig ist. Jetzt kann die benötig-
gigkeiten entstehen beim Design der Komponenten te umgekehrte Abhängigkeit der Komponente Auftrag von der
dort, wo Funktionsblöcke wie Auftrag und Stammda- Komponente Abrechnung eingebaut werden (s. Abb. 3). Des-
ten konzeptionell voneinander getrennt werden. halb wählen die GG-Entwickler diese Alternative.
H Technische Abhängigkeiten: Auf verschiedenen Abs-
traktionsebenen gibt es unterschiedliche Arten von
technischen Abhängigkeiten. Auf Klassenebene exis-
tieren Abhängigkeiten, die wechselseitig sein können Horoskop
(Klasse A ist abhängig von Klasse B und umgekehrt).
Auf Komponentenebene existieren Abhängigkeiten,
die nicht wechselseitig sein dürfen (Wenn Kompo- Auftrag
nente A von B abhängt, darf B nicht von A abhängig
sein). Abhängigkeiten zwischen Komponenten sind
die Ursache für die im Artikel beschriebene Depen- Abrechnung
dency-Hölle.
H Dependency-Hierarchie: Komponenten müssen auf-
grund der technischen Abhängigkeiten in einer be- Stammdaten
stimmten Reihenfolge gebaut werden. Basis-Kompo-
nenten, die als erstes gebaut werden können, liegen
in der Dependency-Hierarchie unten. Andere Kom- Abb. 3: OHO 1.1-Abhängigkeiten – Die Komponente Abrechnung wurde in der
Dependency-Hierarchie OHO 1.1 Abhängigkeiten: die Komponente Rot: diese Ab-
Abb. 3: unter die Komponente Auftrag geschoben.
ponenten, die auf den Basis-Komponenten aufbauen, hängigkeit wäreAbrechnung wurde inist aber technisch nicht möglich
für OHO 1.2 nötig, der Dependency-Hierarchie unter die
liegen in der Dependency-Hierarchie darüber. Komponente Auftrag geschoben. Rot: diese Abhängigkeit
H Fachliche Offenheit: Nach dem Open-Closed-Prinzip wäre für OHO 1.2 nötig, ist aber technisch nicht möglich
[CCDOCP] soll ein System geschlossen sein für Ver-
änderungen, aber offen für Erweiterungen. Muss ein Fortdauernder Umbau
System für eine Erweiterung umgebaut werden, ist
dieses Prinzip verletzt. Können Erweiterungen ohne Das Geschäft mit OHO 1.1 läuft weiterhin gut und Hunder-
Umbau vorgenommen werden, ist das System „of- te Horoskope werden erstellt und abgerechnet. Starlet kann
fen“. Dieser Artikel stellt ein Dependency-Manage- jetzt einfacher die Rechnungspositionen eines Auftrages ein-
ment vor, in dem neue fachliche Abhängigkeiten ohne sehen, ist aber in vielen Einzelfällen mit einigen Buchungs-
Umbau des bisherigen Beziehungsgeflechts realisiert details nicht einverstanden. Mit der Zeit wird klar, dass die
werden können. Dieses Dependency-Management Kommunikation zwischen den beiden Fachkräften Starlet und
wird hier deshalb als „fachlich offen“ bezeichnet. Billy noch effektiver sein würde, wenn Starlet bei Bedarf Ab-
rechnungsanweisungen bei der Erstellung des Horoskops im
www.javaspektrum.de 43

4. Fachthema 
Horoskop speichern und diese Information von Billy bei der ler erwägen wieder die oben genannten ersten beiden Alter-
Abrechnungserstellung ausgewertet werden könnte. nativen. Die hitzige Diskussion darüber schürt das Feuer der
Diese neue Anforderung bedeutet eine fachliche Abhän- Dependency-Hölle.
gigkeit der Komponente Abrechnung von der Komponente
Horoskop. Technisch würde das zu einem Abhängigkeitszyklus
zwischen den Komponenten Horoskop, Auftrag und Abrechnung Ausweg aus dem Abhängigkeitswirrwarr
führen (s. Abb. 3). Das neue Abhängigkeitsdilemma wird von
den GG-Entwicklern diskutiert und sie einigen sich auf fol- In dieser heißen Phase kommt ein neues Mitglied ins GG-
gende Lösung: Entwicklerteam. Es schlägt vor, die Schnittstellenbeschreibung
Für einen selektierten Auftrag wird ein neues Horoskop er- (API) aus der Komponente Auftrag herauszuziehen und von
zeugt und alle für das Horoskop nötigen Auftragsdaten wer- der Implementierung zu trennen. Zu diesem Zweck soll eine
den aus dem Auftrag in das Horoskop kopiert. Der Nachteil neue technische Komponente eingeführt werden, welche nur
dieser Vorgehensweise sind weitere redundante Informatio- die Schnittstelle der Komponente Auftrag definiert, d. nur
h.
nen. Der Vorteil aber für das Dependency-Management be- deren Interfaces beinhaltet. Diese Komponente wird Auftrag-
steht darin, dass die Komponente Horoskop technisch nicht API genannt.
mehr von der Komponente Auftrag abhängig ist. Jetzt können Mit dieser Konstruktion brauchen die beiden Komponenten
die GG-Entwickler in OHO 1.2 die neue benötigte Abhän- Abrechnung und Horoskop keine technische Abhängigkeit zur
gigkeit von der Komponente Abrechnung zur Komponente Komponente Auftrag, sondern nur noch zu Auftrag-API (s. Abb.
Horoskop einbauen, ohne einen Abhängigkeitszyklus zu ver- 4b). Die Abhängigkeiten, die die Dependency-Hölle verursa-
ursachen (s. Abb. 4a). chen würden, sind so nicht nötig. Die GG-Entwickler imple-
mentieren in der Komponente Auftrag den Service „Auftrag-
suche“ und stellen das dazugehörende Interface IAuftragssuche
in Auftrag-API zur Verfügung. Dieses Interface kann aus den
Auftrag Komponenten Abrechnung und Horoskop referenziert werden.
Die Dependency-Injection von Spring übernimmt das Instanzi-
Interfaces
ieren des Auftragsucheservice.
Die GG-Entwickler stellen fest, dass ihre Entwicklungs-
umgebungen keine Kompilierungsfehler melden, die Anwen-
Abrechnung dung mit Maven gebaut, deployt und erfolgreich angewendet
werden kann. Das Feuer der Dependency-Hölle ist mal wieder
Horoskop gelöscht.
Stammdaten
Integrationstests im Maven-Build
Die GG-Entwickler schreiben in der Komponente Abrechnung
Auftrag-API
die Testklasse AuftragsucheTest.java, in der eine Auftragsuche
Interfaces durchgeführt wird. Dieser Test läuft in der Entwicklungsum-
gebung erst nach manueller Erweiterung des Klassenpfades,
Abb. 4:Abb. 4: Unterschiede zwischen OHO 1.2 1.3 1.3
Unterschiede zwischen OHO 1.2 und und weil die Abhängigkeiten zur Komponente Auftrag nicht aufge-
a) chwarz: OHO 1.2-Abhängigkeiten: die Komponente Auftrag steht jetzt in der
S a) Schwarz: OHO 1.2 Abhängigkeiten: die Komponente Auftrag steht jetzt löst werden konnten. Später beim Maven-Build stellt sich her-
Dependency-Hierarchie ganz oben. Rot: diese Abhängigkeiten wären für OHO
in der Dependency-Hierarchie ganz oben. Rot: diese Abhängigkeiten aus, dass dieser aus dem gleichen Grunde nicht läuft. Ursache
1.3 nötig, sind OHO 1.3 nötig, sind technisch aber nicht möglich
wären für technisch aber nicht möglich
b) Blau b) Blau und Schwarz :1.3-Abhängigkeiten, durch die Verschiebung der Auf-
und Schwarz: OHO OHO 1.3 Abhängigkeiten, durch die Verschiebung ist, dass die GG-Entwickler einen Integrationstest geschrie-
trag-Interfaces in die neue in die neue technische Komponente Auftrag-API
der Auftrag-Interfaces technische Komponente Auftrag-API (grau) werden ben haben, in dem eine in der Dependency-Hierarchie unten
(grau), werden die rot markierten Abhängigkeiten unnötig.
die rot markierten Abhängigkeiten unnötig gelegene Komponente (Abrechnung) eine andere Komponen-
te benutzen möchte, die in der Dependency-Hierarchie weiter
oben liegt (Auftrag, s. Abb. 4a).
Beim Auflösen von nach oben gerichteten Abhängigkeiten
Die Dependency-Hölle müsste Maven eine alte, zuvor gebaute Version der Auftrag-
Komponente benutzen, um die Integrationstests in der Kom-
Das Geschäft mit OHO 1.2 läuft immer besser und tausende ponente Abrechnung durchführen zu können. Diese Vorgehens-
Horoskope müssen erstellt und abgerechnet werden. Dank der weise wäre im Maven-Build falsch, weil hier sichergestellt wer-
verbesserten Kommunikation zwischen Starlet und Billy kann den soll, dass nur die aktuellen Ressourcen verwendet werden.
die gute Auftragslage einigermaßen bewältigt werden. Aller- Mit dem Integrationstest AuftragsucheTest.java in der Kom-
dings kommt es immer häufiger vor, dass sich die beiden Fach- ponente Abrechnung haben die GG-Entwickler eine techni-
kräfte wünschen, aus einer Abrechnung bzw. aus einem Horo- sche Abhängigkeit implementiert, die im Maven-Build un-
skop nach früheren Aufträgen des gleichen Kunden zu suchen, überwindlich ist. Die Dependency-Hölle brennt wieder. Als
um daraus Daten zu übernehmen oder mit aktuellen Daten ab- schnelle Lösung, um den Maven-Build wieder zum Laufen zu
zugleichen. bekommen, wird der Auftragsucheservice in der Komponente
Diese neue Anforderung stellt eine fachliche Abhängigkeit Abrechnung für die Testausführung gemockt [MockO]. Dieser
der beiden Komponenten Abrechnung und Horoskop von der Auftragsucheservice-Mock beinhaltet keine Funktionalität
Komponente Auftrag dar. Jetzt sind die GG-Entwickler end- und dient nur dazu, die fehlende Abhängigkeit für die Depen-
gültig in der Dependency-Hölle angekommen, weil mit dem dency-Injection von Spring aufzulösen. Damit kann zwar der
aktuellen Dependency-Management diese Abhängigkeiten Maven-Build erfolgreich ausgeführt werden, aber der Integra-
technisch nicht realisiert werden können. Die GG-Entwick- tionstest bleibt im Maven-Build unausgeführt.
44 JavaSPEKTRUM 6/2012

5.  Fachthema
Durch den Kunstgriff der API-Komponente konnte also die ministrativen Tätigkeiten eine völlig neue Komponente Admi-
Dependency-Hölle zur Compile-Zeit überwunden werden. nistration.
Über die in der Dependency-Hierarchie aufwärts gerichteten Damit lodert die Dependency-Hölle wieder auf. Die GG-
Integrationstests bekommt aber die Dependency-Hölle wieder Entwickler überlegen jetzt, wie eine vollständige Überwin-
eine offene Tür in Form der Maven-Build-Test-Runtime. dung der Dependency-Hölle aussehen könnte, die sowohl
zur Compile-Zeit als auch zur Maven-Build-Test-Runtime alle
Dependency-Probleme endgültig löst.
Grenzen des klassischen Dependency-Managements
Das Geschäft mit OHO 1.3 läuft so gut, dass Starlet sich ent- Fachliche Offenheit zur Compile-Zeit
schließt, noch eine Fachkraft aus dem Bereich Sachbearbei-
tung einzustellen, die sich speziell um die Auftragsbearbei- Der Ansatz im Kapitel „Ausweg aus dem Abhängigkeitswirr-
tung und um sonstige administrative Tätigkeiten kümmert. Zu warr ist gut, aber nicht konsequent zu Ende gedacht und zwar
diesem Zweck soll OHO eine neue Funktion bekommen, die aus zwei Gründen:
es ermöglichen soll, aus den Stammdaten heraus nach Aufträ- H Wenn die API-Komponente sämtliche Interfaces der Kompo-
gen und Abrechnungen zu suchen. Die Komponente Stamm- nenten Abrechnung, Auftrag und Horoskop beinhalten würde,
daten wird damit abhängig von den Komponenten Auftrag und bräuchte man zur Compile-Zeit keine Abhängigkeiten mehr
Abrechnung. Außerdem planen die GG-Entwickler für die ad- zwischen diesen fachlichen Komponenten. Die GG-Ent-
wickler führen ein Refactoring durch und bauen die Version
OHO 1.4 (s. Abb. 5a).
H Es gibt immer noch technische Abhängigkeiten zu der Kom-
ponente Stammdaten. Hier hat das Feuer der Dependency-
Abrechnung Auftrag Horoskop Hölle noch Brennmaterial. Die vollständige Entkoppelung
zur Compile-Zeit erreichen die GG-Entwickler in der Ver-
sion 2.0, in der alle fachlichen Komponenten nur noch zur
API-Komponente eine technische Abhängigkeit aufweisen
(s. Abb. 5b und Abb. 6).
Stammdaten
Interfaces
Fachliche Offenheit zur Maven-Build-Test-Runtime
Nach wie vor können für einige Integrationstests nicht alle be-
Stammdaten-Interfaces Tagesgeschaeft-API nötigten Abhängigkeiten im Maven-Build aufgelöst werden (z.
Abrechnung-Interfaces Auftrag-Interfaces Horoskop-Interfaces B. die Auftragssuche in der Komponente Abrechnung). Dieses
Problem ließe sich lösen, indem GG-Entwickler die nötigen
Abb. 5: Unterschiede zwischen OHO 1.4 und 2.0 Abhängigkeiten mit dem Maven-Scope „test“ konfigurieren
Abb. 5: Unterschiede zwischen OHO 1.4 und 2.0
a) Schwarz: OHO 1.4 Abhängigkeiten: zwischen den Komponenten würden. Damit wäre aber nur die Dependency-Hölle von der
a) chwarz: OHO 1.4-Abhängigkeiten: zwischen denAbhängigkeiten mehr.
S Abrechnung, Auftrag und Horoskop gibt es keine Komponenten Abrechnung,
Auftrag und Horoskop gibt es keine Abhängigkeiten mehr. Die 1.3-Komponente
Die 1.3-Komponente Auftrag-API wurde in Tagesgeschaeft-API umbenannt.
Compile-Zeit in die Maven-Build-Test-Runtime verschoben.
Auftrag-API wurde in Tagesgeschaeft-API umbenannt. sind technisch aber
Rot: diese Abhängigkeiten wären für OHO 1.5 nötig, Rot: diese Abhängigkei- Endgültig lösen die GG-Entwickler das Problem, indem sie
tennicht möglich,
wären für OHO 1.5 nötig, sind technisch aber nicht möglich in der Phase „test“ des Maven-Lebenszyklus nur echte Unit-
b) Blau: durchdurch die VerschiebungStammdaten-Interfaces in die die
b) Blau: die Verschiebung der der Stammdaten-Interfaces in technische API- Tests ausführen lassen. Das bedeutet, dass in den Tests des
Komponente (grau), werden die letzten Abhängigkeiten zwischen den fachlichen
technische API-Komponente (grau), werden die letzten Abhängigkeiten
Komponenten (weiß) unnötig. Statt 1.5 wird diese Version 2.01.5 wird diese
zwischen den fachlichen Komponenten (weiß) unnötig. Statt genannt Maven-Builds nur Funktionalität aus der eigenen Komponente
Version 2.0 genannt. ausgeführt wird. Wird eine Funktionalität aus einer anderen
Komponente zum Test gebraucht, muss diese Funktionalität
gemockt werden [MockO].
Die Integrationstests führen die GG-Entwickler also jetzt
Auftrag
erst aus, nachdem der Maven-Build erfolgreich durchgelau-
fen ist und alle Komponenten frisch gebaut vorliegen. Dann
Abrechnung Administration Horoskop
spielt die Dependency-Hierarchie keine Rolle mehr. Zu diesem
Zweck implementieren die GG-Entwickler die Integrations-
Stammdaten
tests in einem separaten Maven-Projekt, welches die Abhän-
gigkeiten zu allen fünf fachlichen Komponenten auflösen kann
[MavenIT].
Ein Continuous Integration (CI)-Server führt regelmäßig das
OHO-Model-Impl OHO-API OHO-Maven-Build durch. Ist dieses erfolgreich, führt der CI-
Server im direkten Anschluss automatisch das Maven-Goal
„test“ im Integrationstest-Projekt durch. Damit werden die
OHO-Model-API Integrationstests ganz ohne Dependency-Hölle regelmäßig im-
mer direkt nach dem Maven-Build durchgeführt.
Abb. 6: OHO 2.1 Abhängigkeiten. Aus – Aus verschiedenen Gründenmehrere mehrere
Abb. 6: OHO 2.1-Abhängigkeiten verschiedenen Gründen wurden wurden
technische Komponenten (grau) nötig. Die Die fachlichen Komponenten haben haben
technische Komponenten (grau) nötig. fachlichen Komponenten (weiß) (weiß)
untereinander keine (technischen) Abhängigkeiten mehr.mehr.fachliche Komponente
untereinander keine (technischen) Abhängigkeiten Jede Jede fachliche Kompo- Das fachlich offene Dependency-Management
hat Abhängigkeiten zu allen drei technischen Komponenten. Die 1.4-Komponente
nente hat Abhängigkeiten zu allen drei technischen Komponenten. Die 1.4-Kom-
Tagesgeschaeft-API wurde in OHO-API in OHO-API umbenannt
ponente Tagesgeschaeft-API wurde umbenannt. Mit der fachlichen Offenheit sowohl zur Compile-Zeit als auch
zur Maven-Build-Test-Runtime ist es möglich, fachliche und
www.javaspektrum.de 45

6. Fachthema 
technische Abhängigkeiten vollständig voneinander zu ent- anderen Komponenten) bewusst formulieren müssen. Werden
koppeln. Neue fachliche Abhängigkeiten durch neue Anfor- fachliche Abhängigkeiten durch technische Abhängigkeiten
derungen, die häufig in der Weiterentwicklung von Software definiert, liegen alle als public deklarierten Klassen einer Kom-
auftreten, können so schmerzfrei und schnell implementiert ponente A im Klassenpfad der anderen Komponenten, die von
werden. Komponente A abhängig sind. Das verleitet Entwickler dazu,
Die GG-Entwickler führen ein Refactoring durch und Klassen aus fremden Komponenten zu referenzieren, die ei-
bauen die OHO-Version 2.0 nach dem fachlich offenen De- gentlich gar nicht zur Schnittstelle dieser Komponente gehören.
pendency-Management (s. Abb. 5b). Jetzt können alle ausste- Mit einem fachlich offenen Dependency-Management ist
henden Änderungen problemlos durchgeführt und auch die das nicht möglich. Hier werden die Entwickler gezwungen,
neue Komponente Administration kann ohne Seiteneffekte ein- die Funktionalität einer Komponente, die nach außen zu Ver-
gebaut werden. Alle in Administration benötigten Funktionen fügung gestellt werden soll, bewusst in der API-Komponente
aus fremden Komponenten stehen dank der API-Komponente in Form einer Interface-Klasse bzw. in einer ihrer Methoden
nur durch eine Abhängigkeit zu der Komponente OHO-API zu definieren. Damit wird zusätzlich dem Dependency-In-
zur Verfügung. Und auch umgekehrt können so alle anderen version-Prinzip [CCDDI] Folge geleistet – die Komponenten
Komponenten bei Bedarf die Funktionalität der Komponente hängen nicht direkt voneinander ab, sondern nur von ihrer
Administration nutzen. Das Dependency-Management ist fach- Abstraktion (API).
lich völlig offen für alle Arten von Veränderungen (s. Kasten
„Begriffserläuterungen“, Fachliche Offenheit).
Notwendigkeit weiterer technischer Komponenten
Nachteile des fachlich offenen Dependency- Häufig kann es sinnvoll sein, die große API-Komponente in
Managements zwei oder mehrere technische Komponenten aufzuteilen. Bei-
spielsweise lösen die GG-Entwickler die Interface-Klassen ih-
Als Nachteile sind folgende drei Punkte zu nennen: rer Domänen-Objekte (z. B. IAuftrag.java aus der Komponente
H Das Paradigma der fachlich motivierten Komponentenbil- Auftrag oder IHoroskop.java aus der Komponente Horoskop) aus
dung ist durch die Einführung der rein technischen API- der großen API-Komponente heraus, weil ein Datenimport-
Komponente aufgeweicht. Zum einen, weil eine zusätzliche Tool auf das OHO-Datenmodell zugreifen muss. Durch Erzeu-
technische API-Komponente nötig ist, zum anderen, weil gung der technischen Komponente OHO-Model-API ist das ge-
diese API-Komponente einen Interface-Monolithen darstellt. zielt möglich. Außerdem ist es sinnvoll, die Implementierung
Die fachliche Trennung gilt also nur für die Implementie- der Domänen-Objekte aus den fachlichen Komponenten in ei-
rung, nicht für die Deklaration der Schnittstellen. ne weitere technische Komponente OHO-Model-Impl heraus-
H Die fachlichen Abhängigkeiten sind im Quellcode weniger zuziehen. Abbildung 6 zeigt das Resultat dieses Umbaus. Mit
transparent, weil die fachlichen Abhängigkeiten nicht mehr der Version OHO 2.1 können die Domänen-Objekte aller fach-
durch die Analyse der technischen Abhängigkeiten ermit- lichen Komponenten überall instanziiert werden. Das hat den
telt werden können. Um die fachlichen Abhängigkeiten Vorteil, dass beim Schreiben von Tests Domänen-Objekte aus
aus dem Quellcode zu ermitteln, müssen die Referenzen fremden Komponenten (z. B. AuftragImpl.java in der Komponen-
der einzelnen Interface-Klassen in der API-Komponente te Horoskop) nicht gemockt werden müssen [MockO], sondern
gesucht werden oder die Spring-Konfiguration muss ana- einfach instanziiert werden können. Die Testbarkeit wird da-
lysiert werden. Mit einer modernen IDE ist das jedoch kein durch deutlich verbessert. Für die fachliche Offenheit spielt die
großer Aufwand. Zahl der technischen Komponenten keine Rolle. Entscheidend
H Für die Wiederverwendung einer Komponente reicht es ist nur, dass die fachlichen Komponenten keine technischen
nicht aus, die Komponente selbst in einen neuen Kontext Abhängigkeiten untereinander, sondern nur Abhängigkeiten
einzufügen, sondern es muss zusätzlich auch ihr API-Teil zu den technischen Komponenten haben.
aus der API-Komponente in den neuen Kontext eingebracht
werden. Aber zum einen gehört die Wiederverwendung
von Komponenten nicht zum Alltagsgeschäft und wird eher
selten durchgeführt, zum anderen dürfte eine gute Package-
Struktur in der API-Komponente diesen Zusatzaufwand mi-
nimieren. JavaSPEKTRUM ist eine Fachpublikation des Verlags:
Vorteile des fachlich offenen Dependency- SIGS DATACOM GmbH
Management Lindlaustraße 2c
53842 Troisdorf
Durch die Anwendung des fachlich offenen Dependeny-Ma- Tel.: 0 22 41/23 41-100
nagements ist es möglich, fachliche und technische Abhängig- Fax: 0 22 41/23 41-199
keiten vollständig und konsequent voneinander zu trennen. E-Mail: info@sigs-datacom.de
Damit wird dem Open-Closed-Prinzip [CCDOCP] im Depen- www.javaspektrum.de
dency-Management Folge geleistet. Neue fachliche Abhän-
gigkeiten können beliebig zwischen den Komponenten gezo-
gen werden, ohne technische Probleme und Umbaumaßnah-
men damit nötig zu machen. Das System ist offen für Erwei-
terungen.
Ein zweiter großer Vorteil besteht darin, dass die Entwickler
die Schnittstelle einer Komponente nach außen (das heißt zu
46 JavaSPEKTRUM 6/2012

7.  Fachthema
Fazit [KE] http://de.wikipedia.org/wiki/Komponentenbasierte_Entwicklung
[MavenIT] http://docs.codehaus.org/display/MAVENUSER/
Das fachlich offene Dependency-Management steht auf zwei Maven+and+Integration+Testing
Säulen: [MockO] http://de.wikipedia.org/wiki/Mock-Objekt
H Fachliche Komponenten haben untereinander keine tech- [Modul] http://de.wikipedia.org/wiki/Modul_%28Software%29
nischen Abhängigkeiten, sondern sind technisch nur von [Sinz99] E. J. Sinz, Anwendungssysteme aus fachlichen Kompo-
nicht-fachlichen Komponenten abhängig. nenten, Wirtschaftsinformatik, Ausgabe 1999-01,
H Im Maven-Build wird auf Integrationstests verzichtet, das http://www.wirtschaftsinformatik.de/index.php;do=show/site=wi/sid=451
heißt, beim Bau einer Komponente werden nur echte Unit- 6462854f98ee4a52c49550952029/alloc=12/id=427
Tests durchgeführt und Integrationstests werden erst ausge-
führt, wenn alle Komponenten gebaut wurden.
Die erste Säule entkoppelt die fachlichen und technischen Ab-
hängigkeiten zur Compile-Zeit, die zweite Säule zur Maven-
Build-Test-Runtime. Damit können fachliche Abhängigkei-
ten völlig frei von technischen Einschränkungen implemen-
tiert werden. Dieses fachlich offene Dependency-Management
überwindet vollständig die Dependency-Hölle des klassi- Dr. Reik Oberrath ist als IT-Berater bei der
schen Dependency-Managements und schenkt den Entwick- iks Gesellschaft für Informations- und Kommuni-
lern und Architekten ein kleines Stückchen Himmel in ihrem kationssysteme mbH tätig. Er beschäftigt sich seit
irdischen Alltag. vielen Jahren mit der Entwicklung von individuellen
Geschäftsanwendungen, speziell unter Swing und RCP.
Links Einen besonderen Fokus legt er auf Automatisierung
in der Qualitätssicherung und im Release Build sowie
[CCDDI] http://www.clean-code-developer.de/Gelber-Grad. auf Clean Code.
E-Mail: R.Oberrath@iks-gmbh.com
ashx#Dependency_Inversion_Principle_1
[CCDOCP] http://www.clean-code-developer.de/Gr%C3%BCner-Grad.
ashx#Open_Closed_Principle_0
[CCDSoC] http://www.clean-code-developer.de/Oranger-Grad.
ashx#Separation_of_Concerns_SoC_2
iks Gesellschaft für
Informations- und
Kommunikationssysteme mbH
Siemensstraße 27
40721 Hilden
www.iks-gmbh.com
www.javaspektrum.de 47

8. SONDERDRUCK
Notizen:
Individuelle IT-Konzepte
und Softwarelösungen
Softwareentwicklung
IT-Beratung
IT-Konzepte
Business Intelligence
iks Gesellschaft für
Informations- und
Kommunikationssysteme mbH
Siemensstraße 27
40721 Hilden
Telefon 0 21 03 - 58 72 -0
Telefax 0 21 03 - 58 72 -58
info@iks-gmbh.com
www.iks-gmbh.com
s
ik Gesellschaft für
Informations- und
Kommunikationssysteme mbH
48 JavaSPEKTRUM 6/2012