Architekturmuster - Architektur und Entwurfsmuster der Softwaretechnik - page 288

5 Architekturmuster
Entwurfsmuster stellen feinkörnige Muster dar, während Archi-
tekturmuster grobkörnig sind. Architekturmuster lösen nicht ein
Teilproblem, sondern beeinflussen die Grundzüge der Architektur
eines Systems.
Die in diesem Kapitel vorgestellten Architekturmuster sind den Autoren in der Praxis
besonders oft begegnet. Sie können in die folgenden Kategorien - angelehnt an
[Bus98] - eingeteilt werden:
x Struktur eines Systems: Layers, Pipes and Filters,
x Adaptive Systeme: Plug-in,
x Verteilte Systeme: Broker, Service-Oriented Architecture,
x Interaktive Systeme: Model-View-Controller.
Es folgt eine kurze Übersicht über diese Muster:
Das Architekturmuster Layers (siehe Kapitel 5.1) schneidet die Architektur eines Sys-
tems in Schichten, wobei jede Schicht auf die Dienste der darunterliegenden Schicht
zugreifen kann (horizontale Schichtung eines Systems). Diese Architektur setzt
voraus, dass sich ein sinnvoller Ablauf ergibt, wenn ein Client die oberste Schicht des
Systems als Server ruft, diese in der Rolle eines Clients wieder die nächst tiefere
Schicht als Server usw. bis hin zur letzten Schicht.
Das Architekturmuster Pipes and Filters (siehe Kapitel 5.2) strukturiert in seiner
Grundform eine Anwendung in eine Kette von sequenziellen Verarbeitungsprozessen
(Filtern), die über ihre Ausgabe bzw. Eingabe gekoppelt sind: Die Ausgabe eines Pro-
zesses ist die Eingabe des nächsten Prozesses ( datenflussorientierte Architektur
eines Systems ). Diese Architektur macht Sinn, wenn sich ein System in eine Kette
von Prozessen gliedern lässt, wobei jeder Prozess das Ergebnis des vorangehenden
Prozesses übernimmt und weiterverarbeitet. Eine Pipe dient hierbei zur asynchronen
Entkopplung zweier benachbarter Prozesse.
Das Architekturmuster Plug-in (siehe Kapitel 5.3) strukturiert eine spezielle Anwen-
dung so, dass sie über Erweiterungspunkte in Form von Schnittstellen verfügt, an de-
nen Plug-ins, die diese Schnittstellen implementieren, vom Plug-in-Manager (unter
Verwendung der Laufzeitumgebung) instanziiert und eingehängt werden können. Die
Anwendung ist aber ohne diese zusätzlichen Erweiterungen lauffähig. Eine solche Ar-
chitektur lohnt sich, wenn die Basisanwendung ohne die Erweiterungen einem breiten
Anwenderkreis zur Verfügung steht und die speziellen Erweiterungen für bestimmte
Benutzergruppen gedacht sind.