Designing Computer-Based

Training Systems:

OBIE-1:KNOBE

Roy S. Freedman, Polytechnic University

Jeffrey P. Rosenking, Hazeltine Corporation

Th here is growing consensus among those involvedwith computer-based training that the applica-tion of knowledge-based technology can improvethe quality and cost effectiveness of training per-

sonnel. Recent articles by Freedman,' Kearsley and Seidel,2Montague and Wulfeck,3 Psotka,4 and Woolf5 conclude thatthe next generation of CBT systems will incorporate manyinnovative concepts in the acquisition, representation, andmanagement of expert knowledge and common-senseknowledge.

Cognitive models. Cognitive models of students are nowbeing used to interactively construct a knowledge base rela-tive to a specific teaching domain. The model helps accountfor and evaluate the responses and progress of the student tothe computer-generated queries. These results can then befed back into the CBT system so that the next sequence ofqueries are customized to the students' training needs. These"intelligent tutoring systems" (based on cognitive models ofa learner such as those developed by Stevens6) already showthe promise of creating individualized automated instruction.The key issues are the development of a student model thatis applicable to a specific teaching domain and the develop-ment of a linquistic model for discourse.

Expert systems. Another example of the application ofknowledge-based technology to training is expert systemsand expert system building tools. The teaching strategyusually is based on interactive text-based information retrieval.Even though expert system building tools may simplify theacquisition and representation of the expert's knowledge,very little work has been done in representing the knowledgeassociated with teaching. Just as expert systems are restricted

to a particular knowledge domain, these training systemsapply to one subject and to a particular learning strategy.

Generalizability. This lack of generalizability is not onlyrestricted to the application of expert systems. Many intelli-gent tutoring systems are too closely coupled to their teach-ing domains and to their cognitive models. One example ofthis is Steamer,7 a tutorial system that simulates the opera-tion of steam propulsion engines for ships. Steamer is onlyapplicable to the domain of steam propulsion engines; itwould be difficult to use the models and facilities in Steamerto generate other instructional material.Lack of generalizability is also suggested by the absence of

intelligent tutoring systems that can interface with new mediatechnologies such as interactive video.

Authoring. Creating effective computer-aided instructionalmaterial, or "courseware," is called authoring. In somerespects, authoring is similar to programming: there areauthoring environments that support an authoring team(usually consisting of instructional designers, coursewaredesigners, and subject-matter or content experts) throughouta "courseware life cycle" (similar to a programming lifecycle). In other respects, authoring is similar to knowledgeengineering: authoring is the acquisition and computer rep-resentation of expert knowledge in a specialized task domain.The actual computer programs associated with coursewareare highly interactive and must operate in real time. This isone reason why the authoring process is very expensive. Thisexpense, of course, depends on the sophistication of the instruc-tional strategies chosen and the depth of knowledgerequired. Courseware development involving interactivegraphical simulations is estimated to cost between $8,000

0885-9000/86/0500-0031$01.00© 1986 IEEESUMMER 1986 31

and $15,000 for one hour of student interaction. Edwards8states that costs associated with one hour of student interac-tion for courseware involving interactive video ranges from$30,000 to $500,000.

In this article, we examine the development of knowledge-based tools for authoring CBT material. Our approach is toconcentrate on developing one cognitive model of an author.We conclude by discussing an example of a prototype knowl-edge-based system that is used for procedural training andsimulation.

CBT requirements

be representations of student learning management-providingtests, student diagnosis, and feedback so that instructionalstrategies can be individualized for the student.

Authoring technology. There are two aspects of authoringtechnology.2',3 The first aspect is developing new "media"tools, such as interactive graphics and animation, speechprocessing, simulation, and video. The second aspect isdeveloping new tools to increase the productivity of theauthoring team.1'4 These tools exploit knowledge-basedtechnology by creating cognitive models of the student, thecourseware developer, the instructional designer, and thesubject-matter expert. This concem for user modeling is alsoseen in Sleeman.10

Four requirements in developing CBT systems are

(1) Instructional strategies,(2) Learning scenarios,(3) Authoring technology, and(4) Knowledge representations.

Instructional strategies. Instructional strategies are con-cerned with how best to present the instructional material tothe student, including how much author (computer) controlversus student control there should be, the amount and tim-ing of feedback, and the types of scorings that evaluate thestudent for mastery levels. At one extreme is the simpletutorial sequence "rule-example-practice. " Here, a rule isdisplayed as a text, an example of the rule is provided, andfinally the student is allowed to practice on a variety of exer-cises. This strategy is more often associated with "classical"CBT systems: there is no continuous dialog with the student.In this strategy, the only control that the student has is pro-vided by an author-defined sequence determined by the stu-dent's particular responses.On the other extreme is "discovery" learning. Here, the

student has the greatest control over what he is to learn andthe rate he is to learn. This strategy is seen in various"inspectable" simulations: the student is free to examineand inquire about various components of an operationalentity.

Between these extremes are "controllable" simulationsand instructional "dialog." Controllable simulations offergreater author control by providing specific goals and proce-dures, as in a game. Dialog provides the student with theability to inquire: for example, the student can select to see aparticular rule or a practice or an example. Instructionaldesign "rules" for when to use particular strategies arefound in Merrill.9

Learning scenarios. Learning scenarios are the manage-ment of student transactions with the goal of keeping thestudent interested. On the lowest level, these scenarios maybe representations of the type of student input, such as text,mouse, light-pen, or even natural language (student transac-tion management). On higher levels, these transactions may

Knowledge representation. Finally, developing CBT requiresknowledge representation. Issues include domain-specificCBT systems versus "general" systems; subject-matter depen-dent tools and representations versus subject-matter inde-pendent tools and representations; strategy dependent toolsand representations versus strategy independent tools andrepresentations, and so on. Knowledge representation alsoinvolves the issue of "fidelity" of deep versus shallowmodels for the content (for simulation fidelity), of deepversus shallow models for the student (for effective studentdiagnosis), and so on. Knowledge representations for causal-ity are also important, both for user and content modeling(especially for simulations) and for procedural sequencing ofthe lesson.

Intelligent computer-aided instruction

Cognitive models for the student, author, and instruc-tional designer in CBT systems, as well as sophisticatedmodels of expertise, reveal a trend toward "intelligent"computer-aided instruction. To compare and evaluate differ-ent ICAI systems, we can examine ICAI from the perspec-tive of the student, the authoring team (the tool users), andthe implementors (the tool builders).The student view of ICAI is the learning scenario. He

believes in the fidelity of simulated devices, believes that hisperformance and progress are being monitored, and believesthat the system "knows what he knows."The authoring team is preoccupied with the courseware

authoring environment-analysis, design, programming, andevaluation. Authors believe that the tools can adequatelyacquire content and strategy knowledge and that the toolscan represent and manage this knowledge for a trainingsession.

Implementors of ICAI concentrate on different cognitivemodels associated with the different system users. They havea model for the student (for diagnosis, feedback, and trans-action planning); a model for the author (for knowledgeacquisition), and a model for the instructional designer (forincorporating strategies). Implementors believe that these

IEEE EXPERT32

Figure 1. OBIE-1:KNOBE display ofprocedural training session on theoperation of an aircraft inertial navi-gation system.

models are valid and will result in complete and consistentknowledge representations so that (1) author productivitywill be increased, and (2) student learning will be optimized.No complete ICAI environment exists that incorporates

all these points of view, but it might be instructive to look atone prototype ICAI authoring system, called Object-BasedIntelligent Editor-l:Knowledge-Based Editor, orOBIE-l:KNOBE. OBIE meets the four requirements givenabove for an effective CBT as follows:

(1) The instructional strategy is controllable simulation,(2) The learning scenario is the same as a conventional

CBT system,'"(3) The authoring technology increases the productivity of

the authoring team in developing simulations for proceduraltraining, and

(4) The knowledge representations model the author as asubject-matter expert and instructional designer.

with associated text allow both types of individuals to bene-fit. Moreover, Edwards' states that people retain about 25per cent of what they hear, 45 per cent of what they see andhear, and 70 per cent of what they see, hear, and do. Third,we focused on procedural simulations because they are themost difficult to generate courseware for (compared togenerating simple straight text CBT), especially for individualsnot skilled in programming techniques. By creating anauthoring system to simplify the development of these CBTsimulations, we significantly reduced the time required todevelop simulation courseware for authors unskilled in pro-gramming and simultaneously increased the efficiency oftraining by making more effective instructional strategiesavailable.

Student view

OBIE-1: KNOBE

The OBIE authoring system is a set of knowledge-basedtools and techniques that enable authors (who are unskilledin traditional programming languages) to develop interactiveCBT procedural simulations. These knowledge-based toolscurrently execute on a Symbolics 3600 Lisp Machine.Our decision for focusing on procedural simulation was

threefold. First, many applications have simulating instru-ment panels that students can learn to operate or maintain:aiding the author in producing these panel simulations has alarge potential payoff in the courseware development proc-ess. Second, these CBT simulations have been identified asthose where "learning can be more rapid and long lasting"(e.g., Montague and Wulfeck3) compared to CBT relying onjust ordinary text. Some individuals do find that they canmore easily learn something by reading instructions that arewritten in sentence form. But others are more apt to learnsomething if they can visually see how the something oper-ates. Interactive graphical simulations that are presented

In demonstrating our authoring system we first show howan OBIE-authored lesson appears to a student. As an exam-ple, we show excerpts from a 40-minute procedural trainingsession on the use of an aircraft inertial navigation system.In this session, the student sees a set of simulated devicesand relationships, regions of a screen with text, and "panels"(groups) of interrelated devices. The student believes in thefidelity of the simulations. Student input is accomplished bymeans of mouse and keyboard; in OBIE there is no empha-sis on natural language dialog. In this respect, OBIE-generated courseware corresponds to courseware generatedby other conventional CBT systems such as TICCIT." Aphotograph of an OBIE display of part of this training ses-sion is in Figure 1.

One procedure in the OBIE inertial navigation systemtraining session is longitude/latitude modification. The pur-pose of this procedure is to allow a pilot to change the longi-tude and latitude. This procedure is important: if it is notexactly followed, then the aircraft is in danger of being offcourse.

The steps in this procedure are as follows:

SUMMER 1986 33

(1) Set MSU switch to STBY. This sets all displays in theinertial navigation system to zero (Figure 2).

(2) Set AMR switch to MAN. This causes the insert but-ton to flash. The system is now ready to accept input codesfor verification and modification of latitude and longitude.

(3) Input the three-digit access code using the keypad.Whatever is typed on the keypad now appears in Display-l.

(4) Press insert button. If the access code is correct, thiscauses the previously stored latitude and longitude to appearin DISPLAY-1 and DISPLAY-2, and the TK-CHG buttonflashes. Otherwise, the warning indicator flashes, DISPLAY-1is cleared, and the insert button flashes again. This allowsthe pilot to retype the input code, until the code is correct.

(5) To keep the stored longitude and latitude coordinates,switch AMR to AUTO. All displays are cleared, all indica-tors turn off; we can proceed with other navigation oper-ations.

(6) To change longitude and latitude coordinates, press theTK-CHG button. The insert light now flashes.

(7) Input the longitude coordinates using the keypad;press the insert button. Input the latitude coordinates usingthe keypad; press insert button. Both coordinates appear inseparate displays. The system is now ready for other naviga-tion operations.

In this session, the pilot learns by going through asequence of displayed text (rules), being provided with anexample, and being allowed to experiment in a (controlled-world) simulation: this is a combination of the instructionalstrategies of "rule, example, practice" and controllablesimulation. There is a limited amount of student diagnosisdone by the system. The actual learning strategies, as well asthe degrees of student modeling and control, are incorpo-rated into the training procedures by the author.

Author view

The complete authoring of the forty-minute inertial navi-gation system training session took about ten hours (exclu-sive of graphics). The authoring process applies three tools:the Graphics Interface Editor, the Cognitive ConnectionEditor, and the Panel Sequencing Editor.The first phase of authoring with OBIE involves the crea-

tion of objects. An object is a software representation of thestructural knowledge of a simulated device. The knowledgeconsists of device names, graphics, state names, state values,and information associated with the dynamic behavior ofthe device (such as whether an indicator needle turns clock-wise or counterclockwise or where a student "flips" a switchwith a mouse to turn it on). An author can define any graphicfor an object, as long as its bit-map representation name canbe made known. An author can also associate an object witharbitrary states and state values; the names of the states andstate values are also author defined. However, states must betyped into three different categories (see below). In this way,

the author can construct CBT simulations for differentpanel application areas.

Authors associate names and graphics for an object withthe Graphics Interface Editor. OBIE can use bit-mapscreated by any graphics editor. (Currently, OBIE interfaceswith the DaVinci Graphics Editor. 12) We illustrate in Figure 3part of the process involved with object creation by con-structing a METER object, using the Graphics InterfaceEditor. We want the analog meter to have two shades and theindicator to rotate to the corresponding value. In the figure,the two graphics on the far left and far right represent themeter in the two colors. The graphic in the middle representsthe meter indicator, which points to the graphic that will besubject to a geometric transformation (rotation). At the bot-tom of the figure, object state information is being acquiredby the Graphics Interface Editor as it prompts the author(here considered as a subject-matter expert) for his expertknowledge about the simulation (or more specifically, aboutthe structural knowledge he has about the METER device).Once all the knowledge about a specific object has beenacquired, OBIE creates an internal representation of theobject so that it may use the object at a later time for devicesimulation. An "instantiation" of an object, which we callan actor, is used to configure behavioral simulations.The Graphics Interface Editor classifies states into three

categories: discrete, analog, and sequential. A discrete statehas a finite number of values. An example of an actor thathas a discrete state is a switch or one of the indicator lightswhich may be seen in Figure 1. An analog state ranges overan infinite number of values. An example of an actor thathas this type of state is a clock or the meter in Figure 3. Asequential state has certain state values which are dependenton other state values. An example of an actor that has asequential state is the display in Figure 1, since the currentvalue of a display is always dependent on the previous valueof the display.Once an author has created all the objects needed to con-

struct a simulation, he may proceed to create actors fromthese objects in order to model the behavioral knowledge ofdevices. Actors represent "living" objects-they representoperating devices with states and values that may be dynami-cally changed. For an author to change a value of an actor'sstate (with the potential "side effect" of changing agraphic), the author need only point at the actor with themouse to invoke a state change menu. Figure 4, an exerptfrom a CBT session that teaches authors how to use OBIE,shows this process. Multiple actors may be created from thesame object: they differ only by the name the author givesthem. OBIE protects the author from making mistakes suchas defining two actors with the same name.

Once all the devices (actors) are configured on the com-puter screen, the behavioral knowledge representing simu-lated relationships between the devices may be specified.Devices may be "connected" to one another with the use ofthe Cognitive Connection Editor. The Cognitive ConnectionEditor allows the author to create relationships or "connec-

IEEE EXPERT34

Figure 2. Longitude/latitude modifi-cation procedure: set MSU-Switchto STBY.

Figure 3. Constructing an analogmeter object.

Figure 4. Changing the state of anactor.

SUMMER 1986 35

Figure 5. Making a cognitive con-nection.

tions" between objects using a "common sense" rule-basedmodel. The input to the Cognitive Connection Editor isessentially a list of named actors and their states; the outputof the Cognitive Connection Editor are the relationshipsbetween actors and their states defined by the author.To create a connection between objects, the author must

identify the affector objects-those that affect state changesin other objects-and the affectee objects-those that areaffected by such state changes. Once the affectors and affec-tees are chosen, the author has the ability to "make,""remove," or "edit" an existing connection. The modelused to create the connections between objects embodies thecommon sense notion, "This is what happens to theseobjects when I perform this particular action." Affectorsand affectees make up a cognitive connection and cognitiveconnections make up a simulation.OBIE also allows an author to "bind" the states of actors.

Binding specifies that whatever the state value of the boundaffector state is, then the state value of the bound affecteestate will be the same.We illustrate how an author creates a cognitive connection

between two devices. Figure 5 shows the inertial navigationsystem with the addition of the ALTITUDE actor. Also inthis figure is a menu from the Cognitive Connection Editor.This menu allows the author to specify the actors and theirstates and state values, which will be formed into an author-specified relationship. The rule that is being constructed inFigure 5 will bind the analog state of altitude with theDisplay-String state of DISPLAY-3. Once the rule is speci-fied by the author, any change of the ANALOG state of theALTITUDE device will also cause a change in the DISPLAY-STRING state of the DISPLAY-3 device. Figure 6 shows oneinstance of these bound states.The binding of the ALTITUDE and DISPLAY-3 devices,

as well as the connection which involved the MSU-Switchand the DISPLAY-SELECT-SWIT'CH (Figure 1), are exam-ples of rules that are independent of time. These are knownas declarative rules. Once an author has configured severaldevices together and has constructed all the declarative rulesthat define the interactions among those devices, he cangroup those devices and their relationships together by creat-

ing a "panel." Once defined, a panel may be displayed atany time during an authoring session. A panel is just onepart of a simulation procedure. In some respects, a panel is asingle scene, where a simulation is an entire play. If a simula-tion is to consist of more than one panel, then connections,or rules, must be constructed between the panels to definehow the panels interact. The Panel Sequencing Editor pro-vides the author with a learning management and controlfacility that allows procedure sequencing and student feed-back. The panel/simulation relationship is analogous to theactor/panel relationship-all sequencing and control inOBIE is accomplished by the "common-sense" cognitiveconnection rules.

To construct the panel sequencing rules, an author usesthe Panel Sequencing Editor. This editor is very similar tothe Cognitive Connection Editor. The major difference isthat the Panel Sequencing Editor utilizes a special actor,which we call the "Lesson Actor," whose purpose is toincorporate the ability to change panels into the OBIE rulestructure. A Lesson Actor allows panels to be specified asaffectees of a rule. Sequencing is accomplished when a rule(with a Lesson Actor and an associated panel as one of itsaffectees) is fired that changes the panel that is being viewed.After all the necessary panels have been constructed andappropriately connected to the other panels, then the authorspecifies a name for this conglomerate, and a simulationprocedure has been made. As with a panel, once a simula-tion has been constructed and is specified with an author-defined name, it may be initiated at any time during anauthoring session. The initiation of a simulation begins withthe display of the first specified panel, and then sequences asan author (who at one point may be simulating the student)makes the appropriate state changes to the simulated devices.

Implementor view

A key issue that had to be resolved in the developmentof OBIE concerned the representation of the "common

IEEE EXPERT36

Figure 6. The effect of firing a cog-nitive connection.

sense" knowledge associated with a content domain. Thisknowledge is either structural (viz., describing objects interms of states or properties, together with hierarchicallyordered inheritance relations), or behavioral (viz., describingobjects in terms of causality rules that provide for timedependent and time interdependent relations).Our approach to the modeling of structural content

categorizes device knowledge according to discrete, sequen-tial, and analog states. Other issues are (1) the acquisition ofparticular content knowledge (from subject matter experts)and (2) the actual simulation of the device.

In the first case, we are concerned with matching graphicsand text descriptions with the content actually denoted in asimulation, together with developing facilities that acquireand access this knowledge to create a behavioral simulation.OBIE uses a hierarchical frame-based scheme for this repre-sentation; the frame, consisting of slots denoting the devicename, its states, and the values its states may have, togetherwith appropriate text, graphics, and relative coordinates, iswhat we have been calling an "object. " This representationis convenient for knowledge acquisition tools, since framesallow for "default" slot denotations.

In the second case, we are concerned with how the knowl-edge of content is used to simulate the actual behavior of adevice. Since realistic equipment simulations show the behaviorof several interacting devices, it is necessary to have a com-putational model that explicitly addresses time and concur-rency. One model of such behavioral knowledge is based onActor Semantics. In this model, an actor is a computationalagent that can change its local states (concurrently withother actors), can send messages to other actors, and canmake decisions (i.e., as to whether or not to send a message).In the behavioral representations, actors correspond to"activated" frames (i.e., objects whose graphics are displayedand are ready to change states). In some respects, our use ofobjects and actors is just another "theme and variation"associated with object-oriented programming.'3OBIE also models the behavioral knowledge of relation-

ships between content structures. For example, in an inertialnavigation system simulation, an author might want toestablish the relationship, "When the mode-selector unit is

off, then all of its annunciators are off, and all of the dis-play is initialized to zero and will blink." To build a knowl-edge acquisition tool to easily express this "common-sense"relationship, it is necessary to develop a formal theory ofhow such relationships can be automatically programmed.Our theory is one of "cognitive connections." A cognitiveconnection is a rule that can be expressed as a formula inunary predicate calculus (a subset of mathematical logic) byusing logic to represent causality (e.g., Hagert'4). A cognitiveconnection

MSU-Switch(discrete, position, OFF)-==>5

BATT-light(discrete, on?, YES) andALERT-indicator(discrete, on? NO)

which says that when the MSU-switch is off, then the BATT-light is on and the ALERT-indicator is off, can be expressedin propositional calculus. But the power of unary predicatecalculus allows an author to express a relationship such as

(For All XBATT-light(discrete, on?, X)-==>5

ALERT-indicator(discrete, on?, X)which says that the ALERT-indicator will follow the samebehavior as the on?-state value of BATT-light. The vari-able in these formulas refers only to the value of a particularstate. Using variables allows certain states to be "bound"and provides flexibility and efficiency in rule creation. Forexample, if an author wishes to have an LED display showthe same value as that shown on an analog meter, he onlyneeds to bind their corresponding states. This binding canrepresent literally thousands of simple propositional calculus-type rules.

These cognitive connections enable an author to easilyand quickly represent complex relationships among simu-lated devices. In OBIE, the author does not need to knowthe details of the theory, nor does he need to be familiarwith any programming language. All connections are auto-matically made interactively from choices made on speciallydesigned menus which exploit the cognitive connectionstructure.

SUMMER 1986 37

Another advantage of our cognitive connection approachis to detect loops. Loop detection in OBIE is possible sinceour rules are represented in unary predicate calculus andsince the decision problem, "whether or not there exists analgorithm to determine the truth or falsehood of an entireclass of statements," is solvable in unary predicate calculus.In the case of loop detection, the proposition here is,"whether or not a collection of cognitive connection rulesexhibits an infinite loop upon rule firing." This decisionproblem is closely related to the halting problem, "whetheror not one can determine that a given procedure will stopand produce output upon any input. " Solvability of thehalting problem for a given case guarantees that no infiniteloops exist in the procedure. The halting problem is unsolva-ble in many systems but is solvable in unary predicatecalculus.

O BIE has the advantages of a knowledge-basedapproach to authoring. OBIE-authored CBTsessions for procedural simulation can beproduced in less time than with conventional

authoring methods. However, much work remains to bedone for OBIE to satisfy the four requirements for effectiveCB that were specified above.Even though these goals are ambitious, we believe that the

OBIE object-oriented architecture provides the implemen-tors with the flexibility to build a knowledge-based author-ing environment with the powerful capabilities that we havediscussed.E

AcknowledgmentsWe wish to acknowledge the following people for their support in

developing OBIE-I:KNOBE: Rob Frail, Lois Wilson, Steve Fine,Tim Eller, Dave Mudrick, Ray Masak, Randy Cope, and Sal Nuzzo.We also wish to thank Lois Wilson for her constructive commentsand Marie Deluca for typing the manuscript.

References1. R. S. Freedman, "Knowledge-Based Courseware Authoring,"

Training Technology Journal, Vol. 1, No. 4, 1984, pp. 4-9.2. G. Kearsley and R. Seidel, "Automation in Training and Educa-

tion", Human Factors, Vol. 27, No. 1, 1985, pp. 61-74.3. W. Montegue and W. Wulfeck, "Computer-Based Instruction:

Will it Improve Instructional Quality?" Training TechnologyJournal, Vol. 1, No. 2, 1984, pp. 4-19.

4. J. Psotka, "Intelligent Design Envients and Assistant Sys-tems," panel on Intelligent Computer Assisted Instruction (J.Bonar, moderator), IEEE Proc. Expert Systers in GovernmentSymp., McLean, Va., 1985, pp. 225-228.

5. B. Woolf and D. McDonald, "Building a Computer Tutor:Design Issues," Computer, Sept. 1984, pp. 61-73.

6. A. Stevens, A. Collins, and S. Goldin, "Diagnosing Student'sMisconceptions in Causal Models," Intelligent Tutoring Sys-tems, (ed., D. Sleeman and J. Brown), Academic Press, Cam-bridge, Mass., 1982,

7. J. Hollan, E. Hutchins, and L. Weitzman, "STEAMER: AnInteractive Inspectable Simulation-Based Training System,"The Al Magazine, Vol. 5, No. 2, Summer 1984, pp. 15-27.

8. M. Edwards, "The Mercedes Benz of Interactive Video,"Hardcopy, Vol. 14, No. 5, May 1985, pp. 74-80.

9. M. Merrill, "Component Display Theory," Instructional-Design Theories and Models: An Overview of their Current Sta-tus, (ed., C. Reigeluth), Lawrence Eribaum Associates, Hillsdale,N.J., 1983, pp. 279-330.

10. D. Sleeman (moderator), user modeling panel, Proc. IJCAI-85,Morgan Kaufman, Los Altos, Calif., 1985, pp. 1298-1302.

11. L. Wilson, "Presenting TICCIT, State-of-the-Art Computer-Based Instruction," Training Tednology Journal, Vol. 1, No. 4.

12. R. Frail and R. Freedman, "DaVinci: An ExtendableKnowledge-Based Software Tool for Graphics," IEEE Proc.Conf. Software Tools, New York, N.Y., 1985, pp. 65-70.

13. M. Stefik and D. Bobrow, "Object-Oriented Programming:Themes and Variations," The Al Magazine, Vol. 6, No. 4, 1986,pp. 40-62.

14. G. Hagert, "Modeling Mental Models: Experiments in Cogni-tive Modeling," Proc. Sixth European Conf. Al, Pisa, Italy,1984, pp.389-398.

Roy S. Freedman is an associate professor of electrical engi-neering and computer science at Pblytechnic University. Freed-man joined the Polytechnic from the Hazeltine CorporationResearch Laboratories. For the past four years at Hazeltine, hedirected the Artificial Intelligence Group as its research supervi-sor, where he developed several knowledge-based systems fordesign, manufacturing, simulation, training, and planning.Presently, he consults with Hazeltine and other organizations inthe electronics and financial industries. Freedman obtained hisPhd from the Polytechnic University in 1979.

Jeffrey P. Rosenidng is a software engineer in the ArtificialIntelligence Group at the Hazeltine Corporation ResearchLaboratories. He has implemented many key components of theOBIE authoring system and is presently involved with incor-porating OBIE into a TICCIT facility. He received a BS in com-puter science from the State University at Stony Brook in 1983.

Questions about this article can be addressed to Freedman atDepartment of Electrical Engineering and Computer Science,Polytechnic University, Farmingdale, New York 11735; or toRosenking at Hazeltine Corporation Research Laboratories,Greenlawn, NY 11740.

IEEE EXPERT38