Preliminary Design

Michael Wales - NeedMoreHP@yahoo.com
EEL 5874 - Expert Systems and Knowledge Engineering



Version History:
DocumentDateDescription
Preliminary Des. V1.0March 5, 2002Initial Document


Table of Contents


Introduction to Design of System:

This system will basically consist of two separate applications. The system will have a Java application or applet as a front-end user interface to the user. This application will connect through a TCP/IP socket to JESS (Java Expert System Shell based on CLIPS). JESS will execute a script upon loading that will create the knowledge needed for the system, and then it will connect to the Java front-end application. It will then communicate to the user through this interface. There is a substantial amount of traditional algorithmic procedure for this system, so JESS will pass data through the socket interface to the Java front-end for it to process in a more natural way, and then it will be returned to JESS.

Here are some advantages to this system:

  1. The algorithmic aspects of the problem can be handled by a traditional program.
  2. The expert system shell can handle the rule-based aspects of the problem.
  3. The Java front end can offer a much nicer interface than the clunky interface that JESS comes with.
  4. Possible to create a lightweight applet front-end client that can be executed on the Internet, that communicates to the much more powerful and heavy JESS application running on the webserver.
  5. The Java front-end can collect data from a file or database about computer component pricing and send the data to JESS.

Here are some disadvantages of this system:

  1. The lightweight Java front end isn't trivial to create, will take a while to develop, and will add much more complexity to the system.
  2. The system will require the TCP/IP protocol to be installed. This will only be an issue with systems that never connect to the Internet.
  3. Increased development time.

Creating the system in this fashion will make the system much more complex and increase the development time, but it should greatly increase the look of the system, the power of the system, and the accessibility of the system (especially as a Java applet on the Internet).

Selection of a Knowledge Representation Paradigm:

Our knowledge representation paradigm will be a pure rule based system. We planned to incorporate uncertainty as a tool to evaluate "the amount of need" for a particular application domain. Neither JESS or CLIPS offered this functionality by themselves, but it could be programmed into it them by hand. I feel it will be easier to simply approach the solution in a different way that won't require the uncertainty logic.

Frames were never considered for the system because they weren't any shells available that supported frames. Frames weren't necessary for solving the problem, so it was never really even considered.

Reasoning Method Selection:

There are 3 main reasoning methods for a rule based system: forward chaining, backward chaining, and bi-directional reasoning. The solution is very much weighted towards a forward chaining solution. The system asks the user about their needs, makes some generalizations about what kind of hardware is key to their system, simplifies the fact base, and then puts them a system together that fits in their budget. The solution is arrived at very naturally in this manner, and I think this is the way a human would most likely reason to make a configuration recommendation.

There are so many different possible system configurations possible that a backward chaining solution wouldn't have been practical. I don't think a bi-directional system would be applicable either because the solution arrived at so naturally with forward chaining reasoning.

The fact that all the shells I had access to were forward chaining systems, would have kind of forced us down the forward chaining path anyway.

Tool Selection:

At this point most KB system projects have to consider either developing a custom shell or purchasing a custom shell. Since this project is based on an assignment from class, it's not applicable or justifiable to create a custom shell. There were two shells presented in class that were available, plus one shell that was found on the internet. The assignment was to use an already available shell for the project, so I'm not even considering developing a custom shell.

I considered three different types of shells. It's easiest to make the decision considering what functionality of the shell was most important to me. Here is a list of functions that I would like to have in the shell.

The features of the language weren't really important to me because I have no experience with knowledge based systems. I would probably only use the most basic features of the shell, and the advanced features probably wouldn't be used in my application.

I have chosen JESS as the shell tool for my project. It's syntax and language is based on CLIPS, and CLIPS "code" seems to be 90% compatible with JESS, so JESS does seem to follow a standard syntax. Since JESS is written in Java, it is extremely cross-platform, and can be executed on any system that has a port of the Java Virtual Machine (JVM). The JVM has been ported to most variants of UNIX, Windows, Macintosh, and many others. JESS was also the only shell that I evaluated that offered a network connectivity option, which will be critical for a web interface for the system.

Here are some other details about JESS. I didn't use any of these features as criteria for choosing a system.

Selection of Human Resources:

I will not have any other people work with on the application except for the expert himself. I don't live close to the University of Central Florida, and will be taking the class mostly by tape. It would be very difficult and time consuming (from an hour-long drive) to meet with a group on a regular basis.

Working independently also ensures that a "slacker" group member doesn't hurt the project. The project will reflect how hard I have worked on it, and can't be negatively impacted by a "slacker".

Choosing the Right Knowledge Engineer:

The knowledge engineer will obviously have to be me, since I'm the only person in the group. I'll evaluate myself with the evaluation criteria from the textbook as though I was faced with a choice.

Choosing the Right Team Leader:

This is a trivial decision since I'm the only developer on my project. I'm very unqualified for the position as far as experience with knowledge based systems development is concerned. This would rule me out of the team leader position for 99% of real commercial KB system development.

I am educationally compatible with the knowledge domain. There aren't many four-year degree programs that would give you the background information needed in this knowledge domain other than Computer Engineering. This would be a good pro for having me as a team leader on a real commercial KB system development.

Weighing both the pros and cons, the lack of experience I have with KB system development would definitely rule me out of the team leader position on a real commercial project. After this project I will at least have gained quite a bit of experience, and I will be much more qualified.

Choosing the Right Expert:

I've chosen Shaun Murphy to be my expert for my project. He is a co-worker of mine, and a fellow UCF graduate. He has many years of experience of building his own and friends computer systems.

I will perform my knowledge acquisition from interviews and meetings with Shaun. I also have a lot of knowledge in this domain, so I will also be adding my own knowledge to the system. A majority of my knowledge acquisition will come from hardware benchmarks. These can be found out hardware enthusiast websites such as www.tomshardware.com, www.anandtech.com, and many others.