![]() |
|||
![]()
|
![]() |
![]() |
![]() |
1.2. V&V IN CONVENTIONAL SOFTWARE AND V&V OF EXPERT SYSTEMSA major question within KE is how to benefit from a closer cooperation with SE. This problem is of particular interest in the area of V&V because notions such as dependability, reliability, and safety, as found in SE, are also relevant in KE. Software engineering is an established discipline that has accumulated valuable experience over a long period of time. Verification and validation are terms that have been used for several years in SE. There are now many verification and validation techniques, plus considerable experience and expertise in using them. The potential usefulness of SE specification and V&V techniques has also been discussed in some studies, some going as far as to claim that expert systems are only computer programs and so conventional techniques can straightforwardly be applied to them. However, it is generally agreed that V&V techniques for conventional software can be directly applied to three of the four components of expert systems. Those three components are the inference engine, external interfaces, and tools or utilities. The fourth component is the knowledge base (KB), for which new V&V techniques must be developed. Indeed, it is on the V&V of the KB that work in V&V of expert systems has concentrated (Vermesan and Bench-Capon, 1995). This section attempts to show what characteristics the AI software, i.e., expert systems have that create the need for extended or different V&V approaches. Most of these characteristics will relate to the KB component. The crucial characteristic of KE which sets it apart from SE is related to the requirements specifications. According to traditional SE, a complete and possibly formalized specification given in advance is of vital importance for the development of reliable software. With KB software, the situation is different. In the first place, requirements specifications for expert systems are typically vague. This can make it difficult to tell if "the right system" has been built. Secondly, it is generally hard to specify in advance an expert system completely because of the incremental nature of the knowledge elicitation process. Third, even when requirements can be written down, they may not be amenable to formal analysis. All these characteristics come from the very nature of these systems, which solve those nonstructured, ill-defined problems that cannot be solved by conventional systems. Of course, similar criticisms have also been made with respect to some conventional systems, hence the growing popularity of the prototyping life cycle for conventional systems. Moreover, in SE it is required that the specification is correct with respect to the real world. The software development process can then concentrate on producing efficient algorithms that implement the specification. No reference back to the real world is needed as long as it can be proved that they do indeed perform these transformations. In the case of expert systems, the output constantly needs to be referenced to the real world. Moreover, "correctness" of output can be a matter of opinion (or degree), and it is often difficult to get consensus among different human experts. The functionality of a conventional system typically involves the transformation of some (well-defined) input into some (well-defined) output. In the expert system, what can serve as input is typically not well defined at the outset, and the relation of possible inputs to the output may not be clear either. Other characteristics of expert systems which make it even more difficult to adapt the V & V techniques of conventional software are related to the problem-solving methods used by expert systems. Conventional problem solving deals with algorithmic software, while in expert systems solutions are found by search. While algorithms can be proved to be correct, the correctness of a collection of heuristics is quite a subjective matter, which can often only be determined by examing how they influence the behavior of the system, and is often further affected by their interaction with other heuristics in the system. Another aspect is related to the declarativeness of knowledge bases. Expert systems are usually implemented using declarative programming languages, very often rule-based languages, while conventional software is typically implemented using procedural programming languages. The procedural and declarative styles lead to different types of errors and anomalies for which different V&V techniques must be employed. Rule bases, for instance, have offered scope for techniques to capture anomalies and errors such as redundancy, dead-end rules, missing rules, subsumption, auxiliary rules, and circular rules. While these have correspondences in conventional software (e.g., unreachable code), the effects and methods of detection are rather different. Finally, there are, of course, open problems in verification and validation of conventional systems. Perhaps the biggest open problem in SE is to make verification a standard part of software production. There are numerous program design and construction methods in which verification takes place in parallel with program construction. But in the case of expert system construction, there is no generally accepted life cycle. Hence, V&V cannot be included in the life cycle a system does not have. While SE has consolidated a well-accepted life cycle, for the expert system life cycle a consensus is still missing, although it is no doubt fundamental for producing reliable systems. All these essential differences suggest that applying V&V techniques from SE to expert systems is not straightforward. Although V&V techniques work very well for conventional systems, they must be extended and adapted to work also for expert systems. Moreover, the open problems in V&V of conventional systems should not be overlooked. This suggests that it is worthwhile to look for new V&V methods and techniques for expert systems. Unfortunately, many open problems that exist in SE, remain open in KE as well.
|
![]() |
|
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. |