09_Development of Expert Systems

1

The source of much of this material is Chapter 6: Design of Expert SystemsJoseph C. Giarratano and Gary D. Riley (2005). Expert Systems:Principles and Programming, 4th edition, Course Technology, Thomson Learning, Boston, Mass.

CS5370 SE Topics: KB Systems

Development of Expert Systems

Violetta Cavalli-SforzaSpring 2013

CS5370 SE Topics: KB Systems 2

Outline Introduction Selecting the Appropriate Problem & Tools Stages in the Design of an Expert System Errors in Development Stages Software Engineering and Expert Systems The Expert System Lifecycle A Detailed Lifecycle Model Summary


Introduction Knowledge Management (IM) is linked to:

Information Processing (IP) Information Systems (IS)

Information Technology (IT)

KM covers all sorts of resources for many types of audiences: Ex: office, web, FAQs, Help Desk (human/auto), email,

fax, phone, product, program, developers, managers, end-users and publicity

Large companies use own very detailed methods and tools to manage all that and sell it to others because it is profitable Semi-automated mgmt is cheaper than outsourcing


Selecting the Appropriate Problem & Tools The 4th Law of Wisdom: Before you set

out on a journey, you should know your destination

Why are you building an expert system? The president/head of company wants it There are advantages (previous slides)

Keep Intellectual Property Agreement/Rights in mind There is an expert

One expert only Multiple experts Multiple ES on Blackboard

architecture


Selecting the Appropriate Problem & Tools What is the payoff? What tools are available to build the

system? Many available, count on updates every 2

years and major revisions every 5 The 3rd Law of Wisdom: If you are lost, ask

someone. Also look on the web for use, failures and successes

The 2nd Law of Wisdom: If you are going to ask someone for help, it’s a good idea to know the language.


Knowing The Language Not just the terminology, understand the

relations At the tool-level: Each rule represents a

chunk of knowledge Strong coupling: firing of one rule guarantees

firing of another Weak coupling: firing of one rule makes many

others become available for triggering This is not bad!


Knowing The Language At the domain level: The semantic list of a

knowledge domain Semiotics (study of signs) Use the transcript of interview with expert to spot the

relationships between terms Knowledge clusters Links between knowledge clusters

Use visual representations External representation Makes explicit Something to discuss


Knowing The Tools Expert System shells:

OPS5 CLIPS JESS …

Ontology editors, e.g. Protégé. Essential for building very large systems


Selecting the Appropriate Problem & Tools How much will it cost?

The 1st Law of Wisdom: If you’ve bought a car and are not worried about the cost of gas, it’s a good idea to own your own oil well.

Don’t forget the cost of maintenance! The 0th Law of Wisdom: It’s better to use someone

else’s car and gas. Maintenance of an ES is much more difficult if your expert

is no longer available Bringing in another expert is problematic Use publicly available sources of documentation The result can be useful in handling 90% of the cases (the

easy ones) Don’t forget the cost of training CONCLUSION: Make sure your system is hard to use so

you make money training people to use it.


Stages in ES Development How will the system be developed?

What resources are available? How is the process organized and managed? Stick to what you know

Project Management Activity Management Product Configuration Management Resource Management


Project Management


Activity Management Planning

Define activities Specify priority of activities Resource requirements Milestones Durations Responsibilities

Scheduling Assign starting and ending times Resolve conflicts in scheduling tasks of equal priority

Chronicling Monitor project performance

Analysis Analyze plans, schedules, and chronicled activities


Product Configuration Management Product management

Manage different versions of product Change management

Manage change proposals and impact evaluations

Assess personnel to make changes Install new product versions


Resource Management Forecast needs for resources

Acquire resources Identify expert or knowledge base Arrange your schedule for convenience of

expert Assign responsibilities for optimum use of

resources Provide critical resources to minimize

bottlenecks.


General Stages in the Development of an Expert System


When to Deliver Ideally after all the bugs are worked out

Crucial for mission-critical software Life & very expensive property at stake

Unlikely for commercial software End-users to the testing for you

Automated-bug reports Data mining on bug reports Thresholds for fixing bugs depending on priority

Can earn money with patch downloads and fixes in new versions

Can use earned money to sustain development Announce releases with stockholder reports / to

attract venture capital


How to Deliver The multiple platform problem

Advantages of CLIPS: There are C compilers for most platforms Jess: Java is designed to be platform independent

Make sure ES software interacts well with other widely-used software Be a good host: make it easy to call other software from

the ES Be a good guest: make it easy for the ES to be called

from other software


Maintenance and Evolution As new knowledge is acquired, the performance

of the system should remain constant (or better)

Rule conflicts will happen and are normal

The Minus One Law of Wisdom: If you don’t have a specific destination, go everywhere because you never know what you are missing.

CONCLUSION: New knowledge introduces new bugs but this is an opportunity for a bigger better system that makes more money


Errors in Development Stages


Errors in Expert Systems Expert’s Errors

Flight Technique Panels (NASA) for mission critical projects

Panels … some issues Focus group Not developers unless developing for their own

culture (e.g. game developers) Minus Two Law of Wisdom: If you’re

going to set out on a journey, it’s good if you love to journey.


Software Engineering Methodology



The Expert System Lifecycle Lifecycle is a key concept in software

enginering Maintenance cost will ultimately more

important than development cost

Minus Three Law of Wisdom: If you don’t love to journey, then love what you’ve got. Not Doors BugFix No. 10 but Doors 2010


Models of Software Development The Waterfall Model

The earliest of the models Each stage ends with V & V activity Strictest version: each phase is completed fully

before the next one starts Less strict version: feedback to previous stage

only Much cheaper than iterating development over

several stages


Waterfall Model


Life Cycle = Process Model Concerned with

What should be done next? How long should the next stage be performed?

Process model is a metamethodology because it determines the order and duration of application of common software methods Specific methods to accomplish a stage include:

Planning, Requirements, Knowledge acquisition, Testing Representation of stage products: Documentation, Code,

Diagrams


Models of Software Development The Code & Fix Model

The method of choice for novice programmers of standard software and expert systems

The Do-it-Twice Model The Waterfall Model did not work so well with

Expert Systems because it assumed that all knowledge was known for a stage

In practice, could not write complete requirements till a prototype was built, so

Prototype, test to elicit requirements, build real system


Models of Software Development Incremental Model

The Incremental Model refines the Waterfall Model Major increments of functionality, e.g.

ES is assistant ES is colleague ES is expert

or by area tackled Minor increments of expertise within each level (major

increment) that offer significant increase Microincrement is the change in expertise by adding

or refining a rule


Spiral Model for ES Adapts standard

Spiral Model (Barry Boehm’s) for SE

Each spiral adds functional capability to the system


For ES: The Linear Model Describes the development of system to some

point when its functional capabilities will be evaluated Several stages, from Planning to System Evaluation

Then used for subsequent maintenance and evolution

Validation and Verification proceed in parallel Each bug fix must be carried through the same

sequence of stages to maintain quality Can be considered one circuit of the spiral model


The Linear Model Each stage consists of tasks

Planning Knowledge Definition Knowledge Design Code & Checkout Knowledge Verification System Evaluation


Linear Model of Expert System Development Cycle


Planning Stage Goal: To produce a formal work plan for development Feasibility assessment is the most important task in the life

cycle


Knowledge Definition Stage Goal: To define the knowledge requirement

for the expert system Two main tasks:

Knowledge source identification and selection Knowledge acquisition, analysis and extraction


Knowledge Definition: Acquisition, Analysis & Extraction Goal: To produce and verify the knowledge

required by the system By the time the knowledge is baselined, it

should be correct and suitable for the next stage: knowledge design

Can use human expert or automated knowledge acquisition



Knowledge Design Stage Goal: to produce the detailed design for

the ES Two main tasks:

Definition Detailed design


Knowledge Design: Definition

Internal fact structure specification is targeted at adapting a good informational style Some ES languages may have strong typing (require

values of a certain type)


Knowledge Design: Detailed Design

Goal: the baselined design document from which coding can proceed


Code & Checkout Stage Begins the actual code implementation Terminates with test readiness review


Knowledge Verification Stage Goal: to determine the correctness, completeness

and consistency of the information Two main tasks:

Formal tests Test analysis

Formal Tests Tasks


Knowledge Verification: Test Analysis Task Goal: to look for major problems

Incorrect, incomplete, inconsistent answers Assigns blame for the problem:

Rules, inference chains, uncertainty, combinations of these three factors, or

Buggy ES tools software Knowledge verification must be done on all

knowledge, not just new knowledge


System Evaluation Stage Goal: to summarize what has been learned

with recommendations for improvements and corrections

Usually and interim report describing the increased functionality

Ideally the entire system should be validated at each iteration (but the expert may get irritated).


Summary Expert systems must be quality products Factors to consider before deciding to build one

include problem appropriateness, cost, and papyoff

Managerial and technical aspects must be considered

Lifecycle models for ES: the Linear Model combined with Incremental Model

Releasing software with bugs and requesting payment for updates/fixes seems to be more profitable than releasing bug free software or retiring software

Efforts to make rules machine readable are underway with RuleXML and Rule Markup Initiative (http://www.ruleml.org)

Documents

09_Development of Expert Systems