Java-Architektur-Management: vier leistungsfähige Werkzeuge vorgestellt
Kommentare

Physisches und logisches Architekturmodell
Die physische Architektur einer Java-Anwendung besteht aus den in der Java Language Specification definierten syntaktischen Sprachstrukturen Package,­ Compilation

Physisches und logisches Architekturmodell

Die physische Architektur einer Java-Anwendung besteht aus den in der Java Language Specification definierten syntaktischen Sprachstrukturen Package,­ Compilation Unit, Type (Class oder Interface), Method und Variable. Ein Package wird auf ein Dateiverzeichnis abgebildet, eine Übersetzungseinheit auf eine Datei. Als weitere Struktur eines physischen Modells kommt noch die Java-Archive-Datei (Jar) hinzu. Da die Verschachtelung von Packages auf Verzeichnisse und Unterverzeichnisse abgebildet wird, entspricht die physische Struktur einer Java-Anwendung einem oder mehreren Bäumen. Das Archivieren in Jar-Dateien ist allerdings unabhängig davon, so können z.B. verschiedene Jar-Dateien verschiedene Klassen desselben Packages enthalten; ein Vorteil, den man sich bei der Abtrennung von Unit-Tests, Mock-Objekten oder generierten Klassen zunutze macht.

Eine logische Architektur erweitert die syntaktischen Einheiten von Java um semantische (sinntragende) Einheiten wie Subsysteme, technische Schichten und fachliche Schnitte. Für diese logischen Einheiten gibt es nach heutigem Stand keine verbindliche Sprachdefinition, deshalb ist es wichtig, dass das Managementwerkzeug eine solche möglichst mächtige Definition mitbringt. Der Architekt kann damit ein logisches Modell der Architektur seiner Anwendung entwerfen. Für den Entwurf einer logischen Architektur gibt es bewährte Muster, das maßgebende Leitbild dafür ist die Trennung von Verantwortlichkeiten (Separation of Concerns):

  • Technisch sinnvoll unterscheidbare Funktionen können in horizontalen Schichten von Subsystemen organisiert werden (z.B. grafische Benutzeroberfläche, Geschäftslogik, Transaktionen, Datenzugriff, Backend-Systeme)
  • Fachliche Bereiche können unabhängig von den Schichten in vertikalen Schnitten organisiert werden (z.B. Kundenverwaltung, Warenverwaltung, Bestellwesen)
  • Technische Dienste und fachliche Objekte können als lose gekoppelte Subsysteme dargestellt werden. Ein Subsystem liegt in genau einer technischen Schicht und eventuell innerhalb eines fachlichen Schnittes.
  • Subsysteme können ineinander verschachtelt sein (nach dem Composite-Muster).
  • Zwischen den Schichten und unter den Schnitten sind Regeln definiert, in welche Richtung Subsysteme einander benutzen dürfen (z.B.: Darstellungsschicht benutzt Geschäftslogikschicht; oder: Subsystem Kunde benutzt Subsystem Logging, aber nicht umgekehrt).

Ist das logische Modell definiert, kann der Architekt das physische Modell darauf abbilden. Auch hierfür gibt es keine festen Regeln, sondern nur bewährte Muster:

  • Ein Subsystem besteht aus mindestens einer Übersetzungseinheit.
  • Eine Übersetzungseinheit gehört zu höchstens einem Subsystem.
  • Ein Package sollte höchstens einem Subsystem zugeordnet sein usw.

Sind alle Klassen, Interfaces und Packages auf logische Strukturen abgebildet, kann das Werkzeug überprüfen, ob das physische Modell die Architekturregeln des logischen Modells einhält. Regelverstöße werden als Architekturverletzungen bezeichnet. Sie können nur durch Änderungen der Vorschriften des logischen Modells oder durch Refactoring des Quellcodes behoben werden.

Lattix LDM

Lattix LDM ist ein Produkt der amerikanischen Firma Lattix. Es besteht aus einem Stand-alone-Programm, einem Eclipse-Plug-in und einer Build-Server-Komponente.

Lattix baut auf dem Verfahren der Dependency-Structure-Matrix auf. Die­se Methode zur Analyse und Visualisierung von Abhängigkeiten in Form einer Matrix wurde bereits für das Projektmanagement in großen Luftfahrtprojekten verwendet und von der Firma Lattix auf das Software-Architektur-Management übertragen. Alle physischen Einheiten der analysierten Anwendung erscheinen jeweils als Spalten und Zeilen einer Matrix. Jede Zelle markiert die Abhängigkeiten zwischen zwei Einheiten, wobei die angezeigte Stärke der Abhängigkeit als Menge der Referenzen berechnet wird. Wird ein Projekt als Sammlung von Jar-Dateien eingelesen, können auf diese Weise die Abhängigkeiten zwischen den Bibliotheken analysiert werden. Jede Spalte und Zeile kann von der Jar-Datei-Ebene über die Package-Ebene bis auf die Typebene aufgefächert werden. Durch dieses Drill-down-Prinzip der Matrix kann unabhängig von der Größe des Projekts jedes Detail schnell angesprungen werden und trotzdem bleibt der Gesamtumfang jederzeit im Blick.

In Lattix ist ein Subsystem nach dem Composite Pattern definiert, d.h., ein Subsystem kann weitere Subsysteme enthalten. Auf der obersten Ebene kann jede Java-Archive-Datei als ein Subsystem betrachtet werden, auf der untersten Ebene jede einzelne Java-Datei. In den Ebenen dazwischen ist ein Subsystem identisch mit einem Zweig des Package-Pfades. So enthält z.B. das Subsystem „com.exam­ple“ alle Compilation Units, deren Pa­ckage-Pfad mit „com.example“ beginnt. Ein logisches Architekturmodell existiert in Lattix also immer innerhalb der Strukturen des physischen Modells.

Bei zyklischen Abhängigkeiten zwischen mehreren Subsystemen müssen diese aus logischer Sicht wie ein einziges Subsystem behandelt werden. Lattix sortiert die Matrix, sodass solchermaßen gekoppelte Subsysteme als Einheit angezeigt werden. Die Definition von Architekturregeln erfolgt innerhalb der Abhängigkeitsmatrix. In jeder Zelle der Matrix können mithilfe des Kontextmenüs erlaubte und verbotene Abhängigkeiten definiert werden. Diese Definitionen werden ebenso wie ihre Verstöße als farbige Ecken der Tabellenzellen angezeigt. Das Werkzeug gibt Hinweise zu sinnvollen Refactoring-Maßnahmen. Diese können virtuell durchgeführt und in einer To-do-Liste gesammelt werden. Eine weitere Anwendung von Lattix ist das Server-Modul LDC, das HTML-Berichte über die Regelverletzungen und Metriken generiert. Zu den großen Stärken von Lattix gehört die schnelle Analyse großer Mengen von Code sowie die unglaubliche Übersichtlichkeit durch die Dependency-Matrix. Für die gelungene Einführung des Dependency-Matrix-Verfahrens in das Architektur-Management hat Lattix den Jolt Award 2006 erhalten.

Abb. 1: Die Dependency-Matrix von Lattix
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -