REGISTER  |  SIGN IN
United States Patent5978785
Johnson , ; et al.November 2, 1999
Title
Object oriented case-based reasoning framework mechanism
Abstract
A framework for use with object-oriented programming systems provides a case-based reasoning (CBR) system shell that permits a framework user to develop a case base having case histories and generates a case-based reasoning system that receives user requests for query solutions and produces a query solution that can be incorporated into the case base. The framework includes a Session component that controls processing of the CBR system, a Control Flow component that manages the extension of the categories and classes of the OO framework, a Data Store component that stores persistent case structure definitions, case instances, and a change log, a Presentation component that manages the user interface to the CBR system user, and a Query Engine that evaluates a received query against the case base. The case definitions and case base descriptions comprise a set of object oriented classes that are organized into an inheritance hierarchy. Also disclosed is a case-based reasoning system that permits dynamic adjustment of property weights in either object oriented programming implementations or procedural programming implementations. This permits users to control which properties and weights are used and whether missing items should penalize case matching.
Inventors:Johnson; Verlyn Mark (Wykoff, MN), Koski; Dennis Dale  (Rochester, MN), Shore; Thomas Alan  (Rochester, MN)
Assignee:International Business Machines Corporation (Armonk, NY)
Appl. No.:089435
Filed:June 3, 1998
Current U.S. Class:706/54 
Field of Search:706/54
U.S. Patent Documents
4531186July 1985Knapman
4943932July 1990Lark et al.
5020019May 1991Ogawa
5057996October 1991Cutler et al.
5101364March 1992Davenport et al.
5119469June 1992Alkon et al.
5119475June 1992Smith et al.
5181162January 1993Smith et al.
5195172March 1993Elad et al.
5222195June 1993Alkon et al.
5226161July 1993Khoyi et al.
5247693September 1993Bristol
5249270September 1993Stewart et al.
5251131October 1993Masander et al.
5257384October 1993Farrand et al.
5261080November 1993Khoyi et al.
5263159November 1993Mitsui
5274572December 1993O'Neill et al.
5276775January 1994Meng
5287447February 1994Miller et al.
5289563February 1994Nomoto et al.
5293470March 1994Birch et al.
5297283March 1994Kelly, Jr. et al.
5315703May 1994Matheny et al.
5317677May 1994Dolan et al.
5341478August 1994Travis, Jr. et al.
5367633November 1994Matheny et al.
5369766November 1994Nakano et al.
5377309December 1994Sonobe et al.
5379430January 1995Nguyen
5388264February 1995Tobias, II et al.
5390325February 1995Miller
5396626March 1995Nguyen
5398336March 1995Tantry et al.
5404514April 1995Kageneck et al.
5412756May 1995Bauman et al.
5418942May 1995Krawchuk et al.
5418948May 1995Turtle
5418951May 1995Damashek
5437027July 1995Bannon et al.
5446842August 1995Schaeffer et al.
5546577August 1996Marlin et al.
5555201September 1996Dangelo et al.
5555370September 1996Li et al.
5659727August 1997Velissaropoulos et al.
5659742August 1997Beattie et al.
Foreign Patent Documents
943058669Aug., 1994EP
Other References
Inspec Abstract No. 4540729, from Bailes et al., "The Ecology of Class Refinement", Jan. 1991. .
Inspec Abstract No. 4534334, from Campbell et al., Sep. 1992, "A Technique for Documenting the Framework of an Object-Oriented System". .
Inspec Abstract No. 4534330, from Istavrinos et al., Sep. 1992, "Experiences with an Object-Oriented Mapper for Coherent Distributed Shared Memory". .
Inspec Abstract No. 4528985, from Beneventano et al., Dec. 1993, "Taxonomic Reasoning with Cycles in LOGIDATA+". .
Inspec Abstract No. 4525743, from Hakimzadeh et al., Dec. 1993, "Instance Variable Access Locking for Object-Oriented Databases". .
Inspec Abstract No. 4512593, from H. Sakai, Jun. 1993, "A Method for Contract Design and Delegation in Object Behavior Modeling". .
Inspec Abstract No. B9310-6210L-099, "Templates, Types and Classes in Open Distributed Processing", Jul. 1993, Rudkin, S. .
Inspec Abstract No. 4459325, from Kesim et al., Jun. 1992, "On the Evolution of Objects in a Logic Programming Framework". .
Inspec Abstract No. 4447153, from Klein et al., Nov. 1992, "An Object-Oriented Framework for Curves and Surfaces". .
Inspec Abstract No. 4426852, from Benveniste et al., Dec. 1992, "Concurrent Programming Notations in the Object-Oriented Language Arche". .
Inspec Abstract No. 4425343, from Demurjian et al., Feb. 1993, "Programming Versus Databases in Object-Oriented Paradigm". .
Inspec Abstract No. 4417604, from Kraiem et al., Jun. 1992, "Mapping of Conceptual Specifications Into Object-Oriented Programs". .
Inspec Abstract No. 4417563, from E. Maim, Jun. 1992, "Recognizing Objects from Constraints". .
Inspec Abstract No. 411998, from Yi Deng et al., Jun. 1992, "Unifying Multi-Paradigms in Software System Design". .
Inspec Abstract No. 4408394, from Allen et al., Jun. 1992, "GEM: Global Event Management in CAD Frameworks". .
Inspec Abstract No. 4400350, from Y. Shoham, Mar. 1993, "Agent-Oriented Programming". .
Inspec Abstract No. 4395549, from Hogstrom et al., Mar. 1992, "Portability and Data Structures in Scientific Computing-Object-Oriented Design of Utility Routines in Fortran". .
Inspec Abstract No. 4391388, from Thomas et al., Mar. 1992, "A Generic Object-Oriented Concurrency Mechanism for Extensibility and Reuse of Synchronization Components". .
Inspec Abstract No. 4387201, from Chu et al., Jun. 1992, "A Pattern Based Approach of Integrating Data and Knowledge to Support Cooperative Query Answering". .
Inspec Abstract No. 4366189, from Holt et al., Apr. 1992, "A Framework for Using Formal Methods in Object-Oriented Software Development". .
Inspec Abstract No. 4356300, from Bertino et al., Feb. 1993, "Path-Index: An Approach to the Efficient Execution of Object-Oriented Queries". .
Inspec Abstract No. 4341376, from Bertino et al., Feb. 1992, "Optimization of Object-Oriented Queries Using Path Indices". .
Inspec Abstract No. 4331060, from Lau et al., Jun. 1992, "An Object-Oriented Class Library for Scalable Parallel Heuristic Search". .
Inspec Abstract No. 4318465, from P. Madany, Jun. 1992, "Object-Oriented Framework for File Systems". .
Inspec Abstract No. 4302722, from Eggenschwiler et al., Oct. 1992, "ET++SwapsManager: Using Object Technology in the Financial Engineering Domain". .
Inspec Abstract No. 4298324, from S. Nichol, Nov. 1992, "Extending Turbo Vision". .
Inspec Abstract No. 4297404, from Tanaka et al., Apr. 1992, "Two-Level Schemata and Generalized Links for Hypertext Database Models". .
Inspec Abstract No. 4287814, from Natarajan et al., Sep. 1992, "Issues in Building Dynamic Real-Time Systems". .
Inspec Abstract No. 4281362, from Marshall et al., Oct. 1991, "Using VDM within an Object-Oriented Framework". .
Inspec Abstract No. 4275707, from Tsukamoto et al., Dec. 1991, "DOT: A Term Representation Using DOT Algebra for Knowledge-Bases". .
Inspec Abstract No. 4275698, from Van den Bussche et al., Dec. 1991, "Evaluation and Optimization of Complex Object Selections". .
Inspec Abstract No. 4275693, from Giannotti et al., Dec. 1991, "Non-Determinism in Deductive Databases". .
Inspec Abstract No. 4270361, from Artale et al., Oct. 1991, "Introducing Knowledge Representation Techniques in Database Models". .
Inspec Abstract No. 4270125, from Becker et al., Oct. 1991, "Reusable Object-Oriented Specifications for Decision Support Systems". .
Inspec Abstract No. 4258492, from M. Ball, Jul. 1992, "Inside Templates: Implementing C++ Strategies". .
Inspec Abstract No. 4258051, from Rundensteiner et al., Aug. 1992, "Set Operations in Object-Based Data Models". .
Inspec Abstract No. 4244023, from George et al., Aug. 1991, "An Object-Oriented Data Model to Represent Uncertainty in Coupled Artificial Intelligence-Database Systems". .
Inspec Abstract No. 4234438, from Madany et al., Dec. 1991, "Organizing and Typing Persistent Objects Within an Object-Oriented Framework". .
Inspec Abstract No. 4152687, from M. Wolczko, Mar. 1992, "Encapsulation, Delegation and Inheritance in Object-Oriented Languages". .
Inspec Abstract No. 4117514, from Wuwongse et al., May 1991, "An Object-Oriented Approach to Model Management". .
Inspec Abstract No. C94204-6110J-017, "Choices, Frameworks and Refinement", R. H. Campbell et al., Dec. 1991. .
Inspec Abstract No. 4090970, from P. Kougiouris, May 1991, "Device Management Framework for an Object-Oriented Operating System". .
Inspec Abstract No. 4077440, from A. Mahler, Jan. 1991, "Organizing Tools in a Uniform Environment Framework". .
Inspec Abstract No. 4067033, from Shaw et al., Jun. 1990, "Experience with the ET++ Application Framework". .
Inspec Abstract No. 4060084, from Muller et al., Jun. 1989, "ODICE: Object-Oriented Hardware Description in CAD Environment". .
Inspec Abstract No. 4050569, from Di Giovanni et al., Jun. 1990, "HOOD Nets". .
Inspec Abstract No. C91072815, from Holtkamp et al, Oct. 1990, "DEMOM-A Description Based Media Object Data Model". .
Inspec Abstract No. C91072016, from A. Lane, Jul. 1991, "/DOS/C++-Application Frameworks". .
Inspec Abstract No. C91072574, from Hemery et al., "An Analysis of Communication and Multiprogramming in the Helios Operating System", Sep. 1991. .
Inspec Abstract No. C91064787, from Madany et al., Jul. 1989, "A Class Hierarchy for Building Stream-Oriented File Systems". .
Inspec Abstract No. C91064580, from Gamma et al., Jul. 1989, "Integration of a Programming Environment into ET++-A Case Study". .
Inspec Abstract No. C91058815, from Menga et al., Mar. 1990, "G++: An Environment for Object Oriented Analysis and Prototyping". .
Inspec Abstract No. B91052096, from Cusack et al., May 1990, "Object-Oriented Specification in LOTOS and Z, or My Cat Really is Object-Oriented!". .
Inspec Abstract No. C91053475, from Queinnec et al., Jul. 1988, "An Open Ended Data Representation Model for EU-LISP". .
Inspec Abstract No. C91053151, from E. Cusack, Apr. 1991, "Refinement, Conformance and Inheritance". .
Inspec Abstract No. C91042802, from T. Yokoyama, May 1990, "An Object-Oriented and Constraint-Based Knowledge Representation System for Design Object Modeling". .
Inspec Abstract No. C91041980, from Choi et al., Jan. 1991, "Graph Interpretation of Methods: A Unifying Framework for Polymorphism in Object-Oriented Programming". .
Inspec Abstract No. C91042655, from Q. Li, Mar. 1991, "Extending Semantic Object Model: Towards More Unified View of Information Objects". .
Inspec Abstract No. C91024852, from Pierra et al., Sep. 1990, "An Object Oriented Approach to Ensure Portability of CAD Standard Parts Libraries". .
Inspec Abstract No. C91010951, from T. Helton, Nov. 1990, "Level5 Object". .
Inspec Abstract No. B90075006, from Gossain et al., Nov. 1989, "Designing a Class Hierarchy for Domain Representation and Reusability". .
Inspec Abstract No. C91003997, from J. Muys-Vasovic, Nov. 1989, "MacApp: An Object-Oriented Application Framework". .
Inspec Abstract No. C91004708, from Bertino et al., Mar. 1990, "Optimization of Queries Using Nested Indices". .
Inspec Abstract No. C90052277, from I. Tervonen, Jan. 1990, "Object-Oriented Development as a Multiview Software Construction Methodology". .
Inspec Abstract No. C90052627, from Schrefl et al., Jul. 1988, "A Knowledge-Based Approach to Overcome Structural Differences in Object Oriented Database Integration". .
Inspec Abstract No. C90047457, from Yokoyama et al., Dec. 1990, "A Constraint-Based and Object-Oriented Knowledge Representation". .
Inspec Abstract No. C90034818, from Q. Chen, Sep. 1988, "Extending the Object-Oriented Paradigm for Supporting Complex Ojects". .
Inspec Abstract No. C90030609, from Forde et al., Dec. 1990, "Object-Oriented Finite Element Analysis". .
Inspec Abstract No. C90007733, from Weinand et al., Dec. 1989, "Design and Implementation of ET++, A Seamless Object-Oriented Application Framework". .
Inspec Abstract No. C89062837, from Pasquier-Boltuck et al., Aug. 1988, "Prototyping an Interactive Electronic Book System Using an Object-Oriented Approach". .
Inspec Abstract No. C89056727, from Campbell et al., Apr. 1989, "Principles of Object-Oriented Operating System Design". .
Inspec Abstract No. C89056859, from Hull et al, May 1989, "On Accessing Object-Oriented Databases: Expressive Power, Complexity, and Restrictions". .
Inspec Abstract No. C89049257, from Madany et al., Apr. 1989, "Class Hierarchy for Building Stream-Oriented File Systems". .
Inspec Abstract No. C89039001, from Brophy et al., Jan. 1989, "A Framework for Multiple, Concurrent Graphical Representation". .
Inspec Abstract No. C89033226, from Corradi et al., Jul. 1988, "PO: An Object Model to Epxress Parallelism". .
Inspec Abstract No. C89014870, from R. King, Oct. 1988, "Semantic and Object-Oriented Database Support for Software Environments". .
Inspec Abstract No. 89003142, from Tenma et al., Dec. 1986, "A System for Generating Language-Oriented Editors". .
Inspec Abstract No. C88013915, from Woelk et al., Jul. 1987, "Multimedia Information Management in an Object-Oriented Database System". .
Inspec Abstract No. C88007447, from P. Allen, Feb. 1987, "A Framework for Implementing Multisensor Robotic Tasks". .
Inspec Abstract No. C87007043, from Whitted et al., May 1986, "Exploiting Classes in Modeling and Display Software". .
Inspec Abstract No. C86039588, from K. Fukunaga., Aug. 1985; "PROMPTER: A Knowledge Based Support Tool for Code Understanding". .
Inspec Abstract No. C86024804, from Greenspan et al., Dec. 1986, "A Requirements Modeling Language and Its Logic". .
Inspec Abstract No. C84005713, from Meyer et al., Sep. 1982, "Towards a Two-Dimensional Programming Environment". .
Inspec Abstract No. C81005505, from Mylopoulos et al., Oct. 1980, "Some Features of the TAXIS Data Model". .
Abstract from WIPO Patent Application No. WO 9422081, Sep. 29, 1994, "Hardware-Independent Interface for Interrupt Processing," G. O. Norman et al. .
P. Katalagarianos, "On the Reuse of Software: A Case-Based Approach Employing a Repository," Automated Software Engineering, Mar. 1995, vol. 2, pp. 55-86. .
Text of IBM Technical Disclosure Bulletin, vol. 37, No. 12, Dec. 1994, pp. 19-22, Al-Karmi et al., "Events Set for Event Tracing in Distributed Object-Oriented Systems". .
Text of IBM Technical Disclosure Bulletin, vol. 37, No. 12, Dec. 1994, pp. 375-378, Acker et al., "Automatically Generating Formatted Documentation for Object-Oriented Class Libraries". .
Text of IBM Technical Disclosure Bulletin, vol. 37, No. 11, Nov. 1994, pp. 71-72, Behrs et al., "Device Support Framework to Support ISO DPA 10175 and POSIX 1387.4". .
Text of IBM Technical Disclosure Bulletin, vol. 37, No. 7, Jul. 1994, pp. 145-146, Banda et al., "Exception Management Algorithm for Multi-Threaded Method Invocation". .
Text of IBM Technical Disclosure Bulletin, vol. 37, No. 6B, Jun. 1994, pp. 553-556, Gest et al., "Portable Object-Oriented Event Manager". .
Abstract for WIPO Patent Application No. WO 95/04966, F. T. Nguyen, Feb. 16, 1995, "Automatic Management of Components in Object-Oriented System". .
Abstract for U.S. Patent No. 5,388,264, Milne et al., Feb. 7, 1995, "Object-Oriented Framework System for Enabling Multimedia Presentation with Routing and Editing of MIDI Information". .
Abstract for WIPO Patent Application No. WO 94/23364, Heninger et al., Oct. 13, 1994, "Framework Processing Apparatus for Application Software". .
Abstract for U.S. Patent No. 5,369,766, Heninger et al., Nov. 29, 1994, "Object Oriented Application Processing Apparatus". .
Abstract for WIPO Patent Application No. 94/19752, Anderson et al., Sep. 1, 1994, "Concurrent Framework Processing Apparatus for Two or More Users". .
Abstract for WIPO Patent Application No. 94/19751, Anderson et al., Sep. 1, 1994, "Concurrent Framework Processing Apparatus for Application Users". .
Abstract for WIPO Patent Applicaton No. 94/19740, Goldsmith et al., Sep. 1, 1994, "Framework Processor of Object-Oriented Application". .
Abstract from WIPO Patent Application No. WO 94/15286, Goldsmith et al., Jul. 7, 1994, "Object-Oriented Framework for Object Operating System". .
Abstract for WIPO Patent Application No. 94/15282, Anderson et al., Jul. 7, 1994, "Dialog System Object-Oriented System Software Platform". .
Abstract for WIPO Patent Application No. 94/15281, Anderson et al., Jul. 7, 1994, "Atomic Command Object-Oriented System Software Platform". .
Abstract from WIPO Patent Application No. WO 9415285, Jul. 7, 1994, "Object-Oriented Notification Framework System", D. R. Anderson et al. .
Abstract for U.S. Patent No. 5,119,475, Schoen et al., Jun. 2, 1992, "Object-Oriented Framework for Menu Definition". .
Abstract for WIPO Patent Application No. 95/01610, Koko et al., Jan. 12, 1995, "Object Oriented Product Structure Management in Computer-Aided Product Design". .
Abstract for WIPO Patent Application No. 95/02219, Helgeson et al., Jan. 19, 1995, "Distributed Computation Based on Movement, Execution and Insertion of Processes in Network". .
Abstract from U.S. Patent No. 5,371,891, "Object Constructions in Compiler in Object Oriented Programming Language", J. Gray et al., Dec. 6, 1994. .
Abstract for EPO Patent No. 619544, S. Danforth, Oct. 12, 1994, "Language-Neutral Object-Oriented Programming". .
Inspec Abstract No. C9504-7460-043, Sells et al., Jul. 1994, "Implementation of the Architecture for a Time-Domain Dynamical System Simulation in a Very High-Level Pictorial Object-Oriented". .
Inspec Abstract No. C9504-7460-042, Coleman et al., Jul. 1994, "An End-to-End Simulation of A Surveillance System Employing Architecture Independence, Variable Fidelity Components and Software Reuse". .
Inspec Abstract No. C9503-6140D-045, Satoh et al., Nov. 1994, "Process Algebra Semantics for a Real Time Object Oriented Programming Language". .
Inspec Abstract No. C9501-7160-020, C. Le Pape, Nov. 1993, "The Cost of Genericity: Experiments With Constraint-Based Representations of Time-Tables". .
Inspec Abstract No. C9501-6140D-005, S. Vinoski, Sep. 1994, "Mapping CORBA IDL Into C++". .
Inspec Abstract No. C9501-7330-007, Salminen et al., Oct. 1994, "Modelling Trees Using an Object-Oriented Scheme". .
Inspec Abstract No. C9412-6110B-221, Berghel et al., Mar. 1992, "A Generic Object-Oriented Concurrency Mechanism for Extensibility and Reuse of Synchronization Components". .
Inspec Abstract No. B9412-6210Q-016, from Oingzhong et al., Mar. 1992, "An Object-Oriented Model for Ingelligent Networks". .
Inspec Abstract No. C9412-7810-003, from Jung et al., Oct. 1993, "Development of an Object-Oriented Anthropometric Database for an Ergonomic Man Model". .
Inspec Abstract No. C9412-6110J-014 from Griss et al., Nov. 1994, "Object-Oriented Reuse". .
Inspec Abstract No. C9411-6130B-108, from Mili et al., Aug. 1992, "Building a Graphical Interface for a Reuse-Oriented CASE Tool". .
Inspec Abstract No. C9411-7100-029, from C. Le Pape, Dec. 1994, "Implementation of Resource Constraints in ILOG Schedule: A Library for the Development of Constraint-Based Scheduling Systems". .
Inspec Abstract No. C9411-6115-035, from Mili et al., Jul. 1991, "SoftClass: An Object-Oriented Tool for Software-Reuse". .
Inspec Abstract No. C9410-6180G-015, from Eichelberg et al., Sep. 1993, "Integrating Interactive 3D-Graphics into an Object-Oriented Application Framework". .
Inspec Abstract No. B9409-6210M-025, from Hellemans et al., Apr. 1994, "An Object-Oriented Approach to Dynamic Service Descriptions". .
Inspec Abstract No. C9409-6180-059, from Wang et al., Aug. 1993, "A Framework for User Customization". .
Inspec Abstract No. C9408-6110B-016, from Chen et al., May 1994, "An Experimental Study of Using Reusable Software Design Frameworks to Achieve Software Reuse". .
Inspec Abstract No. C9408-7420-021, from Pirklbauer et al., May 1994, "Object-Oriented Process Control Software". .
Inspec Abstract No. C9408-6110J-011, from Gyu-Chung Han et al., Dec. 1993, "System Methodologies of Object-Oriented Programs". .
Inspec Abstract No. C9407-7420D-045, from Desai et al., "Controller Structure Definition Via Intelligent Process Control", Mar. 1994. .
Inspec Abstract No. C9407-6140D-014, from Satoh et al., May 1994, Semantics for a Real-Time Object-Oriented Programming Language. .
Inspec Abstract No. C9406-6150N-015, from Schmidt et al., Mar. 1994, "The Service Configurator Framework: An Extensible Architecture for Dynamically Configuring Concurrent, Multi-Service Network Daemons". .
Inspec Abstract No. C9405-6180G-031, from Woyak et al., Mar. 1993, "A Motif-Like Object-Oriented Interface Framework Using PHIGS". .
Inspec Abstract No. C9504-6130B-049, from A. van Dam, Oct. 1993, "VR as a Forcing Function: Software Implications of a New Paradigm". .
Inspec Abstract No. C9504-6140D-024, from Sheffler et al., Feb. 1995, "An Object-Oriented Approach to Nested Data Parallelism". .
Inspec Abstract No. C9503-6110B-045, from Rosiene et al., Mar. 1994, "A Data Modeling Framework for Queueing Network Models". .
Inspec Abstract No. B9503-8110B-023, from Mautref et al., Sep. 1994, "An Object-Oriented Framework for the Development of Interactive Decision Support System". .
Inspec Abstract No. C9502-7160-026, from Menga et al., Oct. 1994, "An Object-Oriented Framework for Enterprise Modelling". .
Inspec Abstract No. C9502-6130G-006, "Support for Enterprise Modelling in CSCW", P. Hennessy et al., Jun. 1994. .
Inspec Abstract No. C9502-7810C-058, from Lin et al., Dec. 1993, "Can CAL Software Be More Like Computer Games?" .
Inspec Abstract No. C9501-6115-039, from Elia et al., Nov. 1993, "G++: An Object Oriented Environment for Developing Distributed Applications". .
Inspec Abstract No. C9412-7330-186, from Righter et al., Oct. 1994, "An Object-Oriented Characterization of Spatial Ecosystem Information". .
Inspec Abstract No. C9412-6160J-025 from J. Livari, Dec. 1994, "Object-Oriented Information Systems Analysis: A Comparison of Six Object-Oriented Analysis Methods". .
Inspec Abstract No. C9412-6110J-006, from Lau et al., Oct. 1993, "Using SOM for Tool Integration". .
Inspec Abstract No. C9411-6160J-011, from Odberg et al., Sep. 1992, "A Framework for Managing Schema Versioning in Object-Oriented Databases". .
Inspec Abstract No. C9406-6115-048, Aug. 1993, "Constructing Multi-View Editing Environments Using MViews". .
Inspec Abstract No. 4664213, "Maintaining Information about Persistent Replicated Objects in a Distributed System", 1993 IEEE Conference on Distributed Computing Systems, May 1993. .
Inspec Abstract No. C9406-6110J-029, "A Comparison of Object-Oriented Analysis and Design Methods", Proceedings of C++ World 1993, Feb. 1993. .
Inspec Abstract No. C9406-0310F-011, Feb. 1993, "Cost-Benefit Analysis of Object-Oriented Technology". .
Inspec Abstract No. C9406-6110J-009, from J. D. Grimes, "Objects 101-An Implementation View", Proceedings of COMPCON 1994, Feb. 1994. .
Inspec Abstract No. 4647921, from Uhorchak et al., Mar. 1993, "An Object-Oriented Class Library for Creating Engineering Graphs Using PHIGS". .
Inspec Abstract No. 4642214, from Marshall et al., May 1992, "Using VDM Within an Object-Oriented Framework". .
Inspec Abstract No. 4626386, from Arora et al., Nov. 1993, "Building Diverse Environments with PCTE Workbench". .
Inspec Abstract No. 4622794, from Campbell et al., Dec. 1993, "A Technique for Documenting the Framework of an Object-Oriented System". .
Inspec Abstract No. 4618974, from Bowers, Dec. 1993, "Some Principles for the Encapsulation of the Behaviour of Aggregate Objects". .
Inspec Abstract No. 461931, from Islan et al, Sep. 1993, "Uniform Co-Scheduling Using Object-Oriented Design Techniques". .
Inspec Abstract No. 4613481, from Thieme et al., Jun. 1993, "Schema Integration in Object-Oriented Databases". .
Inspec Abstract No. 4603430, from G. Booch, Feb. 1994, "Designing an Application Framework". .
Inspec Abstract No. 4596323, from Frank et al., Mar. 1993, "An Integrated Environment for Designing Object-Oriented Enterprise Models". .
Inspec Abstract No. 4593721, Periyasamy et al., Dec. 1993, "A Formal Framework for Design and Verification of Robotic Agents". .
Inspec Abstract No. 4588839, from L. Fisher, Oct. 1992, "Constructing a Class Library for Microsoft Windows". .
Inspec Abstract No. 4588834, from G. Olander, Oct. 1992, "Chembench: Redesign of a Large Commercial Application Using Object-Oriented Techniques". .
Inspec Abstract No. 4566447, from J. Rossazza, Nov. 1992, "An Object-Centered Fuzzy Representation". .
Inspec Abstract No. 4565630, from Karpovich et al, Jul. 1993, "A Parallel Object-Oriented Framework for Stencil Algorithms". .
Inspec Abstract No. C9402-6150G-002, from Bruegge et al., Sep. 1993, "A Framework for Dynamic Program Analyzers". .
Inspec Abstract No. 4550414, from Parrish et al., Nov. 1993, "Automated Flow Graph-Based Testing of Object-Oriented Software Modules". .
L. Becker and T. Guay, "Knowledge reusability in diagnostic environments," J. of Intelligent Manufacturing, pp. 137-154, Dec. 1991. .
K. Becker and F. Bodart, "Reusable Object-Oriented Specifications for Decision Support Systems," Object Oriented Approach in Information Systems, pp. 137-155, Oct. 1991. .
E. Simoudis, et al., "Automated support for developing retrieve-and-propose systems," Proc. SPIE, Applications of Artificial Intelligence 1993: Knowledge-Based Systems in Aerospace and Industry, vol. 1963, pp. 285-292, Apr. 1993. .
T. Yamaguti and M. Kurematsu, "Legal Knowledge Acquisition Using Case-Based Reasoning and Model Inference," Proc. of the Fourth Int'l. Conf. on Artificial Intelligence and Law, pp. 212-217, Dec. 1993. .
J. Kolodner, Case-Based Reasoning, Morgan Kaufmann Pub., Inc., pp. 346-368, Dec. 1993. .
R. Bergmann, et al., "Explanation-based Similarity: A Unifying Approach for Integrating Domain Knowledge into Case-based Reasoning for Diagnosis and Planning Tasks," European Workshop on Case-Based Reasoning, Springer, pp. 182-196, Dec. 1993. .
A. Aamodt, "A Knowledge Representation System for Integration of General and Case-Specific Knowledge," Proc. Sixth Int'l. Conf. on Tools with Artificial Intelligence, pp. 836-839, Nov. 1994. .
J.P. Burke, "ART Entriprise builds professional objects," HP Professional, vol. 8(12), p. 20, Dec. 1994. .
PCAI, p. 47, Jan. 1996. .
http://www.haley.com/framed/CPR.html, Dec. 1998. .
S.K. Wong, et al., "Distributed intelligent power system protection using case based and object oriented paradigms," Int'l. Conf. on Intelligent Systems Applications to Power Systems, pp. 74-78, Jan. 1996. .
K.-D. Althoff, et al., "Case-Based Reasoning for Decision Support and Diagnostic Problem Solving: The INRECA Approach," Proc. 3rd German Workshop on CBR, pp. 63-72, Mar. 1995. .
K.-D. Althoff, et al., "INRECA--A Seamless Integration of Induction and Case-Based Reasoning for Decsion Support Tasks," Proc. 8th Workshop of the German Special Interest Group on Machine Learning, (7 pages), Dec. 1995. .
Text of IBM Technical Disclosure Bulletin, vol. 37, DeBinder et al., Feb. 1994, "Results Folder Framework", pp. 431-432. .
Text of IBM Technical Disclosure Bulletin, vol. 36, Coskun, N., Jun. 1993, "Persistent Framework Independent Record/Playback Framework", pp. 261-264. .
Text of IBM Technical Disclosure Bulletin, Baker et al., Oct. 1991, "Model View Schema", pp. 321-322. .
Text of IBM Technical Disclosure Bulletin, Baker et al., Oct. 1991, "Office Container Class", pp. 309-310. .
Text of IBM Technical Disclosure Bulletin, Cavendish et al., Jul. 1991, "Icon Pane Class", pp. 118-119. .
Text of IBM Technical Disclosure Bulletin, Baker et al., Jun. 1991, "Distribution List Class", p. 159. .
Text of IBM Technical Disclosure Bulletin, Cavendish et al., Jun. 1991, "Object-Oriented Documentation Tool", pp. 50-51. .
Text of IBM Technical Disclosure Bulletin, Allard et al., Feb. 1990, "Object-Oriented Programming in C--the Linnaeus System", pp. 437-439. .
Text of IBM Technical Disclosure Bulletin, vol. 38, No. 1, Jan. 1995, pp. 411-414, J. Knapman, "Generating Specific Server Programs in Distributed Object-Oriented Customer Information Control System"..~
Primary Examiner: Downs; Robert W.
Attorney, Agent or Firm:Martin & Associates, L.L.C. Martin; Derek P.
Parent Case Text


REFERENCE TO PARENT APPLICATION

This application is a divisional of U.S. Ser. No. 08/639,322 filed on Apr. 24, 1996 by Johnson et al., now abandoned, and entitled "Object Oriented Case-Based Reasoning Framework Mechanism", which is hereby incorporated by reference in its entirety.
Claims

We claim:
1. A computer system comprising:
a central processing unit;
a user interface; and
a main memory having an operating system that supports an object oriented programming environment containing a framework that provides an extensible case-based reasoning system that evaluates a user query by determining a set of case instance descriptions that most closely match properties of a query object corresponding to the user query and thereby produces a solution to the user query, the framework including at least one core class that cannot be modified by a user and at least one extensible class that is defined by a user to customize the framework, the customized framework then being compiled to generate a desired run-time case-based reasoning system.

2. A computer system as defined in claim 1, wherein the case instance descriptions comprise an object oriented programming case set class having case instance objects that include property objects, value objects, and attributes.

3. A computer system as defined in claim 2, wherein the framework permits a user to provide a case structure definition class that specifies an inheritance data structure for the case instance objects.

4. A computer system as defined in claim 2, wherein the case instance objects have a data structure and behavior specified by a case structure definition class having property objects and corresponding property value attributes.

5. A computer system as defined in claim 4, wherein the property objects include simple value objects and compound value objects.

6. A computer system as defined in claim 4, wherein the case instance objects further include weight instance objects that assign weight attribute values to each of the property objects.

7. A computer system as defined in claim 2, wherein the framework permits a user to provide an action prompt definition class of objects that specify computer system prompts that are displayed to a user and, upon a received user response, initiate a computer system action.

8. A computer system as defined in claim 2, wherein the framework permits a user to provide an index definition class of objects that specify a subset of the case instance object properties and in which the properties are included, thereby comprising an index to the case instance objects.

9. A computer system as defined in claim 2, wherein the query object includes a pattern of attributes and property objects and value objects corresponding to the attributes, property objects, and value objects of the case instance class of objects, and is evaluated in a match scoring operation that compares the attributes, properties, and values of the query object with the corresponding attributes, properties, and values of a case instance object and computes a match score indicating the similarity of the query object and the case instance object.

10. A computer system as defined in claim 9, wherein the match scoring operation comprises a dynamically weighted operation in which weight multiplier values are applied to designated properties of the query object and the case instance object, wherein each weight multiplier value indicates an importance ranking of the designated property relative to the other properties of the respective query object and case instance object.

11. A computer system as defined in claim 10, wherein the weight multiplier values are received from the user and are then applied to the query and case instance properties.

12. A computer system as defined in claim 11, wherein one or more of the weight multiplier values are zero, such that a zero weight multiplier value is designated for properties that are not to be penalized in the computation of a match score if unspecified.

13. A computer system as defined in claim 9, wherein the match scoring operation comprises a dynamically weighted operation in which relative usage factors are applied to designated properties of the query object and case instance object by multiplying each designated property weight of the query object and case instance object by a corresponding respective query usage scaling factor or case instance usage scaling factor.

14. A computer system as defined in claim 13, wherein the relative usage factors are received from the user and are then applied to the property weights of the query and case instance properties.

15. A computer system as defined in claim 2, wherein the framework permits a user to store the query object into the case set class, whereupon the stored query object can then be retrieved from the case set as the solution to a newly defined query object.

16. A computer system as defined in claim 2, wherein the framework permits a user to specify an incident class of objects into which a query object can be stored for later retrieval and further processing.

17. An object oriented framework for use in a computer system having an operating system that supports an object oriented programming environment that defines a case set class having case instance objects that include property objects, value objects, and attributes comprising case instance descriptions and provides an extensible case-based reasoning system that evaluates a user query by determining a set of the case instance objects that most closely match a query object corresponding to the user query and thereby produces a solution to the user query, the framework including at least one core class that cannot be modified by a user and at least one extensible class that is defined by a user to customize the framework, the customized framework then being compiled to generate a desired run-time case-based reasoning system.

18. An object oriented framework as defined in claim 17, wherein the framework permits a user to provide a case structure definition class that specifies an inheritance data structure for the case instance objects.

19. An object oriented framework as defined in claim 17, wherein the case instance objects have a data structure and behavior specified by a case structure definition class having property objects and corresponding property value attributes.

20. An object oriented framework as defined in claim 19, wherein the property objects include simple value objects and compound value objects.

21. An object oriented framework as defined in claim 19, wherein the case instance objects further include weight instance objects that assign weight attribute values to each of the property objects.

22. An object oriented framework as defined in claim 17, wherein the framework permits a user to provide an action prompt definition class of objects that specify computer system prompts that are displayed to a user and, upon a received user response, initiate a computer system action.

23. An object oriented framework as defined in claim 17, wherein the framework permits a user to provide an index definition class of objects that specify a subset of the case instance object properties and in which the properties are included, thereby comprising an index to the case instance objects.

24. An object oriented framework as defined in claim 17, wherein the query object includes a pattern of attributes and property and value objects corresponding to the attributes, property objects, and value objects of the case instance class of objects, and is evaluated in a match scoring operation that compares the attributes, properties, and values of the query object with the corresponding attributes, properties, and values of a case instance object and computes a match score indicating the similarity of the query object and the case instance object.

25. An object oriented framework system as defined in claim 24, wherein the match scoring operation comprises a dynamically weighted operation in which weight multiplier values are applied to designated properties of the query object and the case instance object, wherein each weight multiplier value indicates an importance ranking of the designated property relative to the other properties of the respective query object and case instance object.

26. An object oriented framework as defined in claim 25, wherein the weight multiplier values are received from the user and are then applied to the query and case instance properties.

27. An object oriented framework as defined in claim 25, wherein one or more of the weight multiplier values are zero, such that a zero weight multiplier value is designated for properties that are not to be penalized in the computation of a match score if unspecified.

28. An object oriented framework as defined in claim 24, wherein the match scoring operation comprises a dynamically weighted operation in which relative usage factors are applied to designated properties of the query object and case instance object by multiplying each designated property weight of the query object and case instance object by a corresponding respective query usage scaling factor or case instance usage scaling factor.

29. An object oriented framework as defined in claim 28, wherein the relative usage factors are received from the user and are then applied to the property weights of the query and case instance properties.

30. An object oriented framework as defined in claim 17, wherein the framework permits a user to store the query object into the case set class, whereupon the stored query object can then be retrieved from the case set as the solution to a newly defined query object.

31. An object oriented framework as defined in claim 17, wherein the framework permits a user to specify an incident class of objects into which a query object can be stored for later retrieval and further processing.

32. A program product for use in a computer system having an operating system that supports an object-oriented programming environment, the program product comprising:
a signal bearing media; and
a framework recorded on the signal bearing media, the framework providing an extensible case-based reasoning system that evaluates a user query by determining a set of case instance descriptions that most closely match properties of a query object corresponding to the user query and thereby produces a solution to the user query, the framework including at least one core class that cannot be modified by a user and at least one extensible class that is defined by a user to customize the framework, the customized framework then being compiled to generate a desired run-time case-based reasoning system.

33. A program product as defined in claim 32, wherein the case instance descriptions comprise an object oriented programming case set class having case instance objects that include attributes, property objects, and value objects.

34. A program product as defined in claim 33, wherein the framework permits a user to provide a case structure definition class that specifies an inheritance data structure for the case instance objects.

35. A program product as defined in claim 33, wherein the case instance objects have a data structure and behavior specified by a case structure definition class having property objects and corresponding property value attributes.

36. A program product as defined in claim 35, wherein the property objects include simple value objects and compound value objects.

37. A program product as defined in claim 35, wherein the case instance objects further include weight instance objects that assign weight attribute values to each of the property objects.

38. A program product as defined in claim 33, wherein the framework permits a user to provide an action prompt definition class of objects that specify computer system prompts that are displayed to a user and, upon a received user response, initiate a computer system action.

39. A program product as defined in claim 33, wherein the framework permits a user to provide an index definition class of objects that specify a subset of the case instance object properties and in which the properties are included, thereby comprising an index to the case instance objects.

40. A program product as defined in claim 33, wherein the query object includes a pattern of attributes and property and value objects corresponding to the attributes, property objects, and value objects of the case instance class of objects, and is evaluated in a match scoring operation that compares the attributes, properties, and values of the query object with the corresponding attributes, properties, and values of a case instance object and computes a match score indicating the similarity of the query object and the case instance object.

41. A program product as defined in claim 40, wherein the match scoring operation comprises a dynamically weighted operation in which weight multiplier values are applied to designated properties of the query object and the case instance object, wherein each weight multiplier value indicates an importance ranking of the designated property relative to the other properties of the respective query object and case instance object.

42. A program product as defined in claim 41, wherein the weight multiplier values are received from the user and are then applied to the query and case instance properties.

43. A program product as defined in claim 41, wherein one or more of the weight multiplier values are zero, such that a zero weight multiplier value is designated for properties that are not to be penalized in the computation of a match score if unspecified.

44. A program product as defined in claim 41, wherein the match scoring operation comprises a dynamically weighted operation in which relative usage factors are applied to designated properties of the query object and case instance object by multiplying each designated property weight of the query object and case instance object by a corresponding respective query usage scaling factor or case instance usage scaling factor.

45. A program product as defined in claim 44, wherein the relative usage factors are received from the user and are then applied to the property weights of the query and case instance properties.

46. A program product as defined in claim 33, wherein the framework permits a user to store the query object into the case set class, whereupon the stored query object can then be retrieved from the case set as the solution to a newly defined query object.

47. A program product as defined in claim 33, wherein the framework permits a user to specify an incident class of objects into which a query object can be stored for later retrieval and further processing.

48. A program product as defined in claim 32, wherein the signal bearing media comprises recordable media.

49. A program product as defined in claim 32, wherein the signal bearing media comprises transmission media.

50. A method of executing an application program in a computer system having a central processing unit that controls processing in the computer system, a user interface, and a main memory having an operating system that supports an object oriented programming environment, the method comprising the steps of:
providing an object oriented framework that provides an extensible case-based reasoning system, the framework including at least one core class that cannot be modified by a user and at least one extensible class that is defined by a user to customize the framework, the customized framework then being compiled to generate a desired run-time case-based reasoning system; and
evaluating a user query by determining a set of case instance descriptions that most closely match properties of a query object corresponding to the user query and thereby produces a solution to the user query.

51. A method as defined in claim 50, wherein the case instance descriptions of the provided object oriented framework comprise an object oriented programming case set class having case instance objects that include attributes, property objects, and value objects.

52. A method as defined in claim 51, wherein the provided framework permits a user to provide a case structure definition class that specifies an inheritance data structure for the case instance objects.

53. A method as defined in claim 51, wherein the case instance objects have a data structure and behavior specified by a case structure definition class having property objects and corresponding property value attributes.

54. A method as defined in claim 53, wherein the property objects include simple value objects and compound value objects.

55. A method as defined in claim 53, wherein the case instance objects further include weight instance objects that assign weight attribute values to each of the property objects.

56. A method as defined in claim 51, wherein the provided framework permits a user to provide an action prompt definition class of objects that specify computer system prompts that are displayed to a user and, upon a received user response, initiate a computer system action.

57. A method as defined in claim 51, wherein the provided framework permits a user to provide an index definition class of objects that specify a subset of the case instance object properties and in which the properties are included, thereby comprising an index to the case instance objects.

58. A method as defined in claim 51, wherein the query object includes a pattern of attributes and property objects and value objects corresponding to the attributes, property objects, and value objects of the case instance class of objects, and is evaluated in a match scoring operation that compares the attributes, properties, and values of the query object with the corresponding attributes, properties, and values of a case instance object and computes a match score indicating the similarity of the query object and the case instance object.

59. A method as defined in claim 58, wherein the match scoring operation of the provided framework comprises a dynamically weighted operation in which weight multiplier values are applied to designated properties of the query object and the case instance object, wherein each weight multiplier value indicates an importance ranking of the designated property relative to the other properties of the respective query object and case instance object.

60. A method as defined in claim 59, wherein the weight multiplier values are received from the user and are then applied to the query and case instance properties.

61. A method as defined in claim 59, wherein one or more of the weight multiplier values are zero, such that a zero weight multiplier value is designated for properties that are not to be penalized in the computation of a match score if unspecified.

62. A method as defined in claim 58, wherein the match scoring operation of the provided framework comprises a dynamically weighted operation in which relative usage factors are applied to designated properties of the query object and case instance object by multiplying each designated property weight of the query object and case instance object by a corresponding respective query usage scaling factor or case instance usage scaling factor.

63. A method as defined in claim 62, wherein the relative usage factors are received from the user and are then applied to the property weights of the query and case instance properties.

64. A method as defined in claim 51, wherein the provided framework permits a user to store the query object into the case set class, whereupon the stored query object can then be retrieved from the case set as the solution to a newly defined query object.

65. A method as defined in claim 51, wherein the provided framework permits a user to specify an incident class of objects into which a query object can be stored for later retrieval and further processing.

66. A method of executing an application program in a computer system having a central processing unit that controls processing in the computer system, a user interface, and a main memory having an operating system that supports a programming environment, the method comprising the steps of:
providing an extensible case-based reasoning framework that operates in the programming environment, the framework including at least one core class that cannot be modified by a user and at least one extensible class that is defined by a user to customize the framework and thereby define a desired case-based reasoning system;
extending the framework to define the desired case-based reasoning system;
compiling the extended framework to generate a run-time case-based reasoning system; and
executing the run-time case-based reasoning system to perform the step of evaluating a user query by determining a set of case instance descriptions that most closely match properties of a user query and thereby produces a solution to the user query; wherein:
the case instances comprise data structures that include properties, values, and attributes;
the user query specifies a pattern of properties, values, and attributes, and is evaluated in a match scoring operation that compares the properties, values, and attributes of the user query with the corresponding properties, values, and attributes of a case instance and computes a match score indicating the similarity of the user query and the case instance; and
the match scoring operation comprises a dynamically weighted operation in which weight multiplier values are applied to designated properties of the user query and the case instance, wherein each weight multiplier value indicates an importance ranking of the designated property relative to the other properties of the respective user query and case instance.

67. A method as defined in claim 66, wherein the weight multiplier values are received from the user and are then applied to the user query and case instance properties.

68. A method as defined in claim 67, wherein one or more of the weight multiplier values are zero, such that a zero weight multiplier value is designated for properties that are not to be penalized in the computation of a match score if unspecified.

69. A method as defined in claim 68, wherein the match scoring operation comprises a dynamically weighted operation in which relative usage factors are applied to designated properties of the user query and case instance by multiplying each designated property weight of the user query and case instance by a corresponding respective query usage scaling factor or case instance usage scaling factor.

70. A computer system as defined in claim 69, wherein the relative usage factors are received from the user and are then applied to the property weights of the user query and case instance properties.
Description
BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to data processing and, more specifically, to object-oriented programming systems and processes.

2. Description of the Related Art

The phrase "case-based reasoning" (CBR) generally refers to a computer process that finds solutions to current problems by examining descriptions of similar, previously encountered problems and their associated solutions, matching the novel problems to the closest previously encountered problems, and using the associated solutions to produce a solution to the current problem. In a CBR system, problem-solution descriptions are stored in a database called a case base. Weights assigned to different properties of each case are used in scoring cases for similarity against a current problem. The CBR system receives a description of a current problem, retrieves the closest matching cases from the case base using a query engine processor, and iteratively prompts the user for additional descriptive information until the retrieved case or cases are sufficiently close (similar) to be considered a solution to the current problem. The produced solution is then validated through a variety of means, such as user feedback or automatic validation. A validated solution can be added to the case base and used in future problem solving, if appropriate.

CBR systems permit experience gained from solving problems to be applied to a much larger number of problem situations than could possibly be remembered by any one individual with substantially reduced chance of providing erroneous or inconsistent solutions. Validation of problem solutions provides an additional safeguard. Finally, updating the case base permits continuous expansion of the case base against which problems are matched, reducing the likelihood that a satisfactory problem solution cannot be produced. In practical terms, CBR systems are gaining use in computer-assisted and automated help-desk and customer service systems and in computer help programs.

The construction of the case base and the way in which stored cases are matched and retrieved can vary greatly from CBR system to CBR system. For example, the case base can comprise problem-solution descriptions stored as plain language text, data records having predefined fields, or semantic networks. Case matching and retrieval processing by the query engine can comprise implementation of nearest-neighbor algorithms, decision trees, or associative memories. The user interface also must be part of the CBR system development process, including construction of the user input and solution presentation mechanisms. The development of each CBR system therefore can require much time, effort, and expense in making such data representation and processing decisions and implementing them.

Many CBR systems are tailored for each particular subject matter application and are developed using conventional procedure-oriented programming languages, such as FORTRAN, Pascal, and C. Many lines of computer programming code must be created for each application. For example, even if the same type of case-matching, query engine processing is used for different CBR systems, the query engine must be adapted to work with the problem-solution description being used. Some code can be modified from other versions, or deleted and replaced with different instructions for different applications, which still can require much analysis and design effort. The development of CBR systems would be easier, less expensive, and less time consuming if the user interface could be more consistent, representation of the problem-solution descriptions standardized, development of the case base made simpler, and the query engine made interchangeable from application to application.

As CBR systems become more widely distributed, more users of CBR systems will be novice users who might be unfamiliar with the case base and with CBR search techniques generally. With current CBR search implementations, search techniques employed by novice users can easily be relatively ineffective. For example, CBR systems typically use weighted matching techniques to find the cases in the case base that are the closest match to a set of specified search criteria. Cases are defined by a set of properties and cases are deemed more closely matched to a search query if they have more properties in common. Conventional weighting techniques can be said to penalize cases that are more completely defined (have more properties in their definition) because searches that leave many properties unspecified result in fewer completely-defined cases being deemed a match. Novice users are especially prone to leaving search properties unspecified.

Many CBR search techniques also penalize cases that are under-defined, or that have fewer properties defined than are defined in the search query. Users of the CBR system have no control over the way in which the system deals with unspecified properties. Some systems attempt to reduce such problems by assigning different weights to properties and thereby properly accommodate case properties that are not specified in a search, case properties that are unmatched to a search, or search properties that are unmatched to a case. Specifying the case base can become relatively complicated, as case base developers struggle to assign weights. Moreover, different weights might be advisable, depending on the specific search. The CBR system either becomes unresponsive to different searches or case definition becomes too complex.

In addition, it would be advantageous to permit both case base developers and CBR system users to include their knowledge about the relative importance of properties for each search query and to adjust the match scoring approach. That is, a CBR system user should not be forced to use the weight set specified by the case base developer. Unfortunately, a CBR system that also supports input of weight values for each search query has not been available.

From the discussion above, it should be apparent that there is a need for a case-based reasoning system development mechanism tool that provides a basis for more rapid, less expensive, and simpler development of case-based reasoning systems with greater user flexibility. The present invention satisfies this need.

SUMMARY OF THE INVENTION

In accordance with the present invention, a reusable object oriented (OO) framework for use with object oriented programming systems comprises a case-based reasoning (CBR) shell that permits a framework user to use a case set comprising a set of case instance descriptions and generates a case-based reasoning system that receives user requests for query solutions and produces a query solution that can be incorporated into the set of case instance descriptions. The object oriented framework includes a Control Flow component that controls processing of the CBR system, a Data Store component that manages all persistent data associated with the system, and a Presentation component that manages interface to users of the CBR system. After the OO operating environment is established, the CBR system user can engage in operations such as query processing, building case history definitions, and modifying operating parameters, according to the object definitions. Thus, the case history descriptions and search queries comprise a set of object oriented classes that are organized into an inheritance hierarchy. In this way, a single framework can be used to generate, update, and use many different case histories and evaluate search queries with reduced development time. The extended framework thereby quickly and efficiently provides a variety of case-based reasoning systems.

In addition, the present invention permits dynamic, user adjustment of property weights used in specifying a search query and in specifying a case set from which a solution will be retrieved. Such dynamic weighting can be applied to a case-based reasoning system implemented in an object oriented environment or in a procedural environment.

In one aspect of the invention, the CBR system developer uses the framework to provide a set of case definitions, property definitions, and case base descriptions for the CBR system under development. The framework provides the CBR system shell having the Control Flow component, Presentation component, Data Store component, and a Query Engine component. The extended framework provides a CBR system that includes the case base and receives a current problem query, matches the current query description to the closest case history description in the case base, and produces a solution to the current query. The produced solution is validated and, if appropriate, is added to the case base. In this way, a CBR system developer can more quickly integrate a case base with a query engine and user interface to provide an operable CBR system.

In another aspect of the present invention, property weights assigned to cases in the case base are dynamically adjusted during search and property weights are also assigned to the search query. In this way, users specifying searches can control which properties are used, what combinations of weights are used, and whether or not missing properties should penalize the case history matching.

For the case base, cases are stored as sets of property/value pairs and each property is assigned an importance rank value relative to the other properties of the case. The rank values are normalized, so that unspecified properties in a query that ordinarily would result in a lower match score instead can be compared in relative terms. Also, only properties specified in a query are considered in calculating the normalized rank score, so that unspecified properties do not skew the scoring. In a similar fashion, search queries are specified as property/value pairs and each property is assigned a normalized importance rank relative to the other properties of the search query and a match score is computed considering only the defined properties of the query. In this way, unspecified properties in a search query do not result in lower match scoring.

Other features and advantages of the present invention should be apparent from the following description of the preferred embodiment, which illustrates, by way of example, the principles of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a category diagram of an exemplary Zoo Administration framework that illustrates the principles implemented by the system of the present invention.

FIGS. 2, 3, 4, 5, and 6 are class diagrams for the exemplary Zoo Administration framework of FIG. 1.

FIG. 7 is an object diagram for the exemplary framework of FIGS. 1 through 6.

FIG. 8 is a functional block diagram of a computer processing system constructed in accordance with the present invention.

FIG. 9 is a flow diagram that illustrates the processing steps performed by the framework mechanism of the computer processing system illustrated in FIG. 8.

FIG. 10 is a flow diagram that illustrates the processing steps performed by the extended framework mechanism of the computer processing system in executing the build case structure definition step of FIG. 9.

FIG. 11 is a flow diagram that illustrates the processing steps performed by the extended framework mechanism of the computer processing system in executing the construct properties, values, and weight set processing step of FIG. 10.

FIG. 12 is a flow diagram that illustrates the processing steps performed by the extended framework mechanism of the computer processing system in executing the build case instance definitions processing step of FIG. 9.

FIG. 13 is a flow diagram that illustrates the processing steps performed by the extended framework mechanism of the computer processing system illustrated in FIG. 8 in producing a solution to a query.

FIG. 14 is a category diagram representation of the framework mechanism of the computer processing system illustrated in FIG. 8.

FIG. 15 is a class diagram representation of the CBR Session category implemented by the computer processing system illustrated in FIG. 8.

FIG. 16 is a class diagram representation of the CBR Base category implemented by the computer processing system illustrated in FIG. 8.

FIG. 17 is a class diagram representation of classes related to a case structure definition for the CBR system as implemented by the computer processing system illustrated in FIG. 8.

FIG. 18 is a class diagram representation that shows the functions implemented by the CaseDefinition category shown in FIG. 17.

FIG. 19 is a class diagram representation of the CaseDefinition category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 20 is a class diagram representation of the PropertyDefinition category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 21 is a class diagram representation of the CaseSet category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 22 is a class diagram representation of classes related to a case history instance as implemented by the computer processing system illustrated in FIG. 8.

FIG. 23 is a class diagram representation of the Case category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 24 is a class diagram representation of the Value category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 25 is a class diagram representation of the CaseInstance category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 26 is a class diagram representation of classes related to a case query as implemented by the computer processing system illustrated in FIG. 8.

FIG. 27 is a class diagram representation of the CBRQuery category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 28 is a class diagram representation of the Pattern category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 29 is a class diagram representation of the DataStoreComponent category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 30 is a class diagram representation of the ControlFlowComponent category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 31 is a class diagram representation of the PresentationPart category and related classes implemented by the computer processing system illustrated in FIG. 8.

FIG. 32 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when a CaseDefinition is created.

FIG. 33 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when Property, Value, and WeightSet objects are constructed.

FIG. 34 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when ActionPrompt, Tracking, and IndexDefinition objects are constructed.

FIG. 35 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when Pattern objects are constructed.

FIG. 36 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when a ParseDefinition object is updated.

FIG. 37 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when a CaseDefinition object is stored.

FIG. 38 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when a CaseInstance Definition object is created.

FIG. 39 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 for selection of a CaseDefinition object.

FIG. 40 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when a PropertyInstance object is created.

FIG. 41 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when PropertyInstance and Value objects are built.

FIG. 42 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when ActionPrompt objects are created and Audit methods are performed.

FIG. 43 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when IndexDefinition objects are refreshed and a CaseInstance object is stored.

FIG. 44 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when a single CBR Query is received from a user.

FIG. 45 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when building a pattern for the CBR Query.

FIG. 46 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when a received CBR Query is evaluated.

FIG. 47 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when a CaseMatch Set is built.

FIG. 48 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when a PropertyMatch Set is built.

FIG. 49 is a scenario diagram representation of the processing steps executed by the host processor illustrated in FIG. 8 when a Query solution is evaluated.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Overview--Object Oriented Technology

The present invention was developed using Object-Oriented (OO) framework technology. The preferred embodiment is implemented in an object oriented programming environment. Therefore, an exemplary OO system will be described next. Individuals skilled in the art of OO framework technology may wish to proceed to the Detailed Description section of this specification. However, those individuals who are new to framework technology, or new to OO technology in general, should read this overview section in order to best understand the benefits and advantages of the present invention.

Object-Oriented Technology v. Procedural Technology

Though the present invention relates to a particular OO technology (i.e., OO framework technology), the reader must first understand that, in general, OO technology is significantly different than conventional, process-based technology (often called procedural technology). While both technologies can be used to solve the same problem, the ultimate solutions to the problem are always quite different. This difference stems from the fact that the design focus of procedural technology is wholly different than that of OO technology. The focus of process-based design is on the overall process that solves the problem; whereas, the focus of OO design is on how the problem can be broken down into a set of autonomous entities that can work together to provide a solution. The autonomous entities of OO technology are called objects. Stated another way, OO technology is significantly different from procedural technology because problems are broken down into sets of cooperating objects instead of into hierarchies of nested computer programs or procedures. That is, procedural technology defines a system in terms of data variables and process functions whereas OO technology defines a system in terms of objects and classes.

The Term "Framework"

There has been an evolution of terms and phrases which have particular meaning to those skilled in the art of OO design. However, the reader should note that one of the most loose definitions in the OO art is the definition of the word "framework." The word framework means different things to different people. Therefore, when comparing the characteristics of two supposed OO frameworks, the reader should take care to ensure that the comparison is indeed one of "apples to apples." As will become more clear in the forthcoming paragraphs, the term framework is used in this specification to describe an OO technology system that has been designed to have core function and extensible function. The core function is that part of the framework that is not subject to modification by the framework purchaser. The extensible function, on the other hand, is that part of the framework that has been explicitly designed to be customized and extended by the framework purchaser as part of its implementation.

OO Framework

While in general terms an OO framework can be properly characterized as a type of OO solution to a programming problem, there is nevertheless a fundamental difference between a framework and a basic OO programming solution. The difference is that frameworks are designed in a way that permits and promotes customization and extension of certain aspects of the OO solution, whereas a basic OO solution can be said to comprise a particular collection, or library, of classes and objects. In other words, frameworks provide an OO programming solution that can be customized and extended to address individualized requirements that change over time. Of course, the customization/extension quality of frameworks is extremely valuable to purchasers (referred to herein as framework consumers) because the cost of customizing or extending a framework is much less than the cost of replacing or reworking an existing program solution.

Therefore, when framework designers set out to solve a particular problem, they should do more than merely design individual objects and specify how those objects interrelate. They should also design the core function of the framework (i.e., that part of the framework that is not to be subject to potential customization and extension by the framework consumer) and the extensible function of the framework (i.e., that part of the framework that is to be subject to potential customization and extension). In the end, the ultimate worth of a framework rests not only on the quality of the object design, but also on the design choices involving which aspects of the framework represent core function and which aspects represent extensible function.

ZAF--An Illustrative Framework

While those skilled in the art appreciate that framework design is necessarily an intertwined and iterative process, example design choices for a simplistic framework are set forth in the paragraphs that follow. It should be understood, though, that this is only an example framework that is being used in this specification to illustrate and best explain frameworks such that the reader can better understand and appreciate the benefits and advantages of the present invention.

Framework designers determine what objects are needed for a framework mechanism by selecting objects from what is called the problem domain. The problem domain is an abstract view of the specific problem at hand. The example problem domain chosen for the illustrative framework is that of zoo administration. The specific problem presented is that of designing a framework that assists zoo keepers in the care and feeding of zoo animals. In the example, which will be referred to as a Zoo Administration Framework (ZAF), an OO framework designer would look to the zoological problem domain and decide that any ZAF would of necessity involve an abstraction that represents the relationship between zoo keepers and animals (i.e., represents how zoo keepers care for animals). The framework designer would also likely recognize that zoo animals usually live in cages, pens, tanks, and other sorts of containment units. Therefore, the framework designer also would start with the idea that the framework would have to involve abstractions or mechanisms that represent all of these fundamental entities and relationships.

How ZAF is Designed

To begin the design process, the framework designer would likely begin with what is called a category diagram. Category diagrams are used to describe frameworks at a high level and to define how the framework components relate to one another. FIG. 1 is a category diagram for the example framework ZAF. The notation used in FIG. 1, and that used in the other figures of this specification, is explained in detail in the Notation section at the end of this portion of the specification. Each entity, or icon, in a category diagram represents groupings of data objects that perform a particular function. For the purposes of illustration, assume that the framework designer decides that ZAF should be made up of four components that, at a high level perspective, will be referred to as mechanisms: a Zoo Administration mechanism, a Zoo Keeper mechanism, an Animal mechanism, and a Containment Unit mechanism.

As shown in FIG. 1, the Zoo Administration mechanism has been designed to use the Zoo Keeper mechanism to administer the zoo. The Zoo Administration mechanism is therefore said to have a "using" relationship with the Zoo Keeper mechanism. (Again, please refer to the notation section of this specification for an explanation of this relationship and the other notation used in this specification.) As discussed above, the Zoo Administration mechanism has been designed to have responsibility for overall control of ZAF. Accordingly, the Zoo Administration mechanism is responsible for scheduling the operation of the Zoo Keeper mechanism. Note also that the framework designer has designed the Zoo Administration mechanism to be a core function of ZAF, which means that it has been designed such that it will not be subject to potential customization and extension. The upper case block letter "C" in the category box for the Zoo Administration mechanism denotes this fact. Note further that the "uses" relationship between the Zoo Administration mechanism and the Zoo Keeper mechanism also has been designed as a core function such that it is not available for ultimate customization by the framework consumer.

The Zoo Keeper mechanism has been designed to be generally responsible for the care and feeding of the zoo animals. Accordingly, it uses the Animal and Containment Unit mechanisms to perform its tasks. Unlike the design of the Zoo Administration mechanism, however, the framework designer has designed the Zoo Keeper mechanism to be an extensible function, which again means that the Zoo Keeper mechanism has been designed to be available for modification and/or extension by the framework consumer to address future care and feeding requirements. This fact is denoted by the upper case block letter "E" in the Zoo Keeper mechanism category box.

The framework designer has designed the Animal mechanism to represent the animal side of the interaction between zoo animals and zoo keepers. Since the animal population in the zoo is something that changes on a regular basis, the Animal mechanism has similarly been designed as an extensible function. The Containment Unit mechanism interacts with the Zoo Keeper mechanism by representing individual containment units such as pens, tanks, and cages. Like the Animal mechanism, the Containment Unit mechanism has been designed as an extensible function such that it can handle future customization and extension requirements. Please note here, however, that even though the Zoo Keeper, Animal, and Containment Unit mechanisms have all been designed as extensible functions, the relationships between the mechanisms have been designed to be a core function of ZAF. In other words, even though it is desirable to give ZAF's consumers flexibility relative to the Zoo Keeper, Animal, and Containment Unit mechanisms, it is not desirable to allow ZAF's consumers to change how these mechanisms relate to one another.

The framework designer next designs the classes and relationships that make up the mechanisms shown on FIG. 1. A class is a definition of a set of like objects. As such, a class can be thought of as an abstraction of the objects or as a definition of a type of object. From the view of a computer system, a single object represents an encapsulated set of data and the operation or a group of operations that are performed by a computer system upon that data. In fact, in a secure computer system, the only access to the information controlled by an object is via the object itself. This is why the information contained in an object is said to be encapsulated by the object.

Each class definition comprises data definitions that define the information controlled by the object and operation definitions that define the operation or operations performed by objects on the data that each object controls. In other words, a class definition defines how an object acts and reacts to other objects by defining an operation or set of operations that is/are performed on the defined data. (Please note that operations are sometimes called methods, method programs, and/or member functions.) When taken together, the defined operation(s) and data are said to be the behavior of the object. In essence, then, a class definition defines the behavior of its member object or objects.

FIG. 2 is an OO class diagram that shows the fundamental classes that the framework designer has designed for ZAF. Each class representation indicates its relationship to the mechanisms shown on FIG. 1. For example, the Zoo Keepers class is denoted as being from the Zoo Keeper mechanism. The fundamental classes of ZAF include: the Zoo Administrator class, which is part of the Zoo Administration mechanism; the Zoo Keeper Registry class, which is also part of the Zoo Administration mechanism; the Animal Registry class, which is part of the Zoo Keeper mechanism; the Zoo Keepers class, which is also part of the Zoo Keeper mechanism; the Containment Unit Registry class, which is also part of the Zoo Keeper mechanism; the Animals class, which is part of the Animal mechanism; and the Containment Unit class, which is part of the Containment Unit mechanism. It should be noted that the relationships between the classes have been designed as core functions of ZAF such that they are not available for ultimate modification by ZAF's consumers.

The Zoo Administrator class is the definition of the object that is responsible for the overall control of ZAF. Again, OO classes only define the objects that interact to provide a solution to the problem. However, it is by exploring the characteristics of the class definitions that one is able to understand how the objects of the framework mechanism have been designed to provide a living solution that can be customized and/or extended to address future requirements.

The Zoo Administration class has been designed to have a "uses" relationship with the Zoo Keeper Registry class. The framework designer has designed the Zoo Administration and Zoo Registry classes to be a core function of ZAF because the designer has decided that ZAF's consumers should not be allowed to modify the behavior of objects that are members of these class definitions. The Zoo Keeper Registry, which has what is called a "contains by reference" relationship with the Zoo Keepers class, is simply a class that defines an object that is a container for all zoo keeper objects. Accordingly, the Zoo Keeper Registry includes a definition for a list.sub.-- zoo.sub.-- keepers() operation. As will be described later, this operation is responsible for providing a list of Zoo Keepers objects to other objects that request such a list.

FIG. 3 shows a lower level view of the Zoo Administrator class. Because objects of type zoo administrator have responsibility for overall control of ZAF, the Zoo Administrator class has been designed to include operations that perform tasks oriented towards zoo administration. The class definition includes the following five operations: 5.sub.-- minute.sub.-- timer(), add/delete.sub.-- animal(), add/delete.sub.-- containment.sub.-- unit(), add/delete.sub.-- zoo.sub.-- keeper(), and start.sub.-- zoo.sub.-- admin().

The start.sub.-- zoo.sub.-- admin() operation is responsible for starting ZAF. That is, a user or system administrator will interact with the start.sub.-- zoo.sub.-- admin() operation to begin administration of a zoo via ZAF. The start.sub.-- zoo.sub.-- admin() operation has been designed to initiate the 5.sub.-- minute.sub.-- timer() operation such that, every five minutes, the 5.sub.-- minute.sub.-- timer() operation instructs the Zoo Keepers objects to go out and check on the zoo animals. The add/delete.sub.-- zoo.sub.-- keeper() operation is responsible for interacting with users of ZAF to define additional zoo keepers (i.e., additional Zoo Keepers classes), to add additional zoo keepers (i.e., Zoo Keepers objects), and to remove Zoo Keeper classes and/or objects. As will become clear in the forthcoming paragraphs, each of the Zoo Keepers objects is responsible for performing a particular zoo task. Therefore, it is natural that a user of ZAF might well want to add a Zoo Keepers definition and object to handle an additional zoo task or to remove a definition or object that is no longer needed. The ZAF framework designer has provided this flexibility by designing the Zoo Keeper mechanism as an extensible function.

Like the add/delete.sub.-- zoo.sub.-- keeper() operation, the add/delete.sub.-- animal() operation is responsible for interacting with users to define additional zoo animal classes and objects and also to remove classes and objects that are no longer needed. Again, it is quite natural for a zoo to need to add and remove animals. The add/delete.sub.-- containment.sub.-- unit() operation is responsible for the definition of new Containment Unit classes and objects and for removal of classes and/or objects that are no longer necessary. Again, the framework designer has provided such flexibility by designing the Animal and Containment Unit mechanisms as extensible functions.

Referring back to FIG. 2, the Zoo Keepers class definition has a "uses" relationship with the Animal Registry, Animals, Containment Unit Registry, and Containment Unit classes. Since the value of ZAF is enhanced by allowing ZAF's consumers to customize and extend the Zoo Keepers, Animals, and Containment Unit classes, the ZAF framework designer has designed these classes as extensible functions. However, changing the behavior of the Animals and Containment Unit Registry classes would disrupt the basic operation of ZAF. Therefore, the framework designer has designed these classes to be core functions of ZAF.

FIG. 4 is a class diagram of the Zoo Keepers class. However, before describing the details of FIG. 4, it is worthwhile to point out that the class definitions shown on FIG. 4 are ranked in a very simple ordering called a class hierarchy. A class, like the Zoo Keepers class, that represents the most generalized/abstract class in a class hierarchy is referred to as the base class of the hierarchy. The ordering of classes in a class hierarchy goes from most general to least general (i.e., from general to specific). Less general classes (e.g., the Feeder class) are said to inherit characteristics from the more general class or classes (i.e., the Zoo Keepers class in this case). As such, class definitions Feeder, Veterinarian, and Temperature Controller are said to be subclasses of the Zoo Keepers class. Inheritance mechanisms will be explored in more detail in the discussion associated with FIG. 5.

As shown on FIG. 4, the Zoo Keepers class definition contains a single operation definition, the check.sub.-- animals() operation definition. The reader should also note that the Zoo Keepers class definition is marked as being an abstract class. Abstract classes are not designed to have objects created as their members, but are instead used to define a common interface/protocol for their subclasses. A class is said to be an abstract class when at least one of its operation definitions is a pure virtual operation definition. Pure virtual operation definitions are designed for the sole purpose of defining a common interface for subclass definition of that operation. In other words, the design of the actual behavior (i.e., the data and operations) is left to the subclasses themselves. In the case of the Zoo Keepers class definition, the Feeder, Veterinarian, and Temperature Controller subclasses define specific implementations of the pure virtual check.sub.-- animals() operation definition that is contained in the Zoo Keepers class. An operation is marked as a pure virtual operation when it is set equal to 0.

It is important to note, though, that the common interface of a pure virtual operation definition must be honored by all subclasses such that requesting objects (called client objects) can use subclass member objects (called server objects) without needing to know the particular subclass of the server object. For example, whenever the object defined by the Zoo Administrator class needs a particular action performed, it interacts with a Zoo Keepers object. Because the interface to these objects was defined in abstract, base class Zoo Keepers and preserved in the subclass definitions for the check.sub.-- animals() operation, the Zoo Administrator object need not have special knowledge about the subclasses of any of the server objects. This has the effect of decoupling the need for the action (i.e., on the part of the zoo administrator object) from the way in which the action is carried out (i.e., by one of the objects of the Zoo Keepers subclasses). Designs (such as the ZAF design) that take advantage of the characteristics of abstract classes are said to be polymorphic.

Polymorphism is extremely important to OO framework design because it allows the way in which something is done (called the implementation) to be changed or extended without effecting the mechanisms that depend on the fact that the action is actually performed. In other words, client objects need only understand that certain objects perform certain functions, not how those functions are actually carried out. This is one way in which a properly designed OO framework can be readily customized and extended to satisfy future requirements.

As previously discussed, the framework designer has designed the ZAF framework such that Zoo Keepers objects interact with Animals and Containment Unit objects to perform their respective tasks. FIG. 5 is a class diagram for the class hierarchy of the abstract class Animals. Because the Animals class definition is responsible for representing the characteristics and behavior of zoo animals, the framework designer has designed the abstract class Animals in a way that reflects this responsibility. As shown, the example class definition for Animals includes data definitions feed.sub.-- freq, location, and temp.sub.-- range and operation definitions get.sub..sub.13 temp.sub.-- range(), feed( ), needs.sub.-- food(), needs.sub.-- vet.sub.-- visit(), and vet.sub.-- visit().

For the purposes of this framework overview, it is not necessary to explore each definition in detail. However, the temp.sub.-- range data definition and the get.sub.-- temp.sub.-- range() and feed() operation definitions are good examples of well thought out framework design choices.

The feed() operation definition is designed to perform the actual feeding of the animals (i.e., through specific feeding apparatus, which is not shown). The feed() operation is a pure virtual operation. Again, this means that the design of the class is such that the actual mechanism that performs the needed function has been left to be defined by the subclasses. Requiring subclass definition is a good design choice in cases like this where objects that are created as members of the subclasses have particularized needs. In the ZAF framework, for example, each type of animal is likely to have need for a particularized feeding apparatus, which not only makes definition of a generic feed() operation difficult, but valueless.

By way of comparison, the framework designer has explicitly designed the get.sub.-- temp.sub.-- range() operation such that it is not a pure virtual operation definition. This means that get.sub.-- temp.sub.-- range() has been generically defined as a default operation. As such, it is considered a virtual operation. Default operations are used to provide generic function to subclasses. The subclasses can simply use the default operations or they can customize or extend the default operations by redefinition. Redefinition of a default operation is called overriding the default operation.

FIG. 5 shows that Mammals is a subclass of the class Animals and, as such, the Mammals class inherits all of the characteristics of the Animals class. The Mammals class is also designed as an abstract class, which again means that it has not been designed to have objects created as its members, but has instead been designed to provide a common interface for its subclasses. Subclass Mammals is further subclassed into classes Carnivore and Herbivore.

Because definition of the feed() operation has been left up to the subclasses, the subclasses Carnivore and Herbivore each have their own definition of the feed() operation. Again, this is a good design choice because meat-eating carnivores are going to have different needs than their plant-eating counterparts.

Temp.sub.-- range is a data definition for the range of temperatures that coincides with that of the specific animal's natural habitat and the get.sub.-- temp.sub.-- range() operation definition is designed to retrieve the temp.sub.-- range for a specific animal and return it to a requesting client object. Subclass Reptiles contains its own data definition for temp.sub.-- range and its own definition for the get.sub.-- temp.sub.-- range() operation. ZAF has been designed this way to point out that data definitions can be overridden just like operation definitions. Since many reptiles live in desert conditions, where nights can be very cold and days very hot, the default tempe.sub.-- range definition has been overridden in the Reptiles class to include time and temperature information (not explicitly shown on FIG. 5). This is another good design choice because it allows ZAF to treat reptile containment units differently than other containment units by allowing temperature adjustments to be made based on the time of day as well as on the current temperature of the containment unit itself.

FIG. 6 is a class diagram showing a lower level view of the Containment Unit class. The containment unit class contains a virtual operation definition adjust.sub.-- temp(). The adjust.sub.-- temp() definition defines both the interface and mechanism used to actually adjust the temperature in the containment units of the zoo (i.e., via heating and cooling mechanisms that are not shown).

How the ZAF Objects Interact

Beyond designing the objects that make up the solution to the specific programming problem, the framework designer must also design how the individual objects interrelate. In other words, the objects must interrelate in way that takes advantage of the manner in which they were designed. As discussed, the way in which the defined operations of an object operate on the data defined for the object is called the object's behavior. While objects may be characterized as autonomous entities, it is still very important that each object exhibit a consistent behavior when interrelating with other objects. Consistent behavior is important because objects depend upon the consistent behavior of other objects so that they themselves can exhibit consistent behavior. In fact, consistent behavior is so important that an object's behavior is often referred to as the contract the object has with the other objects. When an object does not exhibit a consistent behavior, it is said to have violated its contract with the other objects.

When an operation of one object needs access to the data controlled by a second object, it is considered to be a client of the second object. To access the data controlled by the second object, one of the operations of the client will call or invoke one of the operations of the second object to gain access to the data controlled by that second object. One of the operations of the called second object (i.e., a server operation in this case) is then executed to access and/or manipulate the data controlled by the called object.

FIG. 7 is an object diagram showing how the example objects of ZAF interact to assist zoo personnel in operating the zoo. A detailed analysis of the interaction of all of the ZAF objects is unnecessary for the purposes of this overview. However, the reader should review the following simple control flow to obtain a rudimentary understanding of how objects in an OO environment interact to solve problems.

As mentioned, an object is created to be a member of a particular class. Therefore, the object Zelda the Zoo Administrator 706 is an object that is a member (actually, the only member) of the Zoo Administrator class. As such, object Zelda is responsible for overall control of ZAF. All of the Zoo Keeper objects have registered with the Zoo Keeper Register object [object 700]. Therefore, object Zelda obtains a list of the current zoo keepers by calling the list.sub.-- zoo.sub.-- keepers() operation [step 1] of the Zoo Keeper Register object. The Zoo Keeper Register object 700 has been created as a member of the Zoo Keeper Register class. For the purposes of illustration, assume that this occurs every five minutes as part of Zelda's
5.sub.-- minute.sub.-- timer() operation. The Zoo Keeper Register object then responds with the zoo keepers list [step 2]. The list of zoo keepers includes Tina the Temperature Checker [object 714], Vince the Vet. [object 740], and Fred the Animal Feeder [object 752]. Each zoo keeper has been created as a member of the Zoo Keepers class. In particular, objects Tina the Temp. Checker, Vince the Vet., and Fred the Feeder are respectively members of the Temperature Controller, Veterinarian, and Feeder subclasses.

Once the list of current zoo keepers has been returned to object Zelda 706, object Zelda instructs each zoo keeper in the list to check the animals by calling the check.sub.-- animals() operation of each Zoo Keeper object. Only the call to Tina the Temp. Checker is shown, indicated as step 3. It should be noted that object Zelda did not need to understand the types of zoo keepers that were in the zoo keeper list, the number of Zoo Keeper objects in the list, or the specialized characteristics of any one Zoo Keeper object. Object Zelda uses the same interface (i.e., the check.sub.-- animals() operation) to communicate with each Zoo Keeper object. It is then up to the individual Zoo Keeper objects to perform the task for which they have been created. Each Zoo Keeper object performs its assigned task through use of its own check.sub.-- animals() operation. For example, object Tina's check.sub.-- animals() operation retrieves a list of current animals from the Animal Registry object by calling the list.sub.-- animals() operation [step 4] and then a list of containment units from the Containment Unit Register object by calling the list.sub.-- cont.sub.-- units() operation [step 6]. Upon examining the animal list, object Tina's check.sub.-- animals() operation determines that there are only two animals currently registered in the zoo, Sam the Snake [object 728] and Simba the Lion [object 718].

Object Tina's check.sub.-- animals() operation then calls the get.sub.-- temp.sub.-- range() operations to get temperature ranges from objects Sam and Simba [steps 8 and 10]. Once the temperature ranges have been returned, the check.sub.-- animals() operation of object Tina determines which containment units house the respective animals (i.e., Simba and Sam) and then calls the adjust.sub.-- temp() operation of the appropriate containment unit (i.e., Lion Cage 7 in the case of object Simba and Snake Pit 3 in the case of object Sam) to adjust the temperature of the containment units [steps 12 and 13].

The adjust.sub.-- temp() operation of each containment unit then completes the control flow by proceeding to adjust the temperature in a way that is appropriate for the animals contained in each containment unit. (That is, the temperature is adjusted based on time and temperature for Snake Pit 3 and based on time alone for Lion Cage 7.) The reader should note that the relationship between the check.sub.-- animals() operation and the adjust temp() operations is polymorphic. In other words, the check.sub.-- animals() operation of object Tina 714 does not require specialized knowledge about how each adjust.sub.-- temp() operation performs its task. The check.sub.-- animals() operation merely had to abide by the interface and call the adjust.sub.-- temp() operations. After that, it is up to the individual adjust.sub.-- temp() operations to carry our their tasks in the proper manner.

At this point, it is again worthwhile to point out that the ZAF system is an extremely simplistic framework that has been presented to help novice readers understand some basic framework concepts so as to better appreciate the benefits and advantages of the present invention. These benefits and advantages will become more clear upon reference to the following Detailed Description.

The Computer System of the Preferred Embodiment

FIG. 8 is a block diagram of a computer system 30 constructed in accordance with the present invention. The computer system includes a central processing unit (CPU) 32 that operates in response to operator commands, which it receives from an operator/display interface 34 to which it is connected by a system bus 36. The CPU also communicates over the system bus with a main memory 38. The main memory is illustrated containing a variety of data structures, including application programs 40, objects 42, data 44, and an operating system 46. The main memory 38 is represented as a single entity, but those skilled in the art will appreciate that the main memory can comprise a combination of random access memory (RAM), hard disk drives, optical disk drives, and other storage devices containing logically segmented storage locations.

The operating system 46 preferably supports an object oriented programming environment such as provided, for example, by the C++ programming language. The application programs 40 are invoked, or launched, by a user through the operator/display interface 34. The application programs can be written in a variety of languages, including C++. The objects 42 are programming data structures of an object oriented programming language, such as C++.

The computer system 30 also includes a direct access storage device (DASD) interface 48 that is connected to the system bus 36 and also is connected to a DASD 50. Those skilled in the art will appreciate that the DASD 50 can receive and read computer program products 52 from, for example, integrated circuit chips, and also machine-readable storage devices such as magnetic media disks, on which are recorded program instructions whose execution implements the framework of the present invention. The machine-readable storage devices also can comprise, for example, media such as optical disks. The computer system 30 also includes a network interface 54 that permits communication between the CPU 32 and other computer systems 56 over a network 58. The other computer systems 56 can comprise, for example, computer systems similar in construction to the exemplary computer system 30. In that way, the computer system 30 can receive data into the main memory 38 over the network 58 after communication between the computer systems has been established by well-known methods that will be understood by those skilled in the art without further explanation.

It is important to note that, while the present invention has been (and will continue to be) described in the context of a fully functional computer system, those skilled in the art will appreciate that the mechanisms of the present invention are capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include: recordable-type media such as floppy disks and CD ROMs and transmission-type media such as digital and analog communication links.

System Processing

Start-Up Processing Steps

FIG. 9 is a flow diagram that represents a typical sequence of processing steps executed by the computer system illustrated in FIG. 8 in processing a query following case-based reasoning (CBR) system generation and start-up processing. The flow diagrams that follow are supplemented by category and object-scenario diagrams described further below.

Each time the CBR system is used, start-up processing is performed that includes initialization of data objects for classes called CBR.sub.-- Session, ControlFlowComponent, DataStoreComponent, PresentationComponent, and ChangeLog. In accordance with one aspect of object oriented programming conventional practice, object and class names will be written as words run together with initial capitals. As illustrated by the "ZAF" example described above, names are also written as words connected by an underscore. The objects and classes are described in greater detail below and are instantiated, or built, according to the object oriented programming environment provided by the computer system illustrated in FIG. 8. The start-up processing is represented by the flow diagram box number 102.

The processing represented by the flow diagram box numbered 102 is further described by the following table of pseudo-code, in which line numbers are provided to indicate ordering of processing steps:

TABLE 1 ______________________________________ Start-Up Processing. ______________________________________ 1 Construct/Initialize CBR.sub.-- SessionComponent; 2 Construct/Initialize ControlFlowComponent; 3 Construct/Initialize DataStoreComponent; 4 Construct/Initialize PresentationComponent; 5 Construct ChangeLog; 6 Execute main control flow; 7 Display menu of user options such as: 8 Single Query, 9 Build CaseDefinition, 10 Build CaseInstance; 11 Reduce Changes ChangeLog; 12 Insert ChangeLog DataStoreComponent; 13 Insert CBR.sub.-- Session DataStoreComponent; ______________________________________

In the preferred embodiment, the CBR system is implemented in an object oriented programming environment. Therefore, the processing represented by the FIG. 9 diagram box numbered 102 (and described in the pseudo-code of Table 1 ) comprises establishing the necessary processing environment. Such processing includes constructing and initializing a CBR.sub.-- SessionComponent object to control processing in the CBR system and determine the environment required by the user for additional processing, as represented by line 1 of Table 1. The information received from the CBR.sub.-- SessionComponent guides construction of a ControlFlowComponent object, a DataStoreComponent object, and a PresentationComponent object, as indicated by lines
2-4 of Table 1. A ChangeLog object also is constructed, as represented by line 5, to store system selections and changes by the user.

CBR System Input--Query Processing, Case Definitions, Search Patterns

After the system environment is established, the user can invoke various CBR system options, specifying query processing, building case definitions, or building case instances. Preferably, the user selects and defines such options in the main control flow through the user interface, by selecting menu options shown on the user display screen. These exemplary options are specified in lines 6-10 of Table 1. Those skilled in the art will appreciate that associated object oriented "destruct" operations (not listed in the pseudo-code) will be performed at the conclusion of CBR system operations to delete the objects that were constructed and/or initialized. Before any destruct operations, the CBR system changes initiated by the user are recorded in the ChangeLog object, as represented by line 11 of Table 1. The recorded changes comprise processed information that might be required in a future system operation and therefore are saved in a format for retrieval using the DataStoreComponent, as indicated by line 12. The information in the CBR.sub.-- Session object also is saved for retrieval at the next system operation, as represented by line 13.

As part of CBR processing, users may build case structure definitions, which specify how case instance descriptions will be stored. The data objects comprising each case structure are built, again according to the object oriented programming environment provided by the computer system illustrated in FIG. 8. The case structure definition processing includes parsing definitions, which are necessary to define how similar cases are recognized and problem descriptions will be analyzed.