Schichtenmodell

 

Wer schon mal ein größeres Softwareprojekt durchgeführt hat, weiß: je komplexer das Projekt, desto mehr Gedanken muß der Programmierer über die Struktur seines Softwareprojekts anstellen, um zum einen effektiv arbeiten zu können und zum anderen das entstehende Programm robuster und fehlerärmer zu gestalten. Dieses Gebiet der Softwareentwicklung wird als Softwarearchitektur bezeichnet. Es gibt in der Softwarearchitektur vielerlei Aspekte; für unsere Zwecke spielen die meisten kaum eine Rolle, weshalb wir hier auf eines fokussieren wollen.

Eines der gängigsten Architekturmuster ist das Schichtenmodell. Es ist für eine Vielzahl von Programmieraufgaben anwendbar. Kerngedanke ist, die im Quelltext enthaltene Funktionalität zu klassifizieren und entsprechend zu gruppieren. Es ist Ziel des Schichtenmodells, zwecks Klarheit und Übersichtlichkeit keine beliebigen Zugriffe zwischen den Gruppen zu erlauben. Die Funktionalitätsgruppen werden so angeordnet, daß lediglich Zugriffe zwischen benachbarten Gruppen in zwei Richtungen möglich sind - daher die Schichten und nicht etwa eine andere Topologie.

Dazu ein Beispiel. In einer astronomischen PC-Anwendung könnte der Quelltext in drei Schichten organisiert werden:

- Schicht 1 enthält sämtliche Elemente für die graphische Benutzeroberfläche - außerhalb dieser Schicht wird keinerlei Code für die Oberfläche auftauchen. Schicht 1 nimmt sämtliche Benutzeraktionen (Eingaben, Selektionen, Schaltflächenaktionen) entgegen und stellt ebenso sämtliche Ausgaben (Text und Grafik) dar. Weitere Funktionalität findet in dieser Schicht nicht statt!

- Schicht 2 vereint sämtliche Programmlogik. Die Programmlogik spiegelt den eigentlichen Zweck der Anwendung wieder und beinhaltet die Verarbeitung sämtlicher Daten (Algorithmen) und die Verwaltung der Programmzustände.

- Schicht 3 wird auch die Persistenzschicht genannt. Sie ist für die Datenhaltung (speichern, laden, aufbereiten) verantwortlich. Hier wird festgelegt, wohin die Daten geschrieben oder gelesen werden (Datei, Datenbank, Schnittstelle, ...) und wie die Daten für die Zugriffe aufbereitet werden. Wechselt man z.B. für ein neues Progamm-Release vom Dateisystem auf eine Datenbank, so braucht man nur den Code für die Schicht 3 anzufassen.

Die Schichten können idealerweise nur mit ihren unmittelbaren Nachbarn kommunizieren, d.h. eine Kommunikation zwischen Schicht 1 und Schicht 3 ist unzulässig. Dies würde hier auch bedeuten, daß die Benutzeroberfläche an der Programmlogik vorbei auf Daten zugreift - ein gefährliches Unterfangen, das die Konsistenz der Daten und Programmzustände gefährden kann.

Viele Softwareprojekte passen in dieses Schema Oberfläche-Programmlogik-Datenhaltung und lassen sich wie oben skizziert gliedern. Der Gewinn besteht darin, daß die Funktionalitäten voneinander separiert und zugleich zentralisiert werden, was die Programmierung erleichtert. Wenn es zweckmäßig ist, können natürlich auch weitere Schichten eingezogen werden.

Nebenbei bemerkt: es existieren aber auch ganz andere Szenarien für das Schichtenmodell, bei denen eine ganz andere Anzahl von Schichten auftreten kann. Bei einem kompletten TCP-IP-Stack beispielsweise sind allein für die Abwicklung der Kommunikation sieben Schichten erforderlich (das sogenannte OSI-Schichtenmodell).