Langlebige Software-Architekturen (eBook)

Technische Schulden analysieren, begrenzen und abbauen

Carola Lilienthal (Autor)

eBook Download: EPUB

2024 | 4. Auflage
319 Seiten
dpunkt (Verlag)
978-3-98890-137-8 (ISBN)

Infos

Das Standardwerk zur Softwarearchitektur - Schließt die Lücke zwischen Softwarearchitektur und Implementierung der Codebasis - Einfache und übersichtliche Strukturierung aller wichtigen Grundkonzepte im Bereich der Softwarearchitektur - Mit über 200 farbigen Bildern aus real existierenden Softwaresystemen und etlichen FallbeispielenJe nachdem, wo Sie gerade stehen, ob Sie ein neues Entwicklungsprojekt planen oder das Ausmaß an technischen Schulden in einem bestehenden System reduzieren wollen, in diesem Buch finden Sie die passenden Antworten, um zu verhindern, dass die Architektur Ihres Systems erodiert, die Komplexität zunimmt, ständig weitere technische Schulden entstehen und Wartung und Erweiterung immer aufwendiger werden. In diesem Buch zeigt Ihnen die Autorin, worauf Sie bei der Umsetzung der Architektur achten sollten und welche Prinzipien eingehalten werden müssen, damit Sie in Ihren Softwareprojekten langlebige Architekturen entwerfen oder Ihre bestehenden Systeme durch kleine und große Refactorings in langlebige Architekturen überführen können. Es werden Muster in Softwarearchitekturen und Mustersprachen sowie verschiedene Architekturstile erläutert und aufgezeigt, welche Vorgaben letztlich zu Architekturen führen, die für Entwickler noch gut durchschaubar sind. Mit über 200 farbigen Bildern aus real existierenden Softwaresystemen und etlichen Fallbeispielen werden schlechte und gute Lösungen verständlich und nachvollziehbar dargestellt. Empfehlungen und vielfältige Hinweise aus Praxisprojekten erlauben dem Leser einen direkten Transfer zu seiner täglichen Arbeit. In der 4. Auflage wurde dem Thema Modularity Maturity Index (MMI) ein eigenes Kapitel gewidmet und der Text inhaltlich so erweitert, dass der gesamte Algorithmus zur Berechnung des MMI zugänglich wird. Nun kann jedes Team den MMI für sein System selbst bestimmen.

Dr. Carola Lilienthal ist Geschäftsführerin der WPS - Workplace Solutions GmbH in Hamburg und verantwortet dort den Bereich Softwarearchitektur. Sie hat 1995 an der Universität Hamburg ihr Diplom in Informatik gemacht und dort zum Thema »Komplexität von Softwarearchitekturen« promoviert. Seit 2003 analysiert sie international im Auftrag ihrer Kund*innen die Architektur von Softwaresystemen und berät Entwicklungsteams, wie sie die Langlebigkeit ihrer Softwaresysteme verbessern können. Insgesamt hat sie mit ihrem Team über dreihundert Softwaresysteme zwischen 30.000 und 15 Mio. LOC in Java, C++, C#, ABAP, PHP und TypeScript untersucht. Besonders am Herzen liegt ihr die Ausbildung von Softwarearchitekt*innen und Entwickler*innen, weshalb sie aktives Mitglied im iSAQB, International Software Architecture Qualification Board, ist und ihr Wissen aus über 25 Jahren Softwareentwicklung regelmäßig auf Konferenzen, in Artikeln und bei Schulungen weitergibt.

Textauszug

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...

Produkt-Details

• Erscheint lt. Verlag: 16.4.2024
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik
• Schlagworte: Architekturanalyse • Architekturbewertung • Architekturstile • Architekturverbesserung • Clean Architecture • domain-driven design • Entwurfsprinzipien • Hexagonale Architekturen • Microservices • Modularity Maturity Index • Mustersprachen • Onion Architecture • Qualität • Softwarearchitektur • Technische Schulden • TypeScript
• ISBN-10: 3-98890-137-7 / 3988901377
• ISBN-13: 978-3-98890-137-8 / 9783988901378