Flexible Intelligent Learning Environments (ILEs): Using Agent-based ...

2 downloads 0 Views 142KB Size Report
David Duncan. Paul Brnay. Abstract. As a eld of research matures the methodologies that it employs become more sophisticated. Recent work on evaluation inĀ ...
Flexible Intelligent Learning Environments (ILEs): Using Agent-based Software Engineering to Build New Agents David Duncan Paul Brnay Abstract

As a eld of research matures the methodologies that it employs become more sophisticated. Recent work on evaluation in the AI and Education community [11, 12] has stressed the need to evaluate the educational bene ts of Intelligent Learning Environments (ILEs) as these systems are developed. At the same time the cost, time and resources, of developing these systems has increased [13, 3, 4]. If both of these problems are to be solved then our research methodologies should include a methodology for software development. This paper outlines a methodology which supports a number of the requirements of ILE research. This methodology has been applied to the development of several systems, and these are used to illustrate the methods for building agents.

1 Introduction As research into Intelligent Learning Environments (ILEs) has matured the issue of research methodology has received more attention. Researchers have rightly highlighted the need to develop methodologies which support the frequent evaluation of the educational bene ts of the ILEs [11, 12]. One of the e ects of this is that the systems will need to go through a large number of changes during their lifecycle. If our research methodologies do not include methods for the software engineering of the ILEs then the cost of ILE research will continue to escalate. Given the requirements of the various stakeholders1 in ILE research the software engineering methodologies need to support the development of exible ILEs. This

exibility should allow the addition and removal of software components, simplify the alteration of components, and support the use of existing software components. In this paper a methodology for agent-based ILE development is proposed. This methodology includes a large number of methods for the development of ILEs. The Department of Arti cial Intelligence, University of Edinburgh, Edinburgh, [email protected] Computer Based Learning Unit, University of Leeds, Leeds, [email protected] Wenger [14] lists a number of research disciplines which should be involved in ILE research. Each of these disciplines are stakeholders in the development of ILEs and their needs have to be incorporated by the ILE developer.  y 1

description is provided below. One of the main steps within the methodology deals with the building of individual agents. To illustrate the methods that apply to this aspect of the development a brief description of an ILE to investigate the use of analogy for learning is provided. Before discussing the methods for building agents an overview of the methodology is given. The paper concludes with a brief discussion on the progress made in providing methods for building agents.

2 Background The purpose of this section is to brie y introduce our starting point for the methodology for agent-based ILE development. The section begins with a brief description of agentbased software engineering [7]. This provides the basis for the methodology. The building of agents is dependent on the architecture adopted and the selected architecture is described next. The section concludes with an overview of part of an ILE which will be used to illustrate a number of the issues that need to be addressed when building agents. Agent-based software engineering [7] was invented to support software interoperation. This is achieved by viewing systems as a collection of agents which communicate with each other using an expressive agent communication language (ACL)2 . Existing software can be incorporated into new systems by extending the software to support this communication process. Genesereth and Ketchpel [7] describe three methods for dealing with the incorporation of legacy software3: wrapping, injection and re-write. Where the software provides the necessary functionality the wrapping technique can be used. This involves adding the agent features which convert the software input/output to the required ACL. Where the source is available and changes need to be made to the software the agent routines can be inserted into the existing code. In situations where the code is not usable or available the radical approach of re-writing needs to be taken. The success of these methods for building agents is dependent on what is involved in the agenti cation process. Agents within a system will require routines which support a number of agent features4. For example, construction of ACL messages, planning of tasks and the ability to negotiate with other agents. The inclusion of these routines for each agent leads to an overhead in the development process. An architecture for an agent is required which reduces the amount of code which is needed to convert existing software into an agent. An architecture which we believe would reduce the amount of code required to convert existing software was developed by Huang et al [10]. This agent architecture for the domain of medical health care incorporates a number of agent features. The architecture separates the communication, planning and interface into di erent modules This language provides message types such as inform and request. That is software which has been developed for another purpose and which the developer wishes to reuse. 4 Note that agents do not have to exhibit all of these features to function within an agent-based environment. 2

3

to working memory and posts results back to working memory. This architecture can be adapted so that processes which carry out the agent's functionality also interact through the use of the working memory. This separation of the agent features and the actual functionality should allow the reuse of the implemented agent features. The development of an ILE will usually involve the construction of new agents in addition to incorporating existing software. It is therefore necessary to consider how the described methods for dealing with legacy code can be supplemented. As an illustration, an ILE in which both new and incorporated agents is provided. In addition the selected agents have di erent communication requirements with the rest of the system. An ILE, called the Analogical Model-based Physics System (AMPS), which is being developed to investigate using analogy to support students exploration of physics concepts [2] requires the development of a number of di erent agents. The agents selected to explore the building methods are: simulation, analogical retrieval and analogical mapping. Simulation agents are required for two reasons. Firstly, an ILE has to provide an environment in which the student can explore the domains which are being taught. Secondly, they provide an example of an agent whose main interaction with other agents is to inform them of the actions of the students. One use of analogy within a simulation-based learning environment is the retrieval of previous examples. An agent can be provided which students can use to retrieve these examples. This agent, which uses the Many are Called/ Few are Chosen (MAC/FAC) algorithm [6], is a good example because it requires the assistance of an agent which is able to carry out structure mapping. There is also a requirement to receive information from the simulation agents. The use of analogical mapping by students has been shown to be problematic (see [2]). As a consequence, we proposed an `intelligent' mapping agent which can assist students in the mapping process. This agent uses an existing implementation of the Analogical Constraint Mapping Engine (ACME) algorithm [9]. Assistance could be provided by helping explore the positive, negative and neutral aspects of the mapping. For the building of agents it provides an example which in addition to requiring information from the simulation also acts as a sub-process to the retrieval agent.

3 Overview of Methodology In the previous section the starting point for the methodology for ILE development was introduced. Through the development of the ILE for learning using analogy this has evolved into a number of steps (see gure 1). These steps are divided into two phases each concluding with the evaluation of the ILE. This methodology is described brie y below. The rst phase involves the design and implementation of the framework to support the agents, and a number of initial agents. The phase begins with the identi cation of the requirements for the ILE. From the requirements, a number of agents to be developed will be identi ed. Agent-based software engineering [7] is based on a federated architecture which involves groups of agents who interact through the use of special

IDENTIFY

GROUP

IDENTIFY AGENTS

REQUIREMENTS

AGENTS

BUILD

BUILD

FRAMEWORK

AGENTS

IDENTIFY NEW REQUIREMENTS

EVALUATE

MODIFY AGENTS

SYSTEM

& FRAMEWORK

IDENTIFY

GROUP

NEW AGENTS

NEW AGENTS

BUILD AGENTS

MODIFY AGENTS

ADD AGENTS

Figure 1: Agent-based Methodology agents called facilitators [8]. This leads to the need to provide methods to support the grouping of agents. The development of these facilitators and the initial agents follows. The phase concludes with the evaluation of the ILE with respect to the research objectives for the project. In response to the evaluation the second phase is entered. This is an iterative phase which continues for as long as the evaluations lead to further changes being required to the ILE. This is similar to the rst phase except there is no requirement to develop the framework. However, any new agents need to be added to the ILE and methods are required to support this process. The addition of agents is supposed to be straightforward [7] but it is likely that signi cant changes will be required. Therefore, methods are provided which support the modi cation of agents. Each of the steps shown have methods de ned to assist the ILE developer [5]. However, we restrict ourselves here to methods dealing with the building of agents. These methods are considered in more detail in the next section.

4 Building Agents As previously stated, agent-based software engineering provided three methods for the conversion of existing software into agents. However, a number of questions need to be addressed if this approach is to be adapted to the development of agent-based ILEs.

processes for each agent can the methods be adapted to reduce this overhead? Secondly, what methods can be provided to simplify the conversion process? And nally, can the provided methods support the future extension of the agent? In order to address these questions the section begins with a brief description of the steps in the initial development of agents. The development of ILEs will generally consist of both new and `converted' agents. In our example AMPS requires simulations which are new agents and makes use of an existing ACME implementation for the mapping agent. A description of the steps required in the building of new agents is followed by the methods for the conversion of existing software. This section is concluded with a discussion of the progress made in demonstrating these methods through the development of the agents introduced in section 2.

Initial Development. The purpose of the initial development method is to construct

an agent framework5. The aim is to provide the agent functionality which is independent of the tasks that each individual agent carries out. This framework consists of three components (communication manager, working memory and the layered agent control module) which need to be developed during phase 1 of the methodology. A brief description of the development of each of these components now follows:  Communication manager. The purpose of the communication manager is to deal with the construction and extraction of ACL messages and the sending and receiving of them. This involves taking the contents of the message from working memory and sending the message to the group's facilitator. Messages received by the agent are extracted and the content placed in working memory. The construction of messages is triggered by information being added to working memory.  Working memory. The components within an agent need to share data and this is achieved by providing a working memory. Each component supplies a list of data types in which they are interested. This information is then used by the working memory to trigger the interested components if the relevant data is added to working memory. It is left to the individual components to retrieve the relevant data.  Agent control module. The agent control module contains a number of routines relating to the agent functionality. These include the communication protocols used for requesting and servicing external agents. Note that it is the responsibility of this module to determine what messages need to be sent. Also included is the agent planning routines. These routines are used to execute the plans which are stored within this module. Once the above components have been developed they can be used by any agents which are developed within the ILE. How this is achieved is covered in the description of the building of new agents and the incorporation of existing software methods.

That is, the provision of a number of modules which provide the agent functionality and may be used with all agents. Note that this relates to the framework for individual agents and not the framework for the multi-agent architecture mentioned in section 3. 5

need to develop new agents. The method to achieve this is described below: 1. Identify processes. The development of a new agent will involve the construction of one or more processes. These processes are connected to working memory in the same manner as the framework components. Choosing whether to split the agent tasks into a number of processes will depend on the future use of the agent. If the developer is satis ed that the agent is complete then only one component should be developed as there is an overhead associated with the number of components attached to the working memory. However, if the agent is liable to be developed incrementally in response to the results of evaluation it is sensible to develop a number of components to simplify future maintenance. 2. Construct processes. Once the required processes have been identi ed the next step is to construct them. In this step the developer is free to select the design methodology and implementation language which is most suitable. The only constraint is that the component should be able to connect to the working memory. 3. Develop interface (if required). One of the features of this approach to developing agent-based ILEs is that each agent can communicate directly with the user. This is not the case with Cheikes's agent-based architecture [3, 4]. Not all agents need to do this, so the development of the user interface is optional. The AMPS mapping agent would not require an interface if it was only used to assist the retrieval agent. As with constructing processes, the developer is free to select the most suitable design methodology and implementation language. 4. Add plans to agent control module. Each agent makes use of plans to achieve the execution of its tasks. The nal step for the developer is the addition of these plans to the agent control module.

Incorporating Existing Software. Section 2 introduced three methods for the in-

corporation of existing software. The adoption of the agent architecture and the development of an agent framework reduces the amount of code that needs to be added to existing software. A brief description is now provided of the steps required to include existing software in the ILE: 1. Determine method of incorporation. The rst step is to determine which of wrapping, injection or re-write should be used. Note that the aim is to provide the routines which handle the addition and retrieval of data to working memory. Where the software provides the required output, wrapping is the preferred option. Injection originally was required if additional functionality was needed. However, the architecture adopted supports the possible addition of new processes (see next step) if additional functionality is required. Therefore, amendment need only be made where the source code is available and the software can easily be modi ed to provide slightly di erent output. The re-writing of the software should only be required if it is impossible to amend functionality by addition or alteration.

is required, either because the software doesn't exactly match requirements or it is only part of the agents functionality, the next step is to develop additional components. This development can be carried out in the same manner as the development of processes in new agents. 3. Amend existing software (if required). Where changes are required these should be carried out. This can be part of the injection method if this is the approach adopted by the developer. 4. Develop interface (if required). As with new agents an interface may be required. This should be developed and incorporated into the agent. Note that if the existing software has a user interface this should be removed and the functionality included in the agent's interface. 5. Add plans to agent control module. As with new agents the nal step is to add the plans to the agent control module.

Discussion of Current Progress. In this section a number of methods for the

building of agents have been described. To evaluate these methods a number of case studies have been carried out. The initial development of the agent framework was carried out in conjunction with the construction of an analogical retrieval agent [1]. In order to investigate the development of agents within a group of researchers this work was carried in collaboration with an MSc student at Napier University. The implementation of the simulations was carried out to investigate the development of new agents using the prescribed methods. The method for incorporating existing software was adopted for the development of the analogical mapping agent. The next step in this evaluation process is to combine the agents within the multi-agent framework. The methods for constructing agents, following on from the early work of Genesereth and Ketchpel [7] attempted to reduce the overhead in the agenti cation process. Taking the agent architecture described by Huang et al [10] and adapting it leads to the development of a single agent architecture which can be reused with minimal changes. This also simpli es the conversion process as the code that needs to be added through wrapping or injection relates only to the interaction with working memory. The future extension of agents is supported through the ability to add new processes. However, the evaluation to date has mainly been concerned with the building process. Further work is required to incorporate these agents within the multi-agent architecture. Reusability of the agents needs to be addressed by the development of further agents which may lead to a revision of the described methods. The evaluation of the methods was carried out with a two person project. The full methodology should eventually be evaluated within the context of a larger project.

5 Summary The need to develop a methodology for constructing ILEs which supports ILE research methodologies [11, 12] was highlighted. An overview of a methodology for agent-based

before brie y discussing the progress made and further work that is required.

Acknowledgements

The authors would like to thank Yota Asimakopoulou for her assistance with this work.

References

[1] Y. Asimakopoulou. An agent-based analogical retrieval tool. Unpublished MSc Thesis, Department of Computer Studies, Napier University, 1996. [2] P. Brna and D. Duncan. The analogical model-based physics system: A workbench to investigate issues in how to support learning by analogy in physics. In A. Diaz de Ilarraza Sanchez and L. Fernandez de Castro, editors, Computer Aided Learning and Instruction in Science and Engineering: Third International Conference, CALISCE'96, pages 331{339, 1996. [3] B.A. Cheikes. GIA: An agent-based architecture for intelligent tutoring systems. In Proceedings of the CIKM '95 Workshop on Intelligent Information Agents, 1995. [4] B.A. Cheikes. Should ITS designers be looking for a few good agents? In N. Major, T. Murray, and C. Bloom, editors, Proceedings of the AI-ED '95 Workshop on Authoring Shells for Intelligent Tutoring Systems, 1995. [5] D. Duncan. A methodology for agent-based intelligent learning environments (ILEs). PhD Thesis, Department of Computer Studies, Napier University, in preparation. [6] K.D. Forbus, D. Gentner, and K. Law. MAC/FAC: A model of similarity-based retrieval. Cognitive Science, 19:141{205, 1994. [7] M.R. Genesereth and S.P. Ketchpel. Software agents. Communications of the ACM, 37(7):48{53, 1994. [8] M.R. Genesereth, N. Singh, and M. Syed. A distributed anonymous knowledge sharing approach to software interoperation. In Proceedings of the International Symposium on Fifth Generation Computing Systems, pages 125{139, 1994. [9] K.J. Holyoak and P. Thagard. Analogical mapping by constraint satisfaction. Cognitive Science, 13(3):295{355, 1989. [10] J. Huang, N.R. Jennings, and J. Fox. An agent architecture for distributed medical care. In M.J. Wooldridge and N.R. Jennings, editors, Intelligent Agents. Lecture Notes in Arti cial Intelligence, volume 890, pages 219{232. Springer Verlag, 1995. [11] M.A. Mark and J.E. Greer. Evaluation methodologies for intelligent tutoring systems. Journal of Arti cial Intelligence and Education, 4(2/3):129{153, 1993. [12] T. Murray. Formative qualitative evaluation for "exploratory" ITS research. Journal of Arti cial Intelligence and Education, 4(2/3):179{207, 1993. [13] K.C. Warren, B.A. Goodman, and S.M. Maciorowski. A software architecture for intelligent tutoring systems. In P. Brna, S. Ohlsson, and H. Pain, editors, Arti cial Intelligence in Education, 1993, pages 50{57. AACE, 1993. [14] E. Wenger. Arti cial Intelligence and Tutoring Systems. Morgan Kaufmann, 1987.