Mehrschichtige Architektur

Früher wurde Software monolithisch entworfen, von Datenzugriff bis Benutzeroberflächen war alles fest miteinander verzahnt. Mit dem verstärkten Aufkommen der Client-Server-Architektur und objektorientierten Programmiersprachen verschwand das monolithische Entwurfsparadigma aber immer mehr aus der Softwareentwicklung. Software wird heutzutage mehrschichtig entworfen.

Für die spätere Wartbarkeit der zu entwickelnden Software ist ein guter Entwurf entscheidend, dieser charakterisiert sich durch die folgenden Eigenschaften:

• Systematisches Treffen von grundlegenden Entwurfsentscheidungen

• Realisierung einer drei- oder mehrschichtigen Architektur

• Einhalten von bewährten Entwurfs-Heuristiken und Standards

• Systematischer Einsatz von Entwurfsmustern

• Verwendung geeigneter Frameworks und Bibliotheken

Entwurfsentscheidungen

Bevor eine Software entworfen und später auch implementiert werden kann, gilt es einige grundlegende Entwurfsentscheidungen zu treffen. Dazu gehören unter anderem:

• Die Wahl der Plattform

  • Microsoft Windows Plattform

  • Sun's Java-Plattform

  • Eine Unix-artige Plattform (Linux, Solaris, BSD)

• Die Wahl der passenden (objektorientierten) Programmiersprache

  • Java

  • C#

  • C++

• Die Wahl des GUI-Frameworks

  • WindowsForms oder Windows Presentation Foundation für .Net

  • Eclipse RCP, SWT oder Swing für Java

  • Web-Oberfläche

• Die Wahl der Datenhaltung

  • Relationale oder objektrelationale Datenbank für grössere Datenmengen

    • Ermöglicht den gleichzeitigen Zugriff für mehrere Benutzer

    • Die Daten werden redundanzarm gespeichert

    • Die Wahrung der Datenkonsistenz wird auch nach Systemfehlern gewährleistet

    • Ermöglicht die zentrale Verwaltung der Zugriffsrechte

    • Ermöglicht die sofortige Ausführung von Abfragen

  • Objektserialisierung oder XML-Dateien für kleinere Datenmengen

• Verteilung der Anwendung auf verschiedene Systeme

  • Client

  • Server

Schichten-Architektur

Software wird heute mehrschichtig entworfen und implementiert. Im Folgenden werden einige grundlegenden Schichten-Architekturen erläutert.

Die Drei-Schichten-Architektur

Eine Drei-Schichten-Architektur (three-tier architecture) besteht aus den folgenden Schichten:

1. Einer GUI-Schicht

   • Benutzeroberfläche einer Anwendung

   • Dialogführung

   • Präsentation der Daten

   • Greift auf die Fachkonzeptschicht zu

2. Einer Fachkonzeptschicht

   • Funktionaler Kern der Anwendung

   • Greift auf die Datenhaltungsschicht zu

3. Einer Datenhaltungsschicht

   • Realisiert die jeweilige Form der Datenhaltung

Die Drei-Schichten-Architektur kann in zwei Ausprägungen auftreten:

1. Eine strenge Drei-Schichten-Architektur

   • Die GUI-Schicht darf nur auf die Fachkonzeptschicht zugreifen

     • Bessere Wartbarkeit, Änderbarkeit und Portablilität

2. Eine flexible Drei-Schichten-Architektur

   • Die GUI-Schicht darf auch auf die Datenhaltungsschicht zugreifen

     • Bessere Performance

Abbildung 1 zeigt eine strenge Drei-Schichten-Architektur, Abbildung 2 zeigt die flexible Version. Die Pfeile stellen die möglichen Zugriffe von der einen Schicht auf eine andere dar.

Abbildung 1: Strenge Drei-Schichten-Architektur

Abbildung 2: Flexible Drei-Schichten-Architektur

In beiden Fällen darf eine übergeordnete Schicht nur auf untergeordnete Schichten zugreifen. Das bedeutet, dass die Fachkonzept nie direkt auf die GUI-Schicht zugreifen darf. Nur durch diese strikte Trennung ist es überhaupt möglich, dass die GUI- und die Fachoknzeptschicht getrennt voneinander entwickelt und zu einem späteren Zeitpunkt einfacher ausgetauscht werden können.

Damit die GUI-Schicht aber dennoch an die Daten der Fachkonzeptschicht gelangen kann, gibt es folgende Möglichkeiten:

1. Polling

   • Die GUI-Schicht setzt ständig in gleichen Intervallen Abfragen an die Fachkonzeptschicht ab, um diese nach Änderungen abzufragen. Dieses Verfahren wirkt sich negativ auf die Performance aus, da unnötig viele Anfragen gestellt werden.

2. Indirekte Kommunikation

   • Die Verbindung zwischen GUI- und Fachkonzeptschicht kann mit dem Beobachter-Muster (observer pattern) realisiert werden. Dabei sind GUI- und Fachkonzeptschicht locker (technisch gesehen über ein Interface) miteinander gekoppelt, die einzelnen Schichten können nach wie vor einfach ausgetauscht werden.

Werden GUI- und Fachkonzeptschicht zu einer einzigen Schicht zusammengeführt, so ist die Rede von einer Zwei-Schichten-Architektur. Der Nachteil daran ist, dass die beiden Schichten fest miteinander verbunden sind und ein Austausch der Benutzeroberfläche oder des Fachkonzepts sehr mühsam durchzuführen ist. Diese Zwei-Schichten-Architektur wird heute in der Praxis kaum noch angewendet.

Zugriffsschichten

Bei grösseren und komplexeren Anwendungen lohnt es sich oftmals, wenn der Zugriff auf eine tiefer liegende Schicht von einer weiteren Zwischenschicht übernommen wird. Hierbei ist die Rede von sog. Zugriffsschichten.

Erweitert man eine Drei-Schichten-Architektur um Zugriffsschichten, so ist die Rede von einer Mehr-Schichten-Architektur (multi-tier-Architektur).

Zugriffsschicht auf das Fachkonzept

In einer Drei-Schichten-Architektur führt die GUI-Schicht streng genommen zwei Aufgaben aus:

1. Präsentation der Informationen

2. Kommunikation mit der Fachkonzeptschicht

Um diesem Sachverhalt auch im Entwurf gerecht zu werden, kann aus der GUI-Schicht eine weitere Schicht extrahiert werden; die Fachkonzept-Zugriffsschicht. Dabei kümmert sich die GUI-Schicht nur noch um die reine Präsentation der Daten, der Zugriff auf die Fachkonzeptschicht wird von der neuen Fachkonzept-Zugriffsschicht übernommen.

Auf diese Weise können die komplexeren Daten-Beziehungen innerhalb der Fachkonzept-Schicht für die GUI-Schicht verborgen werden. Zudem sind GUI und Fachkonzept so noch weniger aneinander gekoppelt, ein Austausch der GUI-Schicht würde in diesem Fall leichter fallen.

Zugriffsschicht auf die Datenhaltung

Die Kernaufgabe der Fachkonzept-Schicht ist die Ausführung der eigentlichen Geschäftslogik. Die Fachkonzept-Schicht muss sich jedoch auch um die Kommunikation mit der Datenhaltungsschicht kümmern. Soll die Datenhaltungsschicht ausgetauscht werden, so kann diese enge Kopplung zu Problemen führen.

Die Lösung dieses Problems liegt darin, dass aus der Fachkonzept-Schicht eine Datenhaltungs-Zugriffsschicht extrahiert wird. Diese kümmert sich um den Zugriff auf die Datenhaltung, die Fachkonzept-Schicht ist so noch lockerer mit der Datenhaltungsschicht gekoppelt, letztere kann somit leichter ausgetauscht werden. Die Fachkonzeptschicht kann die Daten somit in einer höheren Abstraktion verarbeiten, die Geschäftslogik wird weiter von technischen Details isoliert.

Weitere Architekturen

Es gibt eine Unzahl von weiteren Architekturen, den meisten davon liegt aber das Konzept aus der Drei-Schichten-Architektur zu Grunde. Mit zunehmender Grösse einer Anwendung muss diese immer weiter in Schichten aufgeteilt werden. Ansonsten würden die Schichten unübersichtlich gross werden.

Man sollte es mit der Anzahl der Schichten jedoch auch nicht übertreiben, ansonsten kann auf Dauer die Orientierung verloren gehen. Zudem verschlechtert sich die Performance mit jeder weiteren Schicht, eine Anfrage muss schliesslich jede einzelne Schicht passieren. Bei einfachen Anfragen wirken die einzelnen Schichten so als blosser „Durchlaufserhitzer“.

Entwurfsziele

Ob die gewählte Schichten-Architektur optimal für die jeweilige Anwendung ist, kann anhand folgender Entwurfsziele überprüft werden:

• Wiederverwendbarkeit

  • Jede Schicht besitzt eine präzise Schnittstelle.

  • Die Kommunikation mit dieser Schicht soll einzig und allein über diese Schnittstelle funktionieren können.

  • Eine Schicht kann so einfach in eine andere Anwendung integriert werden.

• Änderbarkeit/Wartbarkeit

  • Die internen Mechanismen einer Schicht sollen beliebig stark angepasst werden können, gegen aussen muss die Schicht aber immer das gleiche Verhalten aufweisen.

  • Dies kann nur durch lockere Kopplung und präzise definierte Schnittstellen erfolgen.

• Portabilität

  • Eine Schicht soll Daten für die darüber liegende Schicht so gut wie möglich abstrahieren.

  • Auch dieses Ziel kann nur unter der Verwendung von klar definierten und strikt eingehaltenen Schnittstellen erreicht werden.

Insgesamt soll also die Kommunikation zwischen den einzelnen Schichten auf ein Minimum reduziert werden. Diese Kommunikation muss zudem über klar definierte und möglichst schlanke Schnittstellen erfolgen.

Entwurfsheuristiken

Bei einer sog. Heuristik handelt es sich um eine allgemein gültige Vorgehensweise zur Lösung eines bestimmten Problems. Trifft man in der Softwareentwicklung auf ein Problem, so ist in der Regel schon ein anderer Entwickler auf ein vergleichbares Problem gestossen. Aus der Lösung dieser Probleme hat sich über die Jahre ein gewisser Erfahrungsschatz angesammelt.

Auch für den Entwurf einer Anwendung gibt es bestimmte Heuristiken. Wer einen qualitativ hochwertigen Softwareentwurf anstrebt, der sollte die folgenden Heuristiken berücksichtigen:

• Sichtbarkeit

  • Das Geheimnisprinzip realisieren

    • Öffentliche Attributen können überall benutzt werden.

    • Was benutzt werden kann, das wird auch benutzt.

    • Attribute sollen privat gehalten werden!

  • Das Verhalten von internen Operationen sollen verborgen werden

    • Die Schnittstelle soll möglichst schlank gehalten werden.

    • Gemeinsame Teilfunktionen sollen in private Operationen ausgelagert werden.

• Vererbung und Generalisierung

  • Generalisierungshierarchien flach halten

    • Bei einer tiefen Generalisierungshierarchie verschwindet schnell der Überblick.

    • Die Generalisierungshierarchie sollte nicht tiefer als sechs Ebenen sein.

  • Oberklassen sollen abstrakt sein

    • Konkrete Klassen sollen sich nur am Ende der Hierarchie befinden.

    • Mit der Verwendung von abstrakten Klassen bleibt man flexibler.

  • Gemeinsamkeiten so hoch als möglich in der Hierarchie einordnen

    • Attribute und Operationen, die in einer Oberklasse eingetragen sind, können in sämtlichen Unterklassen verwendet werden.

    • Man erspart sich so viele gleichartige Änderungen.

• Interaktion, Kopplung und Bindung

  • Die GUI-Schicht greift auf die Fachkonzeptschicht zu, aber nicht umgekehrt

    • Die GUI-Schicht ändert sich wahrscheinlicher, als die Fachkonzeptschicht.

    • Hier ist lockere Kopplung (z.B. durch das Beobachter-Muster) zu verwenden!

  • Minimierung der Kopplung zwischen den Klassen

    • Eine Klasse A soll nur die öffentlichen Elemente einer Klasse B verwenden!

  • Maximierung der Bindung innerhalb einer Klasse

    • Eine Klasse realisiert genau eine Art von Objekten.

  • Vermeidung der Switch-Anweisung

    • Switch-Anweisungen sind ein Indiz für fehlenden Polymorphismus.

    • Die Verwendung des Zustand-Musters schafft hier Abhilfe.

Referenzen

• Lehrbuch der Objektmodellierung

  • Autorin: Heide Balzert

  • Verlag: Spektrum Akademischer Verlag

  • ISBN-13: 978-3827402851