During the last decade, several problem-solving methods have been discovered in the domain of experts systems. [#!Cla85!#] analysed several expert systems for diagnosis and remodelled the so-called problem-solving method heuristic classification, which was implicitly used by all of these expert systems without being explicitly represented. In spite of various differences all systems have three steps in common: a data-abstraction, i.e., concrete values are mapped on intervals; a heuristic match from abstract problem descriptions to abstract solutions; the hierarchical refinement of these solutions until a final solution has been found.
Thus, Clancey describes a problem-solving method without referring to implementational details of the used knowledge representation formalism of the different systems or to the domain specific knowledge they used. The description of a problem-solving method independently from its implementation and from an application domain are the essential necessities for its reuse. In [#!BWS87!#] a whole set of different problem-solving methods is described at this level. These problem-solving methods are described by defining: the single steps called knowledge sources or inference actions; the structural dependencies of these single steps by a so-called inference structure; and the control flow, i.e. the sequence of these single steps. Such a problem-solving method is often called interpretation model because it can be used as an guideline for the knowledge acquisition process. Once selected, the method can guide the elicitation and interpretation of the experts domain knowledge required for solving the specific task.
A more operational point of view on reuse is taken by theroblem-solving methods.
To overcome these shortcomings of application generators, [#!Mus92!#] proposes a library of reusable mechanisms or generic tasks. These methods have a finer grain size than conventional expert system shells. A complete problem-solving process must be modelled by several mechanisms. These approaches are analogous to the source-code library idea in software engineering. The main characteristics of these approaches is that currently these mechanisms are only described by code and by informal descriptions of the code. Therefore, there is little support for the selection, specialization, and integration of these mechanisms. The lack of descriptions that abstract from implementational details, but do not lead to imprecise natural-language descriptions, makes it difficult to compare such mechanisms, and to provide a precise description of their problem-solving capability. Mathemaows developers to address such components through their names. Currently, there exist neither exhaustive libraries of reusable mec