Presentation-Abstraction-Control

Darstellung-Abstraktion-Steuerung bzw. englisch Presentation-Abstraction-Control (PAC) bezeichnet ein Architekturmuster zur Strukturierung von interaktiven Softwaresystemen.

Will man diese Systeme so entwickeln, dass sie aus einzelnen Teilen bestehen, die jeweils einen Teil der Aufgaben des Systems anbieten und damit eine hohe Flexibilität des Systems erhalten, dann muss man sich darum kümmern, dass diese Teile zu einem funktionierenden Ganzen zusammengesetzt werden und auch zusammenarbeiten. Für eine Softwarearchitektur, die dies sicherstellt, ist PAC ein Muster.

Das Model-View-Controller-Muster (ebenfalls ein Architekturmuster für interaktive Softwaresysteme) reicht für diese Anwendungen nicht aus und so geht PAC über dieses hinaus. Es teilt ein System in zwei Richtungen auf, einmal in die drei Einheiten grafische Benutzungsschnittstelle (Presentation), Vermittlung und Kommunikation (Control) und das Datenmodell (englisch Abstraction) – dies ist ähnlich dem MVC – und darüber hinaus noch hierarchisch in verschiedene Teile, die, wie eingangs gefordert, jeweils einen Teil der Aufgaben des Systems anbieten. Diese Teile nennt man im PAC-Muster „Agenten“ und sie stellen die erste Stufe der Strukturierung während des Architekturentwurfes dar. Das heißt, man beginnt den Entwurf mit der Aufteilung der gesamten Anforderungen auf einzelne Agenten und baut die hierarchische Struktur darauf auf. Für jeden Agenten wird dann im zweiten Schritt des Entwurfes eine Aufteilung in die besagten Komponenten, Darstellung, Abstraktion und Steuerung, vorgenommen.

Hierarchische Struktur

Die Struktur einer Softwarearchitektur nach PAC

Die Hierarchie von PAC ist in drei Schichten aufgeteilt, den Top-Level-Agent, die Intermediate-Level-Agenten und die Bottom-Level-Agenten. Ersterer kommt nur einmal in einem System vor und übernimmt alle globalen Aufgaben, wie z. B. den Datenbankzugriff. Die Bottom-Level-Agenten bieten die eigentlichen Funktionen des interaktiven Systems an, wobei jedes seine eigene, möglichst abgeschlossene, Funktion hat und möglichst über keine Abhängigkeiten zu anderen Bottom-Level-Agenten verfügen sollte. Die Intermediate-Level-Agenten bilden die Schnittstelle zwischen der untersten (Bottom-Level) und der obersten (Top-Level) Schicht und fassen mehrere Bottom-Level-Agenten zu einer Einheit, zu einem Teilsystem, zusammen. Dabei können diese Teilsysteme auch weiter hierarchisch aufgeteilt werden, so dass ein Teilsystem auch aus einem oder mehreren anderen bestehen kann und dann ein Intermediate-Level-Agent mehrere andere Intermediate-Level-Agenten zusammenfasst.

Der Architekturentwurf beginnt mit der Aufteilung der geforderten Funktionalität auf mehrere Bottom-Level-Agenten. Daran anschließend legt man den Top-Level-Agent fest, bzw. die Funktionen, die er erbringen muss. Die Hierarchie wird dann mit der Festlegung der Intermediate-Level-Agenten vervollständigt, die eine Kombination aus Bottom-Level-Agenten darstellen und diesen den Zugriff auf den Top-Level-Agent vermitteln.

Aufteilung der Agenten

Jeder einzelne Agent wird in die drei Komponenten strukturiert. Erstens die grafische Benutzeroberfläche (Darstellung oder Presentation), welche die komplette Ein- und Ausgabe umfasst und nicht wie beim MVC-Muster noch einmal aufgeteilt wird. Die zweite Komponente ist die Abstraktion (Abstraction), welche das Datenmodell des Agenten realisiert. Die dritte Komponente, die Vermittlung und Kommunikation (Steuerung oder Control), stellt die Verbindung zwischen den beiden anderen Komponenten her und ermöglicht die Kommunikation mit anderen Agenten. Sie sind damit die zentrale Schnittstelle, die die Zusammenarbeit der einzelnen Teile eines Systems im PAC-Muster ermöglichen.

Es ist nicht zwingend, dass jeder Agent alle drei Komponenten hat, sondern jeder Agent bringt die Benutzerschnittstelle und das Datenmodell für seine Aufgabe mit. So ist es auch möglich, dass z. B. ein Intermediate-Level-Agent nur in einem Fenster darunterliegende Agenten zusammenfasst und zur Anzeige bringt, aber keine Daten dafür benötigt. Die Steuerungskomponente muss allerdings jeder Agent besitzen, um über sie die Kommunikation mit anderen Agenten und zwischen den Komponenten zu ermöglichen.

Stärken

Die große Stärke des PAC-Musters liegt in der Zerlegung der Funktionen des Gesamtsystems in einzelne semantisch getrennte Teile, welche von Agenten realisiert werden. Damit kann die Funktionalität problemlos durch zusätzliche Agenten erweitert werden. Eine gute Wartbarkeit ist durch die interne Struktur der Agenten gegeben.

Schwächen

Die bedeutendste Schwäche von PAC ist die erhöhte Systemkomplexität, welche durch einen erhöhten Koordinations- und Kommunikationsaufwand zwischen den Agenten hervorgerufen wird. Die Steuerungskomponenten können eine hohe Komplexität erreichen und sind der kritische Punkt bei der Umsetzung dieses Musters, der besondere Beachtung benötigt.