The principal work with which the abstract-architecture approach and its implementation in DOTS should be compared is PROTÉGÉ-I [14]. PROTÉGÉ-I implements a metaview that is based on a generic problem-solving method: skeletal-plan refinement [19]. However, this method-oriented view is restricted to a single problem-solving method. A subsequent project, PROTÉGÉ-II, generalizes PROTÉGÉ-I, and removes some of these restrictions [17]. Spark, Burn, and FireFighter (SBF) [12] form a set of tools designed to make programming easier by providing reusable programming constructs, or . Spark helps the developer to identify and combine relevant mechanisms from a library. In the SBF approach, each mechanism in the library is supported by a corresponding knowledge-acquisition tool. SIS [9] is a metatool that supports a metaview similar to the abstract-architecture view. SIS, however, generates knowledge-acquisition tools that interview experts through a textual question-and-answer dialog.
PROTÉGÉ-I, SBF, and other metatools that support method-oriented views require less modeling than DOTS does, because the former metatools draw their power from assumptions on knowledge acquisition for the problem-solving method supported, and because these metatools use a priori knowledge-acquisition tool designs. Compared to PROTÉGÉ-I and SBF, DOTS trades supportive power for generality, and requires the developer to perform a knowledge-acquisition analysis that results in an overall tool design. DOTS differs from toolboxes that support programmers in the implementation of knowledge-acquisition tools in conventional programming languages [8] by providing an abstract and coherent architectural view, which hides from the developer the details of the run-time library of the knowledge-acquisition tools.