m U John Yen and Jonathan lee, Texas A&M University

R E C E N T INTEREST IN IMPROV- ing the quality and reliability of AI systems has in turn led to interest in specifications. A good specification can eliminate design failures and reduce product costs by help- ing to organize expertise, represent knowl- edge, validate designs and implementa- tions, and maintain the resultingsoftware system.‘

Many software systems use convention- al specification techniques, but expert sys- tems cannot always do so. Whereas con- ventional software can apply algorithmic solutions to well-defined and well-under- stood problems, expert systems usually must apply nonalgorithmic solutions and deal with uncertanity. Several researchers have proposed methods for specifying ex- pert system^,^.^ but these have been used for specific types of expert systems or particular problem-solving architectures.

W e want an approach to expert-system specification that is independent of the prob- lem-solving architecture; that can apply to many expert-system applications; that fo- cuses on what the knowledge is, not how it is implemented; that introduces the major concepts involved gradually; and that sup- ports verification and validation. Toward this end, we have developed a task-based specification methodology (TBSM).

Expert Sys-Gms

THIS METHODOLOGY D E F N E S AN EXPERT SYSTEM’S MODEL AND PROCESS KNOWLEDGE AT

DIFFERENT ABSTRACTION LEVELS, SO THAT SPECIFYRVG THE SYSTEM INVOLVES REFhVING

THE MODEL AND PROCESS SPECIFICATIONS.

By organizing a specification around the system’s functional units (tasks), TBSM lets the knowledge engineer generate spec- ifications relevant to a given task at any point in the process. Like conventional specification techniques, a TBSM specifi- cation has two primary components (see Figure 1): a model specification that de- scribes the system’s static properties, and a process specification that describes its dy- namic properties. TBSM uses a t a s k h e t h - o d h b t a s k approach to help capture these specifications at the appropriate level of abstraction, letting the knowledge engi- neer refine the overall specification by constructing more detailed model and pro- cess specifications. This approach also lets the developer identify inconsistent and in- complete specifications within one abstrac-

tion level or between multiple levels based on their formal semantics.

T o cons t ruc t a specif icat ion, t he developer

(1 ) Constructs a partial task hierarchy for an overall view of the solution, based on initial knowledge acquired from experts or from documentation or ref- erences.

(2) Selects a task and constructs abstract specifications of the relevant model, constraints, states, and state changes:

Identifies terms and relations between terms to form a term hierarchy. Identifies different types of system constraints, based on which the sys- tem can be verified. Identifies preconditions, postcondi-

a 0885/9000/93/0200-008 $3.00 0 1993 IEEE IEEE EXPERl

This is an expanded version of an article that appeared on pp. 260-263 of the Proceedings of rhe /€E€ Inrernarional Conference on Too[s,for Arrificial / t7re/ /~~gencc. published in 1991 bq the IEEE Computer Society Press, Los Alamitos. Calif.

tions, and protections of subtasks (defined later). Identifies the intended control flow between subtasks and the global in- teraction among tasks using task- state expressions.

(3) Verifies the generated specification’s consistency in a single layer as well as its consistency and completeness be- tween layers.

(4) Repeats steps 2 and 3 until all the iden- tified subtasks have been specified.

To evaluate our methodology, we re- verse-engineered a specification of R1/ SOAR,4 an expert system that reimple- ments a major portion of the RI expert system. This article discusses the TBSM in general and draws on examples from our work with RUSOAR. A sidebar explains how our approach is related to work on expert-system specifications and task-ori- ented expert systems.

Model specification

A model specification includes a model of the relevant domain objects and a model of the relevant problem-solving states (par- tial solutions). As the developer refines these models, some of the domain or state objects may be elaborations of those in the previous layer of abstraction, while others may be completely new constructs.

Domain model. The domain model de- scribes terms, relations, and constraints relevant to the task. A term is a user- defined type that can represent abstract concepts (such as Configured-Backplane) o r concrete concepts (such a s Cable- Length). A relation describes a property of a term (such as Has-Component) or a relationship between terms (such a s Has- Connection). In AI, constraints are often heuristic problem-solving knowledge. T B S M characterizes constraints in three ways: single-valued versus multivalued, strong versus weak, and positive versus negative.

Single-valued versus multivalued. A sin- gle-valued constraint is a one-to-one map- ping from a set of variables to a constrained variable. A multivalued constraint is a one- to-many mapping. A single-valued con- straint can be specified by a procedure for

~ FEBRUARY 1993

, - _ _ - - - ._

I Functional specifiatio

Concatenation

Selection L Behavioral specification - zGz:n

Option Condition Iteration

Figure 1. Components of the task-based specification methodology.

computing the constrained variable’s val- ue, while a multivalued constraint can be

For example, constraints in RI /SOAR’s problem domain include

specified using a predicate description that tests whether a set of variable values satis- fies the contraint or a function that gener- ates all values satisfying the constraint. This distinction affects problem solving: Single-valued constraints determine the constrained variable’s value, which there- fore does not require search. Multivalued constraints, on the other hand, often re- quire search.

Strong versus weak. A strong constraint provides an order to be obeyed. It can describe a solution or a situation, and its specification can include “fixes” that de-

* A single-valued, strong, and positive constraint: “If the previous backplane is in the same box, then use a cable of length 10.” A multivalued, strong, and positive con- straint: “An RK611 is also a possibility when the pin type is SPC, provided that an RK6 1 1 module is configured into it at some point.” A single-valued, strong, and negative constraint: “If the remaining unibus length is less than the cable length, the backplane cannot be configured in this position.”

scribe various ways to repair a violation of ~

the Constraint. A weak constraint describes ~ State model. The state model defines a preference, which suggests how to find a ~ the terms (called “state objects”) that de- better solution. Weak constraints typically scribe an expert system’s problem-solving do not include fixes. Distinguishing be- states. In TBSM, a state object can de- tween strong and weak constraints helps us scribe what problem-solving stage the task verify their consistency with the functional ~ is at, as well as dynamic relationships among specification. (We discuss this further in 1 multiple objects. State objects are essential the section on the process specification.) for specifying the functionality of the sys-

tem’s tasks (described later). Positive versus negative. A positive con-

straint describes a variable’s legal values in terms of other variables. A negative constraint describes illegal values. This distinction helps us choose problem-solv- ing methods refined from tasks. For exam- ple, we can use positive constraints for proposing a solution in propose-revise methods, while we can use negative con- straints only to test a constraint violation.

An example. R1 is an expert system for computer configuration; RI /SOAR focus- es on the unibus configuration portion of R I . Figure 2 shows Rl /SOAR’s task-sub- task hierarchy. We’ll focus here on the Configure-Modules and Configure-A-Mod- ule tasks. The functionality of Configure- Modules is to configure as many modules as possibleinto the current backplane while

~

9

Current-Module For-The-Current-Module

Configure-Modules Configure-a-box Cable-backplanes

Select-A-Backplane-Type- /I 0btain-A-

Suitable-For-The- Backplane-Of- Current-Module The-Suitable-Type A A

The-Current-Box Current-Box-Section Box-Section BOX

A Get-The- Order-A-New- C0nfigure-A- Obtain-The- Obtain-An- Configure-The-Moduled- Move-To- Move-To-

Backplane- Backplane Module Next-Module Applicable-Box-As- Backplane-Into-The- The-Next- A-New-

A A From-The-Cover

Configure- Reserve-The- Get-The-Box- Order-A- Boards Panel-Space From-The-Order New-Box

~ ~~

Figure 2. A partial task hierarchy in R1 /SOAR.

optimally ordering the modules. This is achieved by iterating between two sub- tasks: Configure-A-Module, which tries to configure the current module into the cur- rent backplane, and Obtain-The-Next-Mod- ule, which gets the module that follows the current module in the optimal ordering.

A knowledge engineer could easily make an error in specifying what should happen when the current module fails to be config- ured into the current backplane. A correct specification would indicate that Obtain- The-Next-Module should be skipped, since

Configure-A-Module has not finished con- intermediate stage where modules havebeen figuring the current module. The specifica- ~ assigned to the backplane. (Figure 4 shows tion should also indicate that if the current a method for this task.) State objects repre- module cannot be configured into the cur- senting other stages of R!/SOAR’s problem rent backplane, the system should find a ~ solving include “unconfigured backplane,” backplane suitable for the current module “current backplane.” “cabled backplane,” before configuring the next module. As and”configured backplane.” Wedefine such discussed later. a verification algorithm terms by refining terms defined in the do- can detect this common error. main model. The state model is further

refined for the subtask Configure-A-Mod- Strife nioa‘rl. The state model of Config- ule (see Figure 5 ) to introduce additional

ure-Modules (see Figure 3) defines the term terms such as the “compatible” relation be- “moduled backplane,” which represents the 1 tween a backplane and a module, which is

used in the process specification. By defin- ing these terms and refining them as needed, we can describe the specification at each level at an appropriate level of abstraction.

State model: * A moduled backplane is a backplane that (1) has as many modules as

possible been placed in, and (2) satisfies the constraint of maintaining the optimal ordering of modules that are configured into the backplane.

Process specification: Precondition: There exists a current backplane, and a sequence of unconfigured

Protection: The optimal ordering of modules should be maintained (inherited) Postcondition:

modules.

* (rigid) The chosen backplane is a moduled backplane

Figure 3. The task Configure-Modules.

Furthermore, reusing terms defined in the state model significantly reduces the com- plexity of process specification, and hence improves its clarity.

Process specification

Like the model specification, the pro- cess specification has two parts: a func- tional specification that describes “what a task is,” and a behavioral specification that uses task-state expressions to describe the sequence of tasks and the interactions among them at different levels (that is, the sys-

~~ ~

IEEE EXPERT

tem's behavior). Refining a process speci- fication therefore involves refining a task into a set of problem-solving methods or domain-specific methods that can accom- plish the task, and refining a method by specifying subtasks and then using task- state expressions to describe temporal re- lationships among them.

Functional specification. Convention- al software specifications use operations (or events) as a way to change states. Their functionality is characterized by precondi- tions and postconditions: partial descrip- tions of the system's state before and after the operation. However, most methodolo- gies for specifying expert systems do not characterize operations as state changes. TBSM therefore provides a more expres- sive notation for characterizing state chang- es by having the state model define terms for describing complex states, and by ex- tending the conventional notion of the state transition to capture potentially conflict- ing functional requirements on a complex operation.

To explicitly specify a task in TBSM, we treat it as a state transition and specify the states before, during, and after the opera- tion using partial descriptions called pre- conditions, protection, and postconditions. A precondition describes the situation un- der which the task can be invoked. A post- condition describes two kinds of desirable state changes: rigid and soft. A rigid post- condition must always be satisfied; a soft postcondition is desirable. For example, the functional specification of Configure- Unibus, the highest level task in R I/SOAR, includes the following soft postconditions:

Modules are configured in their optimal order. Wasted cabinet space and backplane slots are minimal. Additional components that need to be ordered are least expensive (see Figure 6).

To achieve these, R I B O A R generates a configuration that satisfies the first post- condition, and then tries to improve the configuration by considering the other two.

In general, the notion of softness can also be applied to preconditions to specify situations that may be more effectively handled by a dedicated method. For exam- ple, the initial configuration just mentioned would be optimal if no cabinet space and backplane slots were wasted and no com-

Tt: Configure-A-Module. T2: Obtain-The-Next-Module.

TSE: (L (P1 A P2)TZ" T(Pi A Pz).Tex,# pl: The current module is compatible with the current backplane and is

configured into the current backplane. P2 There exists a remaining unconfigured module

1

Figure 4. A method o f the task Configure-Modules.

a backplane.

Process specification: TSE: (+, Tpl (E; T3: Find-A-Backplane-Suitable-For-Current-Module]) Precondition: There exists a current module, and a current backplane. Protection: The optimal ordering of modules should be maintained (inherited). Postconditions (disjunctive):

* (rigid) pi: The current module is compatible with the current backplane and is

configured into the current backplane. Or,

current backplane is a moduled backplane. +,: The current module is not compatible with the current backplane and the

.. ..

:igure 5. The task Configure-A-Module.

GI: Backplanes, boxes, and a sequence of modules. SI: Optimal ordering of modules. S2: Minimum unused cabinet space and backplane slots. S3: Least expensive additional components added to customer's order. R I : A feasible configuration.

Figure 6. Some soft and rigid postconditions.

ponents needed to be added to the customer Soft postconditions are closely related order. One way to indicate this possibility to weak constraints. A constraint satisfied is to describe the situation as a soft precon- in a soft postcondition is necessarily weak, dition of the task Optimal-Configuration. ~ for it is not an order to be obeyed. A

11 ~

FEBRUARY 1993

constraint satisfied in a rigid postcondition i behavior, undesired system behavior, and , the Follow operator to describe partial task is typically strong, although it could be global interactions between tasks at differ- ’ sequences. A method-levelTSE documents weak. The relationship between weak con- , ent levels. TSEs are based on regular ex- the local control flow among the method’s straints and soft postconditions lets our pressions, which have been used in AI ~ subtasks but typically does not contain the methodology verify the consistency be- ~ planning and software engineering’ to rep- Follow operator. tween a system’s functional specification resent procedural knowledge and execu- A task-level TSE describes the system and its state model. tion paths. They also use the notion of behavior expected when the task is in-

A task’s soft postcondition can become ’ conditional paths for finer control over voked. This property plays an important the rigid postcondition of a child subtask task selection. role in combining TSEs at different levels. when it is considered more important than TBSM uses “+” to indicate the task with

1 which a TSE is associated (see Figure 5 ) . other competing soft postconditions. For The semantics of the task-level TSE im- plies that i t is meaningless to use optional,

example, in R I B O A R , the soft postcondi- I

conditional, and selection operators for the tion “Modules should be configured in their optimal order” appears in the rigid

A TSE uses the following operators:

’ Immediately Follow (concatenate), in- dicated by a comma: (TI, T2) specifies that task Tz immediately follows task TI.

postcondition of the task Unassigned-Back- plane, which generates the initial configu-

associated task. T o verify the consistency of a system 1

ration. Even though the soft postcondition ’ may be violated later as the configuration I is improved during the task Optimal-Con- figuration, it is still more important than 1 other soft postconditions such as “Minimal wasted cabinet space and unused back- plane slots.’’ spEczFzcATzoNo T‘s parent method, El. The composition ’

Protection describes state properties that THE S W M E T R Y OF operator synthesizes task sequences of E7 , should not change while the task is per- formed. TBSM uses protections to limit coupling between modules. Most conven- tional specifications (especially model-ori- ented specifications’) use invariants: re- quirements that must hold for every state. Our protection is similar to local invari- an t s6 Planning in AI has used protection to limit the interaction between subgoals. Adopting this idea to task specification ensures that undesirable interactions be- tween subtasks are avoided.

Returning to our earlier example, the task Unassigned-Backplane has as a pro- i tection the requirement that modules must be configured in the optimal order. Fol- lowing the task hierarchy in Figure 2, the ~ P , T , , , , ) ! , whichis short for(@,, P A ) ! ,

E , , -P,E), where P I is an iteration A-Module inherit this protection. The post- condition, I

Conditional, indicated by a logic formula condition of Configure-A-Module is thus a ’

P: For a TSE E. “P,E, v P2E2 ... v PnE,,” disjunction of two subconditions corre- , means “If P i then E l else if p2 then E2 ... sponding to the two possible outcomes: the

mutually exclusive. the current module into the current back-

* Optional, indicated by [ E ] , which is short plane.

for (E v E ) , where E is the null operation.

A TSE can be described at the task or method level. A task-level TSE associated with a task T, denoted as Er, documents global interactions between the current task where a, r , . r2, and o denote TSEs. The and tasks at different levels that require , formal foundation of the composition op- special attentions in implementing and test- ~ erator is found elsewhere.*

TBSM also helps us specify undesired

IEEE EXPERT

specification, we often need to combine multiple TSEs to obtain a global view of system behavior from local behavior spec- ifications. TBSM has a composition oper- ator for task T , denoted as 0 7 , for combin- ing T’s TSE, E,. and the complete TSE of

MODULARITY 1s ONE OF THE lMPoRTANT ‘IuTEm

FOR EVALUATING A N EXPERT-

with those of Eh, in which T i s invoked. Returning again to our example, Figures

4 and 5 show that there are two TSEs involved. Together, the TSEs state that if the current module and current backplane are incompatible, we should not try to configure another module using the cur- rent backplane, because doing so would violate the protection to maintain the opti- mal ordering of modules. Instead, we should later invoke the task Find-A-Backplane- Sui table-For-The-Current-Module. W e derive this composition from the method-

i PRE- AND POSTCONDZTZONS

CAN HELP US REORMNZZE MODULES T o I M P R o ~

F ~ C T Z O N A L M O D U ~ H T Y ,

, i

’ Follow. indicated by a semicolon: ( T l ; T?) specifies that T2 follows TI after a 1

sequence of intermediate, unspecified tasks (TI , .... T z ) .

* Select between multiple control flows,

are TSEs representing two mutually ex- elusive control flow5,

indicated by ( E r ‘1)’ where Ei and El level TSE in Figure 4 and the task-level 1 TSE in Figure 5 :

Iterate, indicated by ( E ) ! or ( E , , P,E2 v , EW E7,

tasks Configure-Modules, and Configure- = ((TI, ( P I A B2)T2)!, 0-1, PI A P d E ) ) 0,, (TI, YP,(E: T3))

= (TI. ( P i A PdT?)!, VI, y P , ( E ; 7-31 v (TI, l P 2 E))

Some general cases of the composition task either succeeds Or in ‘Onfiguring i else ifp,, then E,,,” where PI , P2, ,,,, P n are results are

E BT E , = E , if E does not contain T

Behavioral specification. Treating a task ( E , v E?) 0 7 E7 = ( E , 0 7 E,) v ( E 2 0 7 ET)

(a , T , per,, r2)) 0 T ( T , P(r,; 0)) = as a state transition lets us explicitly spec- ,

ify its intended functionality, but we still might want to specify the task’s expected interactions so that we can check the sys- tem’s intended behavior against its actual behavior. TBSM uses task-state expres- sions (TSEs) to define anticipated system ’ ing the system. Task-level TSEs often use ,

(” T’ P(ri’ r2;

I , ~. ~ _ _ _ _ -

~~

~ 12

Other related work

TBSM draws on several ideas about specifying expert systems and about the task-oriented expert-systems methodology

Specification Zualkernan and Tsai see two kinds of

specifications for expert systems: problem specifications and solution specifications.’ A problem specification is a contract be- tween supplier and consumer, while the so- lution (or system) specification is a blue- print for the designer.2 Our methodology is influenced by this distinction: TBSM inte- grates the functional requirements of prob- lem and solution specifications into a uni- form framework.

The researchers have also developed two specification methodologies for expert sys- tems: an object-oriented one and a knowl- edge-model one.2 The object-oriented meth- odology establishes the object class for specifying instances of each expert activity, defines the methods for each class, and de- fines the instantiation of class instances. The knowledge-model methodology de- scribes the concept structures and the goal structures required to solve the problem. Both methodologies take a top-down ap- proach and have been demonstrated for a heuristic classification system. Verification and validation are performed through inter- action with experts. Compared to TBSM, these methodologies offer two benefits: the specification is executable, and they are easier to apply to heuristic classification ex- pert systems.

Task orientation

Task-oriented expert systems use a high- level structure in their problem-solving pro- cesses. Previous work on task-oriented methodologies has focused on improving the reusability of problem-solving knowl- edge3-5 and facilitating the acquisition of knowledge about expert-system desigx6 We have adopted the tasldmethodhbtask structure as a general framework for orga- nizing and refining an expert system’s func- tional and behavioral specification. Similar to polymorphism in the object-oriented par-

interactions between tasks at different lev- els by distinguishing between two types of behaviors: intendedand disallowed. A T S E using the operators discussed above can specify intended behavior. W e specify dis- allowed behavior by preceding a TSE with a negation (denoted as Y), thereby indicat- ing an undesired task sequence.

FEBRUARY 1993

adigm, our approach enables a knowledge engineer to separate the specification of the system’s functional units (tasks) from the specification of its information-processing units (methods).

However, our work differs from task- oriented methodologies in one important way: TBSM emphasizes a functional de- composition, whereas the decomposition in task-oriented methodologies mainly re- flects major steps of a general problem- solving method (such as the propose, re- ject, apply, critique, and revise steps of the propose-revise method).

Other specification methodologies

Slagle has used conceptual graphs for specifying a heuristic classification expert

system.’ His approach identifies six kinds of conceptual structures: type definitions, lines of reasoning, implications, facts, a type lattice, and canonical graphs. Sla- gle’s methodology is suitable for heuristic classification systems whose knowledge can be specified by constructing an infer- ence network that relates pieces of evi- dence to hypotheses.

Yost and Newell proposed a problem- space approach* for the SOAR architecture, but i t is difficult to see how this methodolo- gy could be applied to other AI architec- tures. Also, verification of the specification has not been demonstrated.

Compared with all these approaches, TBSM offers two important advantages: a solid automatic verification capability and a detailed functional decomposition technique.

References

1 . I.A. Zualkernan and W.T. Tsai, “Are Knowledge Representations the Answer to Require- ment Analysis?” Proc. IEEE Int’l Conf in Computer Languages, Computer Society Press, Los Alamitos, Calif., 1988, pp. 437-443.

2. W.T. Tsai et al., “Requirements Specification for Expert Systems? A Case Study,” Tech. Report TR 88-44, Univ. of Minnesota, Minneapolis. Minn., 1988.

3. B. Chandrasekaran, “Generic Tasks in Knowledge-Based Reasoning: High-Level Build- ing Blocks for Expert-System Design,” IEEE Expert, Vol. I , No. 3, Fall 1986, pp. 23-30.

4. B. Chandrasekaran, “Design Problem Solving: A Task Analysis,”AI Magazine, Vol. 11, No. 4, Winter 1990, pp. 59-7 I .

5. J . McDermott, “A Taxonomy of Problem-Solving Methods,” in Automating Knowledge Acquisition for Experf Systems, S . Marcus, ed., Kluwer Academic Publishers, Boston, Mass., 1988, pp. 225-256.

6 . S. Marcus, “Salt: A Knowledge-Acquisition Tool for Propose-and-Revise Systems,” in Automaring Knowledge Acquisitionfor Experf Systems, S. Marcus, ed., Kluwer Academic Publishers, Boston, Mass., 1988, pp. 81-124.

7. J.R. Slagle, D.A. Gardiner, and K. Han, “Knowledge Specification of an Expert System,” IEEE Expert, Vol. 5 , No. 4, Aug. 1990, pp. 29-38.

8. G. Yost and A. Newell, “A Problem Space Approach to Expert-System Specification,” Proc. Inr’l Joinr Conf Arrifical Intelligence (IJCAI ’89), Morgan Kaufmann, San Mateo, Calif., 1989, pp. 621-627.

Verification

Verifying a specification helps detect errors early in the software life cycle, thus helping to eliminate design failures and reduce product costs. TBSM provides two levels of inconsistency checking: weak and strong. A system specification is weakly

inconsistent if its consistency cannot be proved. A specification is strongly incon- sistent if its consistency can be disproved. Faults that make a process specification inconsistent include protection violation, precondition violation, postcondition vio- lation, and incorrect TSEs. TBSM also checks for two types of incompleteness:

13 I

Backplane-

~~~~~~~~~~~~~ ~~~~~~~~~~ .~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~

C1: A type of backplane compatible with the current module. Cf‘: A backplane compatible with the current module. C2: The current backplane is a configured backplane.

- ~~ ~ ~~

Figure 7. A change from sequential modulority to function01 modulority.

missing methods and incomplete TSEs. We verify a process specification start-

ing at the highest level task and focusing on one task at a time. Verifying a task T involves two major steps:

union of their before-state descriptions is equivalent to 7 . ’ ~ Precondition.

Obviously, inferring the before- and after-state descriptions is an important step in verification. We accomplish this inTBSM via a progression operator,q which can be concatenated to compute the state descrip- tion after a sequence of tasks have been performed. The inversc of progression - regression ~ has been widely used in AI

’ planning for constructing a plan in a back- ward fashion starting from the final goal.

Considering our example again, if the

T?) ! . a strong inconsistency would be de-

( I ) We prove or disprove T’s precondition using a resolution algorithm to com- pare T s specification with T’s parent method (the method that contains T ) and other subtasks i n the incthod.

(2) We check T’s consistency andcomplete- ness by comparing T s specification with

their subtasks. that accomplish T) . T s methods (Ihe methods’ and ~ method.level TSE in Figure 4 were ( T , .

1

The specification of T‘s method is consis- tent with T if

( I ) the description of the state before the method executes (the “before-state de- scription”) is semantically more spe- cific than T’s precondition,

(2) the description of the state after the method executes (the “after-state de- scription”) is more specific than T’s rigid postcondition, and

(3) T ’ s protection is not violated by any subtasks of T.

tected by the verification algorithm, sincc the postcondition of Configure- A-Module can be formally expressed as

Configured (Current-Module) v Incompatible (Current-Module,

Current-Backplane)

Invoking the sequence ( . . . T?, TI ... ) when the current module is incompatible with the current backplane leads to configuring the next module before the current onc. TBSM detects two strong inconsistcncics:

A set of T’s inethods is complete if the ( I ) The precondition of the task Obtain-

The-Next-Module, which states that the current module should have been configured, can be violated.

( 2 ) The protection that the optimal order- ing of modules should be maintained can also be violated.

Although we have focused here on ver- ifying the process specification, TBSM can also check the model specification’s consistency and completeness (which can be facilitated using a principled knowl- edge representation system, such as a term subsuinption system), and check consis- tency between the process and model spec- ifications. For example, i t can check that the type o f a constraint in the state model is consistent with its use in the process spec- ification, in particular, that a soft postcon- dition does not refer to a strong constraint.

Modularity

Modularity is one o f the most important criteria for evaluating an expert-system specification. In TBSM, analyzing the sym- metry of pre- and postconditions can help us reorganize modules to improve a sys- tem’s functional modularity.

For example, in RI/SOAR’s original implementat ion. Obtain-A-Backplane- Of-The-Suitable-Type is a subtask under Configure-A-Backplane (see Figure 7). Consequently, the precondition of Config- ure-A-Backplane is “a type of backplane compatible with the current module” and its postcondition is “a configured back- plane.” These conditions are not symmet- ric: They refer to two different kinds of state objects ( a backplane type and an indi- vidual backplane). Since a synthesis-type cxpcrt system changes the status of the given objects by dynamically constructing a relationship between them, a functional modulc’s pre- and postconditions should usually refer to the same set ofobjects with different status. Thus. we group Obtain-A- Back p I ane-O f-T he- S U i table-T y pe with Sclect- A-Backplane-Type-Suitable-For- The-Current-Module and thereby change the precondition for Configure-A-Back- plane to “the current backplane is compat- ible with the current module,” which refers to the same object as the task’s postcondi- tion-an individual backplane. Thischange from scqucntial to functional modularity \trengthen\ cohesion within the module.

~

14 ~~ ~

IEEE EXPERT

0 UR METHODOLOGY OFFERS 1 niques that would let us validate these several important benefits:

Incorporating the task structure with the notion of polymorphism provides a de- tailed functional decomposition tech- nique for organizing and refining an ex- pert system’s functional and behavioral specifications. The distinction between soft and rigid conditions lets us specify conflicting functional requirements. Task-state expressions help us not only document the expected control flow and module interactions, but also verify that the behavioral and functional specifica- tions are consistent. T h e state model makes it easier to de- scribe complex state conditions. Ter- minology defined in the state model can be reusedeasily to specify the func- tionality of different tasks. Without such a state model, describing the state con- ditions before and aftzr an expert sys- tem’s functional unit is t o o cumber- some to b e practical. The verification algorithms are based on a well-defined formal foundation and achieved by focusing on one functional unit at a time.

W e now have research plans in four areas: tools support, validation and testing, uncertainty, and verificalion using model- based reasoning.

Tools support. W e have developed a knowledge acquisition tool, called T A M E (the “task-based knowledge-acquisition methodology for expert systems”), to help knowledge engineers generate a structured prototype and a T B S M specification from

tend to enhance the tool by letting develop- ers select general problem-solving meth- o d s f o r cons t ruc t ing t h e me thod specification, W e will also investigate graphical tools and techniques that can facilitate the refinement, integration, brows- ing, and consistency checking o f t h e model specification. These tools could be used to develop a large-scale expert system and provide further evaluation data on TB- SM’s usefulness and limitations.

components with a design o r with an im- plementation.

Uncertainty. This is a major issue for heuristic classification systems. W e plan to address it by generalizing the notion of soft postconditions using fuzzy logic.

Model-based verification. The verifi- cation procedure we described here fo- cused on the consistency of the process specification, However, to take full advan- tage of the potential benefits of the state model, we need to fully integrate the veri- fication algorithm with the reasoning ca- pabilities of the knowledge representation system in which the state model is cap- tured. Hence, w e plan to explore the inter- action between model-based reasoning and the verification algorithm.

Acknowledgments

We thank David Hamilton at IBM for sharing his perspective on expert-system specifications, Paul Rosenbloom at the University of Southern California’s Information Sciences Institute for making the source and English description of RI/SOAR available, and Gregg Yost at Carne-

5. B. Auernheimer and R.A. Kemmerer, “RT- Aslan: A Specification Language for Real- TimeSystems,”IEEE Trans. SofnYureEng., Vol. SE-12, No. 9, Sept. 1986,pp. 879-889.

6. D. Luckham, Programming With Spec$- cation: An Introduction to Anna, A Lun- guuge for Specibing Ada Progrums, Spring- er-Verlag, Berlin, 1990.

7. A. Shaw, “Software Specification Language Based on Regular Expression,” in Sqf’tware Development Tools, W.E. Riddle and R.E. Fairley, eds., Springer-Verlag. Berlin, 1980, pp. 149-175.

8. J. Lee and J. Yen, “The Formal Foundation of a Task-Based Specification Methodolo- gy,“ Tech. Report TR91-034, Texas A&M Univ., College Station, TX, 1991.

9. S.J. Rosenschein, “Plan Synthesis: A Log- ical Perspective.” Proc. Eighth Int’l Joint Cmf: Art[f icinl Intelligence (IJCAI ’ 8 I ) , Morgan Kaufmann, San Mateo, Calif., 198 I , pp. 331-337.

~~

gie Mellon University for answering questions engineering. He is an associate editor of IEEE about R I/SOAR. We also thank Wei-Tek Tsai at Tran.sriction.s on Fuzzy Systems, a member ofthe the University of Minnesota, Alun Preece at I board of associate editors of the Journal of’lntel- Concordia University for fruitful technical dis- ligen? arid Fuzzy System, and a member of Tau cussion, and the reviewers for their valuable ~ BetaPi, IEEE,ACM,AAAI,NAFIPS, andINNS. commentson anearlydraft ofthisarticle. Finally. ~ Yen received his BS in electrical engineering we are indebted to Swee Hor Teh who spent from National Taiwan University i n 1980, and months in understanding R 1 /SOAR’S code. his PhD in computer science from the University

This research was partially supported by IBM of California at Berkeley i n 1986. He received contract No. 90-832786-E1 and partially by an NSF Young Investigator Award in 1992. He Engineering Excellence Fund at Texas A&M 1 can be reached at the Dept. of Computer Sci- University. ~ ence, Texas ABM Univ., College Station, TX

77843; Internet, yen@cs.taniu.edu

Validation and testing. Several novel components of TBSM (such as soft post- conditions, TSEs, and protections) offer opportunities to develop new testing tech-

FEBRUARY 1993

John Yen is an assis- tant professor at Texas A&M University and director ofthe Centerfor Furry Logic and Intelli- gent Systems Research. His research interests in- clude fuzzy logic, ex- pert systems, intelligent control, knowledge rep- resentation, and software

knowledge acquisition sessions. W e in- 1 References 1 . B. Cohen, W.T. Harwood, and M.I. Jack-

son, The Spec[ficcrtioii of Complex Systeins, Addison-Wesley, Reading, Mass., 1986.

2. J.R. Slagle, D.A. Gardiner, and K. Han, ”Knowledge Specification of an Expert System,“ IEEE Expert, Vol. 5. No. 4, Aug. 1990, pp. 29-38.

3 . I.A. Zualkernan et al., “Utility of Knowl- edge-Level Specifications,” Proc. Fourth Ann. Artificiul Intelligence arid Advanced

1988. pp. 79-85, 4. P.S. Rosenbloom et al., “RI/SOAR: An

Experiment in Knowledge-Intensive Pro- gramming in a Problem-Solving Architec- ture,” IEEE Trans. Pattern Analysis uml Machine Intelligence, Vol. PAMI-7, No. 5, Sept. 1985, pp. 561-569.

CoInjJuter Technology C/>r?f: (AI West I988),

Jonathan lee isadoc- toral candidate in com- puter science at Texas A&M University. Hi5 research focuses on soft- ware engineering in AI, expert systems, fuzzy logic, and applying hy- pertext systems to soft- ware development. He and John Yen have a US

patent pending on a method for specifying ex- pert systems. He received his MS in computer science from Texas A&M University in 1988, and his BS i n electrical engineering at Chung Yuan Christian University in 1984. Lee is a member of the IEEE Computer Society, AAAI, and ACM. He can be reached at the Dept. of Computer Science, Texas A&M Univ., College Station, TX 77843: Internet, yjlee@cs. tamu.edu