Download The Application Realisation Guide

IMPLEMENTATION
IMPL-2: How to Implement a Task
ACTIVITY 2
Tasks are generated in the form of 'stub' files, skeleton implementations that can be augmented by the
developer. This enables new domain-specific functionality to be integrated with the automated created
agent-specific code, without needing to modify the later.
Figure 6.2 illustrates the role of tasks in relation to agents. In the course of interacting with other
agents an agent may need to perform a task, whereupon information is passed from agent to task. Once
in the task it can be used for whatever purpose is required, before the information is returned to the
agent (modified or not).
incoming agent
communications
outgoing agent
communications
Agent
Agent
Level
Domain
Level
Task
Information
Received
Information
Used
Information
Returned
Figure 6.2: The flow of information between an agent and a task
As Figure 6.2 suggests, each task consists of three sections: an initial section where the information is
read in from the agent, a mid-section where it is used and a final section when it is returned to the
agent. As agents are unaware of what happens inside tasks, when one is performed the agent will pass
information into it regardless of whether it will be used or not. Furthermore the agent will expect to
receive information in return. The interface between agent and task, i.e. the facts sent and expected
back is what is specified when the developer describes the preconditions and effects of a task, (see
activity TASK-1).
Consequently, of the three sections in a task the mid-section is optional and the first and last sections
are generated by default in the task stub file. This means that if the task does not need to use the
information passed into it, the developer need not alter the task stub file. Thus this activity is only
relevant if the developer wishes to alter how the information received is used, and its scope is limited to
the shaded area depicted in Figure 6.2.
A typical task implementation is shown in Figure 6.3; here the points to note are:
•
the interface between agent and task is the exec() method
•
information is passed to the task in the form of arrays of facts. This enables multiple fact instances
to be passed into the task when there is precondition fact whose cardinality is greater than 1.
•
the information the task expects to receive, i.e. that was specified during the task definition process
(TASK-1), is passed via the array expInputArgs. The information that is actually received is
passed via the inputArgs array; the former can be used to validate the latter.
•
the facts that will be returned to the agent are created inside the task using the corresponding
expected output arguments in the expOutputArgs array as a template.
•
the user code occurs after the parameters have been read from the agent and the expected output
has been created. In this case the task results are not being modified, only passed to a separate
GUI frame for display.
•
the created facts are returned to the agent by copying them into the outputArgs array. Hence if the
task is to modify the information it should be done before this point, otherwise the changes will not
be passed to the agent.
ZEUS REALISTION GUIDE
42