Schichtenmodelle - auch als Schichtenarchitekturen bezeichnet - definieren Prinzipien zur Strukturierung von Software-Architekturen. Die hierarchische Strukturierung von Schichten ist ein häufig angewendetes Muster der Architektur. In diesen Zusammenhang ist auch die sogenannte Drei-Schichten-Architektur (Three Tier Architecture) bzw. das Drei-Schichten-Modell einzuordnen. Wie aus der Abbildung ersichtlich werden die grafische Benutzeroberfläche (GUI) und das eigentliche fachliche Konzept separiert. Darunter liegt dann die Datenhaltungsschicht. Die Drei-Schichten-Architektur ist eine häufig verwendete Form von Architekturmustern bei der Erstellung von Software-Systemen. Aufgrund der strikten logischen Trennung der Schichten ist auch deren Anwendung in verteilten Systemarchitekturen üblich.

<< Anzeige >>

UML-Notation für Drei-Schichten-Architektur

Das Drei-Schichten-Modell ist eine Software-Architektur, die drei unterschiedliche Schichten - die GUI-Schicht, die Fachkonzeptschicht und eine Datenhaltungsschicht - unterscheidet. Das Schichtenmodell verdeutlicht den grundsätzlichen Zusammenhang. Dabei bildet die GUI-Schicht die Funktionalität einer grafischen Benutzeroberfläche - häufig durch die Verwendung eines entsprechenden Frameworks - ab. Die Aufgabe der Fachkonzeptschicht ist die Realisierung der eigentlichen fachlichen Anforderungen. Zudem umfasst diese Schicht entsprechende Schnittstellen zum Zugriff auf die darunterliegende Datenhaltungsschicht, die meist in Form einer Datenbank ausgeführt ist und so für die Speicherung und das Laden der Daten Verantwortung trägt.

Hinsichtlich der Ausprägung der Drei-Schichten-Architektur gibt es zwei unterschiedliche Möglichkeiten; die strenge und die flexible Trennung der drei Schichten. Bei der strengen Trennung kann jede Schicht nur auf die direkt darunter angeordnete zugreifen. Der Vorteil dieser Anordnung ist die strikte Unabhängigkeit der GUI- von der Datenhaltungsschicht. Eine höhere Flexibilität erreicht man, wenn die GUI-Schicht zusätzlich direkt auf die Datenhaltungsschicht zugreifen kann. Eine Verwendung des jeweiligen Stils ist im Hinblick auf die einhergehenden Faktoren wie Wartbarkeit, Änderbarkeit und Portabilität im konkreten Zusammenhang abzuwägen.

Ein grundlegendes Charakteristikum der Drei-Schichten-Architektur ist es, dass weder die Fachkonzeptschicht noch die Datenhaltungsschicht auf die GUI-Schicht zugreifen können. Damit hat auch keine dieser beiden Schichten ein explizites Wissen hinsichtlich der Benutzungsoberfläche. Somit ist auch deren Entwicklung und Modifizierung unabhängig voneinander möglich, was dem heutigen Verständnis eines modernen Software-Engineerings entspricht. Hier spricht man auch von der Realisierung der Model-View-Architektur, wobei Model das Fachkonzept und View die Benutzeroberfläche abbildet. Dennoch muss eine Verbindung zur Anzeige und Eingabe von Daten der Fachkonzeptschicht durch die GUI-Schicht bestehen. Hierzu tauschen die Schichten Nachrichten auf Basis der folgenden Verfahren aus:

Polling. Dabei fragt die GUI-Schicht in regelmäßigen Intervallen bei der Fachkonzeptschicht nach möglichen Modifizierungen an und sendet dazu diesbezügliche Nachrichten an die Fachkonzeptschicht. Dieses Verfahren ist jedoch wenig performant.

Indirekte Kommunikation. Diese kann in der objektorientierten Programmierung auf Basis eines Entwurfsmusters - dem Observer-Muster - erfolgen. Dabei schickt die Fachkonzeptschicht bei Änderungen eine entsprechende Nachricht an die GUI-Schicht. Diese holt dann selbstständig die geänderten Daten ab.

Aufgrund der logischen Trennung der einzelnen Schichten ist die Drei-Schichten-Architektur gut skalierbar und somit verwendbar in verteilten Software-Architekturen. Eine strukturierte Verwendung der Architektur ist beispielsweise in der Zuordnung der GUI-Schicht zu den Workstations der Anwender, in der Ablage der Fachkonzeptschicht auf Workgroup-Servern und der zentralen Integration der Datenhaltungsschicht auf einem Datenbank-Server gegeben. Dabei gilt der Grundsatz, dass je höher die Schicht ist, diese umso besser einem Client zugeordnet werden kann. Umgekehrt gilt aber genauso; je niedriger eine Schicht ist, umso zentraler wird diese in die Software-Architektur eingebettet.