12-10-2013_09-24-50 / [Simon_Kendal,_Malcolm_Creen]_Introduction_to_Know(BookFi.org)

evaluate the use of control and domain knowledge within expert systems (ESs)

evaluate the advantages and limitations of using PSMs

describe the KADS

evaluate the place of HyM in knowledge engineering

describe how a well-structured application can be implemented using an industry standard tool

describe the current areas of methodology research.

SECTION 1: THE NEED FOR METHODOLOGIES

Introduction

This section provides an overview of the common aspects of the different methodologies discussed in the later sections.

Objectives

By the end of the section you will be able to:

Explain the advantages and disadvantages with using conventional methodologies.

Problems with Conventional Life Cycles

Traditional information systems usually perform some clearly definable processing tasks, and may have requirements that are relatively clear—though this does not preclude the possible need to developing throwaway prototypes as part of the requirement analysis phase in order to determine these requirements.

Such systems are often created using the classic waterfall approach to software development. This follows a six-stage life cycle of:

1.analysis

2.design

3.implementation

4.validation

5.installation

6.maintenance.

While these steps provide a useful structure for a traditional software development project, they can be problematic—particularly when applied to the development of a KBS. These issues are discussed in more detail below. Prior to this discussion, attempt Activity 1.

Activity 1

Given the stages in traditional information system design noted above, what might be the principle activities carried out within each stage of a specifically KBS development?

1Feasibility study

2Knowledge acquisition

3Design

4Implementation

5Validation

6Maintenance

The waterfall model of software development provides a well-structured life cycle that has on occasion worked well for the development of procedural information systems however it has one very significant weakness. For the waterfall model to work a clear and detailed set of user requirements must be obtainable during the analysis stage.

Problems with Project Specification

In the development of KBSs, unlike other types of information systems, the end goals are often not clearly defined. In particular, it is difficult to specify the knowledge that the ES must contain. For this reason the waterfall model is inappropriate for the development of KBSs.

Use of Prototyping

One of the main problems with designing ESs is the lack of any firm goals. Expert systems are primarily concerned with the capturing and processing of abstract knowledge. The knowledge domain as well as the activities involved in knowledge acquisition and processing will not be clearly defined, so the actual outputs from the system will be difficult to determine. In a conventional system, outputs can be stated precisely because inputs and processing activities can be clearly explained.

Even when the outcomes can be defined it is difficult to specify both the knowledge that is to be included within an expert system and the quality of the reasoning processes it requires. If these cannot be defined, then it is impossible to define specifications that the design and implementation can be assessed against. For this reason, the waterfall life cycle is problematic when developing any expert system. Prototyping, on the other hand, has an iterative life cycle that allows specifications to be clarified as throughout the lifetime of the project.

Capturing knowledge for KBSs can also be difficult, because detail of the knowledge to be encoded into the system may have to be checked with the human expert a number of times. This does not represent a weakness in system design, but simply shows that additional care is needed in checking the accuracy of any KBS design compared to a conventional system. In KBS terms, this checking of the logical system design is most often done by prototyping.

The prototype is therefore used to check user requirements by providing a mock-up of the knowledge within the system (see Figure 6.1).

This iterative approach has four key stages, which are repeated as necessary:

preliminary requirements are identified

a design phase is performed

a prototype is implemented

the prototype is evaluated.

Design prototype

Evaluate

FIGURE 6.1. An incremental prototyping approach for large or complex systems.

This leads to the design and development of a larger system.

Having obtained requirements from the users and performed some knowledge acquisition the rules are implemented in a prototype. The accuracy of the prototype is checked or evaluated by users, and a new prototype produced based on the expert’s opinions and suggestions. This process continues until the prototype accurately represents user requirements. The initial prototype therefore evolves into the final system.

This life cycle is particularly suited to KBSs. Knowledge-based systems can be very difficult to define even if the task they are required to perform is clear. It is difficult to define when the knowledge they contain is complete, and when the reasoning is up to the required standard. The availability of a cyclical iterative process is therefore extremely useful as it allows the quality of the reasoning process to be inspected and approved even when it was not possible to specify.

Activity 2

On the basis of your previous knowledge of prototyping, suggest what the advantages of this approach would be for the development of KBSs specifically in relation to:

the accuracy of the knowledge base

the quality of the reasoning applied to rule construction

the involvement of users.

Feedback 2

You should have been able to suggest the following advantages:

Allows the accuracy of the knowledge base to be demonstrated during iterations of the life cycle. Any errors or inaccuracies within the knowledge base should be identified as the prototype shows the use and relationship between different rules.

The quality of the reasoning is open to inspection. The detail of the knowledge base can be checked prior to detailed programming; again, any errors or inaccuracies should be identified.

It provides an easy mechanism to involve the users, management and experts. All parties involved with the design and development of the ES can be involved in the checking of the system.

Involvement of management, experts and users is an important part of convincing sceptics and gaining acceptance for the system.

Such an approach also allows the project to be signed off as complete. When the prototype is complete, then this should represent the final version of the rule or case base within the system, hence later signoff will be more of a formality than a detailed check.

Limitations of Iterative Processing

The main limitations of iterative prototyping include:

The ability to develop small projects does not always mean that it is possible to develop and maintain large real-world versions.

The difficulty in defining the costs and timetables. The number of iterations of the prototype will not be clear. This may result in high costs and development taking longer than expected as additional iterations are carried out.

Clearly, we need to overcome some of these problems.

Problems with Project Management (Users/Timescale)

As the development of a KBS is based on knowledge and human reasoning rather performing numerical calculations, management and users may be sceptical of the system. Prototyping provides a mechanism for involving such people in the project and overcoming their doubts; however, the iterative nature of the life cycle can itself cause additional problems as the number of required iterations, and thus the final cost/timescale, cannot be defined.

use of prototyping is required in order to identify the knowledge required within the system. However, prototyping does not solve all of the issues. In particular:

the final cost/timescale, cannot be defined

large KBSs can be difficult to maintain

large KBSs can be very inefficient.

To overcome these problems we need methodologies that support the development of structured and segmented knowledge bases.

Answer 2

Other system development methodologies that can be used to develop commercial systems include:

Structured systems analysis and design methodology (SSADM)

The spiral model

The ‘b’ model.

Information about these systems can be found in many different analysis texts.

Structured systems analysis and design methodology is less suited to ES development than conventional information systems because, for example, it does not recognise the additional difficulties in relation to defining user requirements faced by knowledge engineers when building an ES.

Both the spiral and ‘b’ models could incorporate knowledge engineering. The ‘b’ model may be particularly suitable, with the emphasis on testing and evaluation at the end of the model.

Details of these methodologies can be found in various places including the www.