Ralf Westphal - Zukunftssichere Architektur

EDITORIAL

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

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.

ImprintZukunftssichere Architektur Ralf Westphal published by: epubli GmbH, Berlin, www.epubli.deCopyright: © NMG ISBN: 978-3-8442-2272-2

Methodik des Softwarebaus

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.

Auf einen Blick

Ralf Westphalist freier Softwaretechnologievermittler im Bereich .NET-Softwarearchitektur. Er arbeitet als Fachautor, Coach/Berater und Referent auf Entwicklerevents. Sie erreichen ihn über www.ralfw.de. Inhalt:Beim Entwickeln von Software gibt es zu wenig allgemeingültige Regeln.Das kostet Zeit und Geld.Objektorientierung allein reicht nicht aus.Die Schachtelung von Komponenten würde weiterhelfen. dotnetpro.code:A0806Kolumne

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.