Architektur-Manager

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

Kennen Sie eigentlich die inneren Abhängigkeiten ihrer Java-Projekte? Wissen Sie genau, welche Fremdprodukte Ihre Entwickler in Ihr Produkt einbinden? Wie sorgen Sie dafür, dass Ihre aufwendig entworfene Architektur von Version zu Version erhalten bleibt? Wie finden Sie architektonische Schwachstellen? Konkrete Antworten auf diese Fragen und mehr liefern moderne Werkzeuge zur Analyse der Architektur von Java-Programmen.

Ein ganz normales Java-Projekt besteht heutzutage aus einigen Dutzend Packages mit mehreren hundert Klassen und verwendet zehn bis zu zwanzig Fremdbibliotheken, die aus unterschiedlichsten Quellen stammen. In einem großen Projekt können sich diese Zahlen aber auch verzehnfachen. Bei diesen Mengen kann kein einzelner Entwickler den Überblick über die Verknüpfungen zwischen den Teilen des Ganzen behalten, sodass hier die Unterstützung professioneller Werkzeuge gefragt ist. Solche Werkzeuge zum Architektur-Management werden typischerweise in zwei Szenarien verwendet:

  • Die innere Struktur eines Projektes ist unbekannt und soll analysiert werden. Unter Umständen liegen das Projekt und seine Fremdbibliotheken nur als Bytecode vor.
  • Für ein laufendes Projekt soll die Einhaltung einer definierten Architektur kontinuierlich überprüft werden. Unter Umständen wird das Produkt von einer Fremdfirma entwickelt.

Die Fragen an das Architekturmanagement und die Anforderungen an das Werkzeug sind zahlreich und im Kasten „Kriterien für Architektur-Management-Werkzeuge“ dargestellt. Bevor wir uns aber den vier Produkten Lattix LDM, SonarJ, Sotograph und XRadar zuwenden, nehmen wir kurz den für das Management von Software-Architekturen zentralen Begriff der Metriken unter die Lupe und gehen auf die verschiedenen Modelltypen für Architekturen ein.

Kriterien für Architektur-Management-Werkzeuge
  • Welche Teile der Anwendung werden von welchen anderen Teilen verwendet bzw. verwenden diese? Mit „Teilen“ sind dabei die physischen Einheiten der Sprache Java gemeint, also Jar-Datei, Package und Type. Mit „verwenden“ sind dabei alle Möglichkeiten der Referenzierung gemeint, also Vererbung, Deklaration, Instanziierung etc.
  • Ist die Darstellung übersichtlich und navigierbar? Da die Menge der physischen Einheiten eines Java-Projekts in die Hunderttausende gehen kann (vor allem durch die Fremdbibliotheken), ist dies ein entscheidendes Kriterium.
  • Welche Anwendungteile werden nicht genutzt?
  • Welche werden intensiv genutzt, sodass Änderungen große Auswirkungen haben?
  • Welche Fremdbibliotheken sind eingebunden? Wo werden sie benutzt? Ist die Verwendung beabsichtigt?
  • Werden Fremdbibliotheken mit redundanter Funktionalität verwendet?
  • Welche Lizenzmodelle werden durch die Fremd-bibliotheken in die Anwendung hineingetragen?
  • Das Architekturmanagement muss die Defini-tion von Regeln ermöglichen, die festlegen, welche Teile der Anwendung welche anderen Teile benutzen dürfen. Solche erlaubten und verbotenen Abhängigkeiten können auf der Ebene der physischen Komponenten definiert werden.
  • Fortschrittlicher ist die Definition eines logischen Architekturmodells durch den Architekten. Die Architekturregeln werden dann auf logischer Ebene definiert und durch das Modell auf die physischen Einheiten abgebildet.
  • Sind die engen Koppelungen innerhalb der logischen Komponenten? Sind die Komponenten untereinander lose genug gekoppelt?
  • Gibt es zyklische Abhängigkeiten? Eine zyklische Abhängigkeit zwischen Komponenten macht aus diesen eine einzige logische Komponente.
  • Welche Möglichkeiten zur Auflösung von Architekturmängeln gibt es? Der analysierende Architekt möchte nun von seinem Werkzeug erfahren, wo und wie er mit seinen Refactoring-Maßnahmen ansetzen kann. Liefert das Werkzeug Hinweise für geeignete Refactoring-Maßnahmen?
  • Können Refactoring-Maßnahmen virtuell durchgeführt werden, um ihre Auswirkung auf die Gesamtarchitektur zu simulieren? So kann der Architekt im Vorfeld des Refactorings entscheiden, in welche Richtung die strukturellen Arbeiten am Projekt gehen sollen, um die gewünschte Entkoppelung zu erreichen.
  • Können simulierte Refactoring-Maßnahmen als Aufgabenliste abgelegt werden? Können diese Aufgaben an Ort und Stelle den Entwicklern zugewiesen werden?
  • Liefert das Werkzeug allgemeine Aussagen über die Qualität des Projekts, vor allem hinsichtlich seiner Wartbarkeit? Liefert es Kennzahlen zur Testabdeckung, Dokumentationsabdeckung, Einhaltung von Programmierrichtlinien, Metriken, Code-Duplizierung?
  • Können verschiedene Projektstände über die Zeit miteinander verglichen werden, um Trendanalysen der Kennzahlen zu liefern?
  • Kann das Werkzeug in den Arbeitsplatz des Entwicklers integriert werden? Am besten ist eine Integration in die IDE, sodass dem Entwickler Verletzungen von Architekturregeln noch vor dem Commit in das Repository gemeldet werden.
  • Kann das Werkzeug auch automatisiert ausgeführt werden? Dies ist Voraussetzung für eine Integration in den Build- oder QS-Prozess.
  • Produziert das Werkzeug Berichte, die sich über einen Browser betrachten lassen? Sind die Ergebnisse ausreichend visualisiert? Kann der Betrachter einen Drill-down vom Projektfokus bis auf Methodenebene durchführen? Sind verschiedene Kennzahlen einer Komponente ausreichend integriert dargestellt?
Metriken

Metriken sind eigentlich Algorithmen zur Berechnung von Kennzahlen von Systemen, oft aber werden auch die Kennzahlen selbst als Metriken bezeichnet. Software-Metriken vermessen Eigenschaften von Softwaresystemen. Einfache Metriken sind z.B. die Anzahl der Methoden einer Klasse, die Anzahl der abstrakten Klassen und Interfaces eines Packages oder die Anzahl der Codezeilen. Eine sehr aussagekräftige Metrik ist die zyklomatische Komplexität, die die Anzahl der möglichen Ausführungspfade innerhalb einer Methode misst: Eine If-Anweisung erhöht diese um zwei, eine switch-Anweisung um die Anzahl der case-Zweige plus des default-Zweigs usw.

Mit den modernen Werkzeugen ist die Ermittlung von Metrik-Kennzahlen sehr einfach geworden, schwierig geblieben ist die Frage ihrer Interpretation. Die Aussagekraft einer Kennzahl ist nicht nur von der Programmiersprache und der Projektgröße abhängig, sondern auch von der verwendeten Architektur. Beispielsweise wird die zyklomatische Komplexität mit der Überschaubarkeit und dadurch mit der Wartbarkeit einer Methode korreliert. Es wird behauptet, dass ab einer gewissen Anzahl von möglichen Ausführungspfaden in einer Methode diese so unübersichtlich ist, dass die Menge der Programmierfehler sprunghaft ansteigt. Die Frage ist natürlich, wo der Wert für diese Schwelle anzusetzen sei, denn er ist ja auch von den individuellen Fähigkeiten der Programmierer abhängig.

Zur Ermittlung des Schwellwertes einer Metrik wird ein existierendes Projekt zunächst einmal mit der Metrik vermessen. Als Nächstes werden die Methoden in der Reihenfolge ihrer Werte einem Code-Review unterzogen, wobei mit den maximalen Metrikwerten begonnen wird. Schon nach kurzer Zeit entwickelt sich dabei ein Gefühl, bei welchem Metrikwert eine Grenze zwischen „beherrschbar“ und „unüberschaubar“ besteht. Dieser Wert dient dann als Grundlage einer Architekturregel, z.B. dass keine Methode eine höhere zyklomatische Komplexität als 20 haben darf. Wenn dieser Fall eintritt, muss die Methode sinnvoll in Teilmethoden zerlegt werden. Architektur-Management-Werkzeuge können die Kennzahlen automatisch messen und Überschreitungen von Schwellwerten als Architekturregelverletzungen melden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -