The goal of this view is to model the environment of the target system from two distinctive points-of-view. First, the environment will be analyzed from the perspective of the developer and a general characterization of the environment as it appears to the developer will be generated. Second, the environment will be described from the systems point-of-view in terms of input/output or sensor/effector specifications.
This part of the Environment view describes the environment of the multiagent system from the developers point of view. The main aspects are the organizational context in which the system will be used, the general characteristics of this context as far as it is relevant for the application and a technical assessment of the runtime environment of the operational system.
The first step in modeling the environment of the target system is to clarify the organizational context that determines how and where the target system should be used within the customers organization. If, for example, the target system is meant as a prototypical evaluation of a new approach or some other technology that will not be used in an operational context, it surely directs the focus of the final design onto more functional aspects then onto nonfunctional aspects such as stability or user friendliness. It is hard -- if not impossible -- to specify concrete rules of how to specify the organizational context because the relevant concepts are extremely fuzzy. Therefore, the major contribution of organizational context specification in this view is to provide the designer with a feeling of how the system should be used and what is important with respect to the field of application of the target system.
A very general scheme to describe the environment of agent-based applications is based on five dimensions to capture the characteristic features of the environment.
accessible vs. inaccessible In an accessible environment, the agents can perceive the full state of the environment at any time. In a an inaccessible environment, on the other hand, only partial information is available to the agents.
deterministic vs. nondeterministic This feature describes how the agents perceives the development of its environment, i.e. whether the next state of the environment is completely determined by the current state (as perceived by the agent) or not.
episodic vs. nonepisodic An episode is a single perception-action cycle performed by the agent. In an episodic environment, these cycles are unrelated, i.e. the action of one cycle does not have any impact on the next cycle. Thus, episodic environments are much simpler then nonepisodic environments because they do not need the ability of the agent to plan ahead.
static vs. dynamic In a static environment, the environment cannot change while the agent is not acting (i.e. while the agent is deliberating) whereas this assumption does not hold in a dynamic environment.
discrete vs. continuous In a discrete environment, the agent has distinct, clearly defined percepts that (partially) describe the environment. This is not the case in a continuous environment.
These features can be used to characterize a broad range of environments. The physical world, for example, is inaccessible, nondeterministic, nonepisodic, dynamic and continuous, whereas a virtual world that is inhabited by software agents is also nondeterministic, nonepisodic and dynamic but it is usually accessible and discrete. Characterizing the environment according to the above features can help the designer to anticipate basic problems that are likely to occur in a particular class of environments. Dynamic environments, for example, require a much more sophisticated reasoning mechanism that is capable of integrating newly perceived state information in the ongoing reasoning process.
The organizational context and the general characterization of the environment of the target system usually depend on the particular problem domain. Another important aspect of the system environment from the perspective of the developer that will be discussed in the following section, however, is domain independent.
This aspect of the system environment deals with technical aspects of the runtime environment of the target system. These characteristics are often neglected because they are considered unimportant and could therefore be left out without loosing generality. But this is not true! The runtime environment can have an enormous impact on he final design and performance of the system and should thus be explicitly modeled as early as possible. A good example for the impact of the runtime environment on the final system is the Teamwork Library, a framework for distributed problem solving based on the Teamwork approach. The original design used simulated broadcast messages because physical broadcast was not offered by the communication platform (Ethernet). It was assumed that simulated broadcast would do as well. This turned out to be a mistake because the performance and value of the teamwork approach relied on the fast transfer of large amounts of data. Thus, the entire system had to undergo a re-design phase that added mechanisms and protocols for physical broadcast. To avoid such expensive error-corrective work, the runtime environment must be carefully characterized and evaluated. First of all, the designer must specify the programming model that is used in the target system. Programming models can be classified according to their degree of concurrency: a sequential programming model admits for no concurrency at all; functions are called strictly one after the other. This kind of programming model does not require synchronization mechanisms and it is sufficient in case the multiagent paradigm is solely used for design purposes, i.e. to structure the target system. A pseudo-parallel model, on the other hand, typically uses light weight processes (threads) within a single operating system process to achieve concurrent execution of program fragments. This kind of programming model is well suited for multiagent applications because it allows for a reasonable degree of parallelism while still being easy to handle with respect to debugging and traceability. A fully distributed programming model, finally, distributes the computation space over several computers connected via a communication network. This model is quite hard to handle because it often requires complex synchronization and fault tolerance mechanisms. However, for real world applications, this might be the only possible choice.
In the next step, the designer has to describe the communication platform that will be used within the target system. The choices for the communication platform are usually limited by the choice of the programming model; a sequential system, for example, will usually be limited to internal communication using ordinary method invocation mechanisms. In the case of a pseudo-sequential programming model, the choices are broader because such a programming model usually requires asynchronous message exchange to exploit the (pseudo-)parallelism provided by using several threads of execution. Asynchronous message \index{asynchronous message} invocation methods are usually not offered by the programming language and thus the designer must define a method that is best suited for communication between the entities of the target system. The widest range of choices, however, is given in the case of fully distributed systems. The entities can communicate using network protocols such as TCP/IP or radio transmission protocols such as GSM to exchange messages.
Finally, the choice of the appropriate programming language is an important issue. The programming language need not necessarily support a particular programming paradigm, e.g. object-oriented programming in order to built a multiagent application. However, a cleaner, more structured code will be generated if the programming language supports particular features that are characteristic for multiagent systems. Still, as it was said in the introduction to this section, the developers perspective is just one aspect that is dealt with in the Environment view. Therefore, we will now discuss the other main aspect of this view -- the system that is situated in an environment and that somehow perceives and acts upon this environment.
Specific parts of the system may have a very different perception of the environment given their physical or conceptual constraints. Usually, the system (and later the agents) perceive their environment through a number of sensors and operate on the environment by using effectors. First of all, this very general concept of an input/output specification must be clarified with respect to the characteristic needs and requirements of the target system. Second, the designer must develop a model of the environment that is internally used by the agents to represent their environment and to reason about it. The definition of the mechanisms that enable the entities in the system to perceive and act upon their environment should be general enough not limit the choice of assigning particular sensors and effectors to the roles within the multiagent system defined in the role view. In this view, only a general model of the sensors and effectors that allows the designer to get an overview of how the systems inter-operability with its environment can be arranged should be produced. The model of the sensors and the specification of the individual percepts then leads to the choice of the data structures that are needed to capture an internal world model depending on the functional requirements of the target system. Sometimes, an internal model is completely obsolete, whereas in other cases the agents must be equipped with a rather fine-grained model of their environment and their fellow agents.