Presentation-Abstraction-Control

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 (engl. 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.

Inhaltsverzeichnis

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.


Wikimedia Foundation.

Игры ⚽ Нужен реферат?

Schlagen Sie auch in anderen Wörterbüchern nach:

  • Presentation–abstraction–control — (PAC) is a software architectural pattern. It is an interaction oriented software architecture, and is somewhat similar to model–view–controller (MVC) in that it separates an interactive system into three types of components responsible for… …   Wikipedia

  • Presentation Abstraction Control — Saltar a navegación, búsqueda La estructura de una aplicación con PAC. PAC (Presentation Abstraction Control, o en español, Presentación Abstracción Control) es un patrón de arquitectura de software para sistemas interactivos basada en una… …   Wikipedia Español

  • Presentation-abstraction-control — NOTOC Presentation abstraction control (PAC) is a software architectural pattern, somewhat similar to model view controller (MVC). PAC is used as a hierarchical structure of agents, each consisting of a triad of presentation, abstraction and… …   Wikipedia

  • Presentation, abstraction, controle — Présentation, abstraction, contrôle Pour les articles homonymes, voir PAC. Le patron de conception PAC a été introduit par la chercheuse en informatique grenobloise Joëlle Coutaz dans les années 1980 en tant que modèle abstrait d architecture… …   Wikipédia en Français

  • Présentation, Abstraction, Contrôle — Pour les articles homonymes, voir PAC. Le patron de conception PAC a été introduit par la chercheuse en informatique grenobloise Joëlle Coutaz dans les années 1980 en tant que modèle abstrait d architecture logicielle pour les interfaces homme… …   Wikipédia en Français

  • Présentation, abstraction, contrôle — Pour les articles homonymes, voir PAC. Le patron de conception PAC a été introduit par la chercheuse en informatique grenobloise Joëlle Coutaz dans les années 1980 en tant que modèle abstrait d architecture logicielle pour les interfaces homme… …   Wikipédia en Français

  • Présentation, Asbtraction, Contrôle — Présentation, abstraction, contrôle Pour les articles homonymes, voir PAC. Le patron de conception PAC a été introduit par la chercheuse en informatique grenobloise Joëlle Coutaz dans les années 1980 en tant que modèle abstrait d architecture… …   Wikipédia en Français

  • Model–view–controller — A general representation of the MVC design pattern. Model view controller concept. The solid line represents a direct as …   Wikipedia

  • Model-view-controller — (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the …   Wikipedia

  • Component-based usability testing — (CBUT) is a testing approach which aims at empirically testing the usability of an interaction component. The latter is defined as an elementary unit of an interactive system, on which behaviour based evaluation is possible. For this, a component …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”