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˜oes - Av. Lourival Melo Mota, s/n, Macei´o - AL - Brazil
{rafaelrocha.ufal,patrickhenrique}@gmail.com {evandro,pmss,rodrigo}@ic.ufal.br
2 . Instituto Federal de Alagoas - IFAL
Rua Odilon Vasconcelos, 103, Macei´o - AL - Brazil.
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 pro-viding a set of facilities to be used by the developers of intelligent appli-cations. Therefore, the main idea is to provide effective support with fa-cilities 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: sen-sors 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 architec-ture, 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 explana-tion 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 ex-perts/knowledge engineers. The rule base encoding is somewhat next to the natural language, and shells can be used directly since after the knowledge en-gineer 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 pro-vides 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 en-gineer 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 struc-ture 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 al-lowing 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 exten-sibility (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 sys-tem, and enjoy the object-oriented characteristics of inheritance and polimorfism to simplify the declaration of rules. However, it is not easy to a knowledge en-gineer 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 lan-guages 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 ap-proach 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 imple-ments 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 sec-tions, brings a solution that addresses each one the limitation discussed above. It handles extensibility and adaptability through the framework approach and un-certainty treatment by allowing the knowledge engineer to define fuzzy rules. Al-though 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 cre-ating 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: Knowl-edge 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 ar-chitecture 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 aSensoris
responsible for capturing the state of the environment and presents it to Inabit, anActuatoris used for interfering in the environment.
Every request coming from the environment to Inabit is caught by the Medi-ator. 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 theMediator:
1. Event for managing rules: When mediator receives requests for adding, removing or changing rules, it propagates the request to theRulesrepository; 2. Event for executing rules: When mediator receives events that can acti-vate rules, it propagates the request for the Inference Engine (I.E.) compo-nent. 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 chang-ing the workchang-ing memory, such as a state change comchang-ing from a sensor, it propagates the request to the working memory (W.M.) repository.
An important design decision of the software architecture concerns the exis-tence of aMediatorconnector between theEnvironmentand theI.E.component. The advantage of such connector is to improve the system evolvability, since the addition of new components, such asMachine LearningandCase-Based Reasoning
components, for working together withI.E..
Fig. 1.High-level view of the Inabit’s software architecture.
Now we present how the architecture approaches the agent abstraction pre-sented 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 repre-senting 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 meth-ods 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 fire-able consequent) and Varifire-able(containing the information of the varifire-able value). A fireable expression is a simple expression without ambiguity.
Environment: There is not an implemented environment entity, it can be rep-resented 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.
ThesaveState 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);
Whererb andwm 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 learn-ing agents [8]. Unfortunately, learnlearn-ing agents are not supported by the current architecture yet. However, the architecture can be evolved to support it. We de-veloped 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 ac-tuators 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 modi-fied.
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 rea-soning. 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 af-ter inference. Therefore, at the developer perspective there were no complexity involved beside the interface development. At the expert perspective the knowl-edge 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 frame-work enables other developers to enhance the software’s functionality, and keep the system up to date with novel algorithms in the field. Furthermore, the actu-ator and sensor abstraction provides support to the design of intelligent agents, the form these were incorporated at the framework allows the agent to commu-nicate 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 con-flict 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 chain-ing [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 architec-ture is flexible enough to allow their inclusion in the fuarchitec-ture.
5
Conclusions and Future Work
This paper presented an approach for building agent-based intelligent appli-cations, 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 Intelli-gence. 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 Net-works 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 Confer-ence on AI: Advances in Artificial IntelligConfer-ence. 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 Disci-pline. 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: Proceed-ings 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