es course advisor

Griffith University

School of Computing and Information Technology

Domain: Expert Systems Design and Development

A Course Advisor Expert System

available electronically at:

http://www.cit.gu.edu.au/~noran

© Ovidiu S. Noran


i

Table of Contents.

1 Introduction....................................................................................................1

1.1 Artificial Intelligence and Expert Systems. ........................................................1 1.1.1 Artificial Intelligence. .......................................................................................... 1 1.1.2 Expert System. .................................................................................................. 1

1.2 Limitations of the existing system. ....................................................................2 1.3 The Conversion Course. ..................................................................................3

2 Developing the Expert System. .....................................................................4

2.1 Advantages of the expert system. ....................................................................4 2.2 Concepts of the expert system. ........................................................................4 2.3 Structure of the expert System. ........................................................................5

2.3.1 The User Interface. ............................................................................................ 5 2.3.2 The Inference Engine. ....................................................................................... 5 2.3.3 The Knowledge Base......................................................................................... 5

2.4 Choosing the right implementation. ..................................................................6 2.4.1 Code from the ground up................................................................................... 6 2.4.2 A suitable expert system language.................................................................... 6 2.4.3 A web-enabled expert system language; .......................................................... 6 2.4.4 A web-enabled shell and a pre-made user interface. ........................................ 6

2.5 The Expert System Model. ...............................................................................7 2.5.1 The Conceptual Model....................................................................................... 7 2.5.2 The Behavioural Model...................................................................................... 8 2.5.3 The Knowledge Base......................................................................................... 9 2.5.4 Hybrid Functional Graph / Sequence Diagram................................................ 10 2.5.5 The Details....................................................................................................... 10 2.5.6 The Constraints. .............................................................................................. 11

2.6 Development milestones. ...............................................................................12

3 Using the Expert System. ............................................................................13

3.1 Operating the program. ..................................................................................13 3.1.1 Options............................................................................................................. 13 3.1.2 Running a consultation. ................................................................................... 14

4 Beyond the Prototype. .................................................................................18

4.1 A Full-blown Expert System. ..........................................................................18 4.2 Gathering the required knowledge..................................................................18 4.3 The 'Right Implementation' - revisited.............................................................18 4.4 Extending the Expert System. ........................................................................19 4.5 Knowledge base policies. ...............................................................................20

5 Conclusions. ................................................................................................22

6 References. .................................................................................................22

Appendix A - Functional Diagram. ......................................................................1

Appendix B - Contents of the Disk. .....................................................................2

Course Advisor Expert System Introduction

1

1 Introduction.

The introductory part is largely based on the previously submitted Proposal for the Expert System. The Proposal contained some basic Artificial Intelligence concepts and a very brief introduction to Expert Systems. We will reuse that material in the Introductory Section of the Project Description.

As the expert system prototype has now been developed, many of the uncertainties listed in the Proposal have been clarified and decided upon. Therefore it is more efficient to reuse the (still current) information available in the Proposal and correct /delete / add fresh information regarding the actual implementation, development, testing and tune-up of the expert system.

Please note that this expert system will serve as a prototype for a larger, more comprehensive system which is currently being proposed to support the planned Conversion Course within Griffith University.

The aim of the this introductory part is to define the problems and limitations of the present system and show how the proposed project may help overcome some of them and support the planned Conversion Course.

1.1 Artificial Intelligence and Expert Systems.

1.1.1 Artificial Intelligence. What is A.I. ? A simple definition states: 'The branch of computer science concerned with the automation of intelligent behaviour'. Artificial Intelligence has several areas of interest, such as robotics, vision, natural

language understanding and semantic modelling, speech, artificial neural systems and parallel processing, automated reasoning and theorem proving, expert systems, game playing and human performance modelling.

One of the major roots of the expert systems is in the cognitive science: the way humans process information (the way they think and solve problems).

1.1.2 Expert System. What is an expert system ?

An expert system is a computer system that emulates the decision-making ability of a human expert, i.e. it acts in all respects as its human counterpart.

The term expert may be misleading. In the early days expert systems only contained expert knowledge. Presently however, any system using expert system technology (even if not containing highly specialised expertise in a certain domain) is called an expert system. Therefore, the term knowledge-based system is more appropriate, although most people use the shorter term expert system.

Expert systems have emerged from early work in problem solving, mainly because of the importance of domain-specific knowledge. A human expert's knowledge is specific to a problem domain. In much the same way, expert systems are designed to address a specific domain, called the knowledge domain.

Figure 1 shows the concept of a knowledge-based expert system. The expert system receives facts from the user and provides expertise in return. The main components of the expert system (invisible from the outside) are the knowledge base and the


2

inference engine. The inference engine may infer conclusions (solutions) from the knowledge base, based on the 'facts' supplied by the user.

Figure 1 Main components of an expert system.

Expert systems are suitable for solving the ill-structured (or not entirely defined) type problems, which are usually difficult or impossible to solve by 'conventional' methods (e.g. procedural programming).

1.2 Limitations of the existing system.

This section does not aim to criticise the existing system, but rather to show ways to improve it. The present subject selection and description Web-based system is accessible, fairly easy to use and has an acceptable response time.

However, there are also limitations to this system. To list a few:

• 'dead' pages: Some of the web pages are static. • difficult updates: In order to update a web page containing e.g. subject

description / status information, the page has to be manually edited. Typing errors may and will occur during this process;

• stale data: many subject web pages are in danger of being overlooked in the process of create / read / update / delete;

• maintenance : the Webmaster's problems are multiple: how often to update the subject page ? How to make sure the page contents are always up to date ? How to distinguish between different 'versions' of pages ?

• public image: it is an aspect not to be overlooked. If subjects display erroneous or stale information, students may be (unintentionally) misled in their enrolments / exams etc. This may lead to an unfavourable image of the teaching institution and ultimately to a drop in enrolled students numbers.

• responsibility: web site information inaccuracies may lead to disappointment and even claims for losses recovery (e.g. for mis-enrolments)

• control: the present system does not verify in any way that a student may enrol in subjects contrary to the University policies. Presently, students are responsible for the accuracy of their enrolment. However, a mechanism performing a preliminary compliance check on the student's enrolments would be a substantial improvement.

• confusing: for prospective students, the present subject/course description may be confusing. This project tries to address this category of


3

people. Prospective students are extremely important to the University. They may be reviewing their education options from overseas and the cheapest and most available source of information for them is the Internet - the University Web pages.

A user-friendly system displaying the options available for the particular situation of the prospective postgraduate student would definitely attract more students towards Griffith University.

The implemented system is fairly limited in its possibilities, largely because:

• it is intended to be a prototype only; • the available time and resources are limited. • accurate subject information is nor yet available

The good news about it however is that is it quite scalable, i.e. by updating / extending

the knowledge base the system may become smarter and be able to cope with a larger array of prospective students / lecturers needs.

1.3 The Conversion Course.

The increasing need for highly qualified IT personnel in Australia and abroad is currently being met in two ways:

• new students enrolling in undergraduate IT courses; • existing graduates, notably engineers from other fields, enrolling in IT Masters

courses and PhDs. Up until now, there have been difficulties in accepting enrolments from the second

category of people, mainly because of their lack of IT background. But the primary reason for them wanting to undertake a postgraduate course in IT is the lack of IT skills. Unfortunately very often his leads to a deadlock in their career.

One way to solve this dilemma is a conversion course. This is not a new concept. Many Universities have already implemented such Courses, most notably Griffith University, Gold Coast campus. Since the conversion course is designed for non-IT background people, the main obstruction in their acceptance in a postgraduate course is eliminated.

Back to Table Of Contents.

Course Advisor Expert System Developing the Expert System

4

2 Developing the Expert System.

2.1 Advantages of the expert system.

The expert system aims to provide a prototype (or a preview) of the complete expert system envisaged to support the future Conversion Course. A prototype is a good concept, since it gives an image of the difficulties, advantages, efficiency and feasibility of a project without full financial or resource commitment.

While not providing the full range of features, nor being the ultimate subject selection tool, the proposed prototype expert system will still be able to clarify a whole range of problems the stakeholders may not even have thought of yet.

The advantages of the implemented expert system are:

• simulation an affordable simulation of 'the real thing';

• fresh data information for the expert system will be extracted from the knowledge base, which will be adequately maintained;

• assistance the system provides preliminary assistance and advice for prospective postgraduates;

• friendly the system helps minimise postgrad student disappointment and enrolment errors later on;

• intelligent the system may infer new knowledge from the existing knowledge base and the facts asserted by the user at run-time;

• effective the prototype is already web based and may provide of 24 hours-a-day, up-to-date advice to worldwide prospective students (NOTE: the knowledge base information is largely fictional, although quite credible. Please refer subsequent sections of the document regarding the expert system tune-up).

The expert system users will be prospective postgraduate students and also lecturers, tutors, etc seeking advice on how the subjects may work together within the proposed Conversion Course (or any other course for that matter).

2.2 Concepts of the expert system.

The expert system will be based on a range of existing but enhanced concepts, which will make the subject selection and education processes more flexible and effective for the postgraduate students. These concepts are:

• modularity of subjects. Presently, each subject already has a certain structure attached to it, as envisaged by the subject convenor. Using this structure, we can consider the subject as being composed of several modules;

• prerequisites and outcomes of the subject modules. These concepts already exist, albeit applied only to the subject as a whole. Still it is possible (within a reasonable amount of effort) to group prerequisites and outcomes for each module composing a subject;

• credit for previous studies. Applied to modules within a subject (rather than a subject as a whole), it will allow a student to satisfy a prerequisite for and enrol in a particular module without having to enrol in the whole subject.


5

In other words, through a combined interview / questionnaire procedure it is possible to establish modules within the subjects, and partial prerequisites, outcomes, and credit for these modules.

A balance must be maintained between the number of modules within a subject (e.g. min. 2, max. 5 for a 10CP subject) and the flexibility these modules allow. More modules within a subject mean more flexibility of the structure, but the amount of processing and development time will also increase.

2.3 Structure of the expert System.

This is a knowledge-based system. The knowledge base contains facts and rules referring to the partial / complete prerequisites and outcomes of the subjects offered in the School of CIT in Griffith University. Other supplementary information is provided, such as semester, credit points, parent subject, etc. More information may also be introduced later on as necessary (i.e. module convenor).

The main elements of the proposed system are (also refer Figure 1):

2.3.1 The User Interface.

This is where the user enters the query. This has been chosen to be a Java applet within a Web page. It is based on a pre-made user interface shell called JConsult v.1.3, by Thomas Reichherzer (Ref.5). Is it a lean and simple interface, very suitable for the purpose of a simple Web-based expert system. It has been slightly modified to match it to the specific needs of this project.

2.3.2 The Inference Engine. This is provided by a Java implementation of the CLIPS engine. The CLIPS language

(Ref.1) uses forward-chaining and the RETE fast pattern-matching algorithm, originally designed by Charles R. Forgy, at the Carnegie-Mellon University (refer to Ref.6 for a short expert system history primer). CLIPS uses lists to process information, very similar the LISP language and it is largely used by the Artificial Intelligence community.

The Java implementation of CLIPS is called JESS - The Java Expert System Shell (Ref.4), currently version 5.1 (and 6.01 beta). This provides the user with the power of the CLIPS language and the flexibility of the Java cross-platform concept. In its basic form, JESS is a byte-code set that provides a command prompt similar to CLIPS. However, most of the data structures provided by Java are available in JESS, including the AWT (Abstract Window Toolkit), which makes it possible to construct graphical user interfaces to the JESS (CLIPS) engine.

2.3.3 The Knowledge Base. This is the rules and facts repository, containing:

• the 'fixed' facts, such as the modules information; • the run-time asserted facts - user's answers to the expert systems' questions • the rules - used to infer new knowledge from the fixed and asserted facts.

Similar to CLIPS, the knowledge base is contained in a .CLP file, in plain text format.

Separating the fixed facts from the may be desirable for larger knowledge bases. The listing contains information on how to achieve this.


6

2.4 Choosing the right implementation.

In implementing the expert system, several decisions had to be made. The available choices were:

2.4.1 Code from the ground up.

This simply means programming the inference engine from scratch and thus 're-inventing the wheel'. While it may be suitable for certain applications, it was totally inappropriate for the limited time and resources available in this case.

2.4.2 A suitable expert system language.

This option is quite applicable to this case. The language should already contain the inference engine and other extensions. Valid alternatives were :

• Prolog: a backward-chaining artificial intelligence language. Prolog comes in several flavours, the latest even being Visual, which provides possible integration with other Visual type (event, GUI driven) programming languages

• CLIPS: the C Language Integrated Production System. Despite its name, CLIPS is very similar to LISP (the LISt Processing language), using the concept of lists.

2.4.3 A web-enabled expert system language;

This is an even better option. However, the available tools start getting scarce once we venture in the web-enabled artificial intelligence programming languages. Options:

• Prolog with a web enabled interface. Several Prolog Java wrappers exist. Some of them are commercial - hence not free, very big in size (Mbytes) and with lots of options useless for this particular case. Others are free or shareware, but still in various development / beta testing stages;

2.4.4 A web-enabled shell and a pre-made user interface.

This seems to be the ideal choice for this particular project. Although a programming language clone is not always identical with the original, the basic functions needed for the limited scope of this project should be implemented and sufficient. There has only been one valid option:

• Java Expert System Shell (JESS v.5.1). A basic pre-made user interface called JConsult (v. 1.3) is also available. Both are free but registration is required prior to download.

Since it has been established that a web-based system is the best choice for this application, option D has been chosen. The expert system will run either as a Java application (byte code interpreted by the Java VM) or as an applet, downloaded and run by a Java-enabled browser on the host machine. The (faster to load) Java application implementation will be used for developing and debugging. The expert system will finally be deployed for general use as an applet within a Web page.

Figure 2 shows the preferred method of deployment. It is obvious that the 'bottleneck' here is the time necessary for the applet to download - currently around 10-12 sec., maybe longer depending on the number of 'hops' on the Internet link between the client and server. As previously mentioned, this is not a big concern for this particular case. Still, a different implementation is proposed in Section 4.3, which will allow the expert system to run on the server and only communicate with the user for input and output. Once loaded, the applet runs at full speed though.


7

Figure 2 The Web-based expert system.

2.5 The Expert System Model.

So, what is the structure of the program after all? And what does it do, and how ? The best way to model the expert system architecture is to use a specialised tool. One

such tool is the Unified Modelling Language (UML). UML may be regarded as the successor of the Object Oriented Analysis and Design (OOAD) methods that proliferated during the method wars of the '80s and early '90s. UML represents the unification of the three main modelling language methods within the industry: Booch, Rumbaugh and Jacobson.

We will use the UML to create both the conceptual (static) and behavioural (dynamic) models of the expert system.

2.5.1 The Conceptual Model.

The conceptual model will represent the architecture of the expert system. The UML provides a specialised toolset for conceptual modelling, called the class- and object diagrams.

The class diagrams are defined at the model level - meaning that they represent a generic model of the expert system (e.g. a 'Knowledge-based Expert System'), while the object diagrams are defined at the user model level, which allows them to represent a particular system (eg. 'The Conversion Course Advisor').

The object diagram for the studied expert system is shown in Figure 3 and it has been derived from a generic class diagram. Stereotypes (the items enclosed in guillemots << >>) have been used to explain the classes the objects have been derived from (to avoid showing the class diagram as well). The boxes represent objects, and the lines connecting them represent associations. The filled diamonds ( ) define a composition, that is, a relationship where the components may only belong to one whole at a time and where the components may not exist outside the relationship. The arrows ( ) show the navigation directions, with explanation of the associations.

The diagram shown in Figure 3 is self explanatory (this is the actual purpose of the UML!). The user-expert system interaction occurs through the Applet Window which sends the problem conditions (answers to questions) to the Java Applet, which holds all the temporary data. The inference engine uses the knowledge base for the rules

http://www.rational.com/uml


8

Figure 3 Object diagram of the expert system. (adapted from Ref.7)

and fixed facts, and the Applet for the dynamic facts (asserted at run-time). The knowledge base contains the fixed facts and the rules. Finally, the solution is delivered to the applet window which forwards it to the user.

2.5.2 The Behavioural Model.

After modelling the static aspect of the expert system, we would like to analyse the interaction in time of the expert system components.


Figure 4 Sequence diagram of the expert system. (adapted from Ref.7)

For this purpose we will employ another UML subset : the sequence diagram, which shows how the objects communicate with each other over time.

The Problem temporary object is created by (a part of) the applet and is then passed to the inference engine which cycles through the knowledge base looking for solutions. Once the final solution is found, the Problem temporary object destroys itself and the inference engine passes the solution to the Applet window.

The boxes in the diagram are the objects, and the arrows are messages. The slim vertical rectangle represents an activation of the knowledge base.

2.5.3 The Knowledge Base.

Modelling the knowledge base is both a necessary and fascinating exercise. We will only attempt to describe a few rules here because of the time and space limitations.

In order for an expert system to be understood, it is not enough that the knowledge resides in a software representation within a knowledge base. It must also exist (partially at least) in a document. In the case of the knowledge base, one such document would describe the meta-rules - the rules on how to create and maintain the expert system rules).

With UML, we can represent the rules as objects. In the Object Oriented Paradigm (which UML is based on), objects have attributes and behaviour (consisting of operations). Based on these concepts, the rules representation would be (Figure 5):

Figure 5 UML rule r

A more interesting and potentially efficfor the rules: UML rule icons. Using 6.

St

Prereq. marked 'needed' and not 'known' and not

already available ('done')

Find module with outcome matchinthe prereq., scanmodule prereqs,

mark 'to be matche

Match::Find_Module

Start::Initial_QueryX

If module with outcome matching

prereqs found

Mark module as 'enrolled in', scan

mark all its outcomes as 'don(available to user

Match::Mark_Rest

Find_Module

Mark_Rest, Ask_Add_

Ad

ithenPart = " ask for Q

art::InitialQuery1

epresentation (adapted from Ref.7)

ient way is to create a dedicated representation the icon concept, rules would look like in Figure

g d'

For each prereq.: If prereq. marked 'to be matched'

query user: already known ?

If yes, mark prerq 'known', if not mark 'needed'

Retract 'match'

Match::Ask_Add_Questions

Find_Module

&

e' )

If modules marked 'enrolled in' exist

Scan the module (sem., CP ,subj)

and print out

Print::Print_Modules

Print_Proj_Mods

Q Chk, Find_Module

Show_Hints

d_CP, Proj_Mods, Print::Print Mods

fPart = " job type Database_Admin " uery Optimisation Knowledge & assert the user answer "

9


10

Figure 6 Rule icon UML representation (adapted from Ref.7)

2.5.4 Hybrid Functional Graph / Sequence Diagram

In an attempt to best describe the functionality of the expert system, a 'hybrid diagram' was also developed - mixing graph and sequence diagram elements. The diagram is shown in Appendix A.

2.5.5 The Details

This section explains how the implementation of the program has been accomplished. JESS, like CLIPS (and LISP), uses the list construct to hold the data. The facts may be

asserted manually (i.e. hardcoded in the knowledge base) or at run-time. They are implemented as lists containing one or more other lists. Example:

(attribute (type job)(value "Database Administrator))

Templates are similar to classes and contain models for the facts. For this particular system, three types of templates have been used:

• goal: a special type of fact, only used to start the expert system; • attribute: a general purpose fact consisting of a type and a value; • module a fact type describing the module information.

Example: (deftemplate module ; the module information template

(slot name) ; this is the equivalent of a class (slot CP (type INTEGER)) (slot parent_subject) (slot semester (type INTEGER)) (multislot prerequisites) (multislot outcomes) )

A slot declares a field within the template - actually a list itself. A multislot declares a multifield, i.e. a list with more than two members. An example will make this clearer:

(module ;a particular module - the equivalent of an object

(name Query_Optimisation_Evaluation) (CP 2) (parent_subject Database_Management_Systems)

(semester 1) (prerequisites SQL_Data_Definition_Language Data_Storage)

(outcomes Query_Optimisation Relational_Operators) )

This is a module object example where the prerequisites and outcomes list both have more than two members. This provides a very convenient way to accommodate a variable number of members within a list, without any special requirements.

The rules in the JESS environment take the following form: if-part => then-part. An

example rule (taken from the actual program) would look like this: (defrule RuleDB1a (attribute (type job)(value "Database Administrator"|"Database Designer"))


11

=> (printout t "Databases Knowledge." crlf crlf "Do you have Database Architectures knowledge ?|explanatory|This type of job requires Database Architectures knowledge|yes|no|end") (assert (attribute (type Database_Architectures) (value (readline)))) )

An extensive coverage of the development environment and the GUI is beyond the scope of this document. Please use references in Section 6 for additional information. The principle used in the expert system prototype is as follows:

• modules are seen as objects having interfaces; the interfaces are the prerequisites and the outcomes. A prerequisite or an outcome is an item contained in a prerequisites- or outcomes list, further contained within the facts.

• we start off with a set of initial facts, asserted according to the answers of the user on the job domain and job type queries. This creates the initial unsatisfied prerequisites.

• we try to match these prerequisites against the outcomes already contained in the module facts. This process scans the outcomes lists of all the module facts in the database for matches with the unsatisfied prerequisites.

• when a match is found, the module is marked as "needed" and its prerequisites list is also scanned for new prerequisites. The initial prerequisite for which now the match was found for is marked "done".

• any prerequisites found that are not already declared either "known" by the user or are already satisfied by the existing modules will trigger additional questions for the user;

• according to the user's answers, the prerequisites are either declared "known" or added to the list of unsatisfied prerequisites

• the process is repeated until no unsatisfied prerequisites are left. At this point, all prerequisites are either satisfied ("done") or already "known" by the user.

• the list of all modules marked as "needed" is printed out. Some special modules are automatically added, such as the project modules (which will be present regardless of the user's prior knowledge)

2.5.6 The Constraints.

This is a section not to be overlooked. Some constraints are necessary in order to define the problem and enable a finite solution to be produced. Others are necessary to limit the problem and/or to enable focusing on a particular aspect at a time. The current constraints on the problem are:

• the outcomes of a module must be distinct;

• two modules may not produce the same outcome: if two modules teach approximately the same concept, a different keyword(s) must be used both in prerequisites and outcomes. This makes sense in a real world case.

• per total of module pool, it is desirable (and expected !) that ALL the module prerequisites listed are satisfied by outcomes of the modules on offer. The program includes a mechanism for checking this constraint.

• nil prerequisites are allowed and expected for the system to reach a finite conclusion; a nil prerequisite would mean that common knowledge is still expected from a technical graduate, such as basic maths, etc.


12

• cyclic dependencies between any two modules are disallowed (e.g. if module A needs module B, module B must NOT need module A). Such a dependency would make the system cycle forever: need A - need B - need A -… Should this situation occur, the subject must be re-divided in non-cyclic dependent modules.

Further constraints may be added in the developing the expert system,. However, each addition must be carefully considered. Such constraints may be:

• maximum number of year X modules: may conflict with the concept of a Conversion Course and limit the flexibility of the expert system;

• maximum number of modules per Semester: an objective constraint. The present system does not obey this constraint. A future version may address this important problem. In real life, subjects tend to be equally distributed in all Semesters. The problem is however that modules / subjects from 2 or three years of study may be chosen. This is to be further investigated.

• balanced number of modules in each Semester: same as previous.

2.6 Development milestones. The general development paradigm has been the spiral, which essentially means going

through some essential stages repetitively, but at a higher level each time. First, a very simple prototype (core - a prototype of the prototype) has been developed. This has contained a few rules and some simple facts.

From that point on, new rules and new facts have been added progressively, always keeping some previous versions available, in case fatal errors occurred.

The milestones in the development process of the expert system prototype have been:

• A proposal has been submitted to the convenor. Preliminary development was started at the same time (information collection).

• Feedback for the proposal was received from the subject convenor. This has ensured the project is the right size, has the right objectives, etc for the available amount of time and resources allocated. As a result of the feedback, a firm decision was made as to the method of implementation of the prototype.

• The data gathering stage has been minimised since real data will be obtained in a subsequent stage, for the full version of the expert system. In the meantime, fictional (but credible) data has been used. For some subjects this data is quite accurate already (i.e. Database Management Systems, Software Architecture, Computer Communication Networks, etc), but it only reflects the CURRENT subject offering and may not even be available for the Conversion Course.

• Coding of the knowledge in the knowledge base has been achieved with a standard text editor, given the fact that the particular file format used (.CLP) is plain text. A separation of the rules and the fixed facts (i.e. the module information) could be considered for a larger knowledge base size, although it is desirable to keep the facts and rules together (for debugging and extensions). File separation guidelines have been provided in the listing anyway.

• Testing has occurred at every stage. The Java application version of the expert system was preferred for development, using the JVM (Java Virtual Machine) on an Intel Pentium Win98 platform. However, the bytecode produced is usable on any platform for which a JVM is available (currently running on Apache in UNIX).

• Currently the expert system has been released on the author's web page (http://www.cit.gu.edu.au/~noran) as a beta-version prototype.



13

• The next stage is the 'official' release of the prototype, accompanied by a PowerPoint presentation if necessary (subject to negotiation with the convener).

The expert system is freely accessible on the Web. This should allow everyone to be

able to test it and assess the impact of this technology on the potential users.

3 Using the Expert System. This Chapter will briefly explain the options available in running the expert system. It will

also look at the inputs, outputs and behaviour of the program.

3.1 Operating the program.

Once the platform and shell have been chosen (refer Chapter 1 Section IV), several decisions had to be made in the process of program implementation.

3.1.1 Options

As previously stated, the expert system is implemented using Java. This means that the inference engine and the graphical user interface (GUI) are actually composed of pieces of bytecode (.class files), either standalone or archived in a Java archive (.jar file). In order to be able to run the Java implementation of the inference engine and the GUI, a Java Virtual Machine (JVM) is needed. This is freely available for most of the platforms, as a set of tools (Kit); also, most web browsers (eg. Internet Explorer, Netscape, Opera, etc) are Java enabled, which means they can read and interpret Java applets contained within Web pages.

The expert system shell and user interface provide for two options to run the program:

• as a Java application, using the JVM (refer Figure 7). Normally this option will only be used during development, and when access to the .class files (rather than the Java archive .jar) is granted. It is usually faster to load (there is no need for a web browser to load first, load a web page and then load the applet).

Course Advisor Expert System Using the Expert System

14

Figure 7 The expert system as a Java application.

• as an applet, using a host web page and a web browser (refer Figure 8). This is the intended way to run this application. Users will load the Web page on their browsers, and this will trigger loading and running the Java applet which is the expert system (containing the CLIPS inference engine). The expert system will load and start the rule base, and the consultation process will begin.

3.1.2 Running a consultation.

Currently the program is available as an applet installed within a host page at the address http://www.cit.gu.edu.au~noran/CCourse.htm. Launch your web browser and point it to the indicated address. The following picture will appear:

http://www.cit.gu.edu.au~noran/Ccourse.htm


15

Figure 8 The Expert system embedded in a Web page.

The user interface is extremely simple. Basically, to interact with the system you have to select one option from the radio buttons area and click the button.

The consultation can be restarted at any time by clicking the button. Another (radical) way to abort a consultation is to leave the page the applet is on.

After reading the Notes on the introductory screen, click to start the consultation. After some preliminary questions, the menu shown in Figure 7 will appear. The system will initially require a job domain to target and then ask for a more specific employment opportunity (within the chosen domain) that the user may seek.

After that stage, the system will ask questions about specific knowledge the user may already have and which can be used to enrol in the necessary modules. If the required knowledge is not already present, the system will seek an appropriate module whose outcomes satisfy the present prerequisite (need for knowledge).

The vast majority of modules also have their own prerequisites, and so the system will seek to satisfy all those prerequisites before enrolling the user in the module. This process will occur recursively - i.e. a module with n prerequisites will require other m module(s) that satisfy them, and the latter m module(s) will also have p prerequisites that need to be satisfied, etc..

Every time a new prerequisite is discovered, the user is queried whether he/she has the knowledge to satisfy it. If not, a suitable module is chased to do the job.


16

Although this would seem to create a larger pool of prerequisites each time, in reality there are many prerequisites being satisfied by the same module, and the knowledge base was designed so that there can be no unsatisfied prerequisites - which should be the real case (meaning that Griffith may cater for all the needs of a postgraduate enrolled in a Conversion Course).

After asking all the necessary questions, the expert system will eventually produce an output, containing:

• Stated (existing) knowledge. • Necessary modules, with Parent Subject, Semester, Credit Points. • Project modules (the Conversion Course must include a 40CP 'Project') • Total Credit Points. Some advice is given depending on this value • Unsatisfied dependencies (this should not appear unless there is an error in the rule

base - which is the web site / expert system maintainer's duty, not the user's fault. It is however a very good mechanism to check the rule base consistency and filter out spelling errors, and other human error. Therefore it is ON by default).

• Advice: - CP < 70 - existing knowledge may be overstated - 70 < CP < 105 - Ok. Still, should be around 100CP. - 105 < CP < 150 - existing knowledge may be understated - 150 < CP - the job may be unsuitable for that person

(too little knowledge) The results are shown in the applet's own Hints and Results window. At this stage, the

output may be copied into the clipboard by standard Windows procedure: select the text and press CTRL-C. Then the contents of the Clipboard may be pasted in any other word processor and printed.

A sample run of the expert system for an 'Artificial Intelligence Researcher' while stating some prior knowledge has produced the output shown in Figure 9.

***************** Consultation Output Started ***************** Job targeted: Artificial Intelligence Researcher . ---------------------------------- Prior (existing) Knowledge stated: ---------------------------------- Java_API . Information_Systems_Concepts . Entity_Relationship_Model . Inference_Nets . Artificial_Intelligence_Trends . Knowledge_Representation_Principles . ======================================================= The following Modules are needed: --------------------------------- Semester I: ----------- Programming_I_2, subject Programming_II, Sem. 1, 5 CP. Advanced_Information_Systems_Development, subject Introduction_to_Information_Systems_Development, Sem. 1, 5 CP. Programming_Language_Implementation_1, subject Programming_Language_Implementation, Sem. 1, 5 CP. Programming_Language_Implementation_2, subject Programming_Language_Implementation, Sem. 1, 5 CP. Introduction_to_Artificial_Intelligence_1, subject Introduction_to_Artificial_Intelligence, Sem. 1, 5 CP.


17

Programming_I_1, subject Programming_II, Sem. 1, 5 CP. Natural_Language_Processing_Basics, subject Natural_Language_Processing, Sem.1, 5 CP. Natural_Language_Processing_2, subject Natural_Language_Processing, Sem.1, 5 CP. ------------ Semester II: ------------ Database_Management_Systems_2, subject Advanced_Topics_in_Database_Management_Systems, Sem. 2, 5 CP. Database_Basics, subject Data_Modelling, Sem. 2, 3 CP. Intelligent_Decision_Support_Systems, subject Intelligent_Decision_Support_Systems, Sem. 2, 5 CP. Intelligent_Decision_Support_Systems, subject Intelligent_Decision_Support_Systems, Sem. 2, 5 CP. Expert_Systems_Advanced, subject Expert_Systems, Sem. 2, 3 CP. Artificial_Intelligence_in_the_Future, subject Current_Issues_in_Artificial_Intelligence, Sem. 2, 5 CP. Expert_Systems_Design, subject Expert_Systems, Sem. 2, 4 CP. Expert_Systems_Basics, subject Expert_Systems, Sem. 2, 3 CP. ----------------------------------------- The following Project Modules are needed: ----------------------------------------- Artificial_Intelligence_Project_Part_1, subject Artificial_Intelligence_Project, Sem. 1, 20 CP. Artificial_Intelligence_Project_Part_2, subject Artificial_Intelligence_Project, Sem. 3, 20 CP. ======================================================= Total Credit Points = 113 . *************************************** WARNING: you seem to require over (the required) 100 Credit Points. ---------- -> It is possible that you haven't stated ALL your existing knowledge. -> You may also examine various courses of study by ASSUMING you had some of the knowledge. ---------- ADVICE: *Restart* and answer 'yes' to all existing / assumed knowledge.

***************** End of Consultation Output *****************

Figure 9 Expert system output (copied and pasted from the Java applet).

Note that there is no mechanism to ensure a balanced distribution of the modules within the Semesters. The algorithm for that kind of function may not at all be possible without careful subject planning and requires substantial programming effort.

Back to Table Of Contents

Course Advisor Expert System Beyond the Prototype

18

4 Beyond the Prototype. So, what is next ? If the concept proves to be feasible, then there is a lot of work to do.

4.1 A Full-blown Expert System.

The fully featured system will have to address all the shortcomings of the existing prototype and also:

• provide more error-checking, in order to ensure knowledge base consistency; • separate the known facts from the run-time asserted facts, so that they can be

maintained separately. This may or may not be an advantage (to be assessed); • provide a better alternative for the user to view / save /print the consultation

results and maybe re-run the consultation without having to answer all the questions again;

• the start-up time may also be improved - refer Section 4.3 in this Chapter.

While many of the implementation problems have been addressed during the expert system prototype design, there are other issues that will only become apparent when implementing the full version. Therefore, a suitable beta-testing period has to be allowed for.

Apart from these issues, the same (spiral) development paradigm and development stages may be used as for the expert system prototype.

4.2 Gathering the required knowledge.

As stated in Section 2, one of the limitations of the system has been the lack of real information regarding the modules within the subjects. While some information is available on the subject web pages, most of it is incomplete or not yet available.

The concept of modules has to be implemented; feedback from the teaching staff considered and modules suitably altered. The interfaces have to be carefully assessed so as not to leave open requirements (unsatisfied prerequisites within the pool of offered subjects - exception being basic requirements such as maths, physics)

A questionnaire is currently being developed in order to assist the teaching staff in identifying the modules within the subjects they convene. This will facilitate information gathering.

New knowledge may be added at any time, observing the knowledge base constraints.

4.3 The 'Right Implementation' - revisited.

A major bottleneck in using the existing prototype is the fact that the user's browser must download the expert system applet, which then runs in its own 'sandbox' (i.e. with restricted rights) on the host machine.

The Java expert system shell used (JESS 5.1) comprises several .class files totalising almost 270 Kbytes (compressed). This is very small compared with the current trends of files of several Megabytes. However, in applet terms this is quite sizeable and requires 20 to 30 seconds to download to the host machine. While this is not normally a problem (this is NOT a real-time control application where feedback from the system


19

must be received within milliseconds), a message must be displayed informing the user that the applet is downloading and asking for a little patience.

Enrolling in a Master subject is a quite important decision, both from financial and chronological perspectives. Also, the initial facts regarding the subject modules, etc will not change too often. Because of all these reasons, the users will most likely be willing to wait for the applet to download if in return they can get preliminary advice that can save them time and money.

There is however a better way. Since the beginning of active HTML content, CGI scripts and JavaScript have made it possible to accomplish data / input processing on the server side. The trend is however shifting away from CGI (Perl) programming towards the servlets concept. Servlets are applets with no graphical interface, which run on the server side.

The two main possibilities with servlets are:

• user -program interaction occurs via HTML pages containing FORM requests and the like;

• user-program interaction takes place via applet / servlet interaction: The applet runs on the host machine, and the servlet on the server. Of course, the applet is much reduced in size compared with the applet-only alternative - all it provides is a user interface to send user input and receive and display servlet output.

Figure 10 The servlet-based expert system. (adapted from Ref.2)

It is worth noting that the expert system may already be used in its present form, with an updated knowledge base resulting from a wide teaching staff consultation process. Although not very fancy and limited in features, it is intuitive, simple and it does the job (again, if the knowledge base is properly tuned).

4.4 Extending the Expert System.

Presently the expert system prototype is quite limited, but does prove the feasibility of having an advising tool for prospective students and teaching staff. Some issues are:

• Some of the modules have not been implemented for the prototype, since they are simply repeating the implemented concepts. (and the time was limited);


20

• The knowledge base information does not contain the real Conversion Course data due to the lack of suitable subject / module information;

• The Conversion Course has not been designed yet. The extent of the subjects that will be used in it is not yet known (eg. if Year 1 and 2 subject modules will also be included or not, etc).

• The concept of modules within the subjects has not been implemented yet. This concept will enable students to enrol in parts of a subject and be assessed for them separately.

• The user interface may not be the ultimate toolbar-loaded screen, but it does the job. And since this system addresses overseas students as well, it also has to be intuitive and easy to use.

• There is no maximum number of modules per semester limit (as yet). The above matters have to be approached in the attempt to extend and improve this

prototype. Hence the conclusions:

• Improve the user interface - use HTML pages / forms if possible or improve the applet general aspect - depending on feedback from users during beta-testing;

• Make use of the servlet technologies and base the RETE engine on the server rather than transferring the whole thing onto the client machine for the consultation. This implies using HTML pages and forms or applet / servlet communication.

• Revamp the knowledge base: reassess each module and its interfaces. Make use of the proposed questionnaire to interview the teaching staff and get real modules information.

• Optimise the additional questions mechanism so as to minimise the number of extra questions asked.

• Implement an algorithm to evenly distribute the modules by the semester they are offered in (if possible in the first place).

• Implement a mechanism to limit the number of modules per semester. Some of the above extensions require a considerable effort and may need to be initially

investigated for feasibility.

4.5 Knowledge base policies.

The knowledge base is the central component of the whole expert system. Therefore, a full-scale advisory system will need some quality control policies, such as:

• version / history control; • access control and logging (who accessed / modified the knowledge base,

when, what were the modifications, etc) • reliable backup; • periodic maintenance - check the accuracy of the facts in the knowledge base

reflecting the subject / module information; also check consistency after each knowledge base update. This task may be partly automated and linked with a main (existing?) subject database.

If the above conditions are not met, the system will not meet the requirements and may even give wrong advice to the users.


21


Course Advisor Expert System Conclusions and References

22

5 Conclusions. An expert system is a useful tool if its possibilities and limitations are acknowledged. An

expert system may not think for itself, nor assess whether the facts in its database are properly spelled (syntax), and if they are true and applicable or not (semantics). As with all IT software objects, the GIGO principle applies: Garbage In, Garbage Out.

If the knowledge base contains inexact facts and/or rules, it will reach the wrong

conclusions. Likewise, if the knowledge base is subsequently altered to duplicate a fact or rule, it may corrupt the whole judgement. Any modifications to the knowledge base have to be therefore carefully documented and more historical versions of the base kept. It is also recommended to have a list of the keywords used (a glossary).

Due to the timing and lack of resources (this particular Course is not designed yet and

limited time is available for development), a prototype has been constructed in order to test the concept. Data used in the knowledge base is partly fictional but credible.

Querying the reasoning of the expert system may be sometimes required. In the

implementation presented, this feature is only available to the developer / maintainer (the knowledge engineer). However, it may be made available subsequently if so desired. Usually the reasoning process is queried during debugging or if the decisions of the expert system may produce significant material damages or loss of human life.

The expert system prototype presented accomplishes the task of modelling a larger

system which may give preliminary advice to prospective postgraduate students worldwide. Such a system will appeal to a person willing to self-assess its ability to undertake a certain type of course, without making any material commitments, having to make international phone calls or write letters / E-Mail.

The expert system prototype is available on a link from the Expert Systems Design and

Development Subject at the address: http://www.cit.gu.edu.au/~noran.

6 References. 1. Giarratano & Riley (1998) Expert Systems: Principles and Programming, 3rd Ed.,

PWS Publishing Company, Boston, MA, ISBN 0 534 95053 1 2. R.F.Grove et al, (2000), An Internet Based Expert System for Reptile Identification,

Indiana University of Pennsylvania. 3. O. Noran, P. Bernus (2000) Project Proposal: Conversion Course Expert System,

School of CIT, Griffith University, Nathan Campus. 4. Ernest Friedman-Hill, (2000), JESS - The Java Expert System Shell, Distributed

Computing Systems, Sandia National Laboratories. 5. T. Reichherzer et al, (2000), JConsult v1.3, Institute Of Human and Machine

Cognition, University of West Florida. 6. O. Noran, (2000), Expert Systems Design and Development (Assignment Paper):

The Evolution of Expert Systems, Griffith University. 7. J. Schmuller, (1999), Teach Yourself UML in 24 Hours, SAMS Publishing Company,

Indianapolis, IN, ISBN 0 672 31636 6


Course Advisor Expert System Conclusions and References

23


Course Advisor Expert System Appendix A

A-1

Appendix A - Functional Diagram. This Appendix contains the combined functional graph / state diagram of the expert

system prototype. Please refer Section 2.5 for details.

time

Course Advisor Expert System Appendix B

A-2

Appendix B - Contents of the Disk. The contents of the included floppy disk is as follows: TestCCourse.htm Test web page containing the Expert System applet; CCourse.clp The facts / rules knowledge base (CLIPS format). At this stage

the separation of facts and rules was not necessary. JConsult.jar Java Archive containing the modified GUI wrapper. To run the

expert system as an application, the JConsult.jar archive needs to be extracted with its entire structure in the installation directory (e.g. using WinZip);

Expert.bat Batch file launching the application version of the expert system. In order to run the application version, the Java Development Kit (JDK)1.2.2 for the suitable platform needs to be installed on the host machine and the PATH and CLASSPATH variables be appropriately set.

The batch file will run without modifications if the files (except CCourse.clp) are installed

in a subdirectory called Jess. The file CCourse.clp needs to be installed in a subdirectory of the installation directory (Jess51) called RuleBase.

The CCourse.clp program listing has not been included in printed form due to its size (approximately 30 pages in Times New Roman 9 pt. print).

The expert system protoytpe is available for beta-testing on a web page at the URL: http://www.cit.gu.edu.au/~noran/cit_6105.htm.

http://www.cit.gu.edu.au/~noran/cit_6105.htm

es course advisor

Documents