From: AAAI Technical Report WS-93-05. Compilation copyright © 1993, AAAI (www.aaai.org). All rights reserved.
Knowledge.Based
Process
Specification
Language
A Specification
andValidationTechnique
for Knowledge-Based
Systems
by
G.B.Prabhat
andP. Srinivasan
SundramInformation Systems
(A Division of Sundram
FastenersLimited)
98-A, III Floor, Dr. Radhakrishnan
Salai, Madras600 004.
Tel: (+91)-44-844350
Fax: (+91)-44-844699
138
Abstract
TM. In
This paperis the third in a series of papersto be presentedon the KITSMethodology
this paper, wefocus on the verification and validation issues of Knowledge-Based
Systemswith
particular reference to Knowledge-Based
ProcessSpecification Language,a shell-independent
techniquewehad developedfor the formal specification and subsequentvalidation of KnowledgeBasedProcesses.
Introduction
As a professional organization involved in the development
of Knowledge-Based
intelligent
systems
for clients from various Industry sectors, weobservedthe needfor a shell-independent,
standard schemefor specifying and validating Knowledge-Based
Systems.Weobservedthat
specifying Knowledge-Based
Systemsusing conventionalspecification techniqueslike Structured
English and Flowchartswasinadequate.Therefore, as part of the KITSMethodology- the
methodologyweuse to developour brand of intelligent systems, namelyKnowiedge-integrated
Information TechnologySolutions (KITSTM) - wehave developeda tool-independent formalism to
specify and subsequentlyvalidate Knowledge-Based
Processes.
Knowledge-integratedInformation TechnologySolutions
The term Knowledge-integrated
Information TechnologySolutions (KITS) indicates
Integrated Knowledge-Based
Systemarchitecture as shownin Figure 1. The KITSarchitecture
integrates frontier technologies like Knowledge-Based
Systemsand Hypertextwith conventional
ones like DatabaseManagement
Systems, Procedural Computing,Spreadsheetsand Graphics.
Since Knowledge-Based
Systemsform a major part of the KITSarchitecture, Verification and
Validation are vital issues that are addressedin the KITSMethodology.
KITS Methodology- An Overview
TheKITSMethodology
is a comprehensive
approachto building KITS. It is built on the
basic premisethat existing modelsfor project management
like the Waterfall Modeland techniques
like DataFlowModellingare inadequatefor the professional management
of building intelligent ¯
Information systems. TheKITSMethodologyblends the tenets of the Waterfall Modeland the
Prototyping paradigmproviding a uniqueapproachto building intelligent Information Systems.
Accordingto the KITSMethodology,an application basedon the KITSarchitecture is built
in four phases,viz., Project Inception, Application Design,Prototypingand Project Completionas
shownin Figure 2.
Project Inception
Project Inception consists in evaluating the problemthrougha feasibility studyemploying
special methodsfor domainevaluation. Apart from evaluating the domain,one of the major
problemsassociatedwith building intelligent systemsof this type whichincorporateexpert
knowledge
is determiningthe complexityof the project in termsof time, peopleand cost. Project
Inception helps tackle these issues. Theend productsof Project Inception are the Functional
139
KnowledgeBased
Systems
Procedural
Computing
Hypertext
Graphics
DBMS
Spreadsheets
Figure 1. The KITSArchitecture.
ProjectInception
I
KITSMethodology
ApplicationDesign
Prototyping
ProjectCompletion
Figure 2. The KITS Methodology.
End-user
Training
KITSMethodology
ProjectInception
FeasiblityStudy
ApplicationDesign
Functional
Specifications
Prototyping
ProjectCompletion
Figure 3. The KITS Methodology- Project Inception.
140
Specifications and the Project Plan documents.Thefunctional specifications of the systemare
captured using an Information Flow Diagram(IFDTM) basedon a technique called Information Flow
Modelling[Prabhatet al, 1991].Figure 3 sumsup the activity in Project Inception.
Application Design
Application Designis the processof producinga logical and physical designof the KITS
architecture. Theprimary input to this phaseIs the Information FlowDiagramproducedIn the
Functional Specifications of the system.This abstract Information FlowDiagramis brokendowninto
manyStepsto fundamental
levels of detail. Thedetails of the elementsof the Final Step IFD are
documented
in the Information Flow Components
Dictionary (IFCD~). Thelogical view in the IFD
TM) using a technique
nowmappedonto a physical view in the SystemsArchitecture Diagram(SAD
called SystemsArchitecture Specifications. Thedetails of the elementsin the SADare then
documented
in a SystemsArchitecture Components
Dictionary (SACD~).The Application Design
phaseconcludeswith a prescription of testing strategies as shownin Figure 4.
Prototyplng
PrototypingIs the processof building a microcosmic
version of the ultimate system.It
begins with Knowledge
Acquisition wherethe domainknowledgeis acquired from the expert in the
form of rules, heuristics, proceduresand facts. Theknowledge
acquiredfrom the expert is
documented
in a shell-independentformalism called the Structured English Representationof
Knowledge
[Prabhat et al, 1992]. The output document
at the end of this sub-phaseis the
KnowledgeDocument.The KnowledgeBaseis then designed and specified. The prototype Is
implemented
and validated for conformance
to its functional specifications. TheTest Reportis
generatedat the end of this sub-phase.Wehave developedstructured methodologiesfor each of
thesesteps detailed in Figure 5.
Project Completion
Project Completionphaseconvertsthe prototype systemto the full-scale KITSarchitecture.
It begins with the necessaryredesignof the prototype and scaling up the prototype Knowledge
Baseto contain the completeknowledge.Theprototype is then ported to the delivery platform (if,
different from the development
platform) and integrated with data sourcesand sinks suchas
databases,spreadsheets,etc, Validation Testing is conductedto ensurethat the systemconforms
to the customer’s requirements. TheUser Manualis producedin the Documentation
phase. This
concludes the deploymentof the system. ChangeManagement
modulesassist in the maintenance
of the systemthereafter, Figure 6 summarizes
the activity in this phase.
141
ProjectInception
InformationFlowModelling
ApplicationDesign
SystemArchitectureSpecifications
Prototyping
TestingStrategies
KITSMethodology
Project Completion
Figure 4. The KITS Methodology - Application
Design.
ProjectInception
I
ApplicationDesign
Knowledge
Acquisition
Prototyping
Knowledge
BaseDesign& Specifications
Project Completion
PrototypeImplementation
& Testing
KITSMethodology
Figure 5. The KITS Methodology - Prototyping.
ProjectInception
Scaling up of Knowledge
Base
I
ApplicationDesign
KITS Methodology
Portingto DeliveryPlatform
Prototyping
DataSourcesIntegration
Project Completion
ValidationTesting
Documentation
ChangeManagementModules
Figure 6. The KITS Methodology - Project Completion.
142
Verification andValidation - TheContext
In the KITSMethodology,
Verification and Validation are carried out during the phasesof
Prototyping and Project Completion.In order to ensurethat all Knowledge-Based
Processesin the
KITSarchitecture conformto their functional requirements,they haveto be specified and
documented
in an unambiguous
and tool-independent formalism. In the KITS Methodology,the
specification schemeemployedis called Know/edge-Based
ProcessSpecification Language
(KPSLTM).
This languageis the common
denominatorof the constructs and facilities found in most
commercialKnowledge-Based
Systemshells. Howeverno commercialshell’s representation
languagehas been used.
Knowledge-Based
Process Specification Language
At the end of Application Designand during the phaseof Prototyping, the Knowledge
Engineer encounters various Knowledge-Based
Processes. A Knowledge-Based
Process is one that
requires reasoningand inferencing basedon expert knowledge.Theseprocessesand their
interrelationships are codified in a diagramcalled the Information FlowDiagram(IFD). An IFDis a
pictorial representationof the logical functionality of the KITSarchitecture.
As an example,let us consider a fictitious
diagnostic Knowledge-Based
System.The
systemis required to diagnosethe cause of a problemin a machineand suggest someremedial
action. TheIFD for this systemis shownin Figure 7. TheKnowledge-Based
Process"Start
DiagnosisActivity" gets the "symptom"of the problemfrom the machineoperator and performs
someInitialisation
activities. It then passesthe "symptom"
to the Knowledge-Based
Process"Find
Causeof Problem"which locates the "cause" of the problemand passesit to the Knowledge-Based
Process"SuggestRemedy
for Problem". This process prescribes a "remedy"and passes it the
Knowledge-Based
Process:’End DiagnosisActivity" which performs somewinding up activity and
returns the "remedy"to the operator. EachKnowledge-Based
Processtaps domainexpertise from
its associatedKnowledge
Repository.
All Knowledge-Based
Processesin the IFD are nowspecified using KPSLconstructs. A few
general KPSLconstructs are describedbelow. Followingthat is the KPSLspecification for the
diagnostic Knowledge-Based
System.
KPSLConstructs
Thesyntax usedto describe the KPSLconstructs is given below:
Symbol
Meaning
<>
replacewith appropriateliteral
[]
select from amongalternate choices
I
separatorfor alternate choices
143
<symptom>
~
<cause>
Start Diagnosis
I
I
<symptom>
Initialization
Knowledge
Repository
R1
Machine
Operator
I
Fault Cause
Knowledge
Repository
KR2
I
/
/
/End
/
Diagnosis~
Activity
/Suggest
Remedy~
forProblem
~
f
,f
I
KR4
I
~
/
Knowledge
End
Diagnosis
Repository
I IFau’tRe°
y
Knowledge
Repository
KR3
Legend:
I I I
Knowledge-Based
Process
Knowledge
Repository
/
/
HumanI/O Element
Figure 7. The Information Flow Diagramfor the diagnostic Knowledge-Based
System.
144
I
{}
I iteration
Operators
Arithmetic Operators
*
%
+
Relational Operators
<
>
=
Logical Operators
AND
OR
mod div
<=
>=
,
<>
NOT
Predicates
Predicatesare usedto test various conditions during the processof execution. TheKPSL
predicates are
¯
DEFINED(
<Attribute> ) - ReturnsTRUE
if <Attribute> is defined, Otherwise,returns
FALSE.
¯
NOOFVALUES(
<Attribute> ) - Returnsthe numberof values that the attribute currently
has. This is applicablefor attributes that can take morethan one value.
Problem-Solving
Constructs
Theexpressive powerof KPSLcomesfrom the set of languagestatementsthat describe
the problem-solving process. Someof themare explained below:
1.
DETERMINE
Syntax:
DETERMINE
<Attribute>
BY [ FORWARD
CHAININGI BACKWARD
CHAININGON <Attribute>
]
USING<KnowledgeRepository>
Description:
Establish a value for the attribute by forwardor backward
chaining using the given
KnowledgeRepository.
2.
ATTEMPT TO DETERMINE
Syntax:
A’I-I’EMPT TODETERMINE
<Attribute> = { <Value>}
BY [ FORWARD
CHAININGI BACKWARD
CHAININGON <Attribute>
]
USING<KnowledgeRepository>
Description:
By forward or backwardchaining on the given Knowledge
Repository, attempt to
establish that the attribute takesthe givenvalue(s). In this case,establishingthat
the attribute takes the given value is of primaryimportance.
3.
INITIALIZE
Syntax:
INITIALIZE BY [ FORWARD
CHAININGI BACKWARD
CHAININGON <Attribute>
USING<KnowledgeRepository>
145
]
Description: This is a startup mechanism
to initialize
4.
FIRE
the valuesof various attributes.
RULES
Syntax:
FIRE RULESBY [ FORWARD
CHAININGI BACKWARD-CHAINING
ON <Attribute>
]
USING<KnowledgeRepository>
Description:
,
Loadthe given knowledge
repository and fire the rules in forward or backward
chaining mode.
5.
WINDUP
Syntax:
WINDUPBY [ FORWARD
CHAININGI BACKWARD
CHAININGON <Attribute>
]
USING<KnowledgeRepository>
Description: This is a shutdownmechanism
to perform winding up operations.
6.
SET CURRENTGOAL AS
Syntax:
SET CURRENT
GOALAS <Attribute>
Description: This is a meansof reordering the sequencein which goals will be tried.
KPSLSpecification for the Diagnostic Knowledge-Based
System
Process Name
Start Diagnosis
Activity
ProcessSpecification
INITIALIZE BY FORWARD.CHAINING
ONInitialization
Knowledge
Repository
Process Name
Locate Causeof Problem
Process Specification
’
A’FFEMPTTO DETERMINE
CauseOfProblem= "Insufficient
lubrication"
BY BACKWARD
CHAININGONCauseOfProblemUSINGFault Cause Knowledge Repository
IF NOTDEFINED(CauseOfProblem)
THENATTEMPTTO DETERMINE
CauseOfProblem = "inadequate power supply" BY BACKWARD
CHAININGONCauseOfProblemUSINGFault CauseKnowledge Repository
ENDIF
IF NOTDEFINED(CauseOfProblem)
THEN DETERMINECauseOfProblem BY BACKWARD
CHAININGON CauseOfProblem USING
Fault CauseKnowledgeRepository
ENDIF
146
Process Name
Suggest Remedyfor Problem
ProcessSpecification
DETERMINERemedyOfProblem BY FORWARD
CHAININGON Fault Remedy Knowledge
Repository
*
Process Name
EndDiagnosisActivity
ProcessSpecification
WINDUPBY FORWARD
CHAININGONEnd Diagnosis Knowledge Repository
After these Knowledge-Based
Processes have been implementedusing a Knowledge-Based
shell
or a language,they can be verified and validated by ensuring that they conformto their KPSL
specifications.
Knowledge-Based
ProcessSpecification Language
- Advantages
The advantagesof KPSLare many:
¯
Thespecification results in effective Verification and Validation of Knowledge-Based
components.
¯
It is a structured language;therefore ambiguities in specifying Knowledge-Based
Processes
are significantly reducedresulting in moreaccuratevalidation.
¯
Thespecification is English-like; therefore comprehensibilityof processesis enhanced.
¯
KPSLis shell-independent. A set of Knowledge-Based
Processesspecified using KPSLcan
be implementedin morethan one Knowledge-Based
tool. This helps in easy portability
betweenshells. TheKPSLspecification forms the common
groundfrom which all physical
implementations
arise. This implies that evenif the tool is changed,the specification
remainsunaffected.
References
1. [Prabhat et al, 1991] - Prabhat G.B., Ramachandran
N., NagendraPrasadG., "KnowledgeFlow
Modelling and Beyond: Towardsa DevelopmentMethodologyfor Knowledge-Based
Systems",
Proceedingsof the AAAI-91Workshop
on Standardsin Expert System,July 1991, pp 11-34.
2. [Prabhatet al, 1992]- PrabhatG.B., Rajmohan
S., AnandhiI., SrinlvasanP., "Structured English
Representationof Knowledge- A Mediating KnowledgeRepresentationFormalism", Proceedingsof
the AAAI-92Workshopon KnowledgeRepresentationAspects of KnowledgeAcquisition, July 1992,
pp 129-146.
Trademarks
KITS, KITS Methodology,IFD, IFCD, SAD,SACD,KPSLare trademarks of SundramInformation
Systems,India.
147