Zukunftssichere Architektur: So bauen Sie monolithische Anwendungen zu komponentenorientierten um

Von Ralf Westphal

Glücklich der, der auf der grünen Wiese eine neuen Anwendung planen und aufbauen darf. Angefangen von der Architektur bis hin zum Layout der Bedienoberfläche kann man dann den neuesten Standards gehorchen.
Nur leider gibt es viele Programme, die wunderbar ihren Dienst verrichten, neuen Anforderungen aber angepasst werden müssen. Eine Neuentwicklung will der Kunde nicht bezahlen, also muss man aus dem, was vorliegt, das beste machen.
Architekturspezialist Ralf Westphal zeigt Ihnen in diesem Buch, wie Sie vorgehen, wenn Sie so eine Anwendung weiterentwickeln müssen. Wartbarkeit ist das zentrale Thema. Und die erreicht man durch Auftrennung von Monolithen zu komponentenorientierten Anwendungen. Aber wie gehen Sie dabei vor? In Beispielen führt Sie Ralf Westphal Schritt für Schritt durch einen Prozess, an dessen Ende eine Anwendung steht, die sich aus vielen Komponenten zusammensetzt. Jede der Komponenten kann nun ausgetauscht werden, ohne das Gesamtsystem in Mitleidenschaft zu ziehen.
Einleitend erklärt der Autor auch noch in zwei Grundlagenartikeln, warum Regeln bei der Implementierung nur Vorteile brauchen und warum die Komponentenorientierung so viele Vorteile mit sich bringt.

• Sprache: Deutsch
• Herausgeber: epubli
• Erscheinungsdatum: 13. Juni 2012
• ISBN: 9783844222722

Buchvorschau

EDITORIAL

Im Wandel liegt die Kraft

Fasst man die zentrale Botschaft der Softwarearchitekten gleich welcher Schule zusammen, könnte sie folgendermaßen lauten:

Monolithische Anwendungen sind tot. Lang lebe die komponentenorientierte Architektur.

So einfach sich diese Botschaft auch anhört, steckt doch in ihr die Erfahrung mit alten und neuen Systemen. Erst dank der Verteilung von Funktionalität auf verschiedene voneinander getrennte Komponenten ist es möglich, auf Forderungen der Kunden und der Entwickler einzugehen.

Erweiterbarkeit: Software lebt. Sie muss sich den sich verändernden Anforderungen anpassen können. rst komponentenorientierte Systeme ermöglichen das auf einfache Weise.

Testbarkeit: Die Qualität einzelner Teile soll durch automatische Tests gesichert werden, auch oder gerade wenn an anderer Stelle umgebaut wird.

Refaktorisierbarkeit: Wer erweitert oder umbaut, der muss Teile der Software verändern. Je feingranula-rer dann die Struktur ist, umso weniger muss verändert werden, was nicht nur Zeit und Geld spart, sondern auch die Qualität nicht verringert:

Dieses DevBook soll Ihnen zeigen, wie Sie Architekturen aufstellen, die auch morgen noch Bestand haben, weil sie sich gegen Veränderungen nicht sperren. Zuerst einmal ist es wichtig, strikte Regeln einzuführen, die später dafür sorgen, dass leicht umgebaut werden kann. Dazu zählen Schnittstellen: Wer Schnittstellen sauber aufstellt, kann einzelne Komponenten ersetzen, ohne dass das System in Mitleidenschaft gezogen wird. Solche Schnittstellen sollten durch automatische Tests gesichert werden. Wer die Schnittstellen durch solche Tests komplett abdeckt, kann sich sicher sein, dass bei einer Veränderung alles noch geht.

Diese Vorbemerkungen legen den Grundstock für das zentrale Thema des Buchs: Umbau einer vorhandenen monolithischen Anwendung. Wie gehen Sie dabei vor? Wo fangen Sie an? Schließlich haben Sie es mit einem Wust an Klassen und Methoden zu tun, die Sie eigentlich alle verstehen müssten.

Aber Ralf Westphal nimmt Sie an die Hand und zeigt Ihnen schrittweise, wie Sie aus der Chaos-Struktur eine sauber strukturierte Anwendung bauen. Abhängigkeiten spielen dabei eine große Rolle. Erst wenn Sie verstanden haben, wer von wem etwas braucht, können Sie den Fitz aufdröseln.

Zum Schluss kommt eine Anwendung heraus, die nicht nur durch ihren Aufbau sehr schnell verstehbar ist. Sie ist auch gleich für künftige Anforderungen oder Änderungen bestens gerüstet.

Beim Zerschneiden helfen - wie oben schon erwähnt - immer wieder Unit-Tests, die Schnittstellen absichern. Diese aber in einer monolithischen Anwendung einzuführen, scheint auf den ersten Blick aussichtslos. Aber auch hier weiß Ralf Westphal Rat und zeigt Ihnen, wie Sie dabei vorgehen.

Viel Spaß beim Lesen und Studieren

Tilman Börner

Chefredakteur dotnetpro

Inhalt

Methodik des Softwarebaus: Mehr Regeln wagen

Wie ein Hausbau braucht auch die Entwicklung von Software Konventionen, um Qualität erreichen zu können.

Semantische Verträge: Doppelt genäht hält besser

Wer seine Software als Komponenten entwickelt, hat beim Outsourcing die Nase vorn.

Eine Architektur für Legacy-Code 1: Alter Code neu gebaut

Sie sollen eine Software auf das .NET Framework 3.5 migrieren. Dabei soll das Projekt auch architektonisch fit für die Zukunft werden.

Eine Architektur für Legacy-Code 2: Vom IST zum SOLL

Legacy-Code muss nicht vom Mainframe stammen. Auch .NET-1.0-Code gilt bereits als Vermächtnis von früher. Gehen Sie bei einer Migration systematisch vor!

Eine Architektur für Legacy-Code 3: Landkarten zeichnen

Mit den entsprechenden Werkzeugen ist es kein Problem, sich unbekanntem Code zu nähern.

Eine Architektur für Legacy-Code 4: Geschafft!

Im letzten Teil der Serie formen Sie mithilfe dieser Erkenntnisse ein neues Innenleben für die Software. Dabei machen Sie diese gleich fit für künftige Anpassungen.

Bestehende monolithische Anwendungen für Unit-Tests aufbereiten: Den Sumpf trockenlegen

Wer Software schreibt, sollte sie sofort auch selbst testen. Aber nicht irgendwie, sondern automatisiert mit Unit-Tests.

codekicker: Fragen und Antworten zur Architektur

Die wichtigsten Fragen und Antworten zur Softwarearchitektur aus der Wissensbörse codekicker.de.

Eine Monolith-Anwendung für Unit-Tests aufbereiten: Ein Sumpf wird grün

Eine bestehende monolithische Anwendung mit Unit-Tests nachzurüsten ist möglich. Separate Komponenten und Kontrakte - und schon sind Unit-Tests machbar.

Imprint

Zukunftssichere Architektur

Ralf Westphal

published by: epubli GmbH, Berlin, www.epubli.de

Copyright: © NMG

ISBN: 978-3-8442-2272-2

center

Methodik des Softwarebaus

Mehr Regeln wagen

Wie beim Hausbau braucht auch die Entwicklung von Software Konventionen, um Qualität erreichen zu können. Leider gibt es derzeit davon zu wenig. Mehr Konventionen würden den Entwickler besser leiten, ihm Arbeit und Entscheidungen abnehmen sowie mehr Zeit verschaffen, sich um das eigentliche Problemfeld der Software zu kümmern.

Stellen Sie sich vor, zwei einander unbekannte Softwareentwickler kommen über ihre Projekte ins Gespräch. Was würden sie wohl für Gemeinsamkeiten in der Realisierung ihrer Applikationen feststellen? Beide könnten für dieselbe Plattform entwickeln: Windows und .NET Framework; beide könnten an einer Anwendung derselben Art arbeiten, zum Beispiel eine Desktop- oder Webanwendung; beide könnten Daten in einer relationalen Datenbank speichern.

Und weiter? Sicherlich unterscheiden sich die Problemdomänen, an denen die Entwickler arbeiten. Der eine könnte eine CRM-Software und der andere Immobilienverwaltung schreiben. Sind also nicht mehr Gemeinsamkeiten bei zwei Softwareanwendungen zu erwarten?

Ein paar mögen noch unterhalb der Bewusstseinsschwelle liegen. Sie sind so natürlich, dass die beiden Softwareentwickler sie nicht für erwähnenswert halten. Zum Beispiel programmieren sie beide objektorientiert, zeichnen UML-Diagramme und halten die Normalisierung einer Datenbank für wichtig. Und natürlich haben ihre Anwendungen dieselbe Grundstruktur: Sie bestehen aus einer Benutzeroberfläche, greifen auf Infrastruktur zu und implementieren eine problemdomänenspezifische Logik.

Auf der Oberfläche der Anwendungen würde ein Laie sicherlich grundsätzlich dieselben Steuerelemente finden: Eingabefelder, Menüs, Schaltflächen, Tabellen. Aber darunter? Ist jenseits von Objektorientierung und einer groben Dreigliederung des Codes keine strukturelle Gemeinsamkeit mehr zu erwarten? Vermutlich nicht. Die beiden mögen vielleicht hier und da noch dieselben Entwurfsmuster einsetzen -doch darüber hinaus wird es kaum mehr Gemeinsamkeiten geben.

Jenseits der Werkzeuge und der durch sie vertretenen Konzepte herrscht wenig Konsens in der Softwareentwicklung. Compiler schaffen Gemeinsamkeit bei der Sprache mit ihrem fundamentalen Programmierparadigma. IDEs schaffen Gemeinsamkeit beim Aufbau von Benutzeroberflächen und der Quellcodegrundstruktur. Datenbanken schaffen Gemeinsamkeit bei der Datenorganisation.

Wo Werkzeuge oder Konzepte unbekannt oder nicht weit verbreitet sind, herrscht deshalb im Umkehrschluss keine Gemeinsamkeit; weder in der Vorgehensweise noch in Bezug auf die Produktion oder in Architekturfragen. Die Agilitätsbewegung bemüht sich zwar; Team Foundation Server & Co bemühen sich auch; aber es ist unwahrscheinlich, dass die beiden Entwickler in ihrem Gespräch hier schon viele Gemeinsamkeiten entdecken würden. Und noch unwahrscheinlicher ist es in Bezug auf den grundsätzlichen Aufbau ihrer Anwendungen, also ihre Architektur.

Diese Abwesenheit von Gemeinsamkeiten halte ich für überraschend und kontraproduktiv. Nach 50 Jahren Softwareentwicklungspraxis ist die Zahl der Gemeinsamkeiten zwischen zwei Anwendungen immer noch an einer Hand abzählbar. Das gibt es in keiner anderen Branche. Der Ruf nach Standards ist allerorten zu hören, von den Programmiersprachen über die Kommunikation bis zu Office-Dokumentenformaten; was den inneren Aufbau einer Anwendung angeht, verhallt er ungehört.

Das Resultat: geringe Produktivität. Denn wo kein Konsens herrscht, ist immer erst ein Weg zu bahnen. Das kostet Ressourcen.

Kreativer und produktiver mit Regeln

Mehr Konsens und mehr Systematik tun Not. Softwareentwicklung sollte in mehr Aspekten klaren Regeln und typischen Lösungen folgen, die in mindestens 80 Prozent der Fälle zu ausreichenden Implementierungen führen. Die Normalisierungsregeln für relationale Datenbanken sind dafür vielleicht das beste Beispiel: Sie machen klare Vorgaben, sind leicht umzusetzen, führen zu verständlichen Strukturen und sorgen für Wartbarkeit. In den meisten Fällen sind die sich daraus ergebenden Datenbanken auch effektiv genug. Falls nicht, ist es auch kein Verrat, eine Regel auch mal zu brechen. Den grundsätzlichen Konsens beeinträchtigt das nicht. Er hilft, den Kopf für das Wesentliche, die Problemdomäne, freizuhalten.

Ähnliches gilt auch für die Objektorientierung. Sie ist Konsens, was das allgemeine Programmierparadigma angeht. Dass zwei Entwickler für ein Problem unabhängig voneinander eine objektorientierte Sprache wählen, ist sehr wahrscheinlich. So wird es einfach, produktive Teams zusammenzustellen.

Entwurfsmuster haben das Ziel, Gleiches auf einer höheren Abstraktionsstufe zu wiederholen. Sie definieren ein Vokabular für wiederkehrende Probleme mit probaten Lösungen. MVC und Schichten sind vielleicht die bekanntesten Beispiele. Beide sind übersichtlich und leicht verständlich, beide haben ein klares Anwendungsgebiet. Beim Vorgehensmodell könnte Scrum [1] das Zeug dazu haben, ein konsensfähiges Minimalmuster zu werden.

Konventionen und Regeln bedeuten allerdings nicht sklavisches Befolgen. Sie sollen zunächst nur den Blick leiten und Ordnung in das Chaos bringen. Die schnelle 80-Prozent-Lösung ist ihr Zweck. Sie können selbstverständlich gebrochen werden. Denormalisierung ist nicht nur erlaubt, sondern manchmal einfach geboten. Wer allerdings eine Regel bricht, muss sich erklären. Und das ist gut so. Das schafft Bewusstsein und Verantwortungsgefühl für das, was man tut.

Mehr Regeln machen das Leben leichter, weil sie uns Entscheidungen abnehmen. Sie schaffen sogar Spielräume. Fragen Sie einen Künstler: Der wird Ihnen sagen, dass Kreativität von Beschränkung profitiert, ja, sie geradezu braucht.

Regeln sind auch konform mit der Philosophie der Lean Production und der Agilitätsbewegung, Entscheidungen so spät wie möglich zu treffen. Denn wer nach einer Regel handelt, der muss eigentlich noch