SlideShare ist ein Scribd-Unternehmen logo
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
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
         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
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
           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
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
        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
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

Weitere ähnliche Inhalte

Andere mochten auch

IT und Telekommunikation im Care-Sector
IT und Telekommunikation im Care-SectorIT und Telekommunikation im Care-Sector
IT und Telekommunikation im Care-Sector
Peter Wolff
 
Big bang
Big bangBig bang
Big bang
checho98
 
Ciencias astronimicas
Ciencias astronimicasCiencias astronimicas
Ciencias astronimicas
Miguel Mastarreno Macías
 
Scratch
ScratchScratch
Scratch
checho98
 
Los animales
Los animalesLos animales
Los animales
AlexandraGuzman1982
 
Look camisetas
Look camisetasLook camisetas
Look camisetas
esmeralda_24
 
Guiaparaelaborarunplandecontingencias 110728200752-phpapp02
Guiaparaelaborarunplandecontingencias 110728200752-phpapp02Guiaparaelaborarunplandecontingencias 110728200752-phpapp02
Guiaparaelaborarunplandecontingencias 110728200752-phpapp02
Rosalin Rabines anticona
 
Jimena
JimenaJimena
Jimena
jimenazamora
 
Presentacion powert point recur audio fija
Presentacion powert point recur audio fijaPresentacion powert point recur audio fija
Presentacion powert point recur audio fija
tribunal041721
 
Sizes Of Different Planets, Stars Etc
Sizes Of Different Planets, Stars EtcSizes Of Different Planets, Stars Etc
Sizes Of Different Planets, Stars Etc
IIS
 
Planta de Cerveza Grassau es referencia mundial de Caspary Gmb H
Planta de Cerveza Grassau es referencia mundial de Caspary Gmb HPlanta de Cerveza Grassau es referencia mundial de Caspary Gmb H
Planta de Cerveza Grassau es referencia mundial de Caspary Gmb H
Marcelo Nuñez
 
Informe evento Buenos Aires
Informe evento Buenos AiresInforme evento Buenos Aires
Informe evento Buenos Aires
DBD Ideas Turisticas
 
Dii K4 St1 Reflexive Verbs
Dii K4 St1 Reflexive VerbsDii K4 St1 Reflexive Verbs
Dii K4 St1 Reflexive Verbs
fraubooth
 
Juegos olímpicos 1012 mateo velez
Juegos olímpicos 1012 mateo velezJuegos olímpicos 1012 mateo velez
Juegos olímpicos 1012 mateo velez
mateovelezz
 
Las once características de un buen programa para
Las once características de un buen programa paraLas once características de un buen programa para
Las once características de un buen programa para
max506
 
Estelle
EstelleEstelle
Estelle
heleneg
 
Was kommt nach dem ende der privatsphäre
Was kommt nach dem ende der privatsphäreWas kommt nach dem ende der privatsphäre
Was kommt nach dem ende der privatsphäre
Open Knowledge Maps
 
In Linz Beginnts
In Linz BeginntsIn Linz Beginnts
In Linz Beginnts
Fee63
 
Exoneraciones
ExoneracionesExoneraciones
Exoneraciones
Angela Legui
 

Andere mochten auch (20)

IT und Telekommunikation im Care-Sector
IT und Telekommunikation im Care-SectorIT und Telekommunikation im Care-Sector
IT und Telekommunikation im Care-Sector
 
Big bang
Big bangBig bang
Big bang
 
Ciencias astronimicas
Ciencias astronimicasCiencias astronimicas
Ciencias astronimicas
 
Scratch
ScratchScratch
Scratch
 
Los animales
Los animalesLos animales
Los animales
 
Look camisetas
Look camisetasLook camisetas
Look camisetas
 
Guiaparaelaborarunplandecontingencias 110728200752-phpapp02
Guiaparaelaborarunplandecontingencias 110728200752-phpapp02Guiaparaelaborarunplandecontingencias 110728200752-phpapp02
Guiaparaelaborarunplandecontingencias 110728200752-phpapp02
 
Jimena
JimenaJimena
Jimena
 
Vorschau iPhone App
Vorschau iPhone AppVorschau iPhone App
Vorschau iPhone App
 
Presentacion powert point recur audio fija
Presentacion powert point recur audio fijaPresentacion powert point recur audio fija
Presentacion powert point recur audio fija
 
Sizes Of Different Planets, Stars Etc
Sizes Of Different Planets, Stars EtcSizes Of Different Planets, Stars Etc
Sizes Of Different Planets, Stars Etc
 
Planta de Cerveza Grassau es referencia mundial de Caspary Gmb H
Planta de Cerveza Grassau es referencia mundial de Caspary Gmb HPlanta de Cerveza Grassau es referencia mundial de Caspary Gmb H
Planta de Cerveza Grassau es referencia mundial de Caspary Gmb H
 
Informe evento Buenos Aires
Informe evento Buenos AiresInforme evento Buenos Aires
Informe evento Buenos Aires
 
Dii K4 St1 Reflexive Verbs
Dii K4 St1 Reflexive VerbsDii K4 St1 Reflexive Verbs
Dii K4 St1 Reflexive Verbs
 
Juegos olímpicos 1012 mateo velez
Juegos olímpicos 1012 mateo velezJuegos olímpicos 1012 mateo velez
Juegos olímpicos 1012 mateo velez
 
Las once características de un buen programa para
Las once características de un buen programa paraLas once características de un buen programa para
Las once características de un buen programa para
 
Estelle
EstelleEstelle
Estelle
 
Was kommt nach dem ende der privatsphäre
Was kommt nach dem ende der privatsphäreWas kommt nach dem ende der privatsphäre
Was kommt nach dem ende der privatsphäre
 
In Linz Beginnts
In Linz BeginntsIn Linz Beginnts
In Linz Beginnts
 
Exoneraciones
ExoneracionesExoneraciones
Exoneraciones
 

Mehr von IKS Gesellschaft für Informations- und Kommunikationssysteme mbH

Es wird Zeit KI zu nutzen - Wie es mit Azure KI Services und .NET MAUI gelingt
Es wird Zeit KI zu nutzen - Wie es mit Azure KI Services und .NET MAUI gelingtEs wird Zeit KI zu nutzen - Wie es mit Azure KI Services und .NET MAUI gelingt
Es wird Zeit KI zu nutzen - Wie es mit Azure KI Services und .NET MAUI gelingt
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Thementag 2023 04 Lindern, heilen oder gar fit machen.pdf
Thementag 2023 04 Lindern, heilen oder gar fit machen.pdfThementag 2023 04 Lindern, heilen oder gar fit machen.pdf
Thementag 2023 04 Lindern, heilen oder gar fit machen.pdf
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Thementag 2023 05 Wer zu spät kommt, den bestraft das Leben - Modernisierung ...
Thementag 2023 05 Wer zu spät kommt, den bestraft das Leben - Modernisierung ...Thementag 2023 05 Wer zu spät kommt, den bestraft das Leben - Modernisierung ...
Thementag 2023 05 Wer zu spät kommt, den bestraft das Leben - Modernisierung ...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Thementag 2023 01 Mut zur Modernisierung - ein Praxisbeispiel.pdf
Thementag 2023 01 Mut zur Modernisierung - ein Praxisbeispiel.pdfThementag 2023 01 Mut zur Modernisierung - ein Praxisbeispiel.pdf
Thementag 2023 01 Mut zur Modernisierung - ein Praxisbeispiel.pdf
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Thementag 2023 03 Einführung in die Softwaremodernisierung.pdf
Thementag 2023 03 Einführung in die Softwaremodernisierung.pdfThementag 2023 03 Einführung in die Softwaremodernisierung.pdf
Thementag 2023 03 Einführung in die Softwaremodernisierung.pdf
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Thementag 2022 01 Verpassen Sie nicht den Anschluss.pdf
Thementag 2022 01 Verpassen Sie nicht den Anschluss.pdfThementag 2022 01 Verpassen Sie nicht den Anschluss.pdf
Thementag 2022 01 Verpassen Sie nicht den Anschluss.pdf
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Thementag 2022 04 ML auf die Schiene gebracht.pdf
Thementag 2022 04 ML auf die Schiene gebracht.pdfThementag 2022 04 ML auf die Schiene gebracht.pdf
Thementag 2022 04 ML auf die Schiene gebracht.pdf
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Thementag 2022 03 Ein Modell ist trainiert - und jetzt.pdf
Thementag 2022 03 Ein Modell ist trainiert - und jetzt.pdfThementag 2022 03 Ein Modell ist trainiert - und jetzt.pdf
Thementag 2022 03 Ein Modell ist trainiert - und jetzt.pdf
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Thementag 2022 02 Der Deutschen Bahn in die Karten geschaut.pdf
Thementag 2022 02 Der Deutschen Bahn in die Karten geschaut.pdfThementag 2022 02 Der Deutschen Bahn in die Karten geschaut.pdf
Thementag 2022 02 Der Deutschen Bahn in die Karten geschaut.pdf
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine LearningDaten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Erste Schritte in die neue Welt-So gelingt der Einstieg in Big Data und Machi...
Erste Schritte in die neue Welt-So gelingt der Einstieg in Big Data und Machi...Erste Schritte in die neue Welt-So gelingt der Einstieg in Big Data und Machi...
Erste Schritte in die neue Welt-So gelingt der Einstieg in Big Data und Machi...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Big Data und Machine Learning - Wer braucht das schon!?
Big Data und Machine Learning - Wer braucht das schon!?Big Data und Machine Learning - Wer braucht das schon!?
Big Data und Machine Learning - Wer braucht das schon!?
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Erste Schritte in die neue Welt - So gelingt der Einstieg in Big Data und Mac...
Erste Schritte in die neue Welt - So gelingt der Einstieg in Big Data und Mac...Erste Schritte in die neue Welt - So gelingt der Einstieg in Big Data und Mac...
Erste Schritte in die neue Welt - So gelingt der Einstieg in Big Data und Mac...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine LearningDaten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Big Data und Machine Learning - Wer braucht das schon!?
Big Data und Machine Learning - Wer braucht das schon!?Big Data und Machine Learning - Wer braucht das schon!?
Big Data und Machine Learning - Wer braucht das schon!?
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine LearningDaten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 

Mehr von IKS Gesellschaft für Informations- und Kommunikationssysteme mbH (20)

Es wird Zeit KI zu nutzen - Wie es mit Azure KI Services und .NET MAUI gelingt
Es wird Zeit KI zu nutzen - Wie es mit Azure KI Services und .NET MAUI gelingtEs wird Zeit KI zu nutzen - Wie es mit Azure KI Services und .NET MAUI gelingt
Es wird Zeit KI zu nutzen - Wie es mit Azure KI Services und .NET MAUI gelingt
 
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
 
Thementag 2023 04 Lindern, heilen oder gar fit machen.pdf
Thementag 2023 04 Lindern, heilen oder gar fit machen.pdfThementag 2023 04 Lindern, heilen oder gar fit machen.pdf
Thementag 2023 04 Lindern, heilen oder gar fit machen.pdf
 
Thementag 2023 05 Wer zu spät kommt, den bestraft das Leben - Modernisierung ...
Thementag 2023 05 Wer zu spät kommt, den bestraft das Leben - Modernisierung ...Thementag 2023 05 Wer zu spät kommt, den bestraft das Leben - Modernisierung ...
Thementag 2023 05 Wer zu spät kommt, den bestraft das Leben - Modernisierung ...
 
Thementag 2023 01 Mut zur Modernisierung - ein Praxisbeispiel.pdf
Thementag 2023 01 Mut zur Modernisierung - ein Praxisbeispiel.pdfThementag 2023 01 Mut zur Modernisierung - ein Praxisbeispiel.pdf
Thementag 2023 01 Mut zur Modernisierung - ein Praxisbeispiel.pdf
 
Thementag 2023 03 Einführung in die Softwaremodernisierung.pdf
Thementag 2023 03 Einführung in die Softwaremodernisierung.pdfThementag 2023 03 Einführung in die Softwaremodernisierung.pdf
Thementag 2023 03 Einführung in die Softwaremodernisierung.pdf
 
Thementag 2022 01 Verpassen Sie nicht den Anschluss.pdf
Thementag 2022 01 Verpassen Sie nicht den Anschluss.pdfThementag 2022 01 Verpassen Sie nicht den Anschluss.pdf
Thementag 2022 01 Verpassen Sie nicht den Anschluss.pdf
 
Thementag 2022 04 ML auf die Schiene gebracht.pdf
Thementag 2022 04 ML auf die Schiene gebracht.pdfThementag 2022 04 ML auf die Schiene gebracht.pdf
Thementag 2022 04 ML auf die Schiene gebracht.pdf
 
Thementag 2022 03 Ein Modell ist trainiert - und jetzt.pdf
Thementag 2022 03 Ein Modell ist trainiert - und jetzt.pdfThementag 2022 03 Ein Modell ist trainiert - und jetzt.pdf
Thementag 2022 03 Ein Modell ist trainiert - und jetzt.pdf
 
Thementag 2022 02 Der Deutschen Bahn in die Karten geschaut.pdf
Thementag 2022 02 Der Deutschen Bahn in die Karten geschaut.pdfThementag 2022 02 Der Deutschen Bahn in die Karten geschaut.pdf
Thementag 2022 02 Der Deutschen Bahn in die Karten geschaut.pdf
 
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine LearningDaten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
 
Erste Schritte in die neue Welt-So gelingt der Einstieg in Big Data und Machi...
Erste Schritte in die neue Welt-So gelingt der Einstieg in Big Data und Machi...Erste Schritte in die neue Welt-So gelingt der Einstieg in Big Data und Machi...
Erste Schritte in die neue Welt-So gelingt der Einstieg in Big Data und Machi...
 
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
 
Big Data und Machine Learning - Wer braucht das schon!?
Big Data und Machine Learning - Wer braucht das schon!?Big Data und Machine Learning - Wer braucht das schon!?
Big Data und Machine Learning - Wer braucht das schon!?
 
Erste Schritte in die neue Welt - So gelingt der Einstieg in Big Data und Mac...
Erste Schritte in die neue Welt - So gelingt der Einstieg in Big Data und Mac...Erste Schritte in die neue Welt - So gelingt der Einstieg in Big Data und Mac...
Erste Schritte in die neue Welt - So gelingt der Einstieg in Big Data und Mac...
 
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
 
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine LearningDaten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
 
Big Data und Machine Learning - Wer braucht das schon!?
Big Data und Machine Learning - Wer braucht das schon!?Big Data und Machine Learning - Wer braucht das schon!?
Big Data und Machine Learning - Wer braucht das schon!?
 
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine LearningDaten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
Daten / Information / Wissen - Möglichkeiten und Grenzen des Machine Learning
 
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
 

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

  • 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