 |
Description  |
|
|
TECHNICAL FIELD OF THE INVENTION
This invention relates in general to expert systems and in particular to a method and system for specifying an expert system.
BACKGROUND OF THE INVENTION
In developing an expert system, many previous specification techniques are suitable only for a specific problem solving architecture or for a specific type of expert system (e.g., heuristic classification systems). Accordingly, it is difficult
to practically apply such previous techniques to a wide range of expert systems and problem solving architectures. Other previous techniques provide only a conceptual level approach without any formalized proofing of concepts applied to real expert
systems.
Some previous techniques, such as rapid prototyping, fail to provide a formal framework for specifying the expert system's functionality. For example, in rapid prototyping techniques, a simple prototype of the expert system is quickly developed
without comprehensive formal specification. A shortcoming of such previous techniques is that after developing the simple prototype, no comprehensive formal specification is available to assist in scaling up the simple prototype into a full-scale expert
system.
Moreover, with such previous techniques, it is difficult to systematically verify and validate the expert system at intermediate stages of development, since such techniques fail to provide a comprehensive formal specification. Intermediate
verification is desirable because it helps identify inadequacies of the expert system at an early stage of development before additional effort is wasted. Similarly, without such a specification, it is difficult to systematically test and maintain the
expert system. Accordingly, without such a specification, design failures are more likely to occur, and product costs are more likely to increase.
To assist the verification, validation, testing and maintenance, previous techniques have been used to specify conventional system applications such as filing system, real-time kernel, and user interface design. Nevertheless, such previous
techniques have limited application to highly complex and sophisticated expert systems, because such expert systems problems typically are not as well-defined and well-understood as conventional systems problems. Moreover, solutions for conventional
systems are algorithmic, while solutions for expert systems typically are non-algorithmic.
Thus, a need has arisen for a method and system for specifying an expert system according to a formal framework. A need has also arisen for a method and system for specifying a wide range of expert systems and problem solving architectures.
Further, a need has arisen for a method and system for specifying an expert system to assist in scaling up a prototype into a full-scale expert system. Moreover, a need has arisen for a method and system for specifying an expert system to assist in
systematic verification and validation of the expert system at intermediate stages of development. A further need has arisen for a method and system for specifying an expert system to assist in systematic testing and maintenance of the expert system.
Another need has arisen for a method and system for specifying an expert system, with formalized proofing of concepts applied to real expert systems.
SUMMARY OF THE INVENTION
In a first aspect of a method and system for specifying an expert system, multiple task specifications are formed for specifying tasks as functional units of the expert system. Multiple method specifications are formed for specifying methods for
accomplishing ones of the tasks. At least one of the tasks is specified as a subtask of at least one of the methods, such that ones of the task specifications are organized as a structure having multiple levels of tasks.
In a second aspect, at least one task specification is formed for specifying a task as a functional unit of the expert system. The task is represented as a precondition state before invocations of the task, and a postcondition state after the
invocations. A state model is formed including multiple state objects each representing a state of completion in a problem domain of the expert system. The precondition state and postcondition state are specified relative to the state objects.
In a third aspect, the postcondition state is specified as a soft postcondition state, such that the soft postcondition state is true after less than all of the invocations.
It is a technical advantage of the present invention that a method and system are provided for specifying an expert system according to a formal framework.
It is another technical advantage of the present invention that a method and system are provided for specifying a wide range of expert systems and problem solving architectures.
It is a further technical advantage of the present invention that a method and system are provided for specifying an expert system to assist in scaling up a prototype into a full-scale expert system.
It is yet another technical advantage of the present invention that a method and system are provided for specifying an expert system to assist in systematic verification and validation of the expert system at intermediate stages of development.
It is yet a further technical advantage of the present invention that a method and system are provided for specifying an expert system to assist in systematic testing and maintenance of the expert system.
In another technical advantage of the present invention, a method and system for specifying an expert system are provided with formalized proofing of concepts applied to real expert systems.
BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a block diagram of process circuitry for specifying an expert system, according to the system and method of the preferred embodiment;
FIG. 2 is a block diagram of an expert system development cycle according to the preferred embodiment;
FIG. 3 is an organizational chart of a task-based specification methodology ("TBSM") of process circuitry of the preferred embodiment;
FIG. 4 is a block diagram of structure of a knowledge acquisition tool of process circuitry of the preferred embodiment;
FIG. 5 is a block diagram showing hierarchical structure of major templates of the knowledge acquisition tool of FIG. 4;
FIGS. 6a-l are exemplary screen displays of templates of the knowledge acquisition tool of FIG. 4;
FIG. 7a illustrates a non-primitive task of the preferred embodiment;
FIG. 7b illustrates a primitive task of the preferred embodiment;
FIG. 8 illustrates an exemplary task/method/subtask relationship used by process circuitry of the preferred embodiment; and
FIG. 9 shows an exemplary partial hierarchy of tasks.
DETAILED DESCRIPTION OF THE INVENTION
The preferred embodiment of the present invention and its advantages are best understood by referring to FIG. 1 through 9 of the drawings, like numerals being used for like and corresponding parts of the various drawings.
FIG. 1 is a block diagram of process circuitry, indicated generally at 10, for specifying an expert system, according to the system and method of the preferred embodiment. Process circuitry 10 includes a processor 12 programmed in accordance
with the preferred embodiment for specifying an expert system. Processor 12 is connected to a non-volatile storage device 14, including fixed and non-fixed storage systems and associated disk controller circuitry. Storage device 14 inputs, stores and
outputs data and instructions used by process circuitry 10 in specifying an expert system according to the preferred embodiment. Processor 12 reads data and instructions from storage device 14, as needed, to specify an expert system. Moreover,
processor 12 writes data to storage device 14 so that results of the specification process are stored in a non-volatile manner. The specification technique of the preferred embodiment is described further hereinbelow in connection with FIGS. 2-9.
Processor 12 is further connected to a fast-access memory circuitry 16, such as dynamic random access memory ("DRAM"). Memory circuitry 16 inputs, stores and outputs instructions and other frequently accessed data as directed by processor 12
during the specification process. A knowledge engineer (not shown) specifies commands and data to processor 12 using a keyboard 18 and a pointing device 19 such as a mouse, light pen, roller ball, or joystick.
A data interface 20, such as a serial data port or a parallel data port, inputs digital data from an input data path 22. Further, data interface 20 translates data from input data path 22 into a suitable data format for output to processor 12.
Similarly, data interface 20 translates data from processor 12 into a suitable data format for output on an output data path 24.
In an exemplary embodiment, data interface 20 connects processor 12 to a network, such that information is shared between process circuitry 10 and other devices connected to data interface 20. For example, data interface 20 can be connected to
an optical scanning device via data input path 22, such that process circuitry 10 inputs digital data from the optical scanning device.
Processor 12 displays results of the specification process on a display 26 and prints the results on a printer 28. In the preferred embodiment, process circuitry 10 includes a Sun Microsystems SPARCstation 2 having a UNIX operating system.
FIG. 2 is a block diagram of an expert system development cycle according to the preferred embodiment. The development cycle begins at a block 30, where knowledge is acquired from a human expert concerning desired characteristics of an expert
system being developed. Based on the knowledge acquisition at block 30, a prototype of the expert system is developed at a block 32, and a specification of the expert system is developed at a block 34. The expert system specification developed at block
34 specifies requirements of the expert system for achieving goals of an end user of the expert system. The development of the prototype at block 32 and the development of the specification at block 34 are performed concurrently. Accordingly, as the
design of the prototype is developed at block 32, it is verified for consistency with the specification developed at block 34. After verifying the prototype developed at block 32, the prototype is executed in order to validate that the specification
developed at block 34 accurately represents the user's requirements.
Based upon the prototype developed at block 32, and upon the specification developed at block 34, a full-scale design of the expert system is developed at a block 36. The full-scale design developed at block 36 is a scaled-up version of the
design of the prototype developed at block 32. Based upon the full-scale design developed at block 36, an implementation of the expert system is developed at a block 38.
Significantly, the specification developed at block 34 advantageously provides a basis upon which verification and validation of the expert system are achieved. Moreover, the specification developed at block 34 advantageously assists in scaling
up the prototype design of block 32 to the full-scale design of block 36. Further, the specification developed at block 34 advantageously assists in systematic testing and maintenance of the full-scale design (block 36) and of the implementation (block
38).
Accordingly, after the specification is developed at block 34, the specification itself is verified for internal consistency. If inconsistencies are discovered, the specification is suitably refined. The cycle of verification and refinement of
the specification is repeated at block 34 until a sufficient level of verification is achieved.
Similarly, after the full-scale design is developed at block 36, the full-scale design is verified for consistency with the specification. If inconsistencies are discovered, the full-scale design is suitably refined. The cycle of verification
and refinement of the full-scale design is repeated at block 36 until a sufficient level of verification is achieved.
After the implementation is developed at block 38, the implementation is verified for consistency with the full-scale design. If inconsistencies are discovered, the implementation is suitably refined. The cycle of verification and refinement of
the implementation is repeated at block 38 until a sufficient level of verification is achieved.
After achieving such a sufficient level of verification at block 38, the implementation is validated for consistency with the specification. If inconsistencies are discovered, the cycles of refinement, verification and validation are repeated at
blocks 34, 36 and 38, until a sufficient level of validation is achieved.
FIG. 3 is an organizational chart, indicated generally at 50, of a task-based specification methodology ("TBSM") 52 of process circuitry 10 of the preferred embodiment. Process circuitry 10 uses TBSM 52 for specifying an expert system at block
34 of FIG. 2. TBSM 52 is organized by process circuitry 10 at block 34 (FIG. 2) around the general concept of tasks, such that a knowledge engineer focuses on generating specifications that are relevant to a given task at any point during the
specification process. A task is a functional/process unit of the expert system. Process circuitry 10 advantageously provides TBSM 52 with rigorous formal semantics to facilitate the analysis and verification of a specification developed at block 34 of
FIG. 2.
TBSM 52 of process circuitry 10 provides several advantages. First, TBSM 52 is independent of problem solving architectures. Second, TBSM 52 is applicable to a wide range of expert system applications (e.g., classification, synthesis,
monitoring and control). Third, TBSM 52 focuses on what the knowledge is, independent of how the knowledge is implemented. Fourth, TBSM 52 introduces major concepts in a gradual manner. Fifth, TBSM 52 facilitates explicit documentations of an expert
system's functional requirements. Sixth, TBSM 52 enables explicit documentations of an expert system's intended behavior. Seventh, TBSM 52 supports verification, validation, testing and maintenance.
Toward these objectives, TBSM 52 of process circuitry 10 provides a specification having two primary components: a model specification 54 that describes static properties of the system, and a process specification 56 that describes dynamic
properties of the system. The static properties of the system are described in model specification 54 by two models: a domain model 58 for describing domain objects, and a state model 60 for describing problem solving states relevant to a task.
Domain model 58 describes terms 62, relations 64, and constraints 66 that are relevant to a task. Each of terms 62 is a user-defined type that represents either abstract concepts (e.g. configured-backplane) or concrete concepts (e.g. cable
length). Each of relations 64 describes a property of one of terms 62 (e.g. has-component) or a relationship between multiple ones of terms 62 (e.g. has-connection).
TBSM 52 of process circuitry 10 distinguishes three dimensions that are useful for categorizing constraints 66.
Dimension 1
Functional vs non-functional constraints 68: A functional constraint is a one-to-one mapping from a set of variables to a constrained variable. A non-functional constraint is a multiple-valued mapping. While a functional constraint can be
specified by a technique for determining the constrained variable's value, a non-functional constraint can be specified using a predicate description or a function that generates all values satisfying the constraint such as tuples in MOLGEN or interval
(e.g..chi. [1,5]). This distinction affects the problem solving aspects. More specifically, functional constraints deterministically specify the values of the constrained variable, such that a search is not required. By comparison, nonfunctional
constraints require a search, due to their non-deterministic nature.
Dimension 2
Strong vs weak constraints 70: A strong constraint provides an order to be obeyed. It can describe a solution or a situation. The specification of a strong constraint can include one or several fixes that describe various ways to repair a
violation of the constraint. A weak constraint describes a preference, which provides advice for finding a better solution. Weak constraints are not rigid constraints, such that TBSM 52 of process circuitry 10 is not required to specify a repair method
for fixing a violation of these constraints. By distinguishing strong constraints from weak ones, TBSM 52 of process circuitry 10 can verify the consistency between constraints 66 and the postcondition 84.
Dimension 3
Positive vs negative constraints 72: A positive constraint describes legal values of a variable in terms of other variables. A negative constraint is a constraint that describes illegal values of a constrained variable. By providing this
distinction, TBSM 52 of process circuitry 10 assists the selection of problem solving methods refined from tasks. For example, positive constraints can be used for proposing for a solution in propose-revise methods, while negative constraints can be
used to test a constraint violation.
The second component of model specification 54 describes a state model 60 for describing problem solving states (i.e. partial solutions) in a problem domain of the expert system. State model 60 is a generalization of the concept of flavors in
flavor analysis. Flavors are properties of objects which change during execution of a process. With TBSM 52 of process circuitry 10, state model 60 defines (1) the status of an object that reflects various stages of its completion 74 in problem
solving, and (2) the dynamic relationships between multiple objects for constraint satisfaction 76.
By defining such terms using components of domain model 58, state model 60 facilitates the description of complex constraints regarding the functionality of a task, because state model 60 simplifies the description of preconditions 80,
protections 82, and postconditions 4. State model 60 also enhances the reusability of constraints 66 and simplifies functional specification 78. Accordingly, state model 60 provides a bridge between domain model 58 and a functional specification 78 of
process specification 56.
The dynamic properties of the expert system are described in process specification 56 by two specifications: (1) a functional specification 78 using the concept of state transition to explicitly describe the functionality of a task using
preconditions 80, protections 82, and postconditions 84, and (2) a behavioral specification 86 specifying the relationships, sequence/intention and interactions of tasks, methods for accomplishing the tasks, and subtasks of the methods using task state
expression ("TSE") 88. TSE 88 describes (1) an expectation 90 of desirable sequencing/intention of tasks and of undesirable sequencing/intention of tasks, and (2) an interaction 92 among tasks and methods at different levels.
Process circuitry 10 represents functionality of a task as a sequence of state transitions, and states are specified before, during, and after the operation using precondition 80, protection 82 and postcondition 84 which are partial description
of the state. By representing a task as a sequence of state transitions, TBSM 52 of process circuitry 10 specifies "what the functionality is" independent of "how the functionality is achieved". Moreover, process circuitry 10 extends the conventional
concept of tasks to capture potentially conflicting functional requirements on a complex operation. Precondition 80 of a task describes the situation under which the task can be invoked.
Protection 82 describes one or more state properties to be maintained at various stages of completion between precondition 80 and postcondition 84 of a task. Accordingly, protection 82 limits coupling between tasks in order to protect state
properties that need to be maintained. Protection can be either inherited from a parent task (i.e., global protection 94) or directly specified locally (i.e., local protection 96). Process circuitry 10 verifies locally specified protection against any
inherited protection for consistency. The distinction of high level global protection 94 and low level local protection 96 assists verification of multilevel specifications.
Postcondition 84 of a task describes desirable state changes that should be achieved by the task, which can thus be classified into two categories: rigid 98 and soft 99. A rigid postcondition 98 is a condition that must always be satisfied by
the states after applying the task. A soft postcondition 99 is a condition that is satisfied for some of the state transitions. By distinguishing rigid 99 from soft 98 postconditions, TBSM 52 of process circuitry 10 represents both minimum and desired
functional requirements. Moreover, by distinguishing soft 98 and rigid 99 postconditions, TBSM 52 of process circuitry 10 enables specification of functional requirements that are conflicting in nature.
Process circuitry 10 supports its TBSM 52 with a hypertext-based knowledge acquisition tool: TAME (a Task-based knowledge Acquisition Methodology for Expert systems). Much human knowledge is not well-structured for formal representation and
computer processing. In expert systems, adequate explanation requires the storing of knowledge that is highly significant to the user but not necessarily formally generable or processable. In knowledge acquisition, the knowledge elicited from the
expert may have to undergo substantial transformation before it can be used in an inference system.
Hypertext systems treat knowledge as having limited structure and processability. Hypertext systems provide a limited structure of links that is intended to aid the user rather than allow computer-based inferencing. The loosely structured
representation of knowledge in hypertext systems complements and converges with highly structured representation of knowledge in traditional knowledge-based systems.
TAME provides an integrated environment to acquire and generate specification about the functionality and behavior of an expert system being developed, together with representation of the domain knowledge and domain heuristics for prototype
construction. Together, TBSM and TAME of process circuitry 10 enhance the verification, validation, testing and maintenance of an expert system throughout its life cycle.
FIG. 4 is a block diagram, indicated generally at 100, of TAME's structure. TAME interacts with one or more users 102 to elicit knowledge at a block 104. The knowledge elicited at block 104 is organized into a knowledge document 106, which
includes a specification 108 and a representation prototype 110. Knowledge document 106 depicts the terminology and the relationship among important concepts within a domain, together with the functional and behavioral components. A mapping 112 between
specification 108 and representation prototype 110 is established by associating both of them to tasks. Specification 108 is verified at a block 114 for internal consistency based on its formal semantics and is validated at a block 116 as described
further hereinabove in connection with FIG. 2. Representation prototype 110 is used to develop a prototype (block 32 of FIG. 2) which is verified at block 114 with specification 108 (block 34 of FIG. 2). The prototype is then executed in order to
validate at block 116 that the specification 108 accurately represents the user's requirements. The result of such verification (block 114) and validation (block 116) assists one or more of users 102 in further refining (block 104) specification 108,
representation prototype 110, and the structure of tasks 112.
After the knowledge/specification acquisition phase, the verified and validated specification is used for the design and implementation of an expert system as discussed further hereinabove in connection with FIG. 2. Therefore, TAME not only
elicits and organizes knowledge and specification into knowledge document 106 but also directly supports down-stream activities in the software life cycle such as implementation, verification, validation, testing and maintenance. Further, TAME and TBSM
of process circuitry 10 can be used for reverse engineering, where a human expert's role in forward engineering is replaced by an existing implementation and documentation of the expert system.
TAME is implemented on a KMS hypertext system to support the structure of FIG. 4. KMS is commercially available from Knowledge Systems, 4750 Old William Penn Hwy., Murrysville, Pa. 15668, (412) 241-2240. Accordingly, at block 104, TAME
supports both the elicitation and the refinement of the domain knowledge and the system specification 108. As described further hereinbelow in connection with FIGS. 5-6, TAME's browsing and retrieval aids allow users 102 to navigate knowledge document
106 using search, navigation links, a task hierarchy, and an indexing mechanism. Also, TAME provides verification feedback (block 114) by informing users 102 about duplications, incompleteness, and inconsistency in specification 108.
TAME of process circuitry 10 uses templates as basic building blocks and automatic links for the acquisition process to construct knowledge document 106 including (1) specification 108 about the functionality and the behavior of the target
system, and (2) representation prototype 110 of the domain knowledge and domain heuristics. Relevant items in different templates are linked using an autolinks facility in hypertext to facilitate easy navigation from one frame to another.
FIG. 5 is a block diagram showing the hierarchical structure of some major templates of a TAME acquisition session 120. FIGS. 6a-1 are exemplary screen displays of TAME templates displayed by process circuitry 10 on display 26 (FIG. 1). Some
major types of templates are a project management template 117 (FIG. 6a), an acquisition sessions list template 118 (FIG. 6b), an acquisition session template 120 (FIG. 5 and FIG. 6c), a knowledge engineer template 122 (FIG. 5), a domain expert template
124 (FIG. 5), a tasks list template 126 (FIG. 5 and FIG. 6d), a task description template 128 (FIG. 5) and 130 (FIG. 5 and FIG. 6e), a methods list template 132 (FIG. 5 and FIG. 6f), a method description template 134 (FIG. 5) and 136 (FIG. 5 and FIG.
6g), a domain model template 137 (FIG. 6h), a state model template 138 (FIG. 6i), a state object template 139 (FIG. 6j), and index templates 140 (FIG. 6k) and 141 (FIG. 6l). Users 102 (FIG. 4) specify and refine information in any of the TAME templates
using keyboard 18 (FIG. 1) of process circuitry 10. Users 102 transfer from one template to another by positioning and engaging a display cursor 142 (e.g., FIG. 6a) using pointing device 19 (FIG. 1) of process circuitry 10.
The elicitation process (block 104 of FIG. 4) begins with process circuitry 10 displaying a project management template such as template 117 (FIG. 6a) on display 26 (FIG. 1). As shown in FIG. 6a, project management template 117 elicits and
displays several types of information specified by one or more of users 102 (FIG. 4), including a Project Title, Creation Date, Project Version, Revision Date, Type of Domain of the Project, Type of Task of the Project, Sources of Knowledge/Expertise
(e.g. Domain Expert), Knowledge Engineer, Status of the Project, and Notes. By positioning and engaging cursor 142 as shown in FIG. 6a at "@ Acquisition Sessions List:" an acquisition sessions list template such as template 118 (FIG. 6b) is displayed in
order to provide an overview of all acquisition sessions.
As shown in FIG. 6b, acquisition sessions list template 118 elicits and displays a Session Number, Session Title, and Session ID for each listed acquisition session. By positioning and engaging cursor 142 as shown in FIG. 6b at ". Initial
Attempt (Session ID: 1)" the selected acquisition session template 120 (FIG. 6c) is displayed. Alternatively, by positioning and engaging cursor 142 at "@ Project Management Form:" project management template 117 (FIG. 6a) is displayed.
As shown in FIG. 6c, acquisition session template 120 elicits and displays relevant information in a knowledge acquisition session, including a Session Title, Creation Date, Revision Date, Domain Expert interviewed, participating Knowledge
Engineer, and Notes. By positioning and engaging cursor 142 at ".cndot. Knowledge Engineer:", knowledge engineer template 122 (FIG. 5) is displayed in order to provide additional information concerning the participating knowledge engineer. Similarly,
by positioning and engaging cursor 142 at ".cndot. Domain Expert:" domain expert template 124 (FIG. 5) is displayed in order to provide additional information concerning the interviewed domain expert. Also, by positioning and engaging cursor 142 as
shown in FIG. 6c at "@ Tasks List:" a task list template such as template 126 (FIG. 6d) is displayed in order to provide an overview of all tasks associated with acquisition session template 120. Alternatively, by positioning and engaging cursor 142 at
"@ Acquisition Sessions List:" acquisition sessions list template 118 (FIG. 6b) is displayed.
As shown in FIG. 6d, tasks list template 126 elicits and displays a Task Number, Task Title, and Task ID for each listed task. By positioning and engaging cursor 142 as shown in FIG. 6d at ".cndot. Configure Unibus (Task ID: 1.1)" the selected
task description template 130 (FIG. 6e) is displayed. Alternatively, by positioning and engaging cursor 142 at "@ Parent Session:" acquisition session template 120 (FIG. 6c) is displayed.
As shown in FIG. 6e, task description template 130 elicits and displays relevant information concerning its associated task "Configure Unibus", including a Task Title, Type of Task, Domain Model, State Model, Function, and Behavior. The
"Function:" field elicits and displays relevant information concerning the functional specification 78 (FIG. 3) of the task "Configure Unibus", including precondition, protection, and postcondition. Significantly, a task can have multiple
postconditions, and the postconditions can be rigid or soft as described further hereinabove in connection with FIG. 3. The "Behavior:" field specifies a task state expression ("TSE") of behavioral specification 86 described further hereinabove in
connection with FIG. 3. By positioning and engaging cursor 142 as shown in FIG. 6e at "@ Methods List:" a methods list template such as template 132 (FIG. 6f) is displayed in order to provide an overview of all methods for accomplishing the associated
task. Alternatively, by positioning and engaging cursor 142 at "@ Tasks List:" tasks list template 126 is displayed.
As shown in FIG. 6f, methods list template 132 elicits and displays a Method Number, Method Title and Method ID for each listed method. By positioning and engaging cursor 142 as shown in FIG. 6f at ".cndot. propose-revise (Method ID: 1.1.1),
the selected method description template 136 (FIG. 6g) is displayed. Alternatively, by positioning and engaging cursor 142 at "@ Parent Task", task description template 130 (FIG. 6e) is displayed.
As shown in FIG. 6g, method description template 136 elicits and displays relevant information and specification concerning its associated method "proposerevise", including a Method Title, parent task (Method of:), Guard Condition, Subtasks
listed for accomplishing the associated method, and TSE described further hereinabove in connection with FIG. 3. The "Subtasks:" field elicits and displays a Subtask Number, Subtask Title, and Subtask ID for each listed subtask. By positioning and
engaging cursor 142 as shown in FIG. 6g at "Guard Condition:" a template is displayed for acquiring and displaying relevant information concerning guard condition of the associated method. Also, by positioning and engaging cursor 142 at ".cndot.
Optimal Configuration (Task ID: 1.1.1.2)" a task description template analogous to template 130 (FIG. 6e) is displayed for the associated subtask "Optimal Configuration". Alternatively, by positioning and engaging cursor 142 at"@ Methods List" methods
list template 132 (FIG. 6f) is displayed.
Referring again to FIG. 6e, task description template 130 is linked to both domain model template 137 (FIG. 6h) and state model template 138 (FIG. 6i). Accordingly, by positioning and engaging cursor 142 at ".ANG. Domain Model:" domain model
template 137 is displayed. As shown in FIG. 6h, domain model template 137 elicits and displays relevant information concerning the domain model 58 (FIG. 3) of its associated task "Configure Unibus" including a Concept List of domain objects, Relation
List of domain relations, and parent task (Domain of:). A concept hierarchy can be established accordingly. By positioning and engaging cursor 142 as shown in FIG. 6h at "@ Parent Task" task description template 130 (FIG. 6e) is displayed.
Referring again to FIG. 6e, by positioning and engaging cursor 142 at ".cndot. State Model:" state model template 138 is displayed. As shown in FIG. 6i, state model template 138 elicits and displays relevant information concerning the state
model 60 (FIG. 3) of its associated task "Configure Unibus", including parent task (State Object of:), and State Object Name for each listed state object. Moreover, state model template 138 elicits and displays each listed state object as being one of
two possible types, namely either a first type for representing constraints or a second type for representing stages of completion. A constraint type state object includes a property list to indicate the property of a constraint (e.g., functional,
strong, and positive). By positioning and engaging cursor 142 as shown in FIG. 6i at ", Unconfigured Objects (State Object)", state object template 139 (FIG. 6j) is displayed. Alternatively, by positioning and engaging cursor 142 at "@ Parent Task"
task description template 130 (FIG. 6e) is displayed.
As shown in FIG. 6j, state object template 139 acquires and displays information relevant to its associated task "Configure Unibus" and associated state object "unconfigured objects", including Type of State Object, State Object Definition, and
parent task (State Object of:). By positioning and engaging cursor 142 as shown in FIG. 6j at "@ State Objects List:" state model template 138 (FIG. 6i) is displayed.
The constructed knowledge document 106 (FIG. 4) can be reviewed and accessed in multiple ways. The description of sessions, tasks, methods, concepts, relations, state objects and rules can be retrieved by name using an index having names
arranged in alphabetic order. From any of the TAME templates, users 102 (FIG. 4) can position and engage cursor 142 at "@ TAME Index", such that TAME index template 140 is displayed by process circuitry 10 on display 26 (FIG. 1). TAME index template
140 displays each letter of the alphabet. As shown in FIG. 6k, by positioning and engaging cursor 142 at "*C:" category index template 141 (FIG. 6l) is displayed in order to list all items in knowledge document 106 (FIG. 4) having names beginning with
the selected letter of the alphabet.
Moreover, with TAME index template 140, the user can position and engage cursor 142 at "@ TAME Home:" such that process circuitry 10 displays the template from which TAME index template 140 was displayed. As with any of the TAME templates, the
user can position and engage cursor 142 at "@ Acquisition Sessions List:" in order to display acquisition sessions list template 118 (FIG. 6b). Likewise, the user can position and engage cursor 142 at "@ Project Management Form:" in order to display
project management template 117 (FIG. 6a).
As described hereinabove in connection with FIGS. 5-6, users 102 (FIG. 4) can use links established between TAME templates in order to review an immediate parent task, parent method, and parent acquisition session (i.e., local navigation) or to
review a task list, method list, and acquisition session list (i.e., global navigation). In an analogous manner, TAME further enables users 102 (FIG. 4) to construct a task hierarchy as a global map for tasks acquired in the acquisition sessions. A
task hierarchy in TAME serves two purposes: 1) to provide an overview of the target system, and 2) to navigate through tasks acquired directly from the hierarchy.
A task can be either non-primitive or primitive. FIG. 7a illustrates a non-primitive task, indicated generally at 150. Non-primitive task 150 includes state model 164, domain model 166, behavioral specification 168, and functional specification
170. Non-primitive task 150 can be refined into a set of methods 152 that accomplish the task. Each of the methods, such as a method associated with a method description template 154, can be further refined into subtasks 156. Each method description
template has a method level TSE to document desired sequencing 158 among those subtasks of the associated method. Together, subtasks 156 and sequencing 158 form a process specification of the method of template 154. A prototype representation of
problem solving knowledge of the method is formed by a control block/rules 160 and a set of an application-specific rules 162. Model specification of non-primitive task 150 is formed by a state model 164 and domain model 166. Process specification of
non-primitive task 150 is formed by functional specification 168 and behavioral specification 170. The refinement process is repeated for all non-primitive tasks until only primitive tasks remain.
FIG. 7b illustrates a primitive task, indicated generally at 200. Similar to non-primitive task 150, primitive task 200 includes functional specification 202, behavioral specification 204, domain model 206 and state model 208. Unlike
non-primitive task 150, primitive task 200 is only refined into a set of rules 210. The format for rule description is informal and is represented in an application-specific rule set template 212.
Referring to project management template 117 of FIG. 6a, TAME provides feedback to users 102 (FIG. 4) regarding incomplete refinement. For example, a user exits TAME by positioning and engaging cursor 142 at "@ Exit TAME". Then, upon returning
to TAME, the task hierarchy of each acquisition session can be reviewed by TAME to locate any remaining non-primitive task. If TAME locates such a remaining non-primitive task, then TAME informs the user about the incomplete refinement and offers the
user a chance to refine an acquisition session.
FIG. 8 illustrates an exemplary task/method/subtask relationship used by process circuitry 10 to represent a specification at various abstraction levels in a hierarchical multi-layered structure. In FIG. 8, a configure-unibus task 225 includes a
model specification 228 and a process specification 230 such as described further hereinabove in connection with FIG. 3. Model specification 228 includes multiple defined terms 232a-c having specified relations 234a-b. Model specification 228 further
includes a constraint 236.
Process specification 230 of configure-unibus task 225 includes a method having multiple tasks 238a ("configure-box") and 238b ("configure-backplane") with a specified relation 240. Pieces of high-level abstract specification, such as tasks
238a-b, are refined to more detailed specification at a lower abstraction level according to a task/method/subtask structure, by first refining a task to one or more methods and then refining a method to one or more subtasks. Accordingly, configure-box
task 238a is refined to include a model specification 242 and a process specification 244. Model specification 24 | | |
