Architecture View

The goal of this view is to transform the feature specification of the other views into a system architecture. But what is a system architecture? Because of the fact that there is no widely agreed definition for the term in the Software Engineering community, we have to select one of the existing definitions that is most suitable for the ideas presented in this chapter.

Definition [Software Architecture] The software architecture describes fundamental structural attributes of a software system.

Although this definition is rather general and leaves some space for interpretation it is nonetheless expressive enough to clearly define the focus of this view: to model the components of the target system and the connections between them. The software architecture is therefore a more or less static description of the code of the target system that must, however, account for the dynamic aspects that were defined in some of the other views. Before we start with concrete considerations of how to find the most appropriate system architecture, I will briefly introduce some general properties that should be present in any architecture that is developed.

Two of the most fundamental metrics that have been introduced several years ago are coupling and cohesion. Wheras coupling measures the number of interconnections among the entities of the system, cohesion measures the internal relationships of these entities. In a good system architecture, the coupling should be low in order to achieve a high degree of modularization and the cohesion of the individual components should be high in order to keep effects of particular operations as local as possible. Furthermore, a good system architecture should try to distribute the complexity of the target system equally over the entire architecture as this reduces the complexity of individual components and thus supports the designer's understanding of these components. Obeying these basic requirements will eventually lead to a system architecture that supports changes because of the reduced complexity of the individual components as well as well as reuse because of the modularization of the architecture.

In the rest of this section, I will address some issues that are characteristic for multiagent systems. Due to the wide range of possible implementations, however, I will not try to suggest a reference architecture. The requirements for a particular system can be so specific and individual that it would be highly unnatural to try to fit it into a standard design. However, we strongly believe that some architectural patterns for specific classes of multiagent systems will evolve during the next years when multiagent technology will become more common in industrial systems.

top

System Architecture

In order to find the most appropriate architecture for the target system, it is useful to think first about the overall nature of the system. Then, an appropriate design idiom, i.e. a fundamental pattern that is characteristic for the entire design is chosen according to the classification.

The most common design patterns are the following:

Main Program & Subroutines

This is probably one of the oldest design patterns, stemming from the time where procedural programming languages were the only available higher level languages on the market. The characteristic feature of this pattern is the focus on the main program that provides the main control loop and acts as a driver for the subroutines attached to it. This type of architecture is still often found, especially in systems with a simple control flow, for example for scientific calculations.

Batch Sequential

This architectural pattern is almost as old as the previous one and has its origin in the time when memory was a valuable good and multi-process operating systems had not yet been invented. In this pattern, each component has a set of inputs and outputs and performs a local transformation process that maps the inputs to the outputs. The components are independent of each other and can be invoked sequentially on a single process machine. However, this architectural pattern may gain some new support because it is well suited for workflow systems and supply chain management.

Event Systems

Event Systems are characterized by an asynchronous, implicit method invocation mechanism that is used by the components to communicate with each other. The idea is that each component registers with an event dispatching system in order to receive particular events that are issued by other components. This mechanism is called implicit method invocation because the component that issues an event does not explicitly request a service by another component. It may even be the case the issuing component does not know which other components react to the event. The canonical example for event-driven systems are window systems that contain a large number of and require a flexible, localized control flow.

Object Oriented

The fundamental abstraction in object oriented systems is the encapsulation of data representations and the associated operations in a single structural entity -- the object. Well defined object oriented systems are often easier to understand then systems with a traditional architecture because of the semantic relation of the entities in the system with the entities they are supposed to represent. However, object orientation can easily lead to an over-modularization of the system with fatal consequences to maintenance and runtime behavior. Object-oriented architectures are very common in applications that provide a graphical user interface.

Layered

In a system with this sort of architecture, several layers are built on top of each other and a each layer uses services from the lower layer and provides some service to the upper layer. Layered architectures are the first choice when the complexity of the task can be hierarchically decomposed. Furthermore, layered architectures support local changes because of the well defined interfaces between the layers. The most prominent examples for layered architectures are the OSI reference model for protocol system or the TCP architecture.

Communicating Processes

This design pattern represents a flexible architecture for systems with several independent, interacting entities. These entities can either reside on the same computer or they can be spatially distributed and connected via a communication network. Examples for this architecture include Client-Server systems as well as multiagent systems.

This list of architectural prototypes is not exhaustive but it represents the majority of the common system architectures. However, it is often the case that a particular system is not implemented according to a single idiom, but according to several of them. For example, a multiagent system can be implemented as communicating processes and also have an object oriented architecture at the same time.

top

The Architectural Feature Space

In the Architecture view, we are concerned with the problem of how to transform the more or less abstract feature specifications of the other views into a coherent system design. Therefore, this view will have to work on a lot of features that are shared with other views and I will therefore first of all characterize the design space of the target system. The design space is defined as a three-dimensional space that arranges the features that are addressed within the Architecture view according to three dimensions.

The first dimension describes a particular feature by classifying it according to its temporal behavior. Thus, a feature can either be static in that it accounts for a structural aspect of the system, or it can be dynamic and capture some of the relationships between the static object. Features of the first class will therefore usually relate to components and features of the second class will model the nature of interconnections between components.

The second dimension describes the level of granularity of a feature. This can either be the micro level that captures properties of individual components or it can describe macro aspects, i.e. aspects that influence the architecture of the entire system.

The third dimension, finally, differentiates features according to the purpose. The purpose of a feature can be task specific or it can be task independent. In the first case, the feature will typically represent entities that are characteristic for the domain while in the second case, these features can be found in several domains at the same time.

In the following, I have compiled a non-exhaustive list of selected features that are addressed in this view and classified them according to the three dimensional scheme.

Entities

Not all entities that are part of the system architecture are necessarily agents although the agents play the major role in the target system. However, it is not always a good idea to encapsulate all relevant entities into agents e.g. when such an entity is frequently used by several agents, it is possibly a better idea to model it as an object that is accessed by the agents because of the communication overhead that would accompany the approach to model the entity as an agent. Therefore, it is the goal of this view to identify and to model the agents and the other major objects within the target system.

Control flow

Whereas the control flow at the agent level is defined by the interaction schemes given in the Interaction view, the control flow at the object level must be coordinated explicitly as well. Because not all entities that occur in the target system are agents, the integration of these entities into the system are modeled in this view.

Information flow

The arguments that hold in the case of the control flow can be applied to the information flow as well. Again, the information flow at the agent level is defined in the Interaction view but the information flow between other entities must be modeled as well.

Agent management

Agent Management captures all tasks that are concerned with the operational framework of the agents. This framework includes matters such as the agent identification scheme, available service information or firewall technology. Standards such as described in the FIPA standard can be a valuable help for the designer in this respect.

Communication model

The low level communication model of the application must be described and integrated into the system. The range of possible communication techniques for a particular application is very broad and the designer must decide on the need for synchronous or asynchronous messages, one-to-one, multicast or broadcast messages etc. The need for particular communication services can have a huge effect on the entire system.

Database design

Especially larger systems or systems that are supposed to operate in an industrial context usually need storage facilities and mechanisms that cannot or should not be proprietary. Therefore, the designer must use standard database technology to handle these matters. However, although common database systems provide the necessary software support, it is still up to the designer to develop a database structure that suits the particular needs of the target system. Since database design is a long-known topic in the computer science community, I direct the reader to the widely available literature.

External components/devices

In order to provide the required functionality to the user, a software system usually relies on external services that are provided either by software or hardware components. It is one of the tasks of the Architecture view to identify these components or devices and to fit them into the overall system design. This integration is achieved by defining the appropriate interfaces and the connections of the external entities to particular entities of the software system.

Agent architecture

This aspect is one of the most important and also one of the most difficult aspects to deal with. Therefore, we have dedicated the following section to the detailed discussion of this topic.

Each of these features can be characterized according to the three dimensions presented earlier and arranged in a three dimensional space spawned by these dimensions. In some cases, the decision on which of these idioms to apply for a specific target system might be straightforward. In other cases, where the decision is not so obvious, I can only provide as an advice to the system designer to briefly apply the above idioms to the target system in order to develop a feeling for how a system might look that is implemented according to a particular idiom and then to select the most appropriate. Unfortunately, up to now no generally applicable set of guidelines exists that can help the designer in choosing the best architectural idiom. As it was said above, a major aspect in the system architecture is the agent architecture that implements the runtime environment for the role descriptions.

top

Agent Architecture

One of the most important aspects of multiagent system development is to define the basic entities within the system -- the agents. As I have already discussed in Role view, an agent is a conceptual abstraction the consists of a set of roles and an architecture that implements these roles. Thus, we define the term "agent architecture" as follows.

Definition [Agent Architecture] An agent architecture is a structural model of the components that constitute an agent as well as the interconnections of these components together with a computational model that implements the basic capabilities of the agent.

To select the best agent architecture for a given set of roles is as least as a big a problem as to find the best architectural idiom as discussed in the previous section. Therefore, I recommend the following two step process to identify the best architecture from the numerous architectures that are currently on the market. First of all, the system designer should characterize the requirements for the architecture according to fixed scheme that covers the most important issues to be addressed. Second, the designer should evaluate existing architectures according to the requirements defined in the first step and then select the best matching architecture. I strongly recommend to check existing approaches before trying to define a proprietary architecture. Only if no matching architecture is found, the burden of designing an implementing a new architecture is justified. Even in this worst case, the developer should consult the existing literature in order to avoid sub-optimal results.

To address the first aspect of this two-step process, I have defined the following set of properties that can be used to characterize the requirements for the agent architecture.

Reasoning capabilities

The reasoning capabilities of the agents define the most important property and often determine the overall complexity of the agent architecture. For example, an agent may be forced to plan its actions if it is not a purely reactive agent, or it may use some utilitarian reasoning mechanisms to chose among several possible actions. Another important issue is the ability for an agent to learn from past experiences or the agent may be used to fulfill special tasks such as theorem proving etc.

Resource limitations

This aspect of the characterization describes the resources that are available to a single agent within the multiagent system. If an agent has a very limited amount of processor time or memory space, it is impossible to use an agent architecture that requires, say, the resources of a Unix process. However, this point can also be viewed from a different angle. If the individual agent has to deal with very complex problems, a simple architecture may not be able to cope with the resource requirements of the architecture because it was not designed for heavy weight problems. An individual agent within the system has only limited computational resources because of the expected size of the target system with approximately 5000 agents running in a single process. Therefore, the agents must not be too complex if efficiency is a crucial factor due to the nonfunctional requirements.

Control flow

The aim of this requirement is to characterize the control flow that is needed within the agent. First of all, the designer should decide whether a sequential flow of control is sufficient or if the agent is required to do several things at the same time and thus needs some parallel action execution model. In the second case, a concurrent architecture that in most case is much more complex then a sequential architecture must be chosen. Second, the designer must decide about the required flexibility of the control flow. In a more static setting, the flow of control can be explicitly hard-coded into the architecture while in a dynamic context, the flow of control is likely to undergo changes and must therefore be described implicitly e.g. in plan scripts that are interpreted at run time and that can be changed while the agent is in operation. The control flow within an agent is fixed over time and there is no need for a flexible, explicit representation of the control flow. However, an agent can potentially engage in several interactions at the same time and will also need to monitor the plan execution process while negotiating with other agents. Therefore, the agent needs a parallel action execution model in its architecture.

Knowledge handling

The knowledge representation within the target system is defined in the Task view. In the Architecture view, the knowledge structures that are defined there must be characterized in order to decide which architectural features are necessary to effectively handle these structures. First, it is important if the agents knowledge is stored explicitly in a knowledge base or is it encoded implicitly into the agent code. Second, the knowledge structures may be represented in a symbolic manner using some sort of logical formulae or in a sub-symbolic form e.g. in its simplest form as collection of values or more elaborate in the form of a neural network. The major knowledge structures of the agents are the plans that hold the nodes, travel times and coupling activities of the agents. These plans are likely to change frequently and they must be interpretable by humans. Therefore, the plans are explicitly represented and kept in the knowledge base that must be provided by the agent architecture.

Autonomy

The degree of autonomy that is required by the agent defines how the agent interacts with its environment. A reactive agent simply responds to external stimuli by reproducing a pre-defined behavior when a particular stimulus is given by the environment. A pro-active agent, on the other hand, can become active without external trigger and then perform some action that satisfies the goal. Pro-active agents are usually more complex and their behavior is not always predictable. The degree of autonomy of the agents varies in the different tasks they perform.

User interaction

The more interaction the agent has with the user, the more elaborate the user interface has to be in order to provide convenient means for input and output data. Furthermore, an advanced user interface agent will perform user profiling and try to learn the users preferences from his or her input/output behavior.

Temporal context

This aspect characterizes the agents lifetime. Obviously, an agent with only a limited activation time will need another form of persistence mechanism -- if any at all -- then a long-running agent. Persistence refers to the ability of the agent to maintain knowledge structures over time and over unavoidable down-times due to service failures such as hardware or software crashes. However, the amount of information that is collected by the agent over its lifetime can become very large and must be handled in an effective manner. Thus, the architecture must provide means to manage the data handling process.

Decision making

This attribute characterizes the way in which the agent comes to its decisions during its reasoning processes. While some authors claim that rationality is an inherent property of any agent, there are others who consider architectures that support emotional decision making as an alternative. There are two main fields for a potential application of emotional architectures. First, they can become valuable tools to implement lifelike characters and avatars that represent a human user in networked environments. Second, the notion of emotions can be used to express complex heuristics for advanced software agent in a natural way. However, the development of the basic technology is still in its beginnings and does not play a relevant role until now. Still, the developer of a particular application may want to consider these ideas if they are appropriate for the problem in question.

The developer can use the above characterization scheme to capture the main requirements towards the agent architecture in the system and then decide on that basis, which of the existing architectures is best suited (if any) or if the development of a new architecture might be necessary.

top