an object-oriented model of knowledge bases

Communication Between the Knowledge Base and Other Modules of the Intelligent Tutoring Shell in GET-BITS Model Vladan Devedzic1 and Ljubomir Jerinic2 1

FON - School of Business Administration, University of Belgrade, Jove Ilica 154, 11000 Belgrade, Yugoslavia e-mail: [email protected] 2 Institute of Mathematics, University of Novi Sad, Trg Dositeja Obradovica 4, 21000 Novi Sad, Yugoslavia e-mail: [email protected]

Abstract - The paper describes an application of the object-oriented software design methodology for realizing and arranging designing the knowledge bases and manipulating their contents for intelligent tutoring. Such an approach makes the building process for intelligent tutoring systems (ITSs) more natural and more user friendly, and also makes easier to extend the tool set used to build knowledge bases. An object-oriented model of ITSs knowledge bases has been developed, and its two aspects are presented in the paper. First, the design and organization of knowledge bases, and then, the communication between the knowledge base and some other modules of an ITSs. An example of using the model in the analysis and design of simple knowledge base updating operations is also shown.

1. Introduction Intelligent Tutoring Systems (ITSs) [1, 3, 4, 8, 9] are used for computer-based instruction of students in a particular domain. They have the possibilities of presenting the appropriate contents to the user (student), monitoring his/her reactions and the learning process, generating problems and tasks for the user in order to check his/her knowledge, etc. Relying on a particular model of each student, the control mechanism of an ITS can suit the tutoring process to each individual user. The intensive development of the methods of knowledge engineering and reasoning in the last two decades has provided the possibility that education can be delivered by the computer. The main goal of that approach is the complete individualization of the educational process. The research on ITSs has produced the technology to do this task within the computer program. But, as computers have entered teaching practice, teachers show an increasing interest in educational software systems. For these teachers, however, ITSs is the most difficult one in terms of grasping the total aspects. Of course, they have a chance to read articles about ITSs, but what they can understand through the articles is confined to the abstract level of comprehension. Experience in using ITSs directly through a system that makes transparent the inner mechanisms of ITSs would be a powerful tool to help them in comprehending it. As research in ITSs continues to produce more refined systems, the gap between the research community and educational community continues to become wider. The educators' understanding, and usage of these research results has been much slower than the research progress. As this theory-application gap becomes wider, it becomes more difficult for educators to participate in ITSs research and application, and the result of the research becomes increasingly academic and unconnected to the pragmatic aspects of teaching and learning. Traditional ITSs concentrate on the fields (domains) [10, 11, 12] they are supposed to present, hence their control mechanisms are often domain-dependent. More recent ITSs pay more attention to generic problems and concepts of the tutoring process, trying to separate architectural, methodological, and control issues from the domain knowledge as much as possible. This was also one of the main ideas behind the ITS shell (environment) called EduSof [7], designed to allow fast prototyping of ITSs in different domains. However, the original design of EduSof's mechanisms for representing domain and control knowledge has proved to be fragile in maintenance and further development. Therefore, a new version of EduSof has been designed, considering a new model of ITSs we developed using object-oriented approaches. It is called GET-BITS (GEneric Tools for Building ITSs), and is essentially a specific

extension of a more general, recently developed model of knowledge bases, called OBOA (OBjectOriented Abstraction) [6]. The new version of EduSof is much more flexible and reusable than the first one.

2. The architecture of knowledge in EduSof The original goal of developing the EduSof system was to design a conceptual framework for representing objects, events, responses, reactions, and relationships used in tutoring and learning. The system is featured by an interactive graphical environment in which the teacher can manipulate objects at different levels of abstraction. These objects and relationships between them are used for defining, designing and creating a lesson. The intended users of EduSof are educators and instructional experts, not programmers. The framework is domain independent, and includes mechanisms for representing domain knowledge and control information, thus generating a particular ITS. These mechanisms are responsible for dynamically customizing the machine's responses. In EduSof, a teaching sequence is organized as a list of semantically connected elements Lessons. They consist of a list of Concepts. Concepts, as basic components of a teaching sequence, can be expressed by means of Text, Picture, Voice and/or Simulation. For each Concept, a list of Questions is given, used for testing the acquired knowledge connected to that Concept. For each Question, a list of Alternatives is given, as possible answers to it, or the right Answer. For each Alternative, a Right Answer is provided. Also the information is given about What Next the pupil will learn, in case that a right or wrong answer is chosen. The EduSof system is organized in three separate modules. The creating module Teacher, serve for designing lessons by the teacher of the subject, and the module Learn is a kind of interpreter of the knowledge introduced by the Teacher module, used by pupils while mastering the subject-matter and getting the pertinent knowledge. The third module can be used to test students for marking. There are six modules in EduSof's architecture: Expert (containing domain knowledge that an instructor enters), Student (student model), Tutor (knowledge of teaching strategies and pedagogical knowledge), Diagnostics (evaluation of student's knowledge), Explanation (strategies for explanation of hard topics on student's request), and Interface (user interface). These modules together make EduSof capable of handling basic knowledge (lessons, text, pictures, etc.), additional information (for helping and improving the use of basic knowledge), learning mechanisms and student's reactions. At the current time we can consider authoring systems or ITSs shells [8, 9] in two different classes. Firstly there are the commercial systems like Authorware, ToolBook, Icon Author and Smarttext. These systems have a number of advantages over programming languages such as help in lesson planning, and built-in widgets which make instructional presentation easier. What they lack is any AI. All the adaptive behavior has to programmed in by an experienced user. The other class of systems are the different research tools, such as IDE (Russell et al, 1988), ID Expert (Merrill, 1989), KAFITS (Murray and Woolf, 1992), COCA (Major and Reichgelt, 1992), GTE (Van Marcke, 1992), RIDES (Munroe et al., 1994), Byte-sized Tutor (Bonar et al., 1986) and EON (Murray 1996). These systems come with knowledge base structure and interpreters much like and expert system shell. Their difficulty is knowing how much flexibility to offer to the teacher and how to make that acquisition process as easy as possible. These systems have not made it out of the lab or seen wide use in multiple domains, and according to T. Murray that happens because of one or more of these factors:  They are based on a specific instructional approach;  The domains of application are limited because the system was modeled from an existing task-specific intelligent tutor and generalized to similar domains;  They are too complex because they are based primarily on theoretical concerns or AI techniques;  They provide tools for structuring and using knowledge, but not for creating appealing student interfaces or learning environments. In general, these ITSs, though some are fairly powerful and general, were not designed with significant user input, and do not address the practical issues encountered when educators actually use these systems (with the exception of COCA, which underwent some user testing). Our try to solve these problems with authoring tools and ITSs shells is that instead a component architecture for ITSs shells (like the most of these shells) we used the object-oriented approach in designing new version of EduSof shell. Also, the previous version of EduSof suffered from some deficiencies, which we tried to overcome in the new version. First, different kinds of knowledge in its modules were designed separately, although all of them conceptually had much in common. Second,

decomposing the system functionally to the above modules made it hard to make additional changes and extensions when they were needed. Adding new knowledge representation techniques when needed required substantial changes in several modules. Finally, whenever there was a need for a change, not much of the relevant software could be used without any change.

3. Object-oriented knowledge primitives for intelligent tutoring First we describe a unified abstraction of different knowledge representation techniques and different models of action and maintain the knowledge in knowledge bases in general. That techniques (of a unified abstraction) are used while designing the shell for design intelligent tutoring lessons. The abstraction is derived and realized by applying object-oriented approach. The motivation for defining such an abstraction was to provide a unified description and representation of different elements in knowledge bases and more general knowledge access methods for use in interactions between an knowledge base and the other modules of ITSs at runtime, as well as in interactions between different modules of integrated ITSs building tools at development time. As a result, an object-oriented model of knowledge bases is developed and is called OBOA. It covers both designs of knowledge bases and communication between the knowledge base and other ITSs modules. However, the OBOA model sets only general guidelines for developing and using of object-oriented knowledge bases. It is open for fine-tuning and adaptation to particular applications. The ultimate practical goal of developing the OBOA model was to use it as the basis for building a class library of knowledge representation and knowledge access tools and techniques. The background for developing the OBOA model was several different ideas coming from the fields of knowledge and data modeling, representation and management. Gruber and Cohen [5] have described a hierarchy of knowledge representation techniques and tools, starting from most primitive ones to quite complex knowledge structures. Also, some ideas from the field of object-oriented databases [13] and object-oriented applications [2] were also adopted in the OBOA model. Although the OBOA model was developed for representing knowledge in expert systems, it can be easily extended to other intelligent systems [6]. The essence of the OBOA model is a unified abstraction of different knowledge representation techniques and different models of human knowledge. All kinds of knowledge (e.g., domain, control, explanatory, etc.), as well as all types of knowledge representation formalisms (e.g., rules, frames, logic, etc.), can be viewed from the perspective of an abstract and fairly general concept of "knowledge element". Speaking in terms of object-oriented analysis and design, the OBOA model defines an abstract class K_element for representing an abstract knowledge element, no matter how complex the element is or what its purpose is. In other words, knowledge representation techniques like production rules, frames, semantic networks, etc., as well as problem solving strategies (such as generic tasks, heuristic classification,...), and higher-level concepts and agents (e.g. planners, scripts, blackboards, multiagents, etc.) can all be defined as more specific knowledge elements, simple or aggregate. No matter what and how many knowledge representation techniques are needed in a particular intelligent system, it is always possible to define a suitable hierarchy of knowledge types needed and design a corresponding class diagram starting from K_element, as the most abstract class, in the root. As an example, Figure 1. illustrate what meaningful subclasses can be derived directly from K_element regarding domain knowledge representation in expert systems (the classes shown do not exhaust all the possibilities). Rule and Frame classes are used to specify If-Then rules and frames. Attribute and Relation classes define attributes of more complex knowledge elements and relations that can be defined among some other knowledge elements. K_chunk (Knowledge chunk) class objects can be used as slots for Frame or Media objects, or If- and Then-parts in Rule objects. Of course, the subclasses shown can be (and some of them actually are) too abstract to be used directly in a particular application. Many other subclasses may also be needed for knowledge representation in other intelligent systems or expert systems. In all such cases, additional subclasses can be derived either directly from K_element, or from its direct subclasses. It is a matter of design of a particular intelligent system to define such additional subclasses accordingly.

K_element Rule

...

Relation Frame

...

Attribute K_chunk

Media

Figure 1 The K_element class hierarchy

4. The OBOA model of knowledge primitives In this section the usage of the OBOA model in the knowledge representation of the knowledge primitives of EduSof is presented. That knowledge representation is concerning some particular and concrete type of knowledge elements that are necessary for the realization of the Expert module in any ITS shell. One of the most important elements of knowledge primitives for designing the intelligent tutoring lesson is the model of Lesson, and this is basic class needed for modeling the learning process. Any lesson is consisted of one or more issues, modeled by the class Topic in the OBOA model. We assume that the student must learn these issues, during mastering that lesson. The basic attributes of the lesson are: the name (Name), current topic (CurrentTopic, the issue or the problem introduced, defined and/or explained in the present moment), the task that is currently solved, the level of prerequisites for the student (StudentLevel), and so on.

Concept Explanation

K_element

...

Rule

Explanation

Frame

Goal

HardLesson Lesson

...

Topic

EasyLesson TQ FirstLesson LastLesson

BasicTopic Task DerivedTopic

System Explanation

Question

Multidisciplinary Topic

EndUser Explanation Developer Explanation TQ Explanation

...

Figure 2 Important classes in ITSs Applying the principles of the OBOA model, we can define appropriate class hierarchies for developing ITSs. That's what GET-BITS is about. It also starts from the concept of knowledge element, and derives meaningful subclasses that are needed for building a wide range of ITSs. However, classes for knowledge representation are not the only tools needed to build an object-oriented ITS. Apart from knowledge of various kinds, in each such ITS there must also exist some control objects that functionally connect the system's modules, handle messages, control each session with the system, monitor student's reactions, etc. In other words, such objects provide control and handle dynamics of ITSs. GET-BITS also specifies classes of these control objects. Due to space limitations, we describe only the most important classes specified in GET-BITS for representing various kinds knowledge in ITSs. They are illustrated in Figure 2. Obviously, many key classes are derived from the Frame class (Lesson and Topic - lessons and topics the user learns; TQ - an abstract class used to derive the classes representing questions the student has to answer, tasks and problems the system generates for him/her, etc.; Explanation explanations the system generates on request for various classes of users (end-users and system developers), as well as topic- and concept-oriented explanations). Additional attributes of these classes

make them semantically different and more specific than ordinary frames, although they are actually implemented as more specific frames. The names of the other classes are easily interpreted. Once all of the important classes for knowledge representation (and also for specifying control objects) are implemented within a class library, it is a straightforward task to use them for designing and implementing an ITS shell like EduSof. That is the main practical goal of GET-BITS: letting ITS shell developers "get bits" of software they need, suit them to their own design needs without starting from scratch, yet retaining control over further development of their tools and making them more reusable.

5. Communication between the knowledge base and other ITSs modules The part of the GET-BITS model that describes the nature of communication and the data communicated in the interaction between the knowledge base and other modules of an ITSs (student model, teaching module, mal-rules, user interface etc.) uses the concept of transactions from objectoriented knowledge bases. The entire data transfer between the knowledge base and other parts of an ITSs can be seen as a series of transactions, and the objects exchanged in such transactions are, in most cases, knowledge elements and status messages. In general, transactions in database systems are defined as elementary units of work that, when allowed to proceed concurrently, are guaranteed to produce results that are equivalent to the results produced by some serial execution. However, concurrent knowledge bases are not considered in this paper. In other words, the rest of the paper is limited to the most common case of single-user and single-knowledge-base ITSs. Data flow paths and directions of transactions are shown from Figure 3 till Figure 8. The symbols used in the figures to denote the modules of ITSs and ITSs Building Tools (ITSsBT) are:  KB - Knowledge Base  WM - Working Memory  CK - Control Knowledge - teaching strategies  SM - Student Model  MR - Misunderstanding - Mal Rules  UI - User Interface  UI-D - User Interface to the ITSs Developer - Teacher  UI-E - End-User Interface, i.e. Student Interface  IO - Input/Output  KA - Knowledge Acquisition  KBMS - Knowledge Base Management System  KBM - Knowledge Base Manager  Other - Other modules (databases, hypertext, etc.)

KB

UI

User

WM

IO

Environment

SM MR

CK Figure 3 Commonly used model of ITSs

Most these modules are standard in every ITSs/ITSsBT. Some of them are used only in specialpurpose ITSs/ITSsBTs, like the IO module in Figures 3 and 4, or the Other module in Figure 5. They are separated from the standard modules by dashed lines, but are shown in the figures for the sake of completeness. The rest of the paper focuses to communication between the KB module and the other standard modules only. Figure 3 shows the ITSs model used in most practical applications. Transactions between the KB module and the UI module can take only one direction, i.e. the end-user of an ITSs can only examine the contents of the knowledge base, but is generally not allowed to change them. New knowledge can

be acquired during the system operation and there are transactions from the WM module to the KB module as well. A general model of an integrated ITSsBT is shown in Figure 4. Creating, updating, compiling, searching, and all the other operations over the knowledge base (transactions) are done by the knowledge base manager (the KBM module). The other ITSsBT modules do not have direct access to the knowledge base. This is the fact stressed explicitly in the OBOA model, because of the encapsulation principle. If an ITSs is developed using an integrated ITSsBT, then transactions with the knowledge base at run-time also go through the KBM module (this is not shown explicitly in Figure 4).

KA

UI-D

IO MR

KBMS

IE

SM UI-E Figure 4 Integrated ITSsBT Summarizing the ITSs and ITSsBT models from Figures 3 and 4, the GET-BITS model treats knowledge bases the way shown in Figure 5. In most cases, a knowledge base (the KB module) can exchange knowledge and data objects with three other modules: UI-D, UI-E, and WM. The modules denoted generally by the Other block cannot be regarded standard, although there is a growing tendency in the ITSs technology of coupling knowledge bases with other modules and software systems. The most important fact is that the KBM module fully encapsulates the knowledge base, acting as a "protective filter" in transactions with it. Note also that the UI-E module corresponds to the UI module in Figure 3.

UI-D SM Other

KB

WM

KBM UI-E Figure 5 Transaction with the knowledge base in ITSs and ITSsBT Transactions between the knowledge base and other modules of an ITSs or an ITSsBT can be elementary (atomic) and complex. At an abstract, user-oriented, conceptual level of description, an elementary transaction is equivalent to a basic operation that can be done with (or upon) either a single knowledge element or the entire domain knowledge (or even the knowledge base as a whole). For example, operations like adding a new knowledge element to the knowledge base, or updating an existing element, are elementary transactions in which objects of transactions are single knowledge elements. Operations like creating a new knowledge base (and consequently its domain knowledge part,

which is initially empty), or getting the current size of the domain knowledge are elementary transactions with the knowledge base as a whole. Complex transactions can be represented as ordered sequences of elementary transactions. For example, compiling a rule set in the knowledge base (e.g., in order to generate the equivalent RETE network) is essentially a loop, and the main part of the loop is a single rule compilation. Compiling a single rule is a complex transaction itself, since it requires reading the original rule from the knowledge base, and writing it back in the compiled form after the compilation is done. Note that definitions of both elementary and complex transactions are fairly general. They do not include issues like the type of knowledge elements, or knowledge base organization. Figure 6 shows most common transactions between the knowledge base and the UI-D module. The arrows denote the directions of the transactions, and the labels (KB, K_element) show whether a single knowledge element or the entire knowledge base (domain knowledge) is the object of the transaction. Transaction names are self-explanatory.

UI-D KB

K_element

Compile . . .

GetSize

Find

Get

KB

Add

Delete

Update

K_element

KB Figure 6 Transaction between the knowledge base and UI-D module Transactions between the knowledge base and the UI-E module are a subset of those between the knowledge base and the UI-D module, and are most often reduced to reading a knowledge element from the knowledge base in order to display it or print it, Figure 7a. Transactions between the knowledge base and the working memory exist only during the system initialization (unless is on-line learning in the system), when all the relevant contents from the knowledge base are transferred to the working memory, Figure 7b. The labels (K_elements) suggest that this is generally a complex transaction.

UI-E K_element

K_elements

Get K_element

a /

WM

Init K_elements

KB

KB

b/

Figure 7 Transaction between the knowledge base and a/ the UI-E module b/ the working memory Some of the important classes in the KBM module design are shown in the class diagram in Figure 8. The TrMgr class is the base class used to derive classes corresponding to the transaction managers of particular modules: KB_TrMgr corresponds to the KBM module, UI_TrMgr to the UI-D and UI-E modules, etc. The KB_TrMgr class uses the Transaction class, which is the base class for all the classes representing the types of transactions (AddElem_Tr, DeleteElem_Tr, etc.).

TrMgr 1

UI_TrMgr

n

KB_TrMgr

AddElem_Tr

Transaction

DeleteElem_Tr

...

Figure 8 Transactions and transaction managers The design of the unnecessary details). Name: Visibility: Cardinality: Base classes: Derived classes: Generic parameters: Public Interface Operations: Implementation Uses: Fields: Operations: Persistence: Name: Visibility: Cardinality: Base classes: Derived classes: Generic parameters: Public Interface Operations:

Implementation Uses: Fields:

Operations: Persistence:

TrMgr and the Transaction classes is shown below (again, leaving out TrMgr Exported ; i.e., visible outside the enclosing class category 1 ; in general, list of class names KB_TrMgr, UI_TrMgr,... ; although a base class, TrMgr is not a generic class SetTrRequest, SetTrDone, TrIter, SetTrError,... ; polymorfic functions, implemented in subclasses Transaction,... TrRequest, TrOn, TrDone, TrError,... ; status flags ReportResults ; reports transaction results Dynamic ; destroyed when the program terminates Transaction Exported ; i.e., visible outside the enclosing class category n ; in general, list of class names AddElem_Tr, DeleteElem_Tr,... ; although a base class, Transaction is not a generic class SetSource, Set Destination, GetSource, GetDestination, InitTransaction, Ready, SetTrStatus,... ; Ready is a polymorfic function, implemented in subclasses KB_TrMgr, K_elements,... Source, ; source module of the transaction Destination, ; destination module of the transaction TrType,... ; type of the transaction DoTransaction ; polymorfic function, implemented in subclasses Dynamic ; distroyed when the transaction terminates

6. The Example An example of updating a knowledge base using the GET-BITS model is shown in this Section in order to illustrate the design decisions described in the previous Sections. The example describes how a new knowledge element is added to the knowledge base. However, many other simple transactions are done in much the same way. Hence the figures used in the explanations are general, i.e. can be used to describe other transaction types as well. Initially, the KB_TrMgr object is in the "Start" state, Figure 9, awaiting for the "TrRq" message from an external source module, e.g. UI_D, Figure 10. The "TrRq" message is sent by calling the SetTrRequest function and passing it the pointer to the appropriate Transaction object as a parameter (an argument). This parameter passing is denoted by the "P" letter in the Transaction object's little square box in Figure 10. SetTrRequest sets the KB_TrMgr's TrRequest flag on. This puts KB_TrMgr to

the "InitTr" state, where it stays until either the transaction is done or a transaction error occurs. The Transaction object is generated by the external source and contains the necessary information like the source and the destination of the transaction, the type of the transaction, etc.

Iter TrRq

Start

OK

InitTr

Done Error

Err

Report

Figure 9 State transition diagram of a KB_TrMgr object

External source

TrRq

KB_TrMgr

TrReport InitTransaction P

OK, Iter, Error

Transaction Ready,

TrType

TrStatus

K_Elements

KB

Figure 10 Message passing in transactions KB_TrMgr initiates adding a new knowledge element to the knowledge base by sending the "InitTransaction" message (i.e., calling the InitTransaction function) to the Transaction object, and simultaneously setting its TrOn flag on. In this case, the Transaction object is actually an AddElem_Tr object (Figure 8), but KB_TrMgr addresses it as a Transaction object for the sake of generality. The AddElem_Tr object recognizes the message, and using the values of its attributes sends the appropriate K_elements object a "TrType" message by calling the corresponding K_elements' interface function. K_elements responds by calling the AddElem_Tr's Ready function in order to send an appropriate "Ready" message. This results in AddElem_Tr activating its DoTransaction function in order to add the knowledge element to the K_elements collection. Finally, K_elements calls SetTrStatus and sends the "TrStatus" message, reporting whether the transaction is done successfully or not. Adding a single knowledge element to the knowledge base is a simple transaction, so if it is done correctly KB_TrMgr will receive an "OK" message from AddElem_Tr (it calls SetTrDone) and will make a transition to the "Done" state (Figure 9). Otherwise, AddElem_Tr will send an "Error" message to KB_TrMgr by calling the SetTrError function, and KB_TrMgr will make a transition to the "Err" state. SetTrDone sets the TrDone flag on, and SetTrError sets the TrError flag on. Both functions set the TrOn flag off. In the case of a complex transaction, adding a single knowledge element to the knowledge base would result in AddElem_Tr sending an "Iter" message to KB_TrMgr (i.e. calling the TrIter function), except when the last knowledge element is added (then an "OK" message would be sent instead). The "Iter" message keeps the TrOn flag on and leaves KB_TrMgr iterate in the "InitTr" state until the transaction is done or an error occurs.

Both from the "Done" and the "Err" states KB_TrMgr makes transition to the "Report" state (the final one), where it sends the "TrReport" message to the external source and activates its ReportResults function to generate a report of the transaction status.

7. Discussion and conclusions The purpose of the proposed GET-BITS model of knowledge bases and knowledge base management is to make a basis for applying the ideas of object-oriented software design methodology to ITSs knowledge organization, representation, and access. It covers all important aspects of knowledge bases, like their contents, knowledge representation techniques, using, updating, extending and maintaining the knowledge, etc. However, it is important to stress again that the GET-BITS model should be regarded as an open framework for developing ITSs knowledge bases, rather than as a closed set of design rules and organizational hierarchies. In fact, the model has several open ends. The first open end is the possibility of extension by including new knowledge representation techniques, as it is mentioned in Section 2. For example, suppose an ITSsBT is developed based on the GET-BITS model, and a set of knowledge representation tools and techniques is integrated within that ITSsBT. Suppose further that the ITSsBT developer subsequently decides to extend the ITSsBT with another knowledge representation technique (e.g., in order to make the tool suitable for building some specific ITSs applications). Such an extension can be done extremely easy, without reorganizing the entire ITSsBT. As another open end, an integrated ITSsBT can be easily extended to support new transaction types. This is particularly important if it is required to support some specific complex transaction. Moreover, it is possible to make an extension to support a certain structured query language for examining knowledge bases, an analogy to the SQL in the database technology. Apart from making it easier to extend the set of tools used to build knowledge bases, other important benefits of using the GET-BITS model include:  making the ITSs building process more natural and more user-friendly;  facilitating the possibility of merging ITSs knowledge bases with other software components, like databases.

References [1]

Brna, P., Ohlsson, S., Pain, H., (Eds.) 1993 Proceedings of AI-ED 93, World Conference on Artificial Intelligence in Education, AACE Press, Charlottesville, VA, USA. [2] Booch, G., Object-Oriented Design with Applications, Redwood City, CA, Benjamin Cummings, 1991. [3] Frasson, C., Gauthier, G., Lesgold, A., (Eds.) Intelligent Tutoring Systems, Proceedings of Third International Conference ITS '96, LNCS Vol. 1086, Springer Verlag, 1996. [4] Greer, J., (Ed.) Proceedings of AI-ED 95, World Conference on Artificial Intelligence in Education, AACE Press, Charlottesville, VA, USA, 1995. [5] Gruber, T., Cohen, P., Knowledge Engineering Tools at the Architecture Level, Proceedings of The 10th IJCAI, Vol.1, 1987, 100-103. [6] Devedzic, V., Organisation and Management of Knowledge Bases: An Object-Oriented Approach, Proc. of The Third World Congress on Expert Systems, Seoul, Korea, 1996, 237-244. [7] Jerinic, Lj., Devedzic, V., An object-oriented shell for intelligent tutoring lessons. In LNCS Vol. 1108 A. Diaz-Ilarraza and I. Fernandez-Castro (Eds.) Proceedings of 3rd International Conference on Computer Aided Learning and Instruction in Science and Engineering CALISCE ‘96, 1996, 69-77. [8] Major, N., Murray, T., Bloom, C., (Ed.) AIED '95 Workshop on Authoring Shells for Intelligent Tutoring Systems, Washington, DC, WWW Conference, 1995. [10] Murray, T., (Ed.) ITS '96 Workshop on Architectures and Methods for Designing Cost-Effective and Reusable ITSs, Montreal, WWW Conference, 1996. [1] Ohlsson, S., Some Principles of Intelligent Tutoring, in Lawer & M. Yazdani (Eds) AI and Education, Vol. 1., Albex, Norwood, New Jersey, 1987. [10] Vassileva, J., An Architecture and Methodology for Creating a Domain-Independent, Plan-Based Intelligent Tutoring System, Educational and Training Technology International, 27/4, 386-397, 1994.

[11] Woolf, B., Murray, T., Suthers, D., Schultz, K., 1988, Knowledge Primitives for Tutoring Systems", in Proc. ITS-88, Montreal, C. Frasson & M. Jones (Eds), Univ. of Montreal, pp. 491-498. [12] Zdonik, S.B., Maier, D., (Eds.) Readings in Object-Oriented Database Systems, San Mateo, CA: Morgan Kaufmann Pub, 1990.

Communication Between the Knowledge Base and Other Modules of the Intelligent Tutoring Shell in GET-BITS Model Vladan Devedzic1 and Ljubomir Jerinic2 1

FON - School of Business Administration, University of Belgrade, Jove Ilica 154, 11000 Belgrade, Yugoslavia e-mail: [email protected] 2 Institute of Mathematics, University of Novi Sad, Trg Dositeja Obradovica 4, 21000 Novi Sad, Yugoslavia e-mail: [email protected]

Abstract - The paper describes an application of the object-oriented software design methodology for realizing and arranging designing the knowledge bases and manipulating their contents for intelligent tutoring. Such an approach makes the building process for intelligent tutoring systems (ITSs) more natural and more user friendly, and also makes easier to extend the tool set used to build knowledge bases. An object-oriented model of ITSs knowledge bases has been developed, and its two aspects are presented in the paper. First, the design and organization of knowledge bases, and then, the communication between the knowledge base and some other modules of an ITSs. An example of using the model in the analysis and design of simple knowledge base updating operations is also shown.

Content areas:

Intelligent systems for teaching and learning, AI Application, AI Tools and Engineering

Dear Sir,

Please find enclosed our paper for the TTIA '97. Will You be so kind to inform us that You received our proposal on time on:

Ljubomir Jerinic Institute of Mathematics, University of Novi Sad, Trg Dositeja Obradovica 4, 21000 Novi Sad, Vojvodina Yugoslavia e-mail: [email protected] FAX: +381 21 350 458 Thank You in advance. Yours Sincerely Ljubomir Jerinic