5.2.4 Architektur

Die Architektur eines Programms ist entscheidend für spätere Wartbarkeit und Skalierbarkeit, aber auch für den Austausch und die Wiederverwendbarkeit von Komponenten. Gewachsene Applikationen entsprechen oft nicht mehr der gewünschten Architektur, denn in bestimmten Situationen (z.B. unter Zeitdruck) werden Programmierer nachlässig und implementieren Funktionen an der falschen Stelle der vorhandenen Architektur. Hier ist es die Aufgabe des Software-Architekten diese Fehler zu erkennen und dagegen zu steuern, wenn er vorher keine Möglichkeiten hatte mit dem Programmierer zu sprechen. Die Architekturmuster lassen sich in vier Kategorien aufteilen.

Mud-To-Structure

Diese Muster sollen helfen ein existierendes Programm zu strukturieren, ohne von Anfang an neu beginnen zu müssen, dabei werden die vorhandenen Komponenten und Objekte des Systems neu organisiert. Die Funktionen des Programms werden so aufgeteilt, dass sie kooperieren können, aber logisch voneinander getrennt sind. Zu diesen Mustern gehören die Layer, Pipes und Filter.

Distributed Systems

Die aus dem Broker-Pattern bestehende Architektur befasst sich mit verteilten Ressourcen und Diensten im Netzwerk. Der Broker bietet einen Dienst an, der eine spezifizierte Schnittstelle auf eine Ressource (z.B. Datenbank) hat. Dieses Muster kommt vorrangig in Netzwerken zum Einsatz und dient auch dazu eine Migration durchzuführen, wobei das Programm hinter dem Broker ersetzt werden kann, ohne dass es Auswirkungen auf die den Broker benutzenden Client hätte.

Die Service Oriented Architecture (SOA) basiert oft auf Webservices, kann auch jede andere Art von Dienst sein. Die Komponenten sind über die Dienste lose gekoppelt. Ziel ist es den Zugriff auf die Daten wie bei der Objektorientierung zu kapseln und dem Dienst exklusives Schreib/Lese-Recht auf die Daten zu geben.

Um einen Dienst zu erstellen, ist bei existierender Geschäftslogik initial oft ein hoher Aufwand erforderlich, da die vorhandene Geschäftlogik in einen Service umgebaut werden muss. Der Aufwand hat jedoch den Vorteil, dass danach keine Geschäftslogik­redundanzen mehr auftreten und das IT-System flexibler ist, was zu niedrigeren Betriebskosten führt.

Interactive Systems

Muster dieser Kategorie strukturieren interaktive Programme, also Computer-Mensch-Schnittstellen. Diese Muster werden bei Anwendungen mit GUI (Graphical User Interface = grafische Benutzerschnittstelle) oder im Web benutzt. Das bekannteste Muster ist das Model-View-Controller (MVC) Muster, bei dem das Modell (Daten) und die View (Anzeige) strikt getrennt sind und der Controller die Aktionen des Menschen umsetzt und die Daten aus dem Modell auf die View bringt.

Ein weiteres ist das Presentation-Abstraction-Control (PAC) Muster, das die Nachteile des MVC versucht zu kompensieren. Dabei wird die View und das Model nicht getrennt sondern die View wird abstrahiert und das Model gibt die Editoren für bestimmte Felder selber mit, denn nach diesem Muster muss das Modell am besten wissen, wie der Editor auszusehen hat, für die geforderte Angabe.

Adaptable Systems

Diese Muster unterstützen vor allem die Erweiterungs- und Ausbaufähigkeit von Systemen. Das Microkernel-Muster bietet z.B. nur einige Grundfunktionen, dafür aber die Möglichkeit den Kernel mit Treibern zu erweitern, im Gegensatz zu monolithischen Kerneln, bei denen alle Treiber im Kernel selber laufen müssen. Das andere Muster heißt Reflection und bedeutet, dass man Informationen über das Objekt herausfinden kann. Bedeutung hat dies bei typsicherer Programmierung und bei der Persistenz (Datenhaltung).