What is PAC? The Presentation-Abstraction- Control pattern (PAC) defines a structure for interactive software systems in the form of a hierarchy of cooperating agents.
Moreover… Every agent is responsible for a specific aspect of the application's functionality and consists of three components: presentation, abstraction, and control. This subdivision separates the human-computer interaction aspects of the agent from its functional core and its communication with other agents.
As the comparison The PAC abstraction component corresponds roughly to the model component of MVC. The presentation component in PAC is a combination of the view and control components in MVC. The control component of PAC mediates between agents and has no equivalent in MVC.
Example Consider a simple information system for political elections with proportional representation. This offers a spreadsheet for entering data and several kinds of tables and charts for presenting current standings. Users interact with the software through a graphical interface. Different versions, however, adapt the user interface to specific needs. For example, one version supports additional views of the data, such as the assignment of parliament seats to political parties. The classic example of a PAC architecture is an air traffic control system. One PAC Agent takes input from a radar system about the location of an incoming 747, and uses the Presentation component to paint a picture of that blip on a canvas (screen). Another Agent independently takes input about a DC-10 that is taking off, and paints that blip to the canvas as well. Still another takes in weather data and paints clouds, while another tracks the incoming enemy bomber and paints a red blip instead.
PAC Agents In the context of the Presentation-Abstraction- Control pattern, an agent is an information processing component that includes: – Event receivers and transmitters. – Data structures to maintain state. – A processor that handles incoming events, updates its own state, and may produce new events. Agents can be a s small as a single object, but also as complex as a complete software system.
Context Interactive systems can often be viewed as a set of cooperating agents. – Agents specialized in human-computer interaction accept user input and display data. – Other agents maintain the data model of the system and offer functionality that operates on this data. – Additional agents are responsible for diverse tasks such as error handling or communication with other software systems. Besides this horizontal decomposition of system functionality, we often encounter a vertical decomposition. In such an architecture of cooperating agents, each agent is specialized for a specific task, and all agents together provide the system functionality. This architecture captures both a horizontal and vertical decomposition.
Forces Agents often maintain their own state and data. – For example, in a production planning system, the production planning and the actual production control may work on different data models, one tuned for planning and simulation and one performance- optimized for efficient production. Interactive agents provide their own user interface, since their respective human-computer interactions often differ widely. – For example, entering data into spreadsheets is done using keyboard input, while the manipulation of graphical objects uses a pointing device. Systems evolve over time. – Their presentation aspect is particularly prone to change.
Solution Structure the interactive application as a tree-like hierarchy of PAC agents. There should be one top-level agent, several intermediate- level agents, and even more bottom- level agents. Every agent is responsible for a specific aspect of the application's functionality, and consists of three components: presentation, abstraction, and control. The whole hierarchy reflects transitive dependencies between agents. Each agent depends on all higher-level agents up the hierarchy to the top-level agent.
How it works? The agent's presentation component provides the visible behavior of the PAC agent. Its abstraction component maintains the data model that underlies the agent, and provides functionality that operates on this data. Its control component connects the presentation and abstraction components, and provides functionality that allows the agent to communicate with other PAC agents.
Top-Level The top-level PAC agent provides the functional core of the system. – The top-level PAC agent includes those parts of the user interface that cannot be assigned to particular subtasks, such as menu bars or a dialog box displaying information about the application. – Most other PAC agents depend or operate on this core.
Bottom-level Bottom-level PAC agents represent self-contained concepts on which users of the system can act, such as spreadsheets and charts. – The bottom-level agents present these concepts to the user and support all operations that users can perform on these agents, such as zooming or moving a chart.
Intermediate-level Intermediate-level PAC agents represent either combinations of, or relationships between, lower- level agents, e.g. a floor plan and an external view of a house in a CAD system for architecture.
PAC Benefits Separation of concerns. – Different semantic concepts in the application domain are represented by separate agents. – Each agent maintains its own state and data, coordinated with, but independent of other PAC agents. – Individual PAC agents also provide their own user interface. – This allows the development of a dedicated data model and user interface for each semantic concept or task within the application, independently of other semantic concepts or tasks. Support for change and extension. – Changes within the presentation or abstraction components of a PAC agent do not affect other agents in the system. – New agents are easily integrated into an existing PAC architecture without major changes to existing PAC agents.
Continue…. Support for multitasking. – PAC agents can be distributed easily to different threads, processes, or machines. Extending a PAC agent with appropriate inter-process communication functionality only affects its control component. – Multitasking also facilitates multi-user applications. For example, in our information system a newscaster can present the latest projection while data entry personnel update the data base with new election data.
Liability of PAC Increased system complexity. – The implementation of every semantic concept within an application as its own PAC agent may result in a complex system structure. – If the level of granularity is too fine, the system could drown in a sea of agents. Agents must also be coordinated and controlled, which requires additional coordination agents. Complex control component. – The quality of the control component implementations is therefore crucial to an effective collaboration between agents, and therefore for the overall quality of the system architecture. Efficiency. – The overhead in the communication between PAC agents may impact system efficiency especially if agents are distributed. Applicability. – The smaller the atomic semantic concepts of an application are, and the more similar their user interfaces, the less applicable this pattern is.
Usage examples On the server side, Drupal follows the PAC (Presentation- Abstraction-Control) design pattern. The Drupal Core provides the controller. It responds to user requests and routes them to the appropriate handlers. The theme system provides the presentation layer. The modules (including the built-in modules like Node) access and manipulate the data which is the job of the abstraction layer. The menu system acts as the Controller. It accepts input via a single source (HTTP GET and POST), routes requests to the appropriate helper functions, pulls data out of the Abstraction (nodes and, in Drupal 5, forms), and then pushes it through a filter to get a Presentation of it (the theme system). It even has multiple, parallel PAC agents in the form of blocks that push data out to a common convas (page.tpl.php).