Suche

Software-Architektur: Die Schönheit liegt im Inneren

Dr. Carola Lilienthal

(c) Shutterstock / Hirurg

In unserer täglichen Arbeit beim Programmieren haben wir mit komplexen Strukturen zu tun. Ein normales Softwaresystem von 250.000 Zeilen Code hat bereits um die 3.000 Klassen. Diese Klassen arbeiten auf die eine oder andere Weise zusammen, um die gewünschte Funktionalität zu realisieren. In diesen vernetzten Strukturen dürfen wir Fehler beheben und neue Funktionalität hinzufügen.

In unseren Entwicklungsumgebungen arbeiten wir auf einzelnen Source-Files. Wir lassen uns anzeigen, welche anderen Files alle unsere Funktionalität benutzen und können uns Vererbungsbeziehungen anzeigen lassen. Ein Blick auf die gesamte Struktur bekommen wir aber nicht. Häufig haben wir ein Diagramm der Architektur an der Wand hängen oder am Whiteboard gezeichnet. Aber all das sind nur Abbilder der Vorstellungen, die wir beim Entwickeln im Kopf haben. Die wirklichen Strukturen sehen möglicherweise ganz anders aus.

Ein Blick auf die zahlreichen verschiedenen Strukturen, die wir implementiert haben, kann uns viele Einsichten für unsere Arbeit bringen. Schauen wir uns einmal an, was man für bizarre Schönheiten in Softwaresystemen finden kann. Das folgende Bild stellt einen Klassenzyklus aus 463 Klassen dar. Jedes Rechteck steht für eine Klasse. An den verschiedenen Farben in unserem Bild kann man jeweils die Schicht erkennen, zu der die Klasse gehört. Der Zyklus erstreckt sich über insgesamt neun Schichten.

Bild1

Stellt man diese Struktur so dar, sieht sie erst einmal eigenartig schön aus. Bedenkt man aber, dass all diese Klassen einen stark gekoppelten Haufen bilden, dann kann einem angst und bange werden. An welchem Ende man auch immer anfasst, man hat das ganze Knäuel an der Angel. Stellen wir diese Struktur auf Schichten-Ebene dar, so bekommen wir ein ähnlich schmerzhaftes Bild. Hier sehen wir die neun technischen Schichten (Rechtecke) über die sich die Klassen des Zyklus verteilen. Die grünen Bögen auf der linken Seite stellen Beziehungen dar, die der Schichtung entsprechen. Die roten Beziehungen rechts und der eine gelbe Bogen gehen gegen die Schichtung.

Bild2

In diesem System hängen Klassen von der Oberfläche bis zu den Business-Objekten zusammen. Neue Funktionalität landet fast automatisch eher in diesem Zyklus als außerhalb. Das Knäuel wird mit der Zeit immer größer und die Schmerzen bei seiner Bearbeitung auch!

Welch ein Glück, wenn wir auf ein System mit Strukturen treffen, die aus geschichteten Komponenten bestehen! Auf den folgenden beiden Bildern sieht man links die technische Schichtung und rechts die anonymisierte fachliche Schichtung ein und desselben Systems. Je dunkelgrüner die Schichten, desto mehr Klassen sind in ihnen enthalten. Beide Strukturen sind fast verletzungsfrei. Die Beziehungen gehen alle auf der linken Seite von oben nach unten. Ein paar rote Beziehungen sind vorhanden, aber im Vergleich zum ersten System sind die Verletzungen absolut überschaubar.

Bildschirmfoto 2015-08-19 um 09.32.48

Solche Einsichten in die innere Schönheit oder die zu erwartenden Gruseligkeiten kann man mit einigen Tools erreichen: JDepend, XRadar, Sotograph, Sonargraph, Structure101, Lattix, Axivion Bauhaus Suite, Teamscale, Moose und viele mehr. Auf dem Software Architecture Summit in Berlin im September zeige ich Ihnen in meinem Workshop „Langlebige Softwarearchitekturen – technische Schulden beherrschen und abbauen“ wie man diese Strukturen bearbeitet, um Architekturen wieder zukunftsfähig zu machen.

Darüberhinaus wünschen wir uns natürlich auch noch auf ganz anderen Ebenen Schönheit: z.B. direkt im Sourcecode, wie dies der Artikel „Principles for programming beautiful code“ von Hartmut Schlosser tut.

Aufmacherbild: Closed decorative chest with old metal key von Shutterstock / Urheberrecht: Hirurg

Verwandte Themen:

Geschrieben von
Dr. Carola Lilienthal
Dr. Carola Lilienthal
Dr. Carola Lilienthal ist Senior-Softwarearchitektin bei der Workplace Solutions GmbH und Mitglied der Geschäftsleitung. Sie hat an der Universität Hamburg studiert und dort zum Thema „Komplexität von Softwarearchitekturen“ promoviert. Seit 2003 analysiert sie im Auftrag ihrer Kunden in ganz Deutschland regelmäßig die Architektur von Softwaresystemen und fasst das Ergebnis in Qualitätsgutachten sowie mit priorisierten Refactoring-Maßnahmen zusammen. Außerdem leitet sie seit 2000 Softwareprojekte von unterschiedlicher Größe im Banken-/Versicherungs- und Logistikbereich und berät das Management kleiner und mittelständischer Unternehmen bei der Entwicklung einer modernen IT-Strategie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.