Student Advisor Expert System

101  Download (0)

Full text



Honours Project Report

Student Advisor Expert System


Lynray Jefferson Mpho Barends

Supervised by: Dr. Audrey Mbogho

Category Min Max Chosen

1 Requirement Analysis and Design 0 20 15

2 Theoretical Analysis 0 25 0

3 Experimental Design and Execution 0 20 0

4 System Development and Implementation 0 15 15

5 Results, findings and Conclusion 10 20 15

6 Aim Formulation and Background Work 10 15 15

7 Quality of Report Writing and Presentation 10 10

8 Adherence to Report Proposal and Quality of Deliverables 10 10

9 Overall General Project Evaluation 0 0

Total Marks 80 80

Department of Computer Science University of Cape Town




Student advising is a course planning service available to students, to help them make good choices about what courses to enrol in, particular to their interests and skills. As it is now, majority of the process is done by a human. This process can prove to be quite tedious in some aspects, as students need to go in personally for advisors to sign off on adding and dropping of courses. There is also limited availability to this service, as only few advisors are available, and they themselves, usually have a busy schedule

The proposed solution to this problem is a prototype web-based Expert System that offers an interactive user interface where students are able to request to add or drop courses. The Expert System provides comprehensive feedback when users try to add or drop courses that may affect their course plan. The system also recommends certain courses to users based on their past performance and their course interests.

The application was designed with the aim to allow users to manage their courses in a fast and user friendly manner. The user interface was judged to be intuitive and usable, however some improvements were necessary. The system has been validated by the back end

designer, to ensure that the information put into the system, was as correct, complete and consistent, as possible in the time frame given. User evaluation and Student advisor

evaluation was performed during the process, where positive feedback as well as many useful suggestions for further improvements to be made on the system. All of the users involved in the testing process stated that this system has the potential to have a positive impact on the student advising and course management process.




1.1PROBLEM OUTLINE ... 6 1.2PROJECT OVERVIEW ... 6 1.2.1 Proposed System ... 6 1.2.2 Objectives ... 6 1.2.3 Relevance... 7 1.2.4 Thesis Outline ... 7


2.1WHAT,WHO,WHY? ... 8


2.2.1 Dropping a course... 8

2.2.2 Adding a course ... 8

2.2.3 Recommending ... 8

2.2.3 Assessing Eligibility for Graduation ... 8


2.3.1 Past Performance and courses ... 9

2.3.2 Chosen Degree ... 9 2.3.3 Chosen Major ... 9 2.3.4 Prerequisites /Co-requisites ... 9 2.3.5 Time of year ... 9 2.3.6 Interests ... 9



3.1.1 Expert Systems vs Human Experts ... 10

3.1.2 Expert Systems vs Conventional Programs ... 10


3.2.1 Knowledge Base ... 11

3.2.2 Working Memory ... 12

3.2.3 Inference Engine ... 12

3.2.4 User Interface ... 13


3.3.1 Rule Based System ... 14

3.3.2 Fuzzy Rule Based System ... 14

3.3.3 Frame based systems ... 14





4.3.1 CLIPS ... 16

4.3.2 DROOLS ... 16

4.3.3 JESS ... 17



4 4.5.1 Facts ... 17 4.5.2 Templates ... 18 4.5.3 Rules ... 19 4.5.4 Functions ... 21 4.5.5 Queries ... 21




5.1XCON ... 23


5.3ESAU ... 24



5.6SUMMARY ... 25


6.1APPROACH ... 26 6.2MOTIVATION ... 26 6.3PROJECT DIVISION ... 27 6.4KNOWLEDGE ENGINEERING ... 27 6.4.1 Knowledge acquisition ... 28 6.4.2 Knowledge Representation ... 32 6.4.4 Inferencing ... 33

6.4.5 Evaluation and Validation ... 33

DESIGN ... 35

7.1SYSTEM REQUIREMENTS ... 35 7.1.1 MVC ... 36 7.1.2 Technologies Used ... 37 7.2SYSTEMS ARCHITECTURE ... 38 7.2.1 Database Design ... 38 7.2.2 File Breakdown ... 39


7.3.1 Login ... 41 7.3.2 Home Page/Overview ... 42 7.3.3 Add/Drop Procedure ... 44 7.3.4 Course recommender ... 47 7.3.5 Course browser ... 49 7.3.6 FAQ ... 49 7.4DESIGN CHALLENGES ... 50 7.4.1 Integration ... 50

7.4.2 Compulsory Courses for Major ... 50

7.4.3 Prerequisite Check ... 50




8.1.1 Approach ... 52


8.2.1 Testing Rules ... 52

8.2.2 Testing the database ... 53

8.2.3 Testing various ‘student profiles’ ... 53

8.2.4 Testing adding courses ... 54

8.2.5 Testing recommended courses ... 54

8.2.6 Testing dropping Courses ... 55

8.2.7 Testing changing of graduate information ... 55

8.2.8 Testing course browser ... 55

8.2.9 Overview of validation testing results ... 55


8.3.1 User Testing By Front End Designer ... 55

8.3.2 Final Student Acceptance Testing ... 56

8.3.3 Discussion ... 58


8.4.1 Final Student Advisor Evaluation Testing ... 58

8.4.2 Discussion ... 59


9.1OVERVIEW ... 60 9.2 ACCOMPLISHED OBJECTIVES ... 60 9.3LIMITATIONS ... 61 9.3.1 Time Limitations ... 61 9.3.2 Data Limitations ... 61 9.4FUTURE WORK ... 61 9.4.1 Timetable ... 61 9.4.2 Course Comparator ... 62

9.4.4 Student Advisor Interface ... 62






Chapter 1


1.1 Problem Outline

Student advising is a service given to students in which advisors guide them during their university career, with regard to course choices, changing of degree plans, and assuring that the student’s course plan eventually leads to a qualification. Parts of this process can be quite tedious. One example would be users having to return to the advisor multiple times due to incomplete forms when they are trying to add or drop a course. Another issue is that the availability of service is limited to the number of advisors and their schedules. This project aimed to automate at least some of this process and increase the availability of it, by developing a web-based student advisor system which any current undergraduate BSc (Bachelor of Science) student could have access to. The system combines inputs provided by the student via a user friendly interface, with student information residing in a student database in order to give comprehensive and intelligent advice

1.2 Project Overview

1.2.1 Proposed System

Our main focus in this project was to design an expert system (ES) that simulated tasks of a human student advisor. This was a software engineering project, so there was a zoomed in focus on the design of the front and back end. As students are constantly on the move, we required a web based interface that allowed fast expert-level advice from the system. The user interface (UI) needed to be simple and user friendly. The back end focuses on making the knowledge as complete, consistent and accurate as possible. Like any other web-based system, it would be useful to incorporate security via a login system for the user interface. We have assessed whether an expert system would be sufficient in taking a human student advisor’s place or at least making certain advice more available to students.

1.2.2 Objectives

At the end of this project we planned on presenting a web-based expert system that:


Accesses relevant information about a student

This information would be taken from a database – providing us with a history of the



us to give better advice and recommendations. It would also speed up the process and decrease the amount of input required by the student


Provides a friendly user interface for students

The user interface needs to be intuitive, and easy to use, as students from various years will be using it. Students will also be using it for various reasons, such as adding, dropping, and receiving course recommendations.


Assesses whether a student should be allowed to drop or add a course

Our system will be able to give students warnings about adding or dropping certain courses, depending on the courses they have taken in the past and their selected major. A variety of warnings will be given, dependent on the different situations.


Recommend appropriate courses for students

Courses will be recommended based on the student’s past performance and their subject interests. Specific recommendations may also come from the various departments.

This system has the potential to have a positive impact in universities, as many students need advice, but do not always have the time to go to an advisor. Advisors are usually lecturers or researchers, so their time is limited and their advice may be affected by their knowledge of the handbook, and/or degree rules, among other factors.

1.2.3 Relevance

Student advising is a complex and time consuming task involving advisors guiding and,

explicitly or implicitly, contributing to student’s academic career decisions. Frequent requests from students include advice on changing or dropping a course, and career guidance,

requiring advisors to have a good grasp on curriculum knowledge, and prerequisites. Certain direct factors (e.g. lack of knowledge of expert) and indirect factors (e.g. advisors mood, stress levels, availability) have an effect on the quality of advice given. Hence, alternative and more automatic choices have been suggested [1] [2]. This system would also decrease the need for paper-based forms.

1.2.4 Thesis Outline



Chapter 2

Student Advising and Degree Rules

2.1 What, Who, Why?

As mentioned before, student advising is a service given to students to help them make good choices with regard to the courses they take during their university career. Advisors are usually lecturers or researchers that have a good grasp on the courses offered and their content, as well as a set of skills similar to that of a counsellor. Advisors see a wide range of students and they need to tailor their advice and recommendations to each student’s specific needs.

Advising is a necessary addition to departments, as students may not know of the courses that are available to them, that would suit their paths, goals or interests the best. This service is especially needed by first years, confused students, or students wanting to change their course path.

2.2 Student advisor-assisted tasks

2.2.1 Dropping a course

When students are not satisfied with a course or are struggling with it, it is necessary that they drop it before it is too late. Currently, students need to fill out a form with all the details of dropping the course. Often, students are advised to replace this course with another course, so that they would still be able to graduate.

2.2.2 Adding a course

Adding a course is a similar procedure to that of dropping one. When evaluating whether a student can add a course or not, advisors need to confirm that they have all the prerequisites and that no lecture clashes occur. In some situations an advisor may also bypass the prerequisites if they think there is enough evidence that the student will cope.

2.2.3 Recommending

As advisors gain more experience and come into contact with students in various situations, they become better at recommending courses. When a student does not know which electives to take a student advisor would most likely be the one to provide them with course suggestions.

2.2.3 Assessing Eligibility for Graduation



When advising students, there are a few factors that need to be assessed in order to give them the best advice. These factors create boundaries for the feedback and alternative choices.

2.3 Factors that affect advice

2.3.1 Past Performance and courses

It is usually a requirement for the student to bring their transcript with them, when visiting the advisor. This provides the advisor with a sense of their strengths and course interests. It is also used to judge whether the student has the sufficient prerequisites when wanting to add a course. It is also used to determine whether the student will be able to graduate with their current course choices.

2.3.2 Chosen Degree

Each degree has a list of general rules which govern the requirements to receive the qualification. Examples of rules include: minimum amount of credits, courses that will not count towards the degree, and compulsory courses, to name a few.

2.3.3 Chosen Major

Each major has a set of compulsory courses that need to be completed and passed in order to graduate. The students’ choice of major generally gives insight into their predominant course interests. However, sometimes students change their major along the line, as their expectations have not been met.

2.3.4 Prerequisites /Co-requisites

Prerequisites are required courses or certain requirements that have to be met in order for a student to be allowed to take a specific course. In special circumstances, these requirements can be disregarded, if deemed so by the Dean, Head of Department, or student advisor. The same applies to co-requisites. Co-requisites, however, allow the courses to be taken either before or parallel to taking the desired course.

2.3.5 Time of year

There are time limitations to dropping or adding courses for free. Furthermore, there are limitations to whether a student is allowed to drop or add courses at all. Advisors need to make sure they are aware of these dates.

2.3.6 Interests



Chapter 3

Expert Systems

Like Knowledge Based Systems, expert systems originate from Artificial Intelligence. ES research arose around the mid 1960’s. Expert Systems are systems that attempt to increase the availability and efficiency of expertise by imitating the human reasoning process of an expert. An expert can be defined as someone who possesses superior understanding of solving domain specific problems [4]. This superiority is gained and perfected through experience [1].

ESs usually deal with problems of diagnosis and advice (selecting a hypothesis) or ones of design and planning (creating a solution with all the requirements) [4]. Majority of expert systems aim to aid humans with complex problems and decision making that requires a large amount of knowledge. ESs are usually employed to decrease the cost of a service or increase the quality of it. It fuses various sources of knowledge and experts into one, giving it the potential to be as powerful and reliable as a human, if not more [5].

Applications of ESs have a huge variety, including systems used for psychiatric treatment, scheduling, advising, tutoring, agricultural planning, medical support or planning, and even robotics [6].

3.1 Motivation for use of Expert Systems

3.1.1 Expert Systems vs Human Experts

Computers manage and monitor student progress and more complex problem solving better and are more cost effective than personnel [2]. Expert systems usually deal with consultation processes. Student advising is naturally a consultation process between the student and advisor and most expertise used during a consultation is codified in the curriculum, making the knowledge acquisition process easier [2]. Expert Systems can increase the probability, frequency, and consistency of making good decisions, help to distribute the human expertise, facilitate quick low-cost expert-level decisions, permit objectivity and dynamism (modularity of structure), and finally, they provide a convenient environment for advising to take place [7].

3.1.2 Expert Systems vs Conventional Programs



domain without having to rebuild the program, only updating the knowledge, which is separate from the program [8]. Another advantage is its explanation facility and problems that require a higher level of thinking and reasoning which conventional algorithms do not handle well. For some complicated problems no straight forward solution technique is known at all, as these problems do not have a predefined structure that can be easily manipulated by traditional means. Artificial Intelligence is used to tackle such problems that require a thought process analogous to human reasoning [4]. The core goals of AI research are

reasoning, knowledge, planning, learning and communication [4]. Expert systems focus more on the reasoning aspect of AI, with the aim of encapsulating human knowledge and

reasoning in a computer.

3.2 Structure of an Expert System

The structure of an ES consists of 4 major components: a user interface, knowledge base, working memory, and an inference engine. The modularity of these components facilitate their flexibility i.e. the knowledge base is able to mature and change, without affecting other systems [5].

3.2.1 Knowledge Base

The knowledge base of an expert system is where all the knowledge of the system is held. It consists of all appropriate information, data, rules, and relationships [6]. There are various ways in which knowledge may be represented, such as rules, frames, or databases. The choice of representation usually constitutes the type of expert system. It is crucial for the knowledge to be consistent and correct, if the results are to be trusted. The initial facts form



the background information built into the system. The rules include both, the production rules that apply to the domain of the expert system, and the heuristics, or rules-of-thumb, that are provided by the domain expert in order to make the system find solutions more efficiently.

3.2.2 Working Memory

The working memory is where the facts received from the user, conclusions and inferences are held [9]. These facts all together form case specific knowledge. In certain learning expert systems, such facts could eventually form part of the core knowledge base of the expert system, as opposed to being discarded after the session is complete.

3.2.3 Inference Engine

The inference engine drives the expert system as it forms the central part of a rule engine. An inference engine is similar to a search engine [7], as its’ main purpose is to seek information and relationships from the knowledge base [10]. It attempts to model the reasoning process [1] by using techniques to strategize which knowledge to apply and in what order [7] [11]. Like a human expert, the inference engine hopes to provide the user with appropriate answers, predictions, and advice [7] [10] [12]. It also serves as an explanation facility [10], where users can query how the system arrived at the advice or outcomes it gave.

Two inference strategies [1] used, are forward chaining (data-driven) and backward chaining (goal-driven) [10]. The former starts with facts known by the system and works forward towards conclusions. The latter starts with a conclusion and works backwards to prove it, using known facts.



Figure 2: Inference Engine of ES

Pattern Matcher

The inference engine needs to decide on what rules to fire and when to fire them. This is the job of the pattern matcher, to decide on which rules to fire based on the contents of the working memory. The difficulty of this process depends on the number of rules in the rule base and the number of facts in the working memory. Pattern matching is often the most expensive part of the entire process [9].


Once the inference engine has decided on which rules should be fired, it still needs to decide on which rules to fire first. This list of rules is stored on the agenda. The agenda in turn uses a conflict strategy to decide on the ordering of the rules to be fired. This is based on priority (salience).

Execution Engine

Once the ordering of the rules is complete, the execution engine fires the rules.

3.2.4 User Interface

The user interface (UI) is the point of communication between a user and a computer-based advisor. Through the interface, the user can query the ES and the system can collect

information from it to deduce conclusions and provide advice [8].

In our case the UI provides the user with information received from databases, and certain tasks they can perform, and the expert system will then display conclusions, advice or warnings, depending on the user’s choices and the information in the database.



3.3 Types of Expert Systems

3.3.1 Rule Based System

Rule Based Systems (RBS) encode the knowledge as if-then rules. A rule refers to a conditional statement that connects the conditions with actions or outcomes. Rules are appropriate for representing logical implications. They come in different forms [5]:

Reactions [4]:

Situation/Action – e.g. if temp<10 then turn heater on.

Or Deductions [4]:

Premise/Conclusion – e.g. if nose is running then condition is flu. Antecedent/Consequent – e.g. if x can fly then x is a plane.

3.3.2 Fuzzy Rule Based System

As information is usually surrounded by uncertainty and imperfection, it is necessary in some systems to handle this. The human reasoning process is enabled to handle these grey areas, however, our methods are usually difficult to express. Fuzzy logic provides a framework with which we can model this uncertainty.

Fuzzy expert Systems (FES) make use of fuzzy membership functions and fuzzy rules [14], in comparison to Boolean logic used by RBS. The rules are in a similar format to RBS, however, conditions in FES describe to what degree the rule applies, and the consequent assigns a membership function to each output variable. An example of a Rule would be:

If Project Marks are Low and Test Scores are high then the chances of passing the course are medium

Fuzzy concepts convert multiple rules with clear input into specific linguistic variables e.g. A, B, C, D could be expressed as Excellent, Good, Okay, Bad. The main components of a FES are a Fuzzy Rule Base, an Inference Engine and a defuzzification Interface.

3.3.3 Frame based systems

Frame Based Systems use frames to store knowledge. Frames are appropriate for defining terms and describing objects or taxonomic classes or membership relationships between frames. These frames communicate by sending messages to each other, which in turn, is interpreted and acted upon [13]. Frames represent stereotyped situations and can capture common sense inferences by reasoning, using anticipatory matching [15].



Chapter 4

Expert System Building tools

A majority of programmers make use of procedural programming because most problems are best solved in this way. Expert System programming, however, make use of declarative


4.1 Declarative vs Procedural Programming

In procedural programming, the programmer tells the computer what to do, how to do it, and in what order. Problems that are well suited for this type of programming, are problems in which the inputs are well specified and for which a known set of steps can be carried out to solve the problem [9]. Mathematical computations, for example, are best written

procedurally. In both procedural and object-oriented programming, the programmer writes all the logic that controls the computer. A purely declarative program, in contrast, describes what the computer should do, but omits much of the instructions on how to do it.

Declarative programs need to be executed by a system that understands how gaps need to be filled in and how the information can be used to solve the problems at hand [9]. The use of only the important information facilitates understanding of the program more than procedural programs. The rule engine, determines which rules apply at any given time and executes them as appropriate, thus, making some solutions to complex problems shorter and easier to understand. The writing of rule-based programs is also easier, as you can

concentrate on the rules for one situation at a time, without having to really worry about others.

Declarative programming is seen as a more natural approach to tackle problems that cannot always be solved by a clearly defined algorithmic solution [9]. The following problems that usually fall under this category are:

 Diagnosis

 Prediction

 Classification

 Pattern recognition

 Situation awareness

4.2 The Rete Algorithm



1. Find all rules that are satisfied by a set of facts in working memory 2. Form activation records out of these rule/fact associations

3. Choose one activation record to execute

The initial rules finding facts algorithm kept a list of rules and checked each one’s left hand side (the if part) in turn, against the facts inside working memory [9]. This resulted with a set of activation records for all that matched. After choosing one record to execute, the others would be disregarded and the whole process would start from scratch. This initial rules

finding facts algorithm was clearly found to be inefficient, as tests run on each cycle were

unnecessarily repeated in each iteration, receiving the same results.

The Rete algorithm improved on this, by remembering past test results across iterations of the rule loop [9]. Only new or deleted working memory elements were tested against the rules at each step. It also optimizes performance by organizing the pattern matcher in a way that these few facts are only tested against a subset of rules that may actually match. The Rete Algorithm is the basis for several generations of fast rule-based system shells, including: OPS5, ART, CLIPS, JESS, DROOLS and others. Each enhances and refines the algorithm to improve its’ performance or flexibility.


Construction of the ES will proceed by encoding the knowledge into languages understood by the computer. This may be enabled using an expert system shell. System shells come with an inference engine and user interface capabilities [16]. We considered 3 main options when deciding which one would be most appropriate for our system, namely, DROOLS, CLIPS, and JESS.

4.3.1 CLIPS

CLIPS (C language Integrated Production System) is written in C to provide for portability and speed [8]. It has the ability to handle a wide variety of knowledge, supporting three

programming paradigms, namely rule based, object-oriented, and procedural. There is the capability to integrate with a Java interface using CLIPSJNI [16]. CLIPS was our initial choice for a system shell. However, we decided to change to JESS after our feasibility

demonstration, as many of CLIP’s resources had been taken down, and compatibility issues arose.

4.3.2 DROOLS



4.3.3 JESS

JESS stands for Java Expert System Shell. It is often regarded as a superior version of CLIPS, as it is fully compatible with Java-based software systems and there is a readily available JESS library that can be embedded in Java software. JESS is a rule engine and scripting language written in Java, developed in the late 1990s [9]. JESS can also be extended either through Java code or within JESS itself, allowing for easy customizations for specific applications. These features make JESS the ideal candidate to be used in the development of a Java-based web application. It is possible to build a rule engine from the bottom up, but this would have taken a lot more time and effort.

Initially Jess was disregarded as our initial choice, as it is proprietary. However, support for CLIPS has declined and many of the resources used to successfully integrate it with web-based software had been taken down and many modern expert system research tended to prefer using JESS over CLIPS [8].For the web- based expert system described in this paper, the JESS programming language was used in the end. A JESS licence (valid for 365 days) was obtained for educational purposes free of charge (commercial licences are also available). It includes a graphical integrated development environment for Windows, called JessWin [9]. JESS can be executed in three ways:

 Through the command line interface.

 Using a Graphical User Interface.

 As an embedded Expert System, by utilizing the JESS library.

4.4 Working with JESS

The JESS language has a simple syntax that is quite different from Java’s (in JESS every command is enclosed in brackets). The JESS language has a few built in data types: INTEGER, FLOAT, STRING and LONG. There are several simple control structures such as deffunction,

deftemplate, defquery, defrules. JESS can reference to the entire Java API, which enables you

to call any Java method and make use of any Java data structures (array, linked list, C etc.) provided you import the correct package beforehand.

4.5 JESS programming features

The following elements form the basic features used when programming in JESS: templates, variables, queries, functions, rules and facts.

4.5.1 Facts



 (assert) - Adds facts to the working memory.

 (clear) - Clears the current JESS program.

 (deffacts) - Defines the initial contents of the working memory.

 (modify) – Allows changing the value/s of a fact. The fact will be retracted and asserted again.

 (facts) - Displays the current contents of the working memory.

 (reset) - Initializes the working memory.

 (retract) - Removes a fact from the working memory.

There are two types of facts: ordered facts and unordered facts. Unordered facts

Unordered facts are an important component of rules engines. They are facts in which the order of the slots (‘student-number’, ‘what’, ‘year’, ‘drop’, ‘semester’) do not matter. They could be thought of as a row of a table in a relational database.

The following example illustrates two unordered facts that equate to the same fact.

(request (student-number BRNLYN013) (what drop) (course CSC2003S) (year 2014) (semester S))

(request (student-number BRNLYN013) (course CSC2003S) (year 2014) (what drop) (semester S))

Ordered Facts

Ordered facts, on the other hand, lack structure and are usually used for small pieces of information. The following is an example of an ordered fact

(enough science-credits “BRNLYN013”)

This would be different from the below fact:

(enough “BRNLYN013” science-credits)

The deffacts construct as earlier is used to define the initial contents of the working memory. When the program is reset, only the deffacts remain.

4.5.2 Templates

In JESS before making use of an unordered fact it needs to be defined. This is almost like the writing of a class before you can create an instance of it. The deftemplate construct is used to define the slots in an unordered fact.


19 (deftemplate request (slot student-number ) (slot what) (slot course) (slot year) (slot semester) )

The name of the deftemplate (in this case, request) is used as the head of the fact, you can define as many slots as you want in a deftemplate. Each slot has a value type, the default is string. And each slot value can have a default value, this will be asserted if no other value is explicitly given. deftemplates may also consist of multislots, which allow you to enter multiple values in one slot. This is useful if you need to keep a list of something together. One

example, is if you want a list of keywords to describe a course, the specific template and fact could look something like this:


(deftemplate course (slot course-number) (multislot keywords))


(course (course-number MAM1004S) ( keywords practical trigonometry mathematics))

4.5.3 Rules

A rule has two main parts to it. The first part is the list of facts that needs to be satisfied. The second part is the list of actions that must take place if that rule is fired. The defrule construct is used to create rules. The following is an example:

(defrule speak ?f1<-(say ?message) => (retract ?f1) (printout t (?message)) )

The above rules will only fire if there exists an ordered fact (say) that has one value,



printout prints the given text to the output router, the default output router is defined as t,

which prints out to the console. Additional routers can be added to the JESS program, this can be used, for example, to reroute output to a file.

When wanting to retract or modify a fact, the fact address is needed. Using a variable name followed by a <- will allow the variable to now contain the fact address, which in return can now be used to retract or modify the fact.

Conditional Elements

Conditional Elements(CE)’s are pattern modifiers. They allow grouping of patterns into logical structures, and you can deduce something about the meaning if they are a match. JESS’s conditional elements include:

 or – matches alternative facts

 and – matches multiple facts

 not – matches if no facts match

 exists – matches if at least one fact matches

 test – matches if function call does not evaluate to FALSE

 logical – matching facts offer logical support to new facts

The or, and , and not CE’s are quite similar to those used in other programming languages, with the main difference being that it concerns the existence of facts in the working memory. The logical CE, however, is a different concept to what programming languages are normally used to. It is used many times in our rules engine.

Logical CE

The logical CE creates a logical dependency among certain facts. If one fact is logically dependent on another, then if the latter fact is retracted, the former will be automatically retracted, as well. One example would be if you had a prerequisite for taking a course, then if the user had the prerequisite, they would be eligible to take the course. However, if they decided to drop the prerequisite course, they would not be eligible to take the other course.

(defrule check-eligibility

(logical (taking MAM1000W)) =>

(assert (eligible MAM2000W)) )



4.5.4 Functions

Users can add their own functions using the deffunction construct. A value may be returned by using the return statement, else nothing will be returned. The following is an example of a simple user defined function:

(deffunction sayHello(?name)

(return (str-cat “Hello “ ?name ) ) )

The above example takes in a name as input and returns the concatenation of “Hello “ and the name.

4.5.5 Queries

Jess’s working memory is quite similar to a relational database, where one can query fact base. deftemplates are analogous to relations in a dataset, and in turn, the slots would be equivalent to columns . In Jess we can query the unordered facts by using the defquery construct .The query searches working memory and would correspond to only the LHS of the

defrule construct. A java.util.Iterator is returned with a list of the facts that apply to the


An example of using this construct would be to find all student courses that have been completed:

(defquery find-complete-courses (declare (variables ?sn))

(student-course (student-number ?sn ) (status complete)) )

To run the query the result needs to be bound to a variable.

(bind ?res (run-query find-complete-courses BRNLYN013)

The results could then be iterated through as per usual. The bind construct is used to bind a given value to a variable. Local variables do not have to be defined before they are used in JESS. Argument types also need not be specified either.

The iterator that is produced after running a query is filled with Token objects. These objects contain the facts that matched the query. From them the Fact can be retrieved and in turn any of the slot values contained in this fact can be retrieved. An example of how one would iterate through the values in java follows:

addableCourses =sessionData.getAddableCourses(); while (addableCourses.hasNext()) {



Fact fact1 = token.fact(1);

String courseNum = fact1.getSlotValue("course-number").stringValue(null); System.out.println(courseNum);


count-query-results function returns the outputs an integer corresponding to the amount of

results returned, if this is desired.

(bind ?count (count-query-results find-complete-courses BRNLYN013))

4.6 Embedding JESS in Java

A typical JESS file (file.clp) will contain all of these above mentioned features. When

embedding JESS in Java, you create the Rete object and then load a file that has all the JESS logic in it as follows.

Rete engine = new Rete(); engine.batch(file.clp);

The Rete class is the central class in the JESS library, this is the rule engine itself. Each

jess.Rete object has its own working memory, agenda, rules, etc. [9]. The API has all the

possible methods (assertFact(), reset(), run() etc. ) that can be used to manipulate the Rete object in a Java file.

4.7 Debugging JESS

Debugging JESS can be made easier if you see which facts are asserted, when they are asserted, as well as if certain rules are activated or not.

The (watch) command allows you to view the operations in the console as they happen while a JESS program is running. This is useful for debugging purposes. If you would like to watch all operations you would use the (watch all) command.



Chapter 5

Previous and Related Works

5.1 XCON

The XCON system, built in 1978, and its predecessors are well-known examples of using rule-based systems. Developed at the Digital Equipment Corporation (DEC), the original XCON included 210 rules for validating orders for DEC hardware [9]. The amount of rules increased to 17,500, by 1989, and knew about 31,000 hardware components. The estimated savings to DEC at that time was $40 million annually due to increased accuracy, reduced testing costs, and higher customer satisfaction, compared to configuration by human workers. Such systems have become common anywhere where rule-based systems help to recommend related products, optimize packaging, and perform other routine order-configuration tasks. Every web site that recommends compatible options when you buy a computer online was probably rooted in the research done by XCON [17].

5.2 Alfred Curriculum Planner

Alfred curriculum planner is a system that was developed in Python by Michelle Kuttel and Adrianna Pinska at the University of Cape Town [18]. It helps advisors assist with assisting students plan their timetable by placing constraints on possible module choices, based on degrees chosen and timetable clashes. Alfred does not, however, recommend courses to students and cannot provide expert level advice based on student databases. It is also not able, to a great degree, assess whether a student should be allowed to drop or add a course. This system is predominantly made to be used by student advisors instead of students. This system, however, would be a great addition as the system derived in this project does not cater for detecting timetable clashes.



5.3 ESAU

Expert System for Advising Undergraduates (ESAU) is a system used in the management department at the University of Wisconsin [19]. It was suggested in [19], that a data migration link between the ES and the online student data system be created, thus

decreasing the input students need to provide on courses and information about themselves, speeding up the process even more. They also suggested an alternative design technique, with regard to the knowledge base, where relatively static knowledge (e.g. curriculum knowledge) could be encoded as rules and dynamic knowledge (e.g. course information) could be placed in a database. This separation allows the more volatile components to be easily maintained using common DB tools (e.g. MySQL).

5.4 Course Advisor Expert System

This expert system prototype was created in Australia to help facilitate the request from non-IT graduates wanting to do an non-IT masters or PHD, by offering a conversion course. The

eligibility of these students were judged by this ES, using the modularity of subjects, prerequisites and outcomes of subject modules and credits for previous studies. This

prototype used JESS as the expert system shell and users were able to access the program by downloading a Java applet from the web.



5.5 Web-based Human Advisor Fuzzy Expert System

The use of internet-based technologies and the fuzzy expert system concepts opened up the possibilities of new methods for sharing and distributing knowledge [14]. This research, done at the University of Arak in Iran, included the development and creation of a web-based Fuzzy Expert System for the Common Human advisor (FES-CHA). It was designed to be used as a student advisor at the department’s web portal. Microsoft Visual Studio .NET 2010, MVC Microsoft SQL Server 2012 were all used during implementation. By implementing this system in the university portal, students who should be excluded were determined and prevented from registering in the following semester.

5.6 Summary

From the related work it is clear that this has been attempted to some degree. However, not for all the main tasks of a human advisor. The system discussed in this paper aims to build on the previous work where possible as well as focus on the usability of the interface and the usefulness of the Expert System itself. The systems outlined in previous work have not focused much on the user interface of the system. The above systems also did not



Chapter 6


6.1 Approach

Most expert systems are developed using a more bottom up, iterative approach, compared to the traditional top-down linear software approach [15] [20]. Frequent prototyping usually yields a more robust and efficient system, as expert systems are not well defined at the start of development. This is due to the lack of knowledge of the expert and what their exact duties are at the beginning of the process.

In general, we used the spiral development paradigm, which essentially included repetitively going through important stages, but at a higher level each time [22]. We first started off with a very simple prototype (core), containing few rules and some simple facts. After that had been developed, new rules and facts were added progressively, always keeping some previous versions available in case fatal errors occurred. This reduced risk of failure, and at the same time, facilitated rapid development.

Figure 5: Typical Spiral Model

6.2 Motivation



The spiral model is a realistic approach to this development, as the idea of growing

requirements as the project develops, as well as, the growth between various prototypes to a more complete solution, suits the objectives of this project.

Initially we did not know how we were going to design our system or how best to cater for the users’ needs, so we initially did not have a concrete design or requirements plan. However, after meeting with student advisors, reading through the handbooks thoroughly, and hearing feedback from students we had a better understanding of the task at hand.

6.3 Project Division

For the most part, this project is split into:

1. The user interface

2. The expert system.

For the front end, the researcher enlisted the help of end users (students) to help create a suitable interface, whereas the back end researcher needed to work predominantly with the university handbooks and the experts (student advisors) to get as much accurate knowledge into the system as possible. The two parts were integrated fairly early in the development phase. Once integration had been solved, implementation continued, as well as, testing our separate parts, receiving feedback, and making suitable adjustments before the following cycle began.

6.4 Knowledge Engineering

An important part of the development methodology for an expert system includes an in-depth analysis of the system called Knowledge Engineering. The primary stages of this analysis, which are usually repeated for each prototype, are:

1. Knowledge Acquisition



2. Knowledge Representation and Inferencing 3. Implementation/Adjustments

4. Evaluation and Validation

Feigenbaum states that [7] “..knowledge engineering is the art of building complex computer

programs that represent and reason with world knowledge, using AI principles and tools . It entails of translating the knowledge into a usable computer language, designing the inference engine’s reasoning structure, and deciding what actions to take with regards to uncertain knowledge.”

6.4.1 Knowledge acquisition

Knowledge Acquisition is the key part of building an ES, where we try to extract knowledge from one or more [8] experts and other sources (books, rules etc.), to learn what they know, and how they reason with their knowledge [7]. This is usually a bottleneck in the procedure due to its’ labour intensive nature and the extensive amounts of knowledge available. The main sources used to extract the knowledge for our system were:

Curriculum Handbooks, and General Rules of the University Handbooks:

These were used as the main source of information as contained the relevant rules and information we needed. This is what the student advisors have to refer to if they need information about a degree or course. This was advantageous for us, as most of the information was already in a codified language. The main handbook used was the one for science undergraduate students as our system will be geared towards students aiming to obtain a BSc degree. Another advantage was that this increased the amount of information that could be gained without the use of humans, as this usually slows the process down, due to their availability.

Below are some examples of the rules uncovered in the handbook: Maximum courses per semester:

A student shall not register for more than:

(a) the equivalent of four half-courses in each semester in the first academic year of study; (b) the equivalent of three half-courses in each semester in any other year of study.

This restriction also applies to the number of courses for which a student may be examined. Policy

Permission of Senate to waive these restrictions will only be considered under the following circumstances:

(a) where a student registering for the first time for the first year of a BSc degree has achieved outstanding results in all NSC subjects;



Waivers to students who satisfy either of the above will depend on an assessment by a Student Adviser or Deputy Dean, on the merits of each individual case.

Curricula rules for the Bachelor of Science (BSc) degree

Total number of courses

FB7.1 The curriculum shall include the equivalent of at least nine full-year courses of which at least six full-year courses must be Science courses. A maximum of three full-year courses or the equivalent may be counted from other faculties.

Number of senior courses

FB7.2 The curriculum shall include the equivalent of at least four full-year senior courses or the equivalent, of which at least three shall be Science courses.


FB7.3 The curriculum shall include at least a half Science course in Mathematics (18 HEQS-F credits, level 5) plus a half Science course in Statistics (18 HEQS-F credits, level 5), or a full Science course in Mathematics (36 HEQS-F credits, level 5).

Elective courses FB7.4 Any course

• Only courses with an HEQS-F credit value of 18 or more will be counted (a first year half course in the Science Faculty has an HEQS-F credit value of 18).

• If the equivalent of two or less full Science courses are replaced by courses from another Faculty, any courses not specifically excluded by Science Faculty rules can be chosen. If more than two full year Science courses are replaced with electives from another Faculty, then the further electives must form part of a hierarchical sequence linked to those already completed. • Courses taught by the Faculty of Science for other Faculties are not available for students registered in Science. However, students transferring into Science from other Faculties may be able to count such courses towards their Science curriculum.

It also states:

The standard BSc degree requires:

(a) two majors* *NOTE: A curriculum leading to only one major but including at least 120 NQF credits at level 7 will be acceptable.

(b) a total of 420 NQF credits (nine full-year courses). A minimum of 396 NQF credits will be accepted where the second major or suite of hierarchical courses includes at least one senior full course from another Faculty

(c) a minimum of 276 NQF credits from Science courses (the equivalent of six full-year courses) (d) a minimum of 120 NQF credits at level 7

Course Rules

A small sample of a course with prerequisites follows

AST2002H ASTROPHYSICS NQF credits: 24 HEQSF at level 6 Convener: Dr V A McBride



Major Rules

If the student was a Computer Science Major, They would need to complete these compulsory courses in order to graduate:

Figure 7: Computer Science Major Compulsory course plan

Overall the rules found in the handbook are pretty straightforward. For code snippets refer to Appendix E.

Student Advisors: Interviews were held with two Computer Science student advisors. This proved to be quite beneficial as they could clarify information that the book was not clear about. They also had different suggestions, maximising the potential power of our system.

Mr. Gary Stewart has been advising for about 5- 6 years in the Computer Science department

and predominantly advises students on the extended degree programme (where certain foundational courses are stretched over a longer period of time for the user to fully grasp key concepts).

Dr. Michelle Kuttel has been advising for 8 years in the Computer Science Department and

deals with those not on the EDP programme, but usually deals with similar issues.

In these interviews it was discovered that the most frequent requests or concerns from students were if they had enough credits to graduate, and if they needed to add anymore, what electives they should take, and to drop or change courses. Students on the extended degree programme start with the mainstream course, but if they do not do well at a test taken in the seventh week, they are strongly advised to change to the EDP version of the course. Students doing more than 3 EDP courses are seen as being on the EDP programme. To view the general interview questions , refer to Appendix B.



Third years, are mostly concerned with whether they are able to graduate, and if not, how many courses they still need.

When a student wants to drop a course, they (student advisor) would first be concerned with looking at their transcript and whether/how it would impact their major. It is also important to know why they want to drop the course. It is necessary to make sure that would not be excluded from readmission. The advisors suggested that if anyone drops a basic mathematics course or one of their major senior courses, they should be sent to a human advisor, as this may affect their overall path.

The advisors were asked what they think our system should not cater for. They did not think we should deal with students transferring to the university, students dropping their major or students on the verge of being excluded. They think that automated machines struggle with getting a sense of who the student is, if they are out of their depth, getting them to

reconsider their choices, or simply giving them a pep talk or a wakeup call.

When asked what recommendations they would give students for other courses, Mr. Stewart suggested STA1006S (as it is not a dead end course like STA1006S), film and media courses, and BUS1004- which is a course by the commerce faculty for non-commerce students, which gives you an overview of business, marketing and HR. It was interesting when I asked him about the book strongly recommending MAM2000W to a student doing second year

Computer Science courses. He said that this usually harms students, as they take it, but don’t really need it. These students usually do badly at it then have to drop it or eventually fail it, sometimes extending their university career by a year, if not more.

Dr. Michelle Kuttel was fond of my suggestion of dividing courses into categories, as this would make it easier for students to know the various courses that exist before they go to the advisor. It is tough for a human advisor to know all the various courses out of their head. It can be a challenge for them to recommend specific courses to students based on their interests, if they do not know each and every course offered. She thought that this could be one of the major strengths of our system, where we could allow students to browse courses, and for the system to recommend certain courses to students. Some of the categories that arose were courses that would strengthen your degree, creative courses, course fillers, more mathematics, and language courses.

Other student advisors from various departments were contacted via email for me to get some course recommendations if students were enrolled in a major from their department. As mentioned before, Knowledge Acquisition can be a bottleneck, as getting humans to cooperate can be quite a struggle sometimes. I received only a few responses to my email. It was suggested that students majoring in statistics should take MAM2000W, the full first year of computer science, and the full second year could be useful too. For students majoring in biochemistry or genetics, it was recommended that students take other biology, chemistry human physiology, psychology or computer science courses as electives. However, they did mention that sometimes there are lecture clashes, making some of the courses impossible to take at the same time.



and appropriate, because whatever we put in is what we will get out i.e. Garbage in Garbage out [5].

6.4.2 Knowledge Representation

After the knowledge acquisition phase, quite a great deal of information was gained. Following that phase, the knowledge needed to be accurately encoded into the knowledge base. This has been found in the past to be quite a challenging phase of the process, as you need to make sure that the information put into the system is an accurate equivalent to that gained in the acquisition phase.

The following is information that a student advisor would typically need in a one-on-one session with a student:

Their transcript which contains: - their student number - major/s

- course plan – past/current courses - registration year

- past course marks (if any)

Representation: The information that a student would normally receive from a transcript has been inserted into a database as there may be frequent changes. When a user logs in, their specific “transcript” would be loaded into the rules engine

Change Curriculum Form - Course plan for future - Desired courses to add/drop

Representation: The information concerning student’s future courses would be entered into the same database as above, when the student initially registers at the beginning of the year. The desired courses to add or drop will be chosen by the user through the interface.

Knowledge contained in handbooks

- Various courses offered and their prerequisites - Compulsory courses for various majors

- General degree rules



6.4.4 Inferencing

This involves writing the rules to act on different facts provided with the system and by the user. This is where we try to mirror the reasoning and logic of the expert and knowledge gained, inside our system

The inferencing phase was probably one of the most crucial stages in the process, as it is where the rules are written to give users correct feedback depending on the input received from them and the information given by their database records. For example, if:

1. The User’s major was Computer Science

2. They wanted to drop CSC2002S (a compulsory course for this major and a prerequisite for other courses –CSC3002F)

3. Their total NQF points were at 426

The expert system, would give the following feedback to the user:

"You cannot drop this course if you want to complete this major. If you would like to change majors or look for alternatives it should be advised to see the student advisor of your


“This course is required for CSC3002F. Please check the prerequisites/corequisites again and either add appropriate courses or drop CSC3002F too”

“Your total potential NQF credits after dropping this course will be 402. Please make sure that you add another course that exceeds 420 NQF credits or ensure you are taking at lease 2H or 1W senior non-science courses”

Throughout the assessment the system makes inferences in the background, adding feedback to be shown to the user.

6.4.5 Evaluation and Validation

The main purpose of evaluation and validation was to make sure that the knowledge base is complete, correct and consistent. Like the knowledge acquisition phase, this too, was a bottleneck, due to the need of human participation.

Methods which we used to assess the knowledge of the ES include:

 Direct Knowledge Assessment: As development progressed the rule base was tested by the back end programmer to make sure that the knowledge put into the system was the same as those in the handbook. Test cases were used to make sure that the knowledge was correct and consistent. The completeness of the knowledge was time dependent.



 End-user assessment: We allowed users to assess the response quality of the system, through assessment forms, and had a small group session at the end of development. The front end designer made use of student evaluations more often than the back end designer. However, feedback of these sessions was shared.



Chapter 7


7.1 System Requirements

The aim of this project was to build a web based expert system. This system gets user information from a database and loads it into the system. The user is then, through a user friendly interface, able to get an overview of their university course plan, view their graduate status, be able to add courses, drop courses, ask for recommendations and browse the courses offered. The feedback given to the user was dependent on their input as well as the information in the database. When a user is satisfied with their add and/or drop selections they can submit the form directly to the student advisor.

Information was continuously being processed in the background by a rule based engine, as one decision may have impacted another. As this is a web-based application, there was a need for an intermediate in-between these two core system components, as well as the student database, that would need to process and relay information between the interface and the rule based engine throughout.

The four system components are explained below: Database

The database holds the students information, their passwords and their course plan. When a student logs in, their password is checked, and, if correct, their information is loaded into the rules engine.

The Graphical User Interface

The user interface is used for the user to view certain information, such as their course plan, recommendations and their graduation status. If they would like to perform a certain task (such as add or drop), this is the root from where the back end system would receive the information from. The interface should be easy to use. Providing constant feedback to the user at all times as well as adhering to the standard design heuristics.

The Rule Based Engine

The rule based engine will contain all of the expert knowledge and all knowledge gained from handbooks. This is where all the rules are stored, where all the factual data is stored and where all the results are processed.

The Intermediate



7.1.1 MVC

This system is broken down into the four distinct parts mentioned above (interface, rule based engine, database and controller). This adheres to the Model View Controller (MVC) architecture pattern, whereby the representation of the information is separated from the user’s interaction with it.

This allows the system to be modular and for the components to be independent of each other. Provided there is an API for them to communicate between one another.

The MVC paradigm has widely been adopted as an architecture for applications over the Internet [21].

The following are the three components. View

The view represents the output to the user; in this case the web-based user interface. The aim was to develop a desktop user interface with an additional mobile interface being a possibility initially. With this proposed architecture, these interfaces will serve as different views that will communicate with the same controller.




The Model is where the logic is stored. In this case the database and rule based engine would both exist under the model.


The controller sends commands to the model to update the models state as well as to the associated views in order for them to change their presentation.

7.1.2 Technologies Used

The following is a breakdown of the languages that were used in the development of this system:


 HTML - Hyper Text Markup Language.

 CSS - Cascading Style Sheets.

 JavaScript - Used for client side code.

 AJAX - Asynchronous JavaScript Used for real-time dynamic data exchanges with the server.

 Bootstrap


 Java - Java was used for the servlet.

 JSON - Used to transfer information between the server-side code and the interface on the clients side.

Rule Based Engine

 JESS was used as the rule based engine. JESS stands for Java Expert System Shell. This language was chosen because it can easily be integrated with Java.


 Apache Tomcat was used as the server environment. This enabled us to use Java servlets to process commands and relay information between the front-end interface and the back-end rule based engine. Apache Tomcat is open source, cross platform and easily configurable.


 MySQL was used as the database to hold the students’ information. MySQL was chosen, as it was easy to use, and it is compatible with all the other software used.



7.2 Systems Architecture

The system is comprised of one database, six jsp files, five java classes and a Rete object that represents an instance of the JESS rule based engine.

7.2.1 Database Design

We decided to just use a basic database design, as this was not the main focus of our project. The Database contains three tables:


This table is used to save the users password (hashed using SHA1 algorithm). This table is used to check the student’s password


This table saves all the students details with regard to their names, registration date, majors, current Degree.


This table saves all student courses including, past, current and future.



7.2.2 File Breakdown


This is where the student can log in with their student number. The student number and password will then be sent to the file to be checked. If it is incorrect or

The Base class of all servlets used, which contained the method to check if the session has been initialised. is the servlet that was used to transfer data between the back-end and the front-end. As our web application is hosted on a server; this one instance of is shared through all the concurrent instantiations of the web application. In order for all users to have an independent session we had to make use of different session objects that are referenced with their student number. All the session objects are stored in a HashMap on the object.



Home.jsp – The file that creates the main home page for the site, displaying the users’ addable courses, recommended courses, their course plan, and their form summary. This class uses java to retrieve results from the queries in the SessionData object. – a servlet, that relays information about the course that the user wants to add, to the rules engine. The rules engine in return will return any warnings that occur with adding this course. If there are no warnings then the course will be added to the engine and the page will be redirected to the home page.

Add.jsp – The page that builds the interface where students will be able to view any results and warnings based on the course they would like to add. – a servlet that is the same as, but this one is for when a student would like to drop a course

Drop.jsp - The page that builds the interface where students will be able to view any results and warnings based on the course they would like to drop.

Recommender.jsp – The page that allows students to get recommendations from the system, or browse the various courses in the handbook – This servlet receives the information that the student would like to exit this system. The information pertaining to the student is saved to a file in case anything happens, and the session is invalidated. This then navigates to the logout.jsp file

Logout.jsp – This file, says goodbye to the student and allows them to return to the index page, if they would like to log in again

Web.xml -a deployment descriptor file used by Java web applications to determine how URLs map to servlets, which URLs require authentication, and other information.

This object is needed for session tracking. Because multiple users can be using the web application at the same time there needed to be some centralized way to manage the different users. This object kept data specific to that user, so that every time a different user logs in, the feedback they receive is specific to them.


This is a Rete object. The Rete class is the central class in the jess Library, it is the rule engine itself. Each Rete object has its own working memory, agenda, rules, etc. This object is used to embed JESS in any Java application.





The file that contains the student data from the database in rule format. An example can be seen in Appendix A.

7.3 Systems Control Flow

The system has the following parts to it: 1. Overview – Home Page

2. Add/Drop a Course 3. Course Recommender 4. Course Browser 5. FAQ

7.3.1 Login

Students can log in to the system by entering their password. These details are checked with the database. If they match, then the information is gathered from the database with respect to the student, and exported into a file making rules out of them, with the use of the

checkPasswordandLoad() method. If the password or student number is incorrect the index

page would be reloaded.



7.3.2 Home Page/Overview

Figure 12: Screenshot of Home Page

Student Courses

On the home page, the student is able to see all of their courses divided up per year. If they have been completed, then the student’s final mark will be attached to it. All courses are clickable, and when pressed, a description is provided. Bins that represent dropping of a course are placed next to each course that is a current or future course.

Addable Courses

Only courses that are addable are placed inside a drop down box. A course is addable if:

 There are no course prerequisites/corequisites

 First Year courses with only prerequisites pertaining to their High School results

 You have taking all prerequisites/corequisites

An example of the rule for courses which have no prerequisites follows:

(defrule no-prereq-courses

(course (course-number ?n) (course-name ?na) (prerequisites nil) ) (session-user (student-number ?sN) )


(assert(addable-course (student-number ?sN)(course-number ?n) (course-name ?na))) )