Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!

Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


4.3. LIFE CYCLE MODELS

In Section 3, we identified the waterfall and the spiral as the principal life cycle models in software engineering. This is a simplification, of course: many life cycles have been proposed for both software development and expert system development. In this section, we comment briefly on aspects of the life cycle that relate specifically to expert systems.

From the early days of expert systems, it has been recognized that incremental development is better than monolithic development (Lyons, 1992). For example, O'Keefe (1990) shows how the spiral model can be adapted to expert system development.

Figure 3 shows the life cycle proposed by Gonzalez and Dankel (1993) for the development of knowledge-based systems. The purpose of the analysis phase is to evaluate the problem and the available resources. The specification phase is a formal presentation of the results of analysis; since knowledge-based systems are heuristic, a specification is essential. The preliminary design phase includes enough high-level design decisions to enable the construction of a prototype. The initial prototyping phase is a key step in the life cycle because the prototype justifies the design decisions. The prototype should be similar to the proposed system but may lack breadth; it does not need to be robust. During the evaluation phase, all of the previous steps are reviewed and a decision is made as to whether to complete the project. The final design phase involves completing the initial design and choosing resources for the system to be delivered.

Incremental development is used to implement the system. The implementation phase consists of acquiring all of the required knowledge and encoding it in the rule base. At various stages, testing is performed to evaluate the encoded knowledge. If necessary, design adjustment is performed between testing and the next implementation step. Finally, when the complete system has been tested, the maintenance phase begins.


FIGURE 3 Knowledge-based system life cycle.

4.4. METHODS OF KNOWLEDGE REPRESENTATION

We have assumed above that knowledge in the expert system is represented as rules. This is not always the case. Several other methods for representing knowledge are available. We discuss only software engineering aspects of knowledge representation here: other aspects may be found elsewhere (Gonzalez and Dankel, 1993; Chapter 6).

Frames. It has long been recognized that rule collections have significant limitations. They do not provide easy methods for grouping facts into convenient clusters or for associating procedural knowledge with factual knowledge. A frame encapsulates a collection of related facts and procedures. A frame has a number of slots, each of which can hold data or, exploiting LISP's capabilities, code. Frames are used in expert systems that employ model-based or case-based reasoning. Some expert systems, called hybrid systems, use both rules and frames.

Associative networks. An associative (or semantic) network is a labeled, directed graph in which nodes represent concepts and edges represent associations between concepts. Networks tend to be more explicit and succinct, and may be more efficient to process, than rules. But they have severe disadvantages: there is no accepted standard for interpretation; care must be taken to avoid invalid inferences; and combinatorial explosion may occur.

From the point of view of software engineering, there is little difference between rules, frames, and associative networks. In each case, there is a knowledge base and an inference engine, and similar development techniques are applicable. The importance of these alternative representations is that they were eventually combined with a new development in software engineering: object-oriented programming.

Objects. An object is a collection of data and a description, in the form of procedures and functions, of how the data can be manipulated. The object-oriented programming paradigm has become popular for a number of reasons, not the least of which is the fact that people find modeling with objects more natural than modeling with functions. Since programming with objects is quite different from programming with functions, new programming languages, such as Smalltalk, Eiffel, and C++, and new development paradigms have been introduced.

Object technology has been applied successfully to the engineering of expert systems. An object is in many respects similar to a frame. Objects, however, have a number of advantages over frames, including: encapsulation, or the ability of objects to hide information; inheritance, or describing properties of specific objects in terms of more general objects; and polymorphism, which enables objects of different kinds to recognize the same protocol, facilitating reuse. There is also evidence that object-oriented techniques "scale up" well, allowing the development of larger systems than other techniques from a given set of resources.

4.5. WALKTHROUGHS

Software developers use walkthroughs and inspections to check the quality of code. During a walkthrough, a group of people examine source code line by line, "walking through" it and looking for logical errors, omissions, and inconsistencies. The group is small: four members are typical, although there can be as many as eight. The author of the code is usually present. Although walkthroughs involve several people and proceed slowly -- a few hundred lines of code per hour at most -- they are more cost effective than individual debugging efforts (Russell, 1991). Inspections are similar in principle to walkthroughs but different in detail. A design inspection, for example, might be used to check that the design fulfills the requirements of a specification.

Walkthroughs are also effective for expert system development (Lyons, 1992). Experts and users can collaborate in a careful reading of the rules that is often more productive than simply running the expert system and looking at its answers.

4.6. METRICS

Effective project management requires estimation and prediction. Quantitative measurements can be used to predict the amount of effort required to complete a project, to estimate completion dates, to monitor progress, and to assess quality. Unfortunately, simple metrics, such as lines of code written, are not particularly useful. Creating better measurement tools is an active area of research.

Metrication is another area in which expert system research appears to be following the lead established by software engineering. Quantitative analysis of expert systems will enable developers to improve their estimates of the cost of constructing and maintaining particular systems (Chen, Grogono, and Suen, 1994).


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.