A CaseLP agent can be represented from two different perspectives. From a
descriptive point of view, a CaseLP agent is characterized by
a kind, an architecture, an interpreter and
a set of services.
Kind identifies an agent as logical, interface, facilitator or manager.
Logical agents provide
control and coordination
among MAS components using their reasoning capabilities.
Interface agents provide an
interface between external software modules and the agents in the MAS.
Facilitator agents supply other agents
with a yellow-pages service. Manager agents
create and delete other agents in an application
.
Architecture refers to the
internal architecture of the agent. An architecture specifies both the data
structures that form the agent's internal components and the flow of control that
masters components activity.
Interpreter depends on the type of
external module to which an interface agent is linked. The
interpretation approach to software integration in a MAS
[7] is adopted in CaseLP.
External modules can be written in many
programming languages.
Finally,
services define functionalities that the agent provides or requires for
accomplishing its purpose. Services typically depend on the domain of
application of the prototype. Some provided services can be exported to
external users or other MAS. On the other hand, some services can be
imported from outside the MAS.
Thus, exported and imported services represent an interface between
the MAS as a whole and the external world. They are the functionalities that
the MAS provides or requires to external users, both humans or other MASs.
Exported and imported services are a subset of
the provided and required services set.
If the CaseLP prototype is used as a decision support tool, at least one exported
service must be provided in order to interact with the human user. Otherwise, if
the prototype main purpose is simulation, the set of exported and imported
services can be empty.
Abstracting from the architecture adopted, from a computational
point of view a CaseLP agent is formed by a state, a behavior
and an engine.
State, behavior, and engine are architecture-dependent
components.
State includes data structures to represent the current situation of
computation. Behavior represents knowledge used by the agent to
accomplish its task, i.e. providing its services. According to the agent's
architecture, behavior can range form simple rules to complex plans.
Engine encodes the task control that governs the flow of control of
agent's activities.
Interacting agents with the outlined features can be described in the CaseLP framework at different levels of abstraction, using the different languages and tools that the environment provides. A method guides the user in the various prototyping stages, from the informal description of the application to the development of a working prototype. In any step the user can adopt the more suitable languages and tools among the provided ones.