Download Improving Construction and Maintenance of Agent-based

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