20.2 Architekturmuster

Ein Architekturmuster stellt ein in der Praxis bewährtes Lösungsschema für die Konzeption von Softwaresystemen dar. Es zeigt, wie Systeme in bestimmte Teilsysteme gegliedert werden können, und beschreibt die Verantwortungsbereiche der einzelnen Teilsysteme sowie deren Zusammenwirken.

Schichtenmodell (allgemein)

Das Schichtenmodell gliedert ein Softwaresystem in Teilsysteme. Im Modell werden die einzelnen Teilsysteme als übereinander gestapelte Schichten dargestellt (vgl. Abb. 20-1). Mit Ausnahme der obersten Schicht stellen alle Schichten Dienste bereit, die von der jeweils unmittelbar darüberliegenden Schicht genutzt werden dürfen. Mit Ausnahme der untersten Schicht greifen alle Schichten auf Dienste der unmittelbar darunterliegenden Schicht zu. Mit Ausnahme der angebotenen Dienste ist die Struktur einer Schicht vor anderen Schichten verborgen (Geheimnisprinzip).

Vorteile

Das Schichtenmodell reduziert die Abhängigkeiten zwischen den Teilsystemen. Dies bietet unter anderem folgende Vorteile:

• Entwickler können an einer Schicht arbeiten, ohne dafür detaillierte Kenntnisse über den Aufbau anderer Schichten zu benötigen.
• Schichten können geändert order soger komplett ersetzt werden, ohne dass dies andere Schichten berührt. Ausgenommen sind hierfür lediglich die Dienste, die von der unmittelbar darüberliegenden Schicht genutzt werden. Änderungen in diesem Bereich können auch Anpassungen in der unmittelbar darüberliegenden Schicht erforderlich machen.

Durch die Wahl geeigneter Entwurfsmuster, wie zum Beispiel einer Fassade, kann so eine lose Kopplung zwischen den Schichten erreicht werden.

Drei-Schichten-Architektur

Die klassische Drei-Schichten-Architektur ist ein Standardmodell, das als Grundlage für zahlreiche Varianten und Weiterentwicklungen diente.

Präsentationsschicht

Die Präsentationsschicht (Benutzerschnittstelle, User Interface) stellt eine Benutzeroberfläche bereit, die für die Interaktion mit dem Benutzer verantwortlich ist. Sie nimmt Benutzereingaben entgegen, greift auf Dienste der Fachkonzeptschicht zu und zeigt dem Benutzer fachliche Daten an.

Als Benutzeroberfläche kann prinzipiell auch eine einfache Befehlszeile oder ein textbasiertes Menüsystem zum Einsatz kommen. In der Regel wird es sich jedoch um eine grafische Oberfläche handeln. Diese kann in Form von HTML-Seiten realisiert werden, die von einem Webserver dynamisch – zum Beispiel mit Hilfe von JavaServer Pages bzw. Servlets – generiert werden und anschließend im lokalen Webbrowser angezeigt werden. Alternativ kann die grafische Benutzeroberfläche auch vollständig auf dem Client realisiert werden – zum Beispiel mit Java Swing.

Fachkonzeptschicht

Die Fachkonzeptschicht (Applikationsschicht, Anwendungsschicht) hat die Aufgabe die an die Anwendung gestellten fachlichen Anforderungen umzusetzen.

Hierzu werden Fachklassen eingesetzt, die sich weiter in Entitätsklassen (entity class) und Steuerungsklassen (Geschäftsprozess-Klasse, control class) unterteilen lassen. Entitätsklassen bilden die Objekte der realen Welt ab, die für die fachliche Aufgabenstellung von Bedeutung sind (zum Beispiel Kunde, Auftrag, Artikel). Ihre Attribute enthalten alle relevanten fachlichen Daten. Steuerungsklassen dienen der Realisierung fachlicher Abläufe. Sie erzeugen Entitätsobjekte, modifizieren deren Attributwerte, behandeln Aussnahmen und stellen sicher, dass entweder alle Schritte eines Prozesses erfolgreich abgearbeitet werden oder der Ausgangszustand wiederhergestellt wird. [DUNK03, S. 32 ff.]

Außerdem enthält die Fachkonzeptschicht die Zugriffe auf die Datenhaltungsschicht, in der die jeweilige Form der Datenspeicherung realisiert wird [BALZ99, S. 372].

Datenhaltungsschicht

Die Datenhaltungsschicht (Persistenzschicht) ist für die dauerhafte Speicherung der Anwendungsdaten verantwortlich. Dies kann mit Hilfe von Dateien, zum Beispiel XML, JSON oder flachen Dateien¹ (z. B. CSV), realisiert werden oder mit einem objektorientierten bzw. relationalen Datenbanksystem.

Mehr-Schichten-Architektur

Viele Schichtenmodelle bauen auf der klassischen Drei-Schichten-Architektur auf. Im Folgenden werden beispielhaft zwei zusätzliche Schichten vorgestellt, die bei Bedarf das klassischen Drei-Schichten-Modell zu einem vier bzw. fünf Schichtenmodell erweitern können.

Fachkonzept-Zugriffsschicht

Die Präsentationsschicht erfüllt in einer Drei-Schichten-Architektur zwei unterschiedliche Aufgaben. Zum einen ist sie für die Interaktion mit dem Benutzer verantwortlich und zum anderen für die Kommunikation mit der Fachkonzeptschicht. Zur weiteren Entkopplung von Präsentationsschicht und Fachkonzeptschicht kann es sinnvoll sein die Kommunikation mit der Fachkonzeptschicht in eine eigene Fachkonzept-Zugriffsschicht auszulagern. [BALZ99, S. 375]

Die Präsentationsschicht muss Eingabewerte nun nicht mehr prüfen, sie gegebenenfalls in einen anderen Typ umwandeln und daraus Entitätsobjekte erzeugen. Stattdessen gibt sie die Eingabewerte direkt an die Fachkonzept-Zugriffsschicht weiter.

Da die logische Prüfung der Eingabewerte und Ausnahmebehandlungen nun nicht mehr in der Präsentationsschicht implementiert ist, ist es weniger aufwendig die Präsentationsschicht auszutauschen oder gleichzeitig verschiedene Benutzeroberflächen, wie zum Beispiel eine Weboberfläche und einen lokalen Swing-Client, anzubieten. Ein weiterer Vorteil liegt darin, dass sich Tests der Fachkonzept-Zugriffsschicht leichter automatisieren lassen als Tests der grafischen Benutzeroberfläche.

Datenzugriffsschicht

„Eine direkte Verbindung zwischen der Fachkonzeptschicht und der Datenhaltung kann zu Problemen führen. Die Fachkonzeptschicht muß dann neben ihrer eigentlichen Aufgabe - der Modellierung des Problembereichs - die Zugriffe auf die Datenhaltung durchführen. Die Lösung liegt in einer separaten“ Datenzugriffsschicht. [BALZ99, S. 376]

Die Datenzugriffsschicht stellt die Verbindung zur jeweiligen Datenquelle her und beschafft von dort die von der Fachkonzeptschicht angeforderten Daten. Anschließend übergibt sie die erhaltenen Daten an die Fachkonzeptschicht. Gegebenenfalls überführt sie die Rohdaten zuvor in eine von der Fachkonzeptschicht erwartete Form.

Strenge vs. flexible Trennung der Schichten

Grundsätzlich darf eine Schicht lediglich auf die Dienste der unmittelbar unter ihr liegenden Schicht zugreifen. Wird von dieser Regel abgewichen, indem eine Schicht auch auf Dienste von Schichten zugreift, die zwar unter ihr liegen, jedoch nicht direkt an sie grenzen, spricht man von einer flexiblen Trennung.

Eine strenge Trennung der Schichten reduziert Abhängigkeiten und macht zum Beispiel die Präsentationsschicht unabhängig von der Datenzugriffsschicht. Wird der Präsentationsschicht hingegen der direkte Zugriff auf Dienste der Datenzugriffsschicht erlaubt, erhöht dies die Flexibilität. Dieser Vorteil wird jedoch mit Einschränkungen im Bereich der Wartbarkeit, Änderbarkeit und Portabilität erkauft. Es muss daher in jedem Einzelfall abgewogen und entschieden werden, ob die strenge Trennung angewandt wird oder einer flexiblen Trennung der Vorzug gegeben wird.

Strikt einzuhalten ist jedoch der Grundsatz, dass eine Schicht nicht auf Dienste einer über ihr liegenden Schicht zugreifen darf. Dies schließt jedoch nicht aus, dass die Datenzugriffsschicht im Rahmen der Kommunikation mit der Fachkonzeptschicht Entitätsklassen nutzt. Soll auch das vermieden werden, darf die Datenzugriffsschicht ausschließlich Rohdaten bereitstellen und von der Fachkonzeptschicht nur primitive Datentypen beziehungsweise Strings erhalten.