Navigation  without Java Scripts

Introduction to ESTA

How to write Knowledge bases in ESTA
Knowledge Representation in ESTA
ESTA Sections
ESTA Parameters
ESTA in action
Full on-line Help

How to write Knowledge bases in ESTA

ESTA is fully exploits Microsoft Windows,  making use of the Multiple Document Interface (MDI), DDE communication with other Windows applications, links into the Windows help system for hypertext extensions, and sophisticated integration of Windows bitmaps and metafiles for knowledge representation. The result is a pleasant, user-friendly interface that is exceptionally easy for those consulting your knowledge bases.

Plus, all language-specific parts of ESTA are recorded in specific files that let you easily make your own version of ESTA in any language with a minimum of effort.

ESTA includes provisions for generating license free, consultation-only versions of the system, which may be distributed to end-users.

In addition to knowledge representation, ESTA includes useful features from traditional programming languages, such as procedure calls and mathematical functions.

ESTA is configurable - menus, startup-pictures, and other UI-functionality can be readily customized to match the specific needs of your application..

ESTA includes facilities for the knowledge base to call general purpose routines written in Visual Prolog and (thereby) also routines written in C or other languages.

ESTA has facilities to explain why a question is being asked or why an answer has been given, or to repeat advice given earlier in a consultation. Of course ESTA also enables the user to break off a dialog, change the answer to a previously asked question, or bring up new questions (which have not yet been asked) to answer.

ESTA provides the knowledge engineer with a number of views of the knowledge, including hierarchical tree-representation, where clicking on a node in the tree brings up an edit window containing the corresponding rules.

The knowledge entered into ESTA is automatically translated and syntax checked, and errors are pointed out directly in the text. Furthermore ESTA has a check-facility for noting type errors, endless loops, undefined or unused knowledge.

ESTA is also available in text mode DOS and OS/2 versions. The knowledge bases can be converted between the Windows and text mode version - thus it is possible to have the same knowledge base available for DOS, OS/2 and Windows users. (Pictures and Windows specific features like DDE etc. are not portable.)

Knowledge Representation in ESTA

In ESTA, knowledge is represented in an intuitive way - rules are written in English-like statements as "if its_raining and person_has_umbrella advice 'You can go out' "

A knowledge base in ESTA consists of Sections and Parameters. The sections contains the rules (the logic) that directs the user to the right place in the knowledge base and gives the appropriate advice.

Parameters are the variables that can obtain values - 'its_raining' or 'person_has_umbrella' are examples of parameters that can either be true, false or unknown. Other parameter-types are texts, numbers or categories. Parameter definitions can themselves contain rules and thus their values can be based on other parameters.

A knowledge base in ESTA has a hierarchical structure and could look like this:

estatree.gif (16691 bytes)

Sections

Sections contain the rules that tell ESTA how to solve the problem and which actions to perform, such as giving advice, going to other sections, calling special routines, chaining to other knowledge bases, etc.

Each section can be edited individually in a text window. The first section in a knowledge base must be called 'start', and this is the place where ESTA begins the consultation. The 'do' command executes another section, thus 'do overheating' will execute the overheating Section.

section start : 'main section'
if (problem='starting_problem') do starting_problem
if (problem='overheating') do overheating
if (problem='smell_of_gasoline') do smell_of_gasoline
if (problem='vibration') do vibration
do other

section overheating 'the engine gets overheated'
advice 'Overheating is normally caused by problems in the cooling system'
if not(water_ok) advice
  'Top up your radiator but keep an eye on the
   water level as there might be a leak in the system'
if water_ok and acceleration_noise advice
  'The fan belt may be slipping. Tighten it up.'
if water_ok and not(acceleration_noise) and not(oil_ok) advice
  'Top up the oil in your ' car '. In future, watch the oil level carefully'
  'as it is cheaper to buy new oil than a new engine

During the consultation the 'advice' command will supply the user with advice in this way:

advice.gif (6152 bytes)

Should you wish to know how the system reached a certain conclusion or why a certain piece of advice is given, you click on the 'Why' button and the system is able to establish why the conclusion was reached based on the rules used.

why.gif (7047 bytes)

Parameters

A Parameter is a variable that can have a value (text, number, true/false, or one of a number of options). The value can be calculated from other parameters or specified by the end-user (when ESTA needs the value, and asks for it)

A typical parameter might be defined as shown below, with entries to specify the question to be asked, an explanation to give if the user presses the 'explain' button, the possible values, and even links to a graphic representation . Expressions can be given to calculate the parameter from other parameters, the range can be given etc.

parameter car 'the kind of car'
type category
explanation
  'identify your car with one of the listed types as closely as you can.'
option
  ambulance
  policecar
  sedan - 'car'
  van.
question 'Which kind of car do you have ?'
picture 'cars'

Name

When a parameter is declared, it is necessary to specify the name of the parameter (e.g. 'car') this name is used when the parameter is referred to in rules.

Type

A Parameter has one of the following four types:

Boolean (true, false or unknown)
Number ( integers or reals)
Text (such as a person's name, etc.)
Category (used when the parameter is known to take one of a definite set of values).

Question

ESTA determines if and when it needs the value of a parameter. If the value depends on other parameters it will calculate the value otherwise it will prompt the user for the value. ESTA generates a dialog box and asks the question given in the parameter definition under the 'question' heading.

question.gif (5855 bytes)

Explanation

When a question is given during a consultation, the user will have the option to ask ESTA to 'explain the question'. This explanation can be provided by the knowledge engineer in the 'explanation' field of a parameter declaration. In the dialog it will appear like this:

explain.gif (8013 bytes)

You can also answer 'Unknown' to a question posed by ESTA if you are unaware of the value of the parameter. This can either lead to special advice or to a dialog which will establish the value by other rules.

Option

The Option field is used in parameters of Category type only. After giving the keyword Options, a list of values can be given, and a menu is automatically generated during the consultation. The user may select from the menu by clicking on the appropriate option.

Picture

Pictures can be included as part of advice, questions or explanations. When used together with category parameters, it is even possible to define links between areas of a picture and specific parameter options, so the user can answer a category-based query by pointing at regions of a graphic and clicking.

ESTA in action

To show the power and ease of use of ESTA, this article will take you through a complete expert system development project. A number of aspects are covered:

How to model the real world using ESTA's knowledge representation
How to extend ESTA with your own functionality coded in Visual Prolog
How to integrate ESTA with other applications to take full advantage of the Windows environment.

We want to build a financial expert system for use in a bank. The bank customer should be able to use the system to find out what kind of loan the bank can offer him to best suit his needs.

We'll show how such an expert system can be built using ESTA, in other words, how the expert knowledge is easily represented.

Then, as our demands on the system grow, we will make it increasingly sophisticated, first by linking it to other Windows applications using DDE (Dynamic Data Exchange) and secondly by programming our own extensions to ESTA in Visual Prolog.

Knowledge Acquisition: The Bank Case

We will start out by describing the problem that we want the expert system to solve. This process is often called 'knowledge acquisition', where we seek to extract some of the rules used.

To decide which loan the customer qualifies for, the bank calculates a risk_factor for the customer. The bigger this factor is, the bigger is the risk. Thus a negative risk_factor is desirable - where a risk factor of zero is the average risk - below zero is a low risk, and above zero is a high risk.

The risk can depend on several criteria such as personal income, age, the amount of disposable income after tax etc. The risk factor is calculated using this formula:

(200000-gross income) +
(5000-available amount)*12 +
(5-years employed)*1000 +
agefactor +
150000 if self employed.

The available amount is the amount available after tax, housing, food and other expenses. Years employed is the number of consecutive years in the current line of work. The variable age factor is calculated based on the formula:

100000 if age<20,
40000 if age>=20 and age<50,
70000 íf age>=50

The risk factor, together with other variables is used to determine which loan a customer can have. The bank has these 6 loan types:

The Loans

A - the super-duper loan with very low interest (12 %)

Risk factor <-200000

Max amount 100000

Not for real estate

For customers with at least two other accounts with the bank

B - The cheap car loan with no down payment (12.5%)

Risk factor <-100000

Max 7 years pay back

At least one other account with the bank

C - the cheap car loan with a 30 % down payment (12.5 %)

Max 7 years

Risk factor <-50000

D - the not-so-cheap car loan with no down payment (14.5 %)

Risk factor <=0

max 8 years

E - The real-estate loan (11.5 %)

Risk factor<-50000

not (self employed)

F - the "normal", pretty-high-interest loan for anything you wish (16 %)

Risk factor <50000

Max amount: 25000

The loan type F can be used for anything including cars and real-estate.

1st Version; The basic knowledge base

As our first version of the expert system we make a simple ESTA knowledge base that simply tells the customer what kind of loan he can have based on his personal data.

For our bank's system, the start section looks like this:

section start : 'start'
if risk_factor>= 50000
advice 'Risk factor is too high - we cannot give you any loans',
if loan_amount<=100000 and risk_factor<-200000 and
not(use='real_estate') advice
'Congratulations - you qualify for the Super-Duper cheap A-loan',
if use='car' do car_section
if use='real_estate' do real_estate_section
if use='other' or not(loan_found) do other_section
If the 'risk_factor' parameter is above 50000 no loans can be given - this 'advice' is given and the start section terminates at the quit statement.

image37.gif (5561 bytes)

The 'risk_factor' parameter has the following definition:

parameter risk_factor : 'Risk factor'

type number

rules

(200000-gross_income) + (5000-available_amount)*12 + (5-years_employed)*1000 + agefactor -150000 if self_employed,

(200000-gross_income) + (5000-available_amount)*12 + (5-years_employed)*1000 + agefactor.

The first rule deals with the self employed person and the second one deals with the not self employed person. The parameters 'gross_income', 'available_amount', 'years_employed' and 'self_employed' are entered by the end-user (the bank customer). The parameter definitions look like this:

parameter gross_income : 'Gross income'

type number

explanation 'The gross income is the total income before tax'

question 'What is your gross income per year ?'

When ESTA needs the value this question is asked:

image38.gif (5202 bytes)

The 'agefactor' parameter is based on the parameter 'age' which is also typed in by the customer.

When ESTA starts evaluating the start section and gets to the line:

if risk_factor>50000

The parameter 'risk_factor' has no value - hence it goes to the definition of the parameter to find out how to give it a value. In the definition it finds references to other parameters with no value (yet) and in turn goes to their definitions to find out how they should obtain a value. ESTA starts asking for the values of certain parameters in order to give 'risk_factor' a value - so the beginning of the dialog can go like this:

Are you self employed ?

No

What is your gross income per year ?

300000

What is the available amount per month ?

6000

How many years have you been employed ?

7

What is your age ?

27

The basic strategy is to find the cheapest loan a customer qualifies for. In the start section, the parameter use holds the item the customer wants to use the money for. This can be either 'car', 'real estate' or 'other'. There is a section for each item. If the 'car_section' or the 'real_estate_section' section doesn't yield any results the 'other_section' is tried to see whether any of the non-specific loans can be used. We check for the SuperDuper loan before anything else if the loan isn't for real estate, because the SuperDuper loan is cheaper than any of the other loans.

The 'car_section' looks like this:

section car_section : 'The car loans'

if risk_factor<-100000 and min_years<=7 and other_engagements>=1

advice ' cheap car loan B with no down payment'

if risk_factor<-50000 and min_years<=7 and down_payment_30

advice 'cheap car loan C with 30 % down payment'

if risk_factor<=0 and min_years>=8 and not(down_payment_30)

advice 'the not-so-cheap car loan D with no down payment'

The parameter 'min_years' holds the minimum pay back period acceptable for the customer, the parameter 'down_payment_30' is true if the customer can give a 30% down payment on the car.

We have now made an advisory system that tells a customer what loan he can have based on his personal data.

The system does not deal with the problem of whether the customer can actually afford payments on the loan. For this we need to be able to calculate the monthly payment for a specific loan type, based on the loan-amount, the number of payments, and the interest rate. This and other enhancements will be implemented in the 2nd version.

2nd. Version; Integrated with Microsoft Excel

In the next version of the expert system we will use Excel as our financial calculator and let the customer make his own what-if analysis- chart drawing etc. The customer can use Excel to answer questions like:

· What if I change the pay back period from 5 to 4 years - how does that effect the monthly payment and the total interest paid?

· What if the interest rate drops from 14 to 13 %?

· What if I raise the monthly payment by 500 ...

The first change to the system is that we want it to detect whether the customer can afford the cheapest loan he qualifies for. If not, there is no purpose in trying other more expensive loan types.

When the system has detected the cheapest possible loan type for which the customer qualifies, it will check whether the customer is able to pay this loan. We do this by calling the section 'check_loan' - here in a part from the 'car_section'

if risk_factor<-100000.0 and min_years<=7 and other_accounts>=1

( assign interest:=12.5,

assign min_months:=84,

assign loan_type:='B',

do check_loan,

quit)

The section 'check_loan' is coded using the DDE-interface (see the article "Integrating ESTA with other Windows application"). For each loan type we have defined a separate spreadsheet. The figures below show a fraction of one of these spreadsheets:

image39.gif (5737 bytes)

The calculated payment (C14) is based on the ''loan_amount', the annual interest rate and the term in years and payments per year. ESTA sends the appropriate data to the spreadsheet via the DDE interface as described later in this article. This is done in a modified version of the section 'check_loan':

section check_loan : 'Checking the loan'

assign CH:=dde_initiate("excel","Sheet1")

do load_sheet

call dde_poke_number(CH,"R7C3",loan_amount)

call dde_poke(CH,"R8C3",interest)

call dde_poke_number(CH,"R9C3",years)

assign monthly_payment1:=text_number(dde_request(CH,"R14C3"))

call dde_terminate(CH)

if monthly_payment1>(available_amount-1000)

( advice 'sorry - no loans.',

quit)

advice 'You can have loan ' loan_type ' Go to Excel to make calculations'

The parameter 'loan_amount' is input by the customer. The section 'load_sheet' loads the proper spreadsheet according to the loan type. The values are put in the spreadsheet (with 'dde_poke' and the special numeric version 'dde_poke_number'). The monthly payment is retrieved using 'dde_request' (and text_number because 'dde_request' always returns a string).

This version of the expert system relies on Excel to make specialized calculations used by the system. This requires Excel to be present every time the system is used. In the 3rd version we extend ESTA with a similar financial function, however, this time coded directly in Visual Prolog.

3rd. Version; Programming a New ESTA Function in Visual Prolog

Now we want to extend ESTA with functionality coded in Visual Prolog. The third version of the expert system is an alternative to second one. Instead of using Excel we want to make our own function called pmt to calculate monthly payment for a loan. The function pmt(Interest,Months,Loan_amount) returns the monthly payment for a loan with constant monthly payments and a constant interest rate. The mechanics of this are described later in this article, here we simply show how the new function alters our previous definition of check_loan.

Now we can calculate whether the customer can use the cheapest loan type he qualifies for as follows:

section check_loan

If pmt(interest,min_months,loan_amount)<(available_amount-1000)

( advice ´sorry - you don't have enough money available ',

'for the desired size of the loan´,

quit)

advice ´You qualify for the loan of type´ loan_type

Interfacing ESTA with other Windows Applications:

DDE (Dynamic Data Exchange) is a Windows protocol that lets applications talk to each other. ESTA supports DDE which means that you can interface ESTA to all other applications that support DDE - thus you can have your expert system controlling spread-sheets, word processors and database-systems. You can send data to these applications, you can retrieve information from them, and you can even execute commands in the applications.

The Windows version of ESTA has a DDE interface which is very similar to that of the macro languages in Word and Excel. ESTA can establish one or more conversations with DDE servers. A conversation is created with the function dde_initiate(Application, Topic) which returns a channel-number used to identify the conversation. Application is the name of the server application and Topic is the topic of the conversation - often a file name or a keyword accepted by the server.

The procedure dde_execute(Channel, Command) sends the commands in Command to the server for execution. Channel is the Number returned from 'dde_initiate'.

The procedure dde_poke(Channel,Item,Data) sends Data to the server. Item specifies the destination - Item is a server specific entity - in Excel, for example, Item could be a specific spread sheet cell, thus dde_poke(CH,"R1C1","12") would send the number 12 to the cell A1.

The function dde_request(Channel,Item) is used to retrieve a data-item from the server. dde_terminate(Channel) and dde_terminate_all terminate one specific or all conversations, respectively.

In the following example, a conversation is opened with Excel using the spreadsheet file 'file_a.xls'. The value 546 is sent to the cell R2C4 (D2) - the file 'file_b.xls' is opened using the Excel OPEN command, and the value of R1C1 (A1) is returned.

CH = dde_initiate("excel","file_a.xls")

dde_poke(CH,"R2C4","546")

dde_execute(CH,"[OPEN(file_b.xls)]")

VAL = dde_request(CH,"R1C2")

dde_terminate(CH)

See the "Tips & Tricks" article for the details on how the DDE interface is implemented in Visual Prolog.

Extending ESTA with Visual Prolog

With Visual Prolog you can define your own procedures and functions in ESTA. These specially tailored procedures and functions can be used in ESTA sections and parameters like any other procedures or functions. All you have to do is to define the procedure or function in the file WINEINTF.PRO and compile this file to EXE - then you have a new version of ESTA with your own functionality built into the ESTA language.

Procedures

A procedure is a piece of code that is executed by the call statement in an ESTA section. As an example we will make a simple procedure that shows the text X in Windows message box with the heading Y. The procedure has two arguments, both strings, or phrases as they are called in ESTA. In WINEINTF.PRO we add this clause to define the procedure:

proc_descr(my_msg,2,[phrase,phrase]):-!.

This clause reads: the user defined procedure 'my_msg' has two parameters; a phrase and a phrase. The following clause gives the code for the procedure:

eval_proc(my_msg,[str(X),str(Y)]):-!,

MB_msg = mb_ok + mb_iconexclamation,

MessageBox(0,X,Y,MB_msg),!.

This procedure simply calls the Windows function MessageBox. You can call any Windows function or Visual Prolog predicate in the procedure. You can even call a number of ESTA´s own internal predicates to manipulate the ESTA user interface at run-time.

Functions

ESTA supports functions in the usual sense - procedures that return a value. Both built-in and user-defined functions can be used in sections and parameters alike. Let's define the function 'check_sum(A,B,C)'. This function returns the checksum of A, B and C which in our example is:

(A + 2*b + 3*C) mod 11

The definition of 'check_sum' is:

func_descr(check_sum,3,[number,number,number],number)

The function has 3 arguments which are all numbers and it returns a value which is a number. The clause for the function looks like this:

eval_func(check_sum,[A,B,C],float(Result)):-

number_real(A,A1),number_real(B,B1),number_real(C,C1),

Num = A1 + B1 * 2 + C1 * 3,

Num_int = cast(unsigned,Num),

Result = Num_int mod 11,!.