In the knowledge-engineering literature we find approaches for selecting and configuring problem solving methods (e.g. [Istenes et al., 1996,Stroulia & Goel, 1994,Benjamins, 1993]). None of these approaches validate the selected or configured method or are able to execute this method. These systems are only intended for selecting or configuring a method, and checking whether the method does indeed work effectively is outside their scope. All these systems use a method-decomposition tree for describing a method. In [Istenes et al., 1996] the kind of operations on methods are: select a method, identify a possible method, choose the most favourable method. The approach in [Stroulia & Goel, 1994] comes from the field of knowledge acquisition. The system make choices, advises and interacts with the user during the configuration of a PSM. Examples of feedback of the system are: there is an error in the decomposition tree (e.g. input/output do not match), places which need more specific application conditions of methods, suggestions for changes for data or knowledge. In [Benjamins, 1993] the configuration of methods is based on a decomposition tree of tasks and methods. The decisions for the choice of a method are taken locally at each node, without referring to descendants, ancestors and siblings. The necessary and suitability application criteria determine the choice of the method. The primitive methods of such a tree are labels, which refer to a semi-formal description of the method. The contents of these ``labels'' does not influence the choices during method configuration.
For all these three systems, selecting a method means selecting an informal or semi-formal description of the method. This is a description that is oriented on algorithmic aspects of the method. However, one would expect that the functionality of the method also plays a role in method selection.
Remarkable is that all these theories of selecting and configuring problem solving methods are abstract and very high-level. This is a consequence of the desire to generalise the description of methods across very different families of methods, and therefore to avoid the use of specific knowledge, for instance knowledge of design methods. In our view, we have to exploit domain specific knowledge for strengthening of theories of problem solving methods.
Acknowledgment This work has benefited from many discussions with Dieter Fensel. We also thank Richard Benjamins and Remco Straatman for their comments on an earlier version.