Benutzerspezifische Werkzeuge

Architekturmuster

Ein Architekturmuster bestimmt, wie ein Softwaresystem auf oberster Ebene in Komponenten unterteilt wird und wie diese verbunden werden.

Ein Architekturmuster legt die Grundstruktur eines Softwaresystems fest, während sich so genannte Entwurfsmuster implementierungsnah auf einzelne Teilaspekte einer Softwarearchitektur beziehen. Bei beiden Arten von Mustern wird versucht, wiederkehrende Entwurfsprobleme durch bewährte, rezeptartig formulierte Lösungen in den Griff zu bekommen, sofern der Kontext dies zulässt. Angestrebt wird, dem Softwaresystem eine gewünschte Eigenschaft wie z.B. Übersichtlichkeit, Wartbarkeit, Testbarkeit und Wiederverwendbarkeit der Teile zu vermitteln. Hierbei muss abgewogen werden, ob die durch Einsatz des Musters ggf. ausgelösten nachteiligen Konsequenzen, wie z.B. ein geringer Laufzeit-, Kommunikations- und Speicherplatz-Overhead, in Kauf genommen werden können. Der Übergang zwischen Architektur- und Entwurfsmustern ist fließend.

Die wichtigsten Architekturmuster lassen sich wie folgt in Kategorien unterteilen:

Basisstrukturierung:

  • Schichtenarchitektur: die Komponenten einer Anwendung werden übereinander angeordneten Schichten zugeteilt. Jede Komponente darf nur auf Komponenten der gleichen oder einer tieferen Schicht zugreifen. Die große Mehrheit der Anwendungen ist als Schichtenarchitektur organisiert.

  • Pipes und Filter: die Anwendung wird in Stufen unterteilt. Jede Stufe bezieht ihren Eingabestrom von der vorangegangenen und leitet ihre Ausgaben an die nächste Stufe weiter. Bei einem Filter muss im Gegensatz zu einer Pipe nicht zu jeder Eingabe auch eine Ausgabe erzeugt werden. Ein Compiler lässt sich beispielsweise als Pipe organisieren, bei der nacheinander Scanner, Parser, Semantische Analyse, Zwischencode-Generierung usw. durchlaufen werden.

Verteilung:

Bei den Mustern dieser Kategorie werden die Komponenten häufig unterschiedlichen Rechnern zugeordnet.

  • Client-Server: jede Komponente kann Dienstleistungen anderer Komponenten in Anspruch nehmen, um selber Dienstleistungen anbieten zu können. Ein Client erhält üblicherweise zu jeder Anfrage an einen Server eine Antwort.

  • Eine Serviceorientierte Architektur kann als Spezialfall einer Client-Server-Architektur angesehen werden. Ein Dienst (Service) bietet eine Menge aufeinander abgestimmter Funktionen, die von einem Client einzeln in geeigneter Reihenfolge in Anspruch genommen werden können. Parameter und Ergebnis einer aufgerufenen Funktion sind typischerweise Daten und nicht etwa Objekte (denen ein Verhalten zugeordnet ist). Dienste mit niedrigem Abstraktionsniveau können zu Diensten mit höherem Abstraktionsniveau zusammengesetzt werden.

  • Microservices können als Extremfall einer Serviceorientierten Architektur verstanden werden, bei der kleine, unabhängige Services über meist sprachunabhängige Schnittstellen verknüpft werden. Wenn einer von vielen Microservices ausfällt, so bleibt der Großteil des Systems meist einsatzfähig, wodurch eine erhöhte Resilienz gewährleistet werden kann.
  • Peer-to-Peer: die Komponenten sind gleichberechtigt und kommunizieren üblicherweise über Nachrichten. Im Gegensatz zur Client-Server-Architektur wird auf eine Nachricht keine Antwort erwartet. Falls eine Antwort erforderlich ist, müsste diese als separate Nachricht in der Rückrichtung verschickt werden. Das Peer-to-Peer-Muster wird außer bei Musikaustauschbörsen häufig im Bereich des High-Performance-Computing bei der parallelen Programmierung eingesetzt.

  • Broker: bei dieser speziellen Form von Client-Server-Architektur erfolgt die Vermittlung eines Servers an einen Client über einen so genannten Broker. Die prominenteste Nutzung dieses Musters stellt die Middleware CORBA (Common Object Request Broker Architecture) dar.

  • Blackboard: die Komponenten kommunizieren indirekt über ein gemeinsam genutztes schwarzes Brett. Dies ist einfach zu realisieren, aber wenig strukturiert.

Mensch-Computer-Interaktion:

  • Model-View-Controller: die Anwendung wird in die Teile Geschäftslogik und Daten (Model), Ergebnis-Präsentation (View) und Steuerung (Controller) gegliedert. Die Steuerung nimmt Benutzereingaben entgegen und veranlasst die passenden Operationen der Geschäftslogik.

Adaption:

  • Dependency Injection: die Konfiguration und Einbindung jeder Komponente wird nicht von der Komponente selbst sondern von einem externen Framework übernommen. Häufig werden Annotationen genutzt, um die gewünschte Konfiguration deklarativ im Code der Komponente zu beschreiben.

  • Reflexion: die Metainformationen von Komponenten sind zur Laufzeit zugänglich und können zu einer dynamischen Anpassung des Systems genutzt werden.

Weitere Muster zu den genannten Kategorien finden sich in der angegebenen Literatur. Verschiedene Muster können bei Bedarf kombiniert werden; insbesondere dann, wenn diese aus verschiedenen Kategorien stammen. Beispielsweise kann bei einer Client-Server-Architektur ein Server in Schichten unterteilt werden. Einige Autoren verwenden die Begriffe Architekturmuster und Architekturstil synonym, während andere hier kleine Unterschiede sehen.

Literatur

Buschmann Frank; Henney, Kevlin; Schmidt, Douglas C.: Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing, Volume 4, 2007.

Buschmann, Frank; Meunier, Regine; Rohnert, Hans; Sommerlad, Peter; Stal, Michael: Pattern-orientierte Softwarearchitektur. Ein Pattern-System. Addison-Wesley, 1998.

Fowler, Martin: Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.

Garlan, David; Shaw, Mary: An Introduction to Software Architecture. Research Access Inc., 1994.

Goll, Joachim: Architektur- und Entwurfsmuster der Softwaretechnik: Mit lauffähigen Beispielen in Java, 2., aktualisierte Auflage, Springer Vieweg Verlag, 2014.

Vogel, Oliver; et al.: Software-Architektur – Grundlagen – Konzepte – Praxis. Elsevier, 2008.

Wolff, Eberhard: Microservices: Grundlagen flexibler Softwarearchitekturen, dpunkt.Verlag, 2016.

Autor


 

Prof. Dr. Herbert Kuchen, Westfälische Wilhelms-Universität Münster, Institut für Wirtschaftsinformatik, Praktische Informatik in der Wirtschaft, Leonardo-Campus 3, D-48149 Münster

Autoreninfo


Letzter Abruf: 25.04.2017 04:54
Artikelaktionen