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.7. REUSE

A major goal of software engineering during the last decade has been "software reusability." The term refers to the fact that programmers tend to spend most of their time writing code that is very similar to code that already exists. Although this is clearly wasteful, the structured programming techniques introduced in the 1970s make it hard to avoid. The more recent paradigm, object-oriented programming, mentioned in Section 4.4, promises to simplify the task of reusing existing software.

Among expert systems, the number and size of existing rule bases is already more than sufficient to warrant interest in the reuse of rules. Modularity is a factor in the design of expert systems because a rule module is more likely to be reusable than an unstructured collection of rules. If the analogy with object-oriented programming holds, it is possible that frame-based expert systems will provide more opportunities for reuse than rule-based expert systems.

4.8. INVOLVING THE CLIENTS

In some kinds of business, the client and the supplier write a contract and then do not meet again until the product is delivered. Software engineers know that this scenario will not succeed for a product of any complexity. It is important to keep the client involved during the development of the product. This can be accomplished by incremental development, in which a series of deliverables are delivered to and accepted by the client.

The obvious advantage of client involvement is that problems that may lead to the client failing to accept the product can be recognized and corrected during development. A more subtle advantage is that the client's employees will become familiar with the expert system during development and will be less likely to reject it when the final version is delivered (Bradley and Hauser, 1995).

4.9. TRAINING THE CLIENTS

The supplier may provide the client with a "user manual" for the expert system or, if the expert system is supposed to be "user friendly," may deliver it with minimal documentation. For systems with any degree of complexity, both of these approaches are unlikely to succeed. The client may refuse delivery, or accept the system but fail to use it.

To avoid rejection of the system, client training should be included in the development of any complex expert system. Good training significantly increases the probability that the expert system will be accepted and used by the client (Liebowitz, 1991, p. 51).

5. APPLYING EXPERT SYSTEMS TO SOFTWARE ENGINEERING

The main focus of this chapter is the application of software engineering principles to expert system development. There is another side to the coin: the application of expert systems to software development. From the earliest days, programmers have enjoyed automated assistance from assemblers, compilers, debuggers, and other tools. As artificial intelligence matured, it was natural to look for intelligent assistance (Winograd, 1973). There have indeed been a number of fruitful collaborations between artificial intelligence and software engineering (Partridge, 1991). In this section, we focus specifically on the use of expert and rule-based systems in software engineering. Two issues of IEEE Expert have been devoted to the use of knowledge-based and expert systems in software engineering (Sriram and Rychener, 1986; Tanik and Yeh, 1988).

Tools that embody knowledge are ubiquitous in software engineering. For example, smart editors incorporate knowledge about the syntax of the programming language in use, and compilers embody knowledge of its semantics. These, however, are passive tools: their functions are disjoint from the activities of the programmer. The novelty introduced by artificial intelligence techniques is the interactiveness of the tools.

5.1. PECOS

PECOS represents one of the earliest attempts to apply rule-based reasoning to program development (Barstow, 1979). It uses about 400 rules, of which roughly three quarters are independent of the target language (INTERLISP). The programming methodology is similar to stepwise refinement: PECOS starts with a high-level, but formal, representation of a problem; as rules are applied, the abstract concepts of the problem statement are mapped onto lower level implementation structures; implementations are mapped onto code segments; and, eventually, the entire problem statement has been translated into code.

It is sometimes possible to apply more than one rule to a given configuration. It is therefore possible for PECOS to generate several implementations from a single problem statement, a capability that could be exploited by downstream tools to select a solution that matches particular criteria. For example, PECOS generated about a dozen different programs from a problem statement that specified a test for membership of a collection: the solutions depend on properties of the collection, such as how it is represented and whether items are ordered.

5.2. THE PROGRAMMER'S APPRENTICE

One of the best known applications of artificial intelligence to program development is the Programmer's Apprentice (PA) (Rich and Waters, 1990), a system that depends upon knowledge that is shared between the programmer and the programming environment. PA is implemented as KBEmacs -- the Knowledge-Based Editor in Emacs.

PA has a library of clichés that codify programming concepts over a wide spectrum, ranging from high-level designs such as command processor to low-level implementations such as binary search. PA uses the knowledge embodied in a cliché in several different ways: to refine the program's outline into detailed code; to detect inconsistencies between the cliché and the program's purported use of it; and to explain its (PS's) actions and decisions.

Clichés are represented in Plan Calculus. A plan is a directed graph that describes both control flow and data flow. The graphical representation avoids dependence on a particular programming language: PA has been used to assist programmers writing in LISP, Ada, and other languages. The formal meaning of a plan is the set of computations that the plan describes. Formalization allows PA to reason about plans.

PA is a knowledge-based system but not, in the strict sense, an expert system. It uses a hybrid reasoning system, called Cake, with four layers. The top layer is the Plan Calculus, and it rests on a frames layer, an algebraic reasoning layer, and a propositional logic layer. The propositional logic layer supports nonmonotonic reasoning so that facts may be retracted when they cease being true.

The Programmer's Apprentice addresses the implementation phase of software engineering. Rich and Waters have proposed apprentices for earlier phases of development: the Designer's Apprentice and the Requirements Apprentice (Rich, Waters, and Reubenstein, 1987).


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.