Langlebige Software-Architekturen (eBook)

2Aufspüren von technischen Schulden

Das Analysieren von technischen Schulden ist ein weites Feld. Es kann darum gehen, die auf Papier geplante Architektur eines Systems zu hinterfragen. Man kann Qualitätsziele für eine Architektur mit dem Kunden herausarbeiten und sie mit Szenarien konkretisieren, wie es die Architekturanalysemethode ATAM1 vorschlägt. Oder aber, die Analyse ist, so wie in diesem Buch, darauf ausgelegt, den Sourcecode eines oder mehrerer Systeme auf seine Langlebigkeit und seine technischen Schulden hin zu untersuchen.

Wie Software genau konstruiert sein muss, damit sie langlebig ist, wird in Kapitel 5 unser Thema sein. Damit Sie vorab einen Eindruck bekommen, was bei der Untersuchung von Sourcecode heute möglich ist, startet dieses Kapitel von der praktischen Seite: Nach der Einführung der Begriffe Baustein sowie Soll- und Ist-Architektur beginnen wir direkt mit der Architekturanalyse eines Beispielsystems. Außerdem werden typische Randbedingungen der Architekturanalyse beschrieben und Eigenarten von Programmiersprachen vorgestellt.

2.1Begriffsbildung für Bausteine

Metamodell für Bausteine

Die Begrifflichkeiten in unserer Disziplin sind in weiten Teilen leider nicht einheitlich. Für dieses Buch halten wir uns an die Sprachwelt von Gernot Starke [Starke 2020]: Alle Software- oder Implementierungselemente, die man in der Bausteinsicht finden kann, heißen Bausteine. Das Metamodell von Gernot Starke ist um einige in diesem Buch nicht verwendete Begriffe, wie Skript und Layoutdefinition, reduziert. Neu hinzugekommen ist die Kategorie Modellierungskonstrukt, damit auch Begriffe wie Schicht, Modul, Subsystem und Schnittstelle ihren Platz finden (s. Abb. 2–1).

Abb. 2–1Baustein als Oberbegriff für Software- und Implementierungselemente

Für die Programmierkonstrukte aus Abbildung 2–1 finden sich mit Ausnahme vom Begriff Paket in den jeweiligen Programmiersprachen Definitionen. Die anderen Begriffe aus Abbildung 2–1 bedürfen hier einer Definition, damit sie im weiteren Verlauf des Buches eindeutig sind2:

Programmierkonstrukt

• Paket

  Einerseits ein Oberbegriff für Packages und Namespaces, andererseits das Programmierkonstrukt, mit dem in ABAP Klassen und Programme zusammengefasst werden.

Modellierungskonstrukte

• Subsystem

  Eine Einheit mit eigenem Namen für eine Menge von Klassen/Interfaces, Paketen und/oder Subsystemen eines Softwaresystems. Häufig wird für Subsysteme eine Schnittstelle (s.u.) festgelegt.

• Komponente

  Im Kontext dieses Buches ist eine Komponente dasselbe wie ein Subsystem.

• Schicht

  Ein Subsystem, für das Regeln festgelegt sind, auf welche anderen Subsysteme es zugreifen darf und auf welche nicht. Durch die Regeln entsteht eine Hierarchie der Schichten (s. Abschnitt 6.3).

• Modul

  In diesem Buch ist ein Modul ein fachlicher Schnitt durch ein Softwaresystem, der über alle technischen Schichten verläuft (s. Abschnitt 6.3.2). In anderen Kontexten wird Modul als Synonym für Komponente oder Subsystem verwendet.

• Schnittstelle

  Eine Teilmenge, von den in einem Baustein enthaltenen Bausteinen, auf die von außerhalb zugegriffen werden darf. Die Schnittstelle eines Subsystems könnte beispielsweise aus einer Menge von Klassen und Interfaces oder auch aus einer Menge von Paketen bestehen.

Konstrukte der Entwicklungs-/Build-Umgebung

• Build-Artefakt

  Vom Build-System erstellte Einheiten, die in der Regel ausführbar und aufrufbar sind (z.B. JARs, WARs, DLLs, EXEs, OSGi-Bundles, Maven-Module).

• Projekt

  Von Entwicklungsumgebungen angebotene Organisationsmöglichkeiten für Sourcecode. Häufig entspricht ein Projekt einem Build-Artefakt.

• Directory

  Auf dem Dateisystem existierende Verzeichnisse, mit deren Hilfe Sourcecode sortiert werden kann.

Die Modellierungskonstrukte aus dieser Aufzählung werden wir im nächsten Abschnitt für die Soll-Architektur brauchen. Die anderen Begriffe hingegen sind in der Regel Teil der Ist-Architektur und werden von vielen Entwicklungsteams verwendet, um die Soll-Architektur im Sourcecode sichtbar zu machen.

2.2Soll- und Ist-Architektur

Dokumentation oder Archäologie

Will man die Architektur eines Softwaresystems untersuchen, so stehen verschiedene Quellen zur Verfügung. Zum einen hat das Entwicklungsteam die Architektur hoffentlich geplant und sie in Dokumenten festgehalten oder informell abgesprochen. Ist das nicht der Fall, dann kann man den Plan in der Analyse rekonstruieren. Man spricht dann auch von Software-Archäologie. Zum anderen hat das Entwicklungsteam das Softwaresystem implementiert und dabei die geplante Architektur umgesetzt. Die vom Entwicklungsteam geplante Architektur nennt man Soll-Architektur und die im Sourcecode implementierte Architektur ist die Ist-Architektur (s. Abb. 2–2).

Abb. 2–2Soll- und Ist-Architektur

Sourcecode = Ist-Architektur

Den Sourcecode selbst bezeichnet man als die Ist-Architektur – also die wirklich implementierte Architektur (s. Abb. 2–2). Ein großer Teil der Komplexität eines Softwaresystems, sowohl der essenziellen als auch der überflüssigen, findet sich in seinem Sourcecode und den dort implementierten Strukturen (s. Abschnitt 1.3.2). Der überflüssigen Komplexität im Sourcecode und in der Soll-Architektur geht dieses Buch auf den Grund.

Plan = Soll-Architektur

Die Soll-Architektur ist eine Abstraktion und Vereinfachung des wirklich implementierten Systems. Wichtig ist, dass die Soll-Architektur insbesondere die Bausteine (s. Abschnitt 2.1) festlegt, die im Sourcecode nicht zu finden sind, wie Komponenten, Subsysteme, Module und Schichten.

Ist-Architektur ≠ Soll-Architektur

In allen mir bekannten Fällen weicht die Ist-Architektur von der Soll-Architektur ab. Die Ursachen hierfür sind vielfältig (s. Abschnitt 1.3):

• Im Entwicklungsteam gibt es Missverständnisse oder Unkenntnis über die Soll-Architektur. Die Implementierung verletzt deshalb Vorgaben der Soll-Architektur.
• Fachliche und technische Details wurden bei der Planung der Soll-Architektur übersehen und die Soll-Architektur wurde nicht angepasst. In einem solchen Fall ist die Soll-Architektur möglicherweise überflüssig oder sollte weiterentwickelt werden.
• Konkurrierende Qualitätsziele, wie Performanz und lose Kopplung, werden erst spät im Entwicklungsprozess offensichtlich und sind im Sourcecode an verschiedenen Stellen unterschiedlich umgesetzt.

Auseinanderlaufen = Komplexität

Dieses Auseinanderlaufen von Ist-Architektur und Soll-Architektur erzeugt für das Entwicklungsteam Komplexität. Zum Teil ist diese Komplexität essenziell, weil die Soll-Architektur zu unscharf war und eine Anpassung der Soll-Architektur notwendig wäre. Zum Teil ist sie überflüssig, weil das Entwicklungsteam die Vorgaben der Soll-Architektur verletzt hat, obwohl eine andere Implementierung möglich gewesen wäre. Je nachdem, wie Soll- und Ist-Architektur im Verhältnis zueinander stehen, geht es in der Analyse eher darum, die Abweichungen zu finden, oder mehr darum, eine neue, bessere Soll-Architektur zu entwickeln.

Extraktion

Um Ist- und Soll-Architektur abzugleichen, benutzt man heute Analysewerkzeuge. Das Analysewerkzeug muss dazu mit Ist- und Soll-Architektur gefüttert werden. Die Ist-Architektur extrahiert das Analysewerkzeug aus dem Source- und/oder Bytecode des Systems. Dabei identifiziert es die vorhandenen Programmierkonstrukte, wie Klassen, Methoden, Variablen, Packages, Namespaces, aber auch Directories, Build-Artefakte und Projekte. Für all diese Elemente hält das Analysewerkzeug fest, welche Elemente in welchen Elementen enthalten sind. Außerdem extrahiert es die Benutzt- und Vererbt-Beziehungen zwischen allen Klassen und baut daraus ein Modell der Strukturen im Sourcecode (s. Abb. 2–3). Dieser Schritt der Extraktion erfolgt automatisiert und dauert je nach Größe des zu parsenden Systems zwischen wenigen Minuten und einigen Stunden.

Abb. 2–3Vorgehen bei der Architekturanalyse

Der Abgleich zwischen Soll- und Ist-Architektur, also die Architekturanalyse, besteht aus zwei weiteren...