Devbook
29.06.2012, 15:09 Uhr
Zukunftssichere Architekturen
Architekturspezialist Ralf Westphal zeigt Ihnen in diesem Buch, wie Sie vorgehen, wenn Sie eine alte Anwendung weiterentwickeln und auf neue Anforderungen hin anpassen müssen. Wartbarkeit ist das zentrale Thema. In Beispielen führt Sie Ralf Westphal Schritt für Schritt durch einen Prozess, an dessen Ende eine fertige Anwendung steht.
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 Erfahrungmit 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. Erst komponentenorientierte Systeme ermöglichen das auf einfacheWeise.
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, dermuss Teile der Software verändern. Je feingranularer dann die Struktur ist, umso wenigermuss 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 auchmorgen noch Bestand haben, weil sie sich gegenVeränderungen nicht sperren. Zuerst einmal ist es wichtig, strikte Regeln einzuführen die später dafür sorgen, dass leicht umgebautwerden kann.Dazu zählen Schnittstellen:Wer Schnittstellen sauber aufstellt, kann einzelne Komponenten ersetzen, ohne dass das SysteminMitleidenschaft gezogen wird. Solche Schnittstellen sollten durch automatische Tests gesichert werden.Wer die Schnittstellen
durch solche Tests komplett abdeckt, kann sich sicher sein, dass bei einerVeränderung alles noch geht. DieseVorbemerkungen legen denGrundstock für das zentraleThema des Buchs:Umbau einer vorhandenen monolithischen Anwendung.Wie gehen Sie dabei vor?Wo fangen Sie an? Schließlich haben Sie es mit einemWust an Klassen undMethoden zu tun, die Sie eigentlich alle verstehenmüssten. Aber RalfWestphal 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 wemetwas braucht, können Sie den Fitz aufdröseln. ZumSchluss 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. BeimZerschneiden helfen – wie oben schon erwähnt – immer wieder Unit-Tests, die Schnittstellen absichern. Diese aber in einermonolithischen Anwendung einzuführen, scheint auf den ersten Blick aussichtslos. Aber auch hier weiß RalfWestphal Rat und zeigt Ihnen, wie Sie dabei vorgehen.
Viel Spaß beimLesen und Studieren
Tilman Börner
Chefredakteur dotnetpro
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 Erfahrungmit 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. Erst komponentenorientierte Systeme ermöglichen das auf einfacheWeise.
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, dermuss Teile der Software verändern. Je feingranularer dann die Struktur ist, umso wenigermuss 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 auchmorgen noch Bestand haben, weil sie sich gegenVeränderungen nicht sperren. Zuerst einmal ist es wichtig, strikte Regeln einzuführen die später dafür sorgen, dass leicht umgebautwerden kann.Dazu zählen Schnittstellen:Wer Schnittstellen sauber aufstellt, kann einzelne Komponenten ersetzen, ohne dass das SysteminMitleidenschaft gezogen wird. Solche Schnittstellen sollten durch automatische Tests gesichert werden.Wer die Schnittstellen
durch solche Tests komplett abdeckt, kann sich sicher sein, dass bei einerVeränderung alles noch geht. DieseVorbemerkungen legen denGrundstock für das zentraleThema des Buchs:Umbau einer vorhandenen monolithischen Anwendung.Wie gehen Sie dabei vor?Wo fangen Sie an? Schließlich haben Sie es mit einemWust an Klassen undMethoden zu tun, die Sie eigentlich alle verstehenmüssten. Aber RalfWestphal 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 wemetwas braucht, können Sie den Fitz aufdröseln. ZumSchluss 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. BeimZerschneiden helfen – wie oben schon erwähnt – immer wieder Unit-Tests, die Schnittstellen absichern. Diese aber in einermonolithischen Anwendung einzuführen, scheint auf den ersten Blick aussichtslos. Aber auch hier weiß RalfWestphal Rat und zeigt Ihnen, wie Sie dabei vorgehen.
Viel Spaß beimLesen und Studieren
Tilman Börner
Chefredakteur dotnetpro
Jetzt 1 Monat kostenlos testen!
Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde.
- + Digitales Kundenkonto,
- + Zugriff auf das digitale Heft,
- + Zugang zum digitalen Heftarchiv,
- + Auf Wunsch: Weekly Newsletter,
- + Sämtliche Codebeispiele im digitalen Heftarchiv verfügbar