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


3. BOXES-AND-ARROWS APPROACHES

One of the earliest examples in the literature is that of Buchanan et al. (1983). As the book in which this paper appears is from the dawn of the commercial uptake of expert systems, it has exerted a considerable influence. Figure 2 reproduces Buchanan et al.'s approach.

Gradually this has been extended into what has come to be called the "Expert Systems Development Life Cycle"3 or ESDLC, which by minor or major variations have been modified conventional systems development approaches. The dominant variant is the waterfall approach, though sometimes (see, e.g., Khan, 1992) references are made to prototyping and even spiral-model approaches derived from the work of Boehm (1988).


3The name "cycle" seems to be wrong, because there is not much "cyclical" in the development of information systems. However, the name has caught on, probably because it is derived from the notion of the product life cycle, which is also not cyclical. This one could be derived from the human life cycle, which can be cyclical if reproduction takes place. (Un?)fortunately, information systems don't reproduce (yet?).


FIGURE 2 The life cycle model proposed by Buchanan et al. (1983)

As has already been said in the introduction, it is impossible to track all the proposals that have been made over the last 15 years in this area. In the U.S., the major effort seems to have been in the area of mapping the expert systems life cycle to existing standards for conventional software engineering (e.g., DoD-Std-2167A), which resembles the approach described in Section 5 of linking with existing methodologies for conventional systems. To summarize these efforts it seems sufficient to take one of the most recent books about building KBSs (Awad, 1996) as an example4. The life cycle given in this book is depicted in Figure 3.


4The book by Stefik (1995) is another example. He also modifies the life cycle model of Buchanan et al. (1983) and devotes approximately 15 of the more than 800 pages to methodology issues (though the book abounds with methods and techniques).

Though the world view behind approaches like the one in Figure 3 is rarely made explicit, a few of them can be inferred from the properties of Figure 3:

  • The main focus of development is on tasks; if one succeeds in carrying out the tasks prescribed, it will increase the quality of the resulting KBS.
  • Tasks must be carried out in a more or less fixed sequence that does not depend on the context.
  • Think before you build; you cannot start programming before you have done a proper and complete analysis.
  • Limited "backtracking"; as in all waterfall approaches, the developer is not supposed to go back to all activities completed before


FIGURE 3 A recent example of a waterfall model variant of Figure 2 (Awad, 1996).

Variants of this approach mostly will exhibit the following modifications:

  • Different names in the boxes. This may either reflect another way to carve up the development tasks or just semantic disagreement.
  • More or less boxes. An important problem is the grain size of the tasks. The coarser the grain size, the fewer boxes, the finer the more. Ultimately, the finer the grain size, the closer the tasks come to a "how" description of the task, which is equivalent to a method or a technique.
  • More arrows pointing to previous tasks. The strong linear development path implied by the waterfall model quite often needs modification. This can be achieved by adding arrows to tasks that have already been carried out, increasing the iterating nature of the approach. Note that more arrows of this type don't violate the basic world view that to execute a task you should at least have executed its predecessor once.

Given the abundance of schemes of the type depicted in Figure 3 and the intractability of their possible development into the other two classes, it is impossible to make any definite statement about what they have achieved. From the superficial review of the literature reported in Section 6 it appears that boxes-and-arrows approaches have been used most frequently for building KBSs.


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.