* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Improving Construction and Maintenance of Agent-based
Survey
Document related concepts
Personal knowledge base wikipedia , lookup
Wizard of Oz experiment wikipedia , lookup
Agent-based model wikipedia , lookup
Agent (The Matrix) wikipedia , lookup
Ecological interface design wikipedia , lookup
Soar (cognitive architecture) wikipedia , lookup
Type-2 fuzzy sets and systems wikipedia , lookup
History of artificial intelligence wikipedia , lookup
Fuzzy concept wikipedia , lookup
Cognitive model wikipedia , lookup
Embodied cognitive science wikipedia , lookup
Transcript
Improving Construction and Maintenance of Agent-based Applications through an Integration of Shell and Software Framework Approaches Rafael Rocha1 , Evandro Costa1 , Patrick Brito1 , Marlos Silva2 , Priscylla Silva1 , and Rodrigo de Barros Paes1 1 . Universidade Federal de Alagoas, Computer Institute Campus A. C. Simões - Av. Lourival Melo Mota, s/n, Maceió - AL - Brazil {rafaelrocha.ufal,patrickhenrique}@gmail.com {evandro,pmss,rodrigo}@ic.ufal.br 2 . Instituto Federal de Alagoas - IFAL Rua Odilon Vasconcelos, 103, Maceió - AL - Brazil. [email protected] Abstract. This paper introduces the Intelligent Agent Building Tools, named Inabit, as an engineering approach that adopts the well-known conceptual architecture in which a system is designed on the basis of a problem-situation where an agent interacts with environment through sensors and actuators. Inabit may be seen as a kind of rule-based expert system shell, but it may be also seen as a software framework by providing a set of facilities to be used by the developers of intelligent applications. Therefore, the main idea is to provide effective support with facilities to both domain expert/knowledge engineer and developer. Inabit provides various features commonly used in a typical expert system, such as (i) inference by using goal driven reasoning (backward chaining) or data driven reasoning (forward chaining), (ii) basic explanation facilities, (iii) facilities to create and edit a given knowledge base. Additionally, it supports features concerning uncertainty treatment by means of a fuzzy logic approach as well as the mechanisms to represent the environment where the agent is situated and to implement the two abstractions: sensors and actuators. We tackle some issues related to difficulties found in the construction and maintenance of intelligent applications. To evaluate Inabit we have explored different scenarios, in terms of agent architecture, to demonstrate its feasibility and effectiveness on how to evolve its implementation through different requirements and architectures of agents, range from simple reflex agent to learning agent. Keywords: Expert System, Shell, Software Framework, Intelligent Agent 1 Introduction Knowledge-based systems or particularly expert systems are complex software systems that exhibit intelligent behavior and consist of, at least, a knowledge base and an inference engine. Furthermore, generally there is also an explanation module and sometimes some mechanism for uncertainty treatment. Many times, the construction of such systems has been a hard and time consuming task, mainly when non-standard features are required. To reduce the effort of building such systems, some tools have been proposed, e.g. shells and application frameworks. Building expert systems by using shells offers significant advantages for experts/knowledge engineers. The rule base encoding is somewhat next to the natural language, and shells can be used directly since after the knowledge engineer fills the rule base there is no need for any other procedure to use this knowledge. However, a shell is limited in terms of extending its functionality, it works as a black-box,the interface is very limited and the developer has little or no power to enhance an algorithm within the shell, the developer needs to use the pre-defined interfaces, if there are features to be changed in the shell, they are restricted to the alternatives implemented. There is a divergence between the classic shell architecture and the intelligent agents abstraction as defined by Russel and Norvig [8], in the sense that there is a very strict interaction with a very limited environment model in a shell due to its inflexibility. On the other side, a framework offers a model to build applications, it provides a guide to the developer and the power to change the inner works of the application, but does not offer a friendly interface for the expert/knowledge engineer to write the rule base and use the application quickly and directly. This work aims to facilitate the creation, maintenance and adaptability of intelligent applications by proposing a framework, that reuses the common structure among various agent applications and provides means to adapt the software to the domain, and a shell which provides a more friendly interface to work with inference, but lacks in flexibility. Therefore, this paper introduces the Intelligent Agent Building Tools, named Inabit, as an engineering approach that adopts the well-known conceptual architecture in which a system is designed on the basis of a problem-situation model where the agent interacts with the environment through sensors and actuators. Some related initiatives have been reported in the literature that provides shells implementing forward or backward chaining mechanisms and extensions of those shells developed as plugins to support new features, for instance [2], but our approach differs in proposing an integration between shell and framework allowing a quick manner to use the inference mechanism or develop an application as well as a way to adapt the system to the requirements of the domain. This paper is organized as follows. Section 2 describes some related work. Section 3 introduces Inabit architecture and the description of its main modules. Section 4 describes the current state of the system and shows examples developed with it. Section 5 presents our conclusions and future work. 2 Related Work In this section we show related approaches, the analyzed parameters are extensibility (how much freedom the developer has to modify the original system), adaptability (how well the software developed using the analyzed approach can be adapted to the problem restrictions, and with how much ease) and uncertainty treatment support, since it is needed in various domains. 2.1 JEOPS JEOPS [5] provides reasoning capabilities to an object-oriented programming language, named Java. It supports a forward engine and first-order quantifiers to the developer, as well as the possibility to the developer define the conflict resolution strategy or to use implemented ones. It works as a pre-compiler which translates production rules in java classes that can be handled by the developer, combining the flexibility of a generic programming language to the reasoning capabilities of a production system. Their approach allows Java objects to be manipulated by the production system, and enjoy the object-oriented characteristics of inheritance and polimorfism to simplify the declaration of rules. However, it is not easy to a knowledge engineer to modify the knowledge base. Moreover, JEOPS does not provide any support to uncertainty treatment. 2.2 Jess Jess [2] is an inference machine shell implemented in the Java language which interprets a rule-based language that provides access to the Java APIs. Jess provides a merge between expert and developers needs by providing a domain language which includes host language features. However, this may become a disadvantage since the expert is exposed to the complexity of programming languages and the developer is exposed to the domain complexity. Jess presents some approaches that aim to support uncertainty. Natively, the fuzzy logic is supported by Jess since version 5. However another approaches have been developed to support uncertainty. The first approach is a toolkit that is used to support fuzzy logic via variables, sets and fuzzy values [1]. This extension uses Java objects as global variables in the Jess language. Thus, it provides a set of models for the creation of fuzzy sets at different formats, such as: TrapezoidFuzzySet, RectangleFuzzySet, TriangleFuzzySet, PIFuzzySet, and SFuzzySet ZfuzzySet. However, the use of this extension is generally composed by two interrelated components, a Java program and a knowledge base. This feature makes the approach of Fuzzy Jess more complicated, because it requires the Knowledge Engineer to know details about the FuzzyJess API. A second approach is based on an extension known as the Uncertainty Jess [3]. This approach uses the certainty factor, which is a solution used by the environment MYCIN [10]. Thus, compared to fuzzy logic, the approach of uncertainty factor aims to be an easy, yet powerful, way to deal with uncertainty in Jess [3]. 2.3 Fuzzy Shell Fuzzy Shell [7] is an extension of CLIPS5.1, it allows the rules and facts to be represented by fuzzy terms characterized by membership functions and implements a modified version of the Rete algorithm to fire the fuzzy rules properly. It states that every rule that have a fuzzy variable at the consequent should modify this consequent before this variable can be evaluated at the precedent of another rule. The authors of fuzzy shell shows how the classic reasoning process used upon fuzzy rules can lead to some mistakes at multi-step inference. 2.4 Fuzzy Clips Fuzzy CLIPS is a fuzzy extension to the CLIPS expert system shell to provide fuzzy reasoning capability. To rectify the multi-step reasoning problem, the Fuzzy CLIPS presents some alternatives to the FuzzyShell approach such as modify the conflict reasoning strategy, scoring the rules explicitly so they will fire on the correct order (this approach presents some overload to the knowledge engineer). The current version of fuzzy clips realizes the inference process at the correct order by scoring the rules temporarily based on the most recent fuzzy variable added to the working memory [6]. 2.5 Drools Drools is a business rule management system based on a classical rule engine. It provides an API to build applications using it’s rule inference mechanism, and facilities to enhance the explanation step, as well as templates to allow the expert change the rules without the need of the knowledge engineer. Drools support first-order logic. Thus, it allows the knowledge engineer to use the existential quantifiers in the definition of rules. Also, Drools allows the knowledge engineer to define relations that can be used on rule queries, like Prolog. It does not support uncertainty natively but in order to solve this limitation, some approaches have been developed, one of these is the Jefis (Java Expert Fuzzy Inference System) [12], that provides a library which allows Drools to use a fuzzy object oriented Rete inference machine. Another approach being developed to supply imperfect reasoning is a project called Drools Chance [11] which has different uncertainty systems that are configured to handle imperfect information in a seamless way to the Knowledge Engineer. Furthermore, Drools provides a knowledge agent class that listen to events and applies change sets. Those change sets can add, remove or modify resources, the events fires wherever the knowledge base is updated, after or before a change set is applied or processed and after or before a resource is processed. Basically, it provides mechanism of sensor and actuator but it is restricted to the Resources provided by the API. 2.6 Comparisons Compared to the mentioned approaches, Inabit, as presented in the next sections, brings a solution that addresses each one the limitation discussed above. It handles extensibility and adaptability through the framework approach and uncertainty treatment by allowing the knowledge engineer to define fuzzy rules. Although some of the aforementioned shells presents more sofisticated approaches in certain aspects, as explanation facilities and more efficient algorithms, our framework allows to expand the system to adhere these aspects. 3 Inabit: Main Features In this section we present Inabit facilities to reduce the effort involved in creating an application and/or to maintain an existing one. First, we describe the main system actors and their relations to Inabit. Then, we show the system’s architecture and the features derived from it. 3.1 Two Main Actors Here we focus on two main actors of the proposed solution that are: Knowledge Engineer/Expert and Application Developer and the features that Inabit provides to them. The former can use the proposed shell. Inabit shell provides a rule language for defining if-then rules so that Inabit rule compiler can fill the Rule base and the Working Memory. The variables can be constrained to certain types of values, this allows the compiler to detect errors at interpretation time, while feeding the rule base. The rules can have fuzzy and crisp variables at precedent and consequent. The shell provides data-driven reasoning as well as goal driven reasoning and the explanation mechanism shows a simple trace through the fired rules. The latter uses the proposed framework, at this perspective the Inabit can be used as a template for building intelligent agents. It provides classes for forward and backward reasoning with fuzzy or crisp values as well as abstract classes that the user can extends to implement a different algorithm. Not only the rule engine but every module at the framework is a hot spot, this flexibility allows the developer to evolve the application more freely and the framework can target a broad range of applications. 3.2 Solution Architecture Figure 1 presents a high-level view of Inabit’s software architecture. This architecture is based on a heterogeneous architectural style which combines the data-centered and the component-based architectural styles [9] and shows the main parts of Inabit and how it interacts with the external Environment. As it can be seen, such interaction occurs via sensors and actuators. While a Sensor is responsible for capturing the state of the environment and presents it to Inabit, an Actuator is used for interfering in the environment. Every request coming from the environment to Inabit is caught by the Mediator. This module is responsible for handling the requests and extra information that arrive from the environment and decide which is the proper Inabit’s module for processing it. There are three kinds of events handled by the Mediator: 1. Event for managing rules: When mediator receives requests for adding, removing or changing rules, it propagates the request to the Rules repository; 2. Event for executing rules: When mediator receives events that can activate rules, it propagates the request for the Inference Engine (I.E.) component. Such component is able to perform inference algorithms based on both forward and backward chaining; 3. Event for working memory: When mediator receives requests for changing the working memory, such as a state change coming from a sensor, it propagates the request to the working memory (W.M.) repository. An important design decision of the software architecture concerns the existence of a Mediator connector between the Environment and the I.E. component. The advantage of such connector is to improve the system evolvability, since the addition of new components, such as Machine Learning and Case-Based Reasoning components, for working together with I.E.. Fig. 1. High-level view of the Inabit’s software architecture. Now we present how the architecture approaches the agent abstraction presented by Russel and Norvig [8]: Agent: Perceives the environment and actuates on it. – Sensor: Defines a method getState to get the environment state, which receives a list of words as parameters and returns a single word representing the captured state of the environment. It contains an internal state and provides a method which returns a boolean to notify if the state was changed in the last update(the defined method was called). – Actuator: Interface that defines a procedure which receives a list of words as parameters. – Mediator: Contains identifiable sets of sensors and actuators and methods to handle these. It provides a method that updates all sensors, if the environment’s state has changed it calls a procedure with the changed sensors as parameters. – Inference Machine, Rule Base and Working Memory: The basic expert system’s modules. Implemented as abstract classes, the API provides a simple implementation. Those classes handle the data classes which are FireableRule(containing the expressions to be checked and the fireable consequent) and Variable(containing the information of the variable value). A fireable expression is a simple expression without ambiguity. Environment: There is not an implemented environment entity, it can be represented by the way the getState method is implemented in the sensors. Therefore, the environment can be a passive or active entity based on the sensors implementation. The saveState method allows the definition of constants and restrictions to variables values. The inference engine reset the working memory to the last saved state before the start of the inference process. To execute the inference process the developer have to instantiate an inference engine and execute the main method. Code Sample 1 Executing the inference process InferenceEngine f = new FuzzyForwardEngine(); f.inference(rb, wm); Where rb and wm are the Rule Base and Working Memory, respectively. the inference engine change the values inside the working memory, which provides methods to retrieve the variables and its values. 4 Evaluation The Inabit Architecture facilitates the development of agent-based software. The framework abstraction of the agent interaction with the environment shares the concerns between the modules and supports the evolution between agent classes. We can divide the intelligent agents into five classes simple reflex agents, model-based reflex agents, goal-based agents, utility based agents and learning agents [8]. Unfortunately, learning agents are not supported by the current architecture yet. However, the architecture can be evolved to support it. We developed a simple reflex agent and a model-based agent as scenarios of the system application. 4.1 A Simple Reflex Agent It was developed a simple agent that wanders over a room while painting his path at a different window. When the agent detects a wall it turns to avoid collision and paint where it found the wall(Fig. 2). There is only one type of sensor, a wall detector, but divided into two subsets. When a sensor of the first set detects a wall the robot paint a dot representing a solid. However, if the sensor belongs to the second set the robot turns to avoid the detected solid. There are four actuators: the first makes the agent wander over the room; the second turn the agent at an angle; the third stops the robot; and the fourth paints a dot of a specified color at the window. Fig. 2. Interaction of a simpe reflex agent with the environment The agent complexity was within the implementation of its sensors and actuators methods of the framework, the rules were very straightforward, as a characteristic of reflex-agents. However, they were appart of the development code. Therefore, the agent behavior could change without the code being modified. 4.2 A Model-based Agent To illustrate the development of an agent that uses the reasoning process, we implemented a train-traffic simulation, as described at the Book [4]. This system uses data driven reasoning. When a sensor detects a click, an actuator changes the state of the corresponding source at the working memory. Furthermore, the inference engine reasons upon the rule-base and the current state of the working memory, defining what would be the state of the other variables to avoid collisions. Thus, the agent can activate the actuators that will change the environment to the desired state (see Fig. 3). Fig. 3. A model-based agent in a train station enviroment In this scenario, the development was very straighforward. The developer had to implement the sensors to detect the user mouse click and returned an indentifier corresponding to the graphic-figure clicked, the effectors changed the color of the figure clicked based on the id and colors passed by parameter, the Mediator class called the forward chaining mechanism every time the system state has changed and called the effectors on every variable which had a value on working memory after the inference. The restrictions of the traffic-system, which specifies which color each traffic-light should show, were in the rule definition file, apart from the system code. 4.3 Goal Based and Utility Based agents A goal based agent could use goal driven reasoning instead of data driven reasoning. The backward chaining inference machine is a hot spot in Inabit, when the inference process reaches to a variable which it cannot find the value, the engine calls the ask method, this method can be implemented to ask a sensor instead to an user, so that the agent can keep autonomous. Utility based agents can be derived by using data driven reasoning upon fuzzy rules and using variables that represents the possible actions, the values of these variables are the utility of the represented action. The mediator can keep the history of the sensor. 4.4 Discussion To develop the simple reflex agent we implemented the mediator, sensor and actuator modules of the framework. The sensor input was used to change the values of some representative variables at the working memory, the conclusions changed variables that represented actions the agent should take. The rules that guided the agent were very straightforward and the complexity was within the sensor and actuator implementation, we used the forward engine so that the agent knew the next actions to take based on the sensor input but there were no inference step involved, since its simple cause-consequence interaction in reflex agents. The model agent didn’t implemented the framework modules, it only used the API to change the working memory and retrieve the variables values after inference. Therefore, at the developer perspective there were no complexity involved beside the interface development. At the expert perspective the knowledge was apart from the code, in the description file written at the Inabit rule language, which is simple language mainly composed of if-then statements, and can be modified without the need to change the code. Inabit provides evolvability support to the system being developed, the framework enables other developers to enhance the software’s functionality, and keep the system up to date with novel algorithms in the field. Furthermore, the actuator and sensor abstraction provides support to the design of intelligent agents, the form these were incorporated at the framework allows the agent to communicate with any kind of environment that can be modeled within the limitations of the host language. Besides, Inabit approach to fuzzy representation allows the knowledge engineer to create FuzzySets by drawing as seen in figure 4, or the developer can implement a function object, which can be imported to be used at the rule definition language. Our approach to treat crisp and fuzzy rules has been to change the conflict resolution mechanism to use a breadth-first strategy, which was one of the proposed solutions of FuzzyCLIPS to the problem of multi-step fuzzy rule chaining [6]. Inabit shell does not have facilities to change the explanation system yet. Moreover, we do not provide support to develop learning agents, there are no techniques of this field implemented. However, the system’s framework architecture is flexible enough to allow their inclusion in the future. 5 Conclusions and Future Work This paper presented an approach for building agent-based intelligent applications, mainly focusing on the notion of expert systems, giving facilities to both developers (via application framework) and expert/knowledge engineer (by means of a Shell). The current version of Inabit provides the basic mechanisms and facilities to create agent based applications that executes an intelligent behavior. Our Fig. 4. Fuzzy Set Building solution is mainly architectural, to implement a framework that reflects the agent-environment abstraction presented by Russel and Norvig. We have tried to evolve the framework following the evolution of agent classes [8]. Thus a next step is to provide case based reasoning and inductive rule inference capabilities to allow the agent to learn. Therefore giving support to develop the learning agent class. The Inabit’s architecture provide support for evolvability. Each module is an hot spot, they can be enhanced without great impacts on the system. Since the structure was built upon a problem-situation design it can be adapted to major agent problems. References 1. Introduction to fuzzy jess toolkit, http://www.csie.ntu.edu.tw/~ sylee/ courses/FuzzyJ/FuzzyJess.htm 2. Jess, the rule engine for the java platform, http://herzberg.ca.sandia.gov/ 3. Corsar, D., Sleeman, D.H., McKenzie, A.: Extending jess to handle uncertainty. In: Proceedings of the 2007 SGAI International Conference on Artificial Intelligence. pp. 81–93. Springer-Verlag, Berlin, Heidelberg (2007), http://dx.doi.org/ 10.1007/978-1-84800-094-0_7 4. Cowell, R.G., Dawid, P.A., Lauritzen, S.L., Spiegelhalter, D.J.: Probabilistic Networks and Expert Systems. Springer, 1st edn. (1999) 5. Filho, C.S.d.F., Ramalho, G.: Jeops - the java embedded object production system. In: Proceedings of the International Joint Conference, 7th Ibero-American Conference on AI: Advances in Artificial Intelligence. pp. 53–62. IBERAMIA-SBIA ’00, Springer-Verlag, London, UK, UK (2000), http://dl.acm.org/citation.cfm?id= 645852.756617 6. Hall, L.: Rule chaining in fuzzy expert systems 7. Pan, J., Desouza, G.N., Kak, A.C.: Fuzzyshell: A large-scale expert system shell using fuzzy logic for uncertainty reasoning. IEEE Transactions Fuzzy Systems 6(4), 563–581 (1998) 8. Russell, S., Norvig, P.: Artificial Intelligence: A Modern Approach. Prentice-Hall, 3rd edn. (2009) 9. Shaw, M., Garlan, D.: Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall, Upper Saddle River, NJ, USA (1996) 10. Shortliffe, E.H., Buchanan, B.G.: Readings in uncertain reasoning. chap. A model of inexact reasoning in medicine, pp. 259–275. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA (1990) 11. Sottara, D., Mello, P., Proctor, M.: Adding uncertainty to a rete-oo inference engine. In: RuleML. pp. 104–118. Springer-Verlag, Berlin, Heidelberg (2008), http://dx.doi.org/10.1007/978-3-540-88808-6_13 12. Wulff, N., Sottara, D.: Fuzzy reasoning with a rete-oo rule engine. In: Proceedings of the 2009 International Symposium on Rule Interchange and Applications. pp. 337–344. Springer-Verlag, Berlin, Heidelberg (2009), http://dx.doi.org/10. 1007/978-3-642-04985-9_31