"Raus aus der Dependency Hölle" - ein Artikel der iks im JavaSPEKTRUM
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

"Raus aus der Dependency Hölle" - ein Artikel der iks im JavaSPEKTRUM

  • 2,097 views
Uploaded on

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. ...

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,097
On Slideshare
2,071
From Embeds
26
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 26

http://www.iks-gmbh.com 26

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 AusblickOpenJDK – 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ölleDas fachlich [include] 2. Auftraggeber- Daten erfassenoffene Dependency- 1. Neuen Auftrag erfassen Kunde [include] 3. Daten der Ziel- personen erfassenManagement 4. Horoskop [include] 5. Rechnungsan- ab V 1.2 erstellen weisungen erfassen AstrologeReik OberrathUnter den beiden Paradigmen komponentenorientierte Architektur 6. Rechnung [include] 7. Rechnung erstellen verschickenund 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 BuchhalterNetz von Abhängigkeiten zu tun, in dem es immer schwieriger wird,gegenseitige Abhängigkeiten und Abhängigkeitszyklen zu vermei- 9. Horoskop [include] 10. Kundenden: die Dependency-Hölle. Dieser Artikel zeigt, wie fachlich ent- freischalten informierenworfene Komponenten voneinander entkoppelt werden können, Abb. 1: OHO Use Case Diagrammsodass technische Beschränkungen die fachliche Komponentenbil-dung nicht mehr beeinträchtigen: das fachlich offene Dependency- Abb. 1: OHO-Use-Case-DiagrammManagement.Fallstudie: Online Horoskope Das klassische Dependency-ManagementE 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 referenziertDie 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 Artikelswerden im Kasten „Begriffserläuterungen“ zusammengefasst. Abrechnung HoroskopDie Webanwendung OHO, Version 1.0Die Astrologin „Starlet“ macht sich selbstständig und möch- Auftragte online einen Horoskop-Dienst anbieten. Sie beauftragt einekleine Software-Schmiede namens „Gut&Günstig“ (G&G), dieWebanwendung OHO zu entwickeln. Diese Anwendung solles Kunden (Auftraggebern) ermöglichen, die Erstellung einesHoroskops online sowohl zu beauftragen als auch das erstellteHoroskop nach erfolgter Zahlung abzurufen. Stammdaten Im Auftrag muss ein Auftraggeber alle nötigen Angabenzum Horoskop angeben: Kontoverbindung des Auftraggebersund 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: dieseerstellt 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 OHORatschläge in Sachen Liebe, Finanzen, usw.) auswählen. Aus 1.1 nötig, ist aber technisch nicht möglichden 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 baldAußerdem wird mit OHO die Rechnungsstellung abgewickelt so viel, dass sie sich ganz auf die fachliche Arbeit konzentrierenund nach Zahlungseingang das Horoskop online zur Verfü- möchte, d. h. auf die Erstellung der Horoskope. Sie stellt dengung gestellt (Abb. 1). Buchhalter „Billy“ ein, der sich um die Abrechnungen küm- Die G&G-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 dievon 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 alsdaten, 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 G&G-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 G&G-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 imwww.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 KomponenteHoroskop. Technisch würde das zu einem Abhängigkeitszykluszwischen den Komponenten Horoskop, Auftrag und Abrechnung Ausweg aus dem Abhängigkeitswirrwarrführen (s. Abb. 3). Das neue Abhängigkeitsdilemma wird vonden G&G-Entwicklern diskutiert und sie einigen sich auf fol- In dieser heißen Phase kommt ein neues Mitglied ins G&G-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 vonzeugt und alle für das Horoskop nötigen Auftragsdaten wer- der Implementierung zu trennen. Zu diesem Zweck soll eineden aus dem Auftrag in das Horoskop kopiert. Der Nachteil neue technische Komponente eingeführt werden, welche nurdieser 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 Komponentendie G&G-Entwickler in OHO 1.2 die neue benötigte Abhän- Abrechnung und Horoskop keine technische Abhängigkeit zurgigkeit 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 G&G-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 G&G-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 G&G-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öglichb) 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 G&G-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ängigkeitenDie 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 G&G-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. Alsum daraus Daten zu übernehmen oder mit aktuellen Daten ab- schnelle Lösung, um den Maven-Build wieder zum Laufen zuzugleichen. bekommen, wird der Auftragsucheservice in der Komponente Diese neue Anforderung stellt eine fachliche Abhängigkeit Abrechnung für die Testausführung gemockt [MockO]. Dieserder beiden Komponenten Abrechnung und Horoskop von der Auftragsucheservice-Mock beinhaltet keine FunktionalitätKomponente Auftrag dar. Jetzt sind die G&G-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 deraktuellen Dependency-Management diese Abhängigkeiten Maven-Build erfolgreich ausgeführt werden, aber der Integra-technisch nicht realisiert werden können. Die G&G-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 G&G-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-ManagementsDas Geschäft mit OHO 1.3 läuft so gut, dass Starlet sich ent- Fachliche Offenheit zur Compile-Zeitschließ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 zwardiesem 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 mehrAbrechnung. Außerdem planen die G&G-Entwickler für die ad- zwischen diesen fachlichen Komponenten. Die G&G-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 G&G-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 G&G-Entwickler die nötigen Abb. 5: Unterschiede zwischen OHO 1.4 und 2.0 Abhängigkeiten mit dem Maven-Scope „test“ konfigurierenAbb. 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 dera)  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 G&G-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 G&G-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 G&G-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 mehrereAbb. 6: OHO 2.1-Abhängigkeiten verschiedenen Gründen wurden wurdentechnische Komponenten (grau) nötig. Die Die fachlichen Komponenten haben habentechnische Komponenten (grau) nötig. fachlichen Komponenten (weiß) (weiß)untereinander keine (technischen) Abhängigkeiten mehr.mehr.fachliche Komponenteuntereinander keine (technischen) Abhängigkeiten Jede Jede fachliche Kompo- Das fachlich offene Dependency-Managementhat Abhängigkeiten zu allen drei technischen Komponenten. Die 1.4-Komponentenente hat Abhängigkeiten zu allen drei technischen Komponenten. Die 1.4-Kom-Tagesgeschaeft-API wurde in OHO-API in OHO-API umbenanntponente Tagesgeschaeft-API wurde umbenannt. Mit der fachlichen Offenheit sowohl zur Compile-Zeit als auch zur Maven-Build-Test-Runtime ist es möglich, fachliche undwww.javaspektrum.de 45
  • 6. Fachthema technische Abhängigkeiten vollständig voneinander zu ent- anderen Komponenten) bewusst formulieren müssen. Werdenkoppeln. Neue fachliche Abhängigkeiten durch neue Anfor- fachliche Abhängigkeiten durch technische Abhängigkeitenderungen, 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 vonwerden. Komponente A abhängig sind. Das verleitet Entwickler dazu, Die G&G-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 isthenden Ä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-Komponenteaus fremden Komponenten stehen dank der API-Komponente in Form einer Interface-Klasse bzw. in einer ihrer Methodennur 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 KomponentenKomponenten bei Bedarf die Funktionalität der Komponente hängen nicht direkt voneinander ab, sondern nur von ihrerAdministration 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 KomponentenNachteile des fachlich offenen Dependency- Häufig kann es sinnvoll sein, die große API-Komponente inManagements zwei oder mehrere technische Komponenten aufzuteilen. Bei- spielsweise lösen die G&G-Entwickler die Interface-Klassen ih-Als Nachteile sind folgende drei Punkte zu nennen: rer Domänen-Objekte (z. B. IAuftrag.java aus der KomponenteH 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. EntscheidendH 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 GmbHManagement Lindlaustraße 2c 53842 TroisdorfDurch die Anwendung des fachlich offenen Dependeny-Ma- Tel.: 0 22 41/23 41-100nagements ist es möglich, fachliche und technische Abhängig- Fax: 0 22 41/23 41-199keiten vollständig und konsequent voneinander zu trennen. E-Mail: info@sigs-datacom.deDamit wird dem Open-Closed-Prinzip [CCDOCP] im Depen- www.javaspektrum.dedency-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 Entwicklerdie Schnittstelle einer Komponente nach außen (das heißt zu 46 JavaSPEKTRUM 6/2012
  • 7.  FachthemaFazit [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+TestingSäulen: [MockO] http://de.wikipedia.org/wiki/Mock-ObjektH 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 derschen 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 seitirdischen 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.comashx#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.comwww.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 mbH48 JavaSPEKTRUM 6/2012