The GET-BITS Model of Intelligent Tutoring Systems - Semantic Scholar

The GET-BITS Model of Intelligent Tutoring Systems Vladan Devedzic University of Belgrade, FON - School of Business Administration, Jove Ilica 154, 11000 Belgrade, Yugoslavia Fax: +381-11-461221 Tel: +381-11-2371440 Email: [email protected]

Ljubomir Jerinic University of Novi Sad, Institute of Mathematics, Trg Dositeja Obradovica 4, 21000 Novi Sad, Yugoslavia Fax: +381-11- 350458 Tel: +381-11-58888 Email: [email protected]

Danijela Radovic University of Kragujevac, Technical Faculty Cacak, Svetog Save 65, 32000 Cacak, Yugoslavia Fax: +381-32-42101, Tel: +381-32-24113 Email: [email protected]

Abstract. The paper describes an object-oriented model of intelligent tutoring systems, called GET-BITS. The paper concentrates on class hierarchies and design of classes for knowledge representation in the GET-BITS model. Other models of intelligent tutoring systems used today, as well as the corresponding knowledge models, differ only to an extent. However, the design methodologies employed vary a lot, and sometimes even remain blurred for the sake of the system functionality alone. Although using a shell or an authoring tool for developing intelligent tutoring systems brings more systematic design, it can also become a limiting factor if the shell/authoring tool doesn't support a certain knowledge representation technique or design strategy that may be needed in a particular system. The GET-BITS model makes possible to develop more flexible intelligent tutoring systems and the corresponding software development environments, significantly increasing their modularity and reusability. It is based on a number of design patterns and class libraries developed in order to support building of intelligent systems. Important parts of any ITS design process, like domain knowledge, pedagogical knowledge, student model, and explanation strategies are all covered in the GET-BITS model. The advantages of the model are shown in the paper by a/ explicit discussion of several different aspects of the model, and b/ description of a GET-BITS-based intelligent tutoring system for teaching formal languages. The processes of computer-based tutoring and learning based on the GET-BITS model are much closer to human-based instruction. The model can be easily extended to cover the needs of specific tutoring systems. In addition, two extremely important issues are discussed from the GET-BITS perspective: the issue of ontologies in the area of intelligent tutoring systems, and the issue of software components in that area. Keywords. Intelligent tutoring systems, Knowledge representation for instruction, Principles and tools for instructional design, Object-oriented design, Software components, Ontologies.

1. Introduction Traditional Intelligent Tutoring Systems (ITSs) are concentrated on the domain knowledge they are supposed to present and teach, hence their control mechanisms are often domaindependent (Anderson et al., 1990), (Lajoie and Derry, 1993), (Wenger, 1987), (Woolf, 1992). 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 (Ikeda and Mizoguchi, 1994), (Murray, 1997), (Shute, 1995), (Van Joolingen, 1997), (Vassileva, 1990). The mainstream of current research in the field is dominated by issues like collaborative learning (Suthers and Jones, 1997), Web-based teaching and learning (Brusilovsky et al., 1997), (Stern and Woolf, 1998), pedagogical agents (Johnson, 1998), and the like. However, some general issues always remain interesting and important. One of them is the issue of modeling ITSs. It is always the basis for design and development of practical ITSs. We developed a new model of ITSs using object-oriented approach. It is called GET-BITS (GEneric Tools for Building ITSs), and is essentially a specific extension of a more general, recently developed model of intelligent systems, called OBOA, which stands for OBjectOriented Abstraction (Devedzic and Radovic, 1999). In this paper we present the essentials of the GET-BITS model from ITS design and development perspective. The paper is organized as follows. Section 2 defines the problem more precisely. Section 3 briefly covers the OBOA model from which the GET-BITS model has come out. The main ideas of the GET-BITS model are described in Section 4. In Section 5, we show how this model of ITSs is used in developing a practical ITS. The final two Section state the advantages of the GET-BITS model, as well as the possibilities for its further development.

2. Problem statement Different models of ITSs, used as the basis of today's systems, still have much in common regarding the system architecture and design (see, for example, (Anderson et al., 1990), (Ikeda and Mizoguchi, 1994), (Lajoie and Derry, 1993), (Shute, 1995), (Wong et al., 1996)). On the other hand, there is much more difference regarding ITS design methodologies. A carefully chosen design methodology usually results in significant improvement of the system performance, reduces development time, and facilitates maintenance. In that sense, it is important to specify the design methodology as explicitly as possible. Starting from a general, object-oriented model of intelligent systems (in this case, the OBOA model), it is possible to derive the model of any more specific kind of intelligent systems. In that sense, this paper describes: 1. how the GET-BITS model is derived as a specific extension of the OBOA model; 2. design of some important classes and class diagrams for knowledge representation in ITSs according to the GET-BITS model, from the software engineering perspective; 3. some authoring aspects of GET-BITS; and 4. an example of how the GET-BITS model is used in developing an ITS in the domain of formal languages and automata.

3. Previous work The essence of the OBOA model is a unified abstraction of different knowledge representation techniques and different models of human knowledge (Devedzic and Radovic, 1999). 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 objectoriented 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. It is always possible to define a suitable hierarchy of knowledge types needed in a particular system and design a corresponding class diagram starting from K_element, as the most abstract class, in the root. A suitable analogy of the K_element hierarchy of knowledge types can be found in the domain of programming languages. The Smalltalk and Java languages define the most abstract Object class in the root of their class hierarchies, and all the other classes are derived directly or indirectly from the Object class (Arnold and Gosling, 1996).

As an example, Figure 1 illustrates some meaningful subclasses that can be derived directly from K_element regarding domain knowledge representation. 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 various intelligent systems. In all such cases, additional subclasses can be derived either directly from K_element, or from another class in its class hierarchy. 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 GET-BITS model 4.1.

Key ideas

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. Some control objects are alsoo needed 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.

Concept Explanation

K_element

...

Rule

Explanation

Frame

Goal

HardLesson Lesson

...

Topic

EasyLesson TQ FirstLesson LastLesson

BasicTopic Task DerivedTopic

Multidisciplinary Topic

System Explanation

Question

EndUser Explanation Developer Explanation TQ Explanation

...

Figure 2. Important classes for knowledge representation in ITSs

Some important classes specified in GET-BITS for representing various kinds knowledge in ITSs are illustrated in Figure 2. Obviously, many key classes are derived from the Frame class: • Lesson and Topic - lessons and topics the user learns • PQ - an abstract class used to derive the classes representing questions the student has to answer, 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. Important classes for design and development of object-oriented ITSs include those for knowledge representation, for specifying control objects, and for representing ITS-specific concepts (e.g., student models and pedagogical strategies). Once all of such classes are implemented within a class library in a generic form, it is a straightforward task to use them for designing and implementing an ITS development shell or an authoring tool. That is the main practical goal of GET-BITS: letting ITS 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 systems and making them more reusable.

4.2.

Semantics and hierarchies

The GET-BITS model defines five levels of abstraction for designing ITSs, Figure 3a. If necessary, it is also possible to define fine-grained sublevels at each level of abstraction. Each level has associated concepts, operations, knowledge representation techniques, inference methods, knowledge acquisition tools and techniques, and development tools. They are all considered as dimensions along which the levels can be analyzed, Figure 3b. The concepts of the levels of abstraction and dimensions have been derived starting from the wellknown idea of orthogonal software architecture from the field of software engineering (Rajlich and Silva, 1996).

Level of abstraction

Level of abstraction

Objective

Level 1

Integration

Multiple agents or systems

Level 1

Level 2

System

Single agent or system

Level 2

Level 3

Blocks

System building blocks

Level 3

Level 4

Units

Units of blocks

Level 4

Level 5

Primitives

Parts of units

Level 5

Semantics

(a)

Dimensions D1 D2 . . . Dn

(b)

Figure 3. The GET-BITS model: (a) The levels of abstraction (b) Dimensions

Semantics of the levels of abstractions is easy to understand. In designing an ITS, there are primitives, which are used to compose units, which in turn are parts of blocks. Blocks themselves are used to build self-contained agents or systems, which can be further integrated into more complex systems. For getting a feeling for how the GET-BITS' levels of abstraction correspond to some well-known concepts from the ITS domain, consider the following examples. Primitives like plain text, logical expressions, attributes and numerical values are used to compose units like rules, frames, and different utility functions. These are then used as parts of certain building blocks that exist in every ITS, e.g. topics, lessons and teaching strategies. At the system level, we have self-contained systems or agents like explanation planners, student modeling agents, and learning actors, all composed using different building blocks. Finally, at the integration level there are collaborative learning systems, distributed learning environments, and Web-based tutoring systems. It should be also noted that the borders between any two adjacent levels are not strict; they are rather approximate and "fuzzy". For example, a single ITS can be put at the system level, as a self-contained system. However, there are equally valid arguments for putting it at the

integration level, since it integrates domain knowledge, a student model, and a pedagogical module. These three modules can be developed by different tools and made to interact at a higher level, as in (Murray, 1997) and (Shute, 1995). Several other concepts can be also treated at different levels of abstraction. The concepts, operations, methods, etc. at each level of abstraction can be directly mapped onto sets of corresponding components and tools used in ITS design. Table 1 shows some of these components and tools identified in the GET-BITS model, classified according to their corresponding level of abstraction and role in the ITS architecture. Level of abstraction 1 - Integration

Role

Components and tools

Domain knowledge Pedagogical knowledge

Curriculum composers, ontology editors Communities of pedagogical agents, theories of instruction Explanation composing tools for distributed learning environments Multiple student models, group models, cooperative student models, shared student models Curriculum, pedagogical structure of the domain Pedagogical agents, teaching planners, learning actors, learning companions, troublemakers Explanation planners, simulators, hint generators, example generators Student modeling agents and tools Lesson, topic, objective, pedagogical point, goal, plan, question, exercise, quiz Teaching and learning strategies, hints, errors Explanations (explanations of the knowledge elements, explanations of the learning process, explanations of the teaching strategies), examples, simulations Overlay, enumerative, reconstructive, generative Rule, frame, picture Problem/question templates, quiz templates, result checkers Explanation templates, explanation presentation functions State, operator, transition, problem space, path, temporal belief, misconception, conflict detector Slot, logical expression, clause Exercise/problem difficulty, example suitability Canned text, explanation criterion (what element to include in the explanation and what to skip), explanation detail (degree of details in the explanation), explanation type State parameters, state transition codes, learning speed, knowledge level, current progress, level of concentration, level of performance, student's capacity

Explanation Student model

2 - System

Domain knowledge Pedagogical knowledge

Explanation Student model Domain knowledge

3 - Blocks

Pedagogical knowledge Explanation

Student model 4 - Units

Domain knowledge Pedagogical knowledge Explanation Student model

5 - Primitives

Domain knowledge Pedagogical knowledge Explanation

Student model

Table 1. The GET-BITS model: some components and tools for ITS design

The complexity and the number of these components and tools grow from the lower levels to the higher ones. Consequently, it is quite reasonable to expect further horizontal and vertical subdivisions at higher levels of abstraction in practical applications of the GET-BITS model for ITS design and development. Appropriate identification of such subdivisions for some particular issues of ITS design, such as collaborative learning and pedagogical agents, is the topic of our current research (Devedzic, 1998). From the software design point of view, components and tools in Table 1 can be considered as classes of objects. It is easy to derive more specific classes from them in order to tune them to a particular application. The classes are designed in such a way that their semantics is defined horizontally by the corresponding level of abstraction and its sublevels (if any), and vertically by the appropriate key abstractions specified mostly along the concepts and knowledge representation dimensions. Class interface functions and method procedures are defined mostly from the operations and inference methods dimensions at each level. The knowledge acquisition and development tools dimensions are used to specify additional classes and methods at each level used for important ITS development tasks of knowledge elicitation, learning, and knowledge management. At each level of abstraction, any class is defined using only the classes from that level and the lower ones. For example, the Lesson class at level 3 in Table 1 is defined using the Topic, Objective, Pedagogical point, Goal, Plan, Question, Exercise, and Quiz classes, as well as primitive data types, such as strings and numbers.

4.3.

Design details

In order to illustrate some important details from the GET-BITS model regarding knowledge representation techniques, we show how some types of knowledge elements are designed. One of the key types of knowledge elements is the one for representing the lessons that students have to learn in a certain domain. It is assumed that each lesson is composed of several topics that the student must understand and adopt. Attributes of each lesson include its title, the topic being taught at a given moment (CurrentTopic), the current goal of the learning that has to be achieved according to a certain tutoring strategy (CurrentGoal), the student's prerequisite knowledge (StudentLevel), etc. They are all included in the Lesson class, which is designed as in Figure 4 (less important details are omitted). Name: Lesson Visibility: Exported ; visible outside the enclosing class category Cardinality: n ; there can be more than one such object Base class: Frame ; in general, a list of base classes Derived classes: ; in general, a list of derived classes Interface Operations: SetTopic, GetTopic, UpdateTopic, DeleteTopic, CreateTopicCollection, GetTopicCollection,... Implementation Uses: Topic, Goal,... ; in general, a list of classes, used by this one Fields: Title, CurrentTopic, CurrentGoal, StudentLevel, TopicCollection_Ptr [ ],... Persistency: Static ; disk files Figure 4. Design of the Lesson class

Another important type of knowledge is explanations generated by the system or required from the user. GET-BITS differs between several kinds of explanations (those presented to endusers - EndUserExplanation, those presented to ITS developers - DeveloperExplanation, those required from students when checking their knowledge - StudentExplanation, those concerned with explaining the system's functioning - SystemExplanation, those explaining various concepts or topics - ConceptExplanation and TopicExplanation, etc.). In generating explanations, a GET-BITS-based ITS can use knowledge from various kinds of knowledge elements (rules, frames, knowledge chunks, etc.). The corresponding Explanation class is designed as in Figure 5. Name: Visibility: Cardinality: Base class:

Explanation Exported n Frame

; visible outside the enclosing class category ; there can be more than one such object ; in general, a list of base classes

Derived classes: Interface Operations: Implementation Uses: Fields: Persistency:

EndUserExplanation, DeveloperExplanation, StudentExplanation, SystemExplanation, PQExplanation, TopicExplanation,...

SetExplanation, GetExplanation, UpdateExplanation, DeleteExplanation,... Rule, Frame, K_chunk, Goal, Topic,... CannedText, TopicCollection_Ptr [ ], RuleCollection_Ptr [ ],... Static/Dynamic ; disk files for some parts only Figure 5. Design of the Explanation class

Heuristic rules are derived directly from K_element. There are a number of more specific classes that can be derived from the Rule class (e.g., RuleCf, for representing rules with certainty factors). Figure 6 shows the design of the Rule class. Name: Visibility: Cardinality: Base class: Derived classes: Interface Operations: Implementation Uses: Fields: Persistency:

Rule Exported ; visible outside the enclosing class category n ; there can be more than one such object K_element ; in general, a list of base classes RuleCf, FuzzyRule, ActionRule,... SetRule, GetRule, UpdateRule, DeleteRule, CreateRuleCollection, GetRuleCollection, AttachRuleToFrame,... K_chunk ; for If-clauses and Then-clauses RuleName, IfPart, ThenPart Static ; disk files Figure 6. Design of the Rule class

4.4.

Using design patterns

Design patterns are descriptions of successful solutions of common problems that occur in software design over and over again when producing applications in a particular context (Gamma et al., 1994). It is important to understand that design patterns are not invented. They are discovered from experience in building practical systems. There are catalogues of design patterns, in which all of the patterns are described using some prescribed template. In GET-BITS, we have made an attempt to bring more light on this important concept and to describe the benefits that design patterns can bring to the field of AIED. Using design patterns increases efficiency to the design process when building intelligent tutoring systems. Furthermore, design patterns make intelligent tutoring systems more reusable, more flexible, and more robust. We have used a number of well-known design patterns when developing the class libraries that support building of GET-BITS-based ITSs. As an example, consider how our explanation generator is designed, Figure 7. It lets us generate explanations for students having different previous knowledge of a certain topic. Novice students should get more general and easy explanations, while the ITS should generate more complex and detailed explanations to more advanced students. The problem is that the number of possible explanations of the same topic or process is open-ended. It should be anticipated that during the system maintenance another set of knowledge levels can be introduced in order to describe the student model more accurately. The explanation generator should not be modified each time another set of knowledge levels is introduced. On the contrary, it should be easy to add a new knowledge level easily. Using the Builder pattern (Gamma et al., 1994) provides a solution: the explanation generator can be configured with a ExplanationBuilder, an object that converts a specific knowledge level from the student model to an appropriate type of explanation. Figure 7 illustrates this idea. Whenever the student requires an explanation, the explanation generator passes the request to the ExplanationBuilder object according to the student's knowledge level. Specialized explanation builders, like EasyExplanationBuilder or AdvancedExplanationBuilder, are responsible for carrying out the request. Note that their concrete implementations of the functions like CreateText and CreateGraphics provide polymorphism in generating explanations.

Generator

builder

Construct ( )

If knowledge level = novice Then build explanation for novices Else build explanation for advanced students

ExplanationBuilder

builder

CreateText ( ) CreateGraphics ( )

EasyExplanationBuilder CreateText ( ) CreateGraphics ( ) CreateSound ( ) Explanation for Novices

AdvancedExplanationBuilder CreateText ( ) CreateGraphics ( ) Explanation for Advanced Students

Figure 7 - Using the Builder pattern in designing explanation generator

What is the pattern here? The key to the answer is to realize that the Builder pattern can be used in ITS design in several different components, not only in the explanation generator. For example, when the student is solving problems put by the system, the GET-BITS hint generator may decide to generate some useful hints and show them to the student. This can be done in much the same way as giving explanations to the student. The GET-BITS exercise generator also can construct exercises for a predefined set of users, which is configurable (e.g., beginners, midlevel, advanced, and experts). The internal structure of all such generators looks much like the one in Figure 7, and is reused from the general Builder pattern.

4.5.

Authoring aspects

There are two broad categories of integrated software tools for development of ITSs: ITS development shells and authoring tools. ITS development shells are integrated software environments that support development of ITSs but are usually low-level tools, in the sense that they require software design specialists in order to use the shell when developing practical systems. The role of the specialists is to make possible to adapt the capabilities and the options offered by the shell to the particular project. On the other hand, an authoring tool lets its users define, design and create lessons and curricula of ITSs in a graphical environment, using various widgets and other tools for instructional design. The intended users authoring tools are teachers, educators and instructional experts, not programmers. Authoring tools are usually domain independent, and include mechanisms for representing domain knowledge and control information, thus generating a particular ITS. These mechanisms are responsible for dynamically customizing the machine's responses. Using an ITS development shell or an authoring tool for developing ITSs brings more systematic design than developing ITSs from scratch (Johnson, 1990), (Kong, 1994), (Mizoguchi and Ikeda, 1996), (Vassileva, 1990). However, it can also become a limiting factor if the shell or the authoring tool doesn't support a certain knowledge representation technique or design strategy that may be needed in a particular ITS. Also, these tools often have a number of options which are seldom or never actually used in developing practical systems. In developing GET-BITS, we have tried to reduce the above mentioned deficiences of using ITS shells and authoring tools. Designing and developing an ITS based on the GET-BITS model is a matter of developing an ITS development environment first, and then using it for building the ITS itself. In spite of the fact that this means starting the project without a shell/authoring tool, it is a relatively easy design and development process, because of the strong software engineering support of the class libraries and design patterns. Once the core functionality of ITS shells/authoring tools is assembled from the existing components into an integrated development environment, the authoring process can begin. The core functionality always includes interface tools for extending the initial set of knowledge representation techniques in the authoring phase. This approach does require a software design specialist, but only in the initial phase, before the core development environment is created from the set of existing lower-level components. Although at the first glance it may seem better to have the core development environment already available before the new project starts, the problem is that there is still no consensus on what exactly the core functionality should include. Also, our experience shows that instructors usually have quite different ideas of what tools they would like to have in the

authoring phase. This is true even for different specialists in a single application domain. Therefore, the GET-BITS approach prefers potential authors to specify the initial set of requirements themselves. The core functionality of the development environment is then developed starting from their requirements and the set of lower-level components and tools. Our current research includes efforts towards specification of the core functionality for some application domains. On the other hand, the benefits of such an approach are increased flexibility and reduced complexity of the ITS development environment. The lower-level tools are designed in a generic form, in order to allow for rapid adaptation to a wide spectrum of initial requests. Then the development environment might grow during the authoring phase, but only to include the new things that the author wants to include.

4.6.

Software components and ontologies for ITSs

The concept of software components has been largely used in the area of software engineering during the last decade (see, for example, (Szyperski, 1998)). However, it is only since recently that it draws significant attention in the community of researchers working in the area of ITSs (see, for example, (Koedinger et al., 1998) and (Ritter et al., 1998)). One of the goals of the GET-BITS model is to support design of component-based ITSs. An elaborated discussion of how software components are treated in GET-BITS is presented in (Devedzic et al., 1998). A brief overview of it is given here. Informally, a component is a piece of a larger system that can be put in, taken out, and used together with other components to contribute to the global system's behaviour. Componentbased software design enables designing systems from application elements (components) that were built independently by different developers using different languages, tools, and computing platforms. In other words, such a design process is based on the assembly of pretested, reusable, interoperable, independent software components. It lets ITS designers assemble the systems that use only the tools and options that are really needed in the systems they develop. This is quite different from using traditional ITS shells and authoring tools, which offer numerous options that can be completely useless in a particular application. Moreover, once a sufficient number of software components are developed, the components can be put into a repository and catalogued. The repository could then be easily accessed from another site, enlarged by newly developed components, and updated by new versions of already existing components. Due to the interoperability of components, ITS developers could use the repository for building practical systems on a variety of existing hardware platforms. The choice of the operating system and programming language is also up to the developer. Although repositories of software components for building ITSs are not widely available at the moment, in GET-BITS we have identified a number of generic components that are useful for developing a range of practical ITSs. Some of them are shown in Table 2. Note that they only roughly correspond to some items listed in Table 1, since a given class of objects does not necessarily evolve into a software component. In the context of GET-BITS, we haven't considered components for ITS user interfaces yet. Domain knowledge components Lesson Topic Exercise Question Goal

Pedagogical components Teaching strategy Teaching operator Teaching planner Path selector Model of task difficulty

Explanation components Explanation Example Simulation Hint generator Template

Student model components Motivation Concentration Capacity Misconception Current knowledge

Table 2 - Partial lists of software components for ITSs (by ITS modules) in the GET-BITS model

Two important facts come from the above discussion: • specification of components for ITSs must be preceded by an agreement on a common vocabulary in the domain; • components must be organized around a certain taxonomy. These facts bring us to the important question on the relation between components and ontologies. In our view, there is a significant commonality between these two concepts, although they are not the same. Questions that must be answered precisely are: 1. What is the correspondence between components and ontologies?

2. Can ontologies be components and vice versa? As for the first question, both components and ontologies require common vocabulary and a certain organizational structure. On the other hand, ontologies are conceptually more abstract, in the sense that they define abstract concepts and relations between them in a problem domain, such as ITS. Components are more "down on Earth" things, being real software implementations of concepts and their functionalities at a certain level of abstraction and at a certain place in the overall software architecture. In GET-BITS, ontologies are, in a sense, a basis for component development since it is ontologies that define a certain conceptual relationship between components, i.e. the kind of relations and communication between software components (Radovic et al., 1998). For similar research ideas, see also (Chen et al., 1998), (Ikeda et al., 1997), (Mizoguchi et al., 1995), (Mizoguchi et al., 1996), (Suthers and Jones, 1997). The second question, in our opinion, requires more elaboration. As for now, it looks more or less obvious that components can be parts of ontologies. This is the only way the relation between components and ontologies has been treated in GET-BITS so far (Radovic et al., 1998). Ontologies are formalized structures (e.g., hierarchies and grids), and usually nodes or intersections of such structures represent concepts that can have more or less precisely defined functionalities in terms of the vocabulary of the problem domain. It is also possible to develop a component that fully corresponds to a certain ontology. For example, in the Eon system (Murray, 1997), there are "ontology objects". They are data objects, each of which defines a conceptual vocabulary for a part of the system. Topic Ontology objects are concrete examples of ontology objects for which corresponding software components can be developed. We also envision development of other software components corresponding to certain ontologies as a whole. In the context of GET-BITS, our efforts in this sense are just initiated towards development of the Student Model ontology (Radovic and Devedzic, 1998). It should be also noted that our experience shows that at a certain level of abstraction components need not necessarily fully correspond to ontologies or parts of ontologies. There are components shared by different domains and different ontologies.

5. Application The GET-BITS model has been used as the basis for development of FLUTE, an ITS in the domain of formal languages and automata. FLUTE is briefly described here in order to illustrate how GET-BITS supports practical design and development of ITSs. The idea of the FLUTE project is to develop software that facilitates systematic introduction of students into the system's domain, in accordance with both the logical structure of the domain and individual background knowledge and learning capabilities of each student. The system is discussed here only from the GET-BITS perspective. It is described in detail elsewhere (Devedzic and Debenham, 1998). The architecture of the FLUTE system is shown in Figure 8. The Expert module contains all of the domain-dependent knowledge: 1. the concepts, topics, facts and domain heuristics the student has to learn; 2. a database of examples used to illustrate the domain concepts, topics, etc.; and 3. the pedagogical structure of the domain. The pedagogical structure of the domain is considered a part of the domain knowledge rather than a part of the pedagogical module, as well as in (Vassileva, 1990). In FLUTE, pedagogical structure of the domain is defined as a set of directed graphs showing explicitly precedence relationships of knowledge units within each lesson and among the topics of different lessons. FLUTE always operates in one of the following three modes of operation: teaching, examination, and consulting. It is actually the Pedagogical module from Figure 8 that operates in one of these three modes. FLUTE's Explanation module tightly cooperates with the Pedagogical module in the consulting mode, in order to answer the student's questions and provide desired explanations (Jerinic and Devedzic, 1997). Student model in FLUTE is an object of a class derived from the corresponding GET-BITS class.

Expert module Concepts, facts, and heuristics

Pedagogical structure

Examples

Explanation module

Student model

Pedagogical module

User interface

Student Figure 8. Architecture of the FLUTE system

In order to develop FLUTE, we have used the class libraries that support the GET-BITS model and have developed an ITS development environment. In the beginning, some classes necessary for knowledge representation in FLUTE (and hence in the development environment as well) have been missing. Most of them could have been created in the authoring phase as well. However, the initial analysis of requirements for the core development environment has shown that they may be useful in development of some other ITSs as well. Therefore, we have developed the missing classes during the process of assembling the core development environment, starting from the existing ones and from the overall hierarchy presented in Figure 3. The newly developed classes have been added into the existing class libraries. The following example illustrates this process. A lesson in FLUTE is a meaningful subset of concepts, topics, facts and domain heuristics. These items in a lesson are closely coupled but they can refer to items in other lessons. Some important attributes of each FLUTE's lesson are sets of objectives and goals, sets of topics, concepts, facts, theorems, etc. taught in that lesson, a set of the corresponding teaching rules, and a set of associated problems (tests, questions and exercises). The Lesson class, as it is specified in GET-BITS and included in the current version of the supporting class libraries, supports most of the above attributes. However, from the requirements for the core development environment, based on the structure of the domain knowledge to be implemented in FLUTE, it turned out that many lessons could be better organized if the Lesson class had some additional features. Therefore a new class, T-Lesson, has been designed and built into the core development environment. The T-Lesson class supports using theorems in presenting a lesson and fine-tuning the presentation by showing/hiding theorem proofs, lemmas and corollaries (this is controlled by dedicated Boolean flags). It is shown in Figure 9. Name: ... Base class: Derived classes: Interface

T-Lesson Lesson -

Operations:

SetTheorem, GetTheorem, DeleteTheorem, CreateTheoremCollection, GetTheoremCollection, ..., SetSkipProofs_Flag, SetSkipLC_Flag

Implementation Uses: Theorem Fields: SkipProofs_Flag, SkipLC_Flag Persistency: Static ; disk files Figure 9. Design of the T-Lesson class

This example simultaneously illustrates how computer-based tutoring and learning based on the GET-BITS model can be easily adapted to closely reflect the way human-based instruction is done in a given domain and given the student's background knowledge and goals. It is possible to control the setting of SkipProofs_Flag and SkipLC_Flag from the rules of the Pedagogical module. Among the other conditions and heuristics, pedagogical rules use the values of the relevant attributes of the student model in order to adapt the lesson presentation to each individual user.

6. Discussion The previous example shows that potential design flexibility is an important advantage of using the GET-BITS model (along with the high modularity and reusability provided by the class libraries). Development of the core ITS building environment means putting together only those pieces of software from the class libraries that are really needed for a given application. Extending the class libraries to include some new functionality that may be needed in the core environment does require additional design and programming efforts, but it is a straightforward process. The class hierarchies and design patterns of GET-BITS provide a firm ground to start from in such an additional development. As with the OBOA model, most additional subclasses can be derived directly from some of the already existing classes - there is already quite enough generic classes in the libraries. The classes of the GET-BITS model are designed in such a way to specify "concept families" using the least commitment principle: each class specifies only the minimum of attributes and inheritance links. That assures the minimum of constraints for designers of new classes. It is assumed that each new class for knowledge representation used in the development of a specific ITS (no matter in which module) will be designed starting from a certain concept family of the class hierarchies represented in Figures 1 and 2. This is not a tight constraint either, since many concept families in the GET-BITS' supporting class libraries are already well elaborated. For example, several dedicated subclasses are derived from the Rule class in order to support specific attributes of rules needed in different modules of ITSs (e.g., domain rules and pedagogical rules have slightly different attributes).

7. Conclusions The GET-BITS model of intelligent tutoring systems, presented in the paper, allows for easy and natural conceptualization and design of a wide range of ITS applications, due to its objectoriented approach. It suggests only general guidelines for developing ITSs, and is open for fine-tuning and adaptation to particular applications. ITSs developed using this model are easy to maintain and extend, and are much more reusable than other similar systems and tools. The model is particularly suitable for use by ITS shell developers. Starting from a library of classes for knowledge representation and control needed in the majority of ITSs, it is a straightforward task to design additional classes needed for a particular shell. Moreover, the model also supports development of component-based ITSs, which have started to attract increasing attention among the researchers in the field. Further development of the GET-BITS model is concentrated on development of appropriate classes in order to support a number of different pedagogical strategies. The idea is that the student can have the possibility to select the teaching strategy from a predefined palette, thus adapting the ITS to his/her own learning preferences. Such a possibility would enable experimentation with different teaching strategies and their empirical evaluation. Another objective of further research and development of GET-BITS is support for different didactic tools that are often used in teaching.

Putting further development of the GET-BITS model in a wider context, it should be noted that there are several remaining open questions that need to be investigated in more details. One of the most important is the question of the contents of components for ITS design. It is tightly coupled with the development of ontologies for different aspects of ITSs. In spite of considerable research efforts in that area, many elaborated and practical solutions are still to come. Another interesting open question concerns the relationship between software components and ontologies, which still needs to be precisely defined.

8. References 1. Anderson, J.R., Boyle, C.F., Corbett, A.T., & Lewis, M.W. (1990). Cognitive modelling and intelligent tutoring. Artificial Intelligence, 42 (1), 7-49. 2. Arnold, K., & Gosling, J. (1996). The Java programming language. Reading, MA: AddisonWesley. 3. Brusilovsky, P., Ritter, S., & Schwarz, E. (1997). Distributed intelligent tutoring on the Web. In B. du Boulay and R. Mizoguchi (Eds.), Artificial Intelligence in Education (pp. 482489). Amsterdam: IOS Press / Tokyo: OHM Ohmsha. 4. Chen, W., Hayashi, Y., Kin, L., Ikeda, M., & Mizoguchi, R. (1998). Ontological issues on an intelligent authoring tool. In Proceedings of the ECAI'98 workshop on model-based reasoning for intelligent education environments (pp. 138-148). Brighton, England. 5. Devedzic, V. (1998). Components of pedagogical knowledge. In Proceedings of the Fourth World Congress on Expert Systems, WCES4 (Vol.2, pp. 715-722). Mexico City, Mexico. 6. Devedzic, V., Radovic, D., & Jerinic, Lj. (1998). On the notion of components for intelligent tutoring systems. In B.R. Goettl, H.M. Halff, C.L. Redfield and V.J. Shute (Eds.), Lecture Notes in Computer Science, 1452 (pp. 504-513). New York: Springer-Verlag. 7. Devedzic, V., & Debenham, J. (1998) An intelligent tutoring system for teaching formal languages. In B.R. Goettl, H.M. Halff, C.L. Redfield and V.J. Shute (Eds.), Lecture Notes in Computer Science, 1452 (pp. 514-523). New York: Springer-Verlag. 8. Devedzic, V., Radovic, D. (1999). A framework for building intelligent manufacturing systems", IEEE Transactions on Systems, Man, and Cybernetics (to appear in 1999). 9. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns: Elements of reusable object-oriented software. Reading, MA: Addison-Wesley. 10. Ikeda, M., & Mizoguchi, R. (1994). FITS: A framework for ITS - A computational model of tutoring. Journal of Artificial Intelligence in Education, 5 (3), 319-348. 11. Ikeda, M., Kazuhisa, S., & Mizoguchi, R. (1997). Task ontology makes it easier to use authoring tools. In Proceedings of The Fifteenth International Joint Conference on Artificial Intelligence (pp. 23-29). Nagoya, Japan. 12. Jerinic, Lj., & Devedzic, V. (1997). OBOA model of explanation in an intelligent tutoring shell. ACM SIGCSE Bulletin 29 (3), 133-135. 13. Johnson, W.L. (1998). Pedagogical agents. Invited paper in Proceedings of The ICCE'98 International Conference on Computers in Education, Vol.1 (pp. 11-20). Beijing, China. 14. Johnson, W.L. (1990). Understanding and debugging novice programs. Artificial Intelligence 42 (1), 51-97. 15. Koedinger, K.R., Suthers, D.D., & Forbus, K.D. (1998). Component-based construction of a science learning space. In B.R. Goettl, H.M. Halff, C.L. Redfield and V.J. Shute (Eds.), Lecture Notes in Computer Science, 1452 (pp. 166-175). New York: Springer-Verlag. 16. Kong, H.P. (1994). An intelligent, multimedia-supported instructional system. Expert Systems with Applications, 7 (3), 451-465. 17. Lajoie, S., & Derry, S. (Eds.) (1993). Computers as cognitive tools. Hillsdale, NJ: Lawrence Erlbaum Associates. 18. Mizoguchi, R., & Ikeda, M. (1996). Towards ontology engineering (Technical Report No. AI-TR-96-1). Osaka University: ISIR. 19. Mizoguchi, R., Sinitsa, K., & Ikeda, M. (1996). Task ontology design for intelligent educational/training systems. In Proceedings of the Workshop "Architectures and Methods for Designing Cost-Effective and Reusable ITSs". Montreal, Canada. 20. Mizoguchi, R., Sinitsa, K., & Ikeda, M. (1996). Knowledge engineering of educational systems for authoring system design - preliminary results of task ontology design. In Proceedings of The European Conference on Artificial Intelligence in Education. isbon, Portugal.

21. Mizoguchi, R., Tijerino, Y., & Ikeda, M. (1995). Task analysis interview based on task ontology. Expert Systems with Applications 9 (1), 15-25. 22. Murray, T. (1997). Authoring knowledge based tutors: Tools for content, instructional strategy, student model, and interface design. Submitted to the Journal of the Learning Sciences. Also available from: http:// www.cs.umass.edu/~tmurray/ 23. Murray, T. (1996). Toward a conceptual vocabulary for intelligent tutoring systems. Working paper available at http://www.cs.umass.edu/~tmurray/papers.html 24. Radovic, D., Devedzic, V., & Jerinic, Lj. (1998). Component-based student modeling. In Proceedings of the Workshop on Current Trends and Applications of Artificial Intelligence in Education (pp. 73-82). Mexico City, Mexico. 25. Radovic, D., & Devedzic, V. (1998). Towards reusable ontologies in intelligent tutoring systems. In Proceedings of the CONTI'98 Conference (pp. 123-130). Timisoara, Romania. 26. Rajlich, V., & Silva, J.H. (1996). Evolution and reuse of orthogonal architecture. IEEE Transactions on Software Engineering 22 (2), 153-157. 27. Ritter, S., Brusilovsky, P., & Medvedeva, O. (1998). Creating more versatile intelligent learning environments with a component-based architecture. In B.R. Goettl, H.M. Halff, C.L. Redfield and V.J. Shute (Eds.), Lecture Notes in Computer Science, 1452 (pp. 554563). New York: Springer-Verlag. 28. Shute, V. (1995). SMART: Student Modeling Approach for Responsive Tutoring. User Modeling and User-Adapted Interaction 5 (1), 1-44. 29. Stern, M.K., & Woolf, B.P. (1998). Curriculum sequencing in a Web-based tutor. In B.R. Goettl, H.M. Halff, C.L. Redfield and V.J. Shute (Eds.), Lecture Notes in Computer Science, 1452 (pp. 574-583). New York: Springer-Verlag. 30. Suthers, D., & Jones, D. (1997). An architecture for intelligent collaborative educational systems. In B. du Boulay and R. Mizoguchi (Eds.), Artificial Intelligence in Education (pp. 55-62). Amsterdam: IOS Press / Tokyo: OHM Ohmsha. 31. Szyperski, C. (1998). Component software: Beyond object-oriented programming. Reading, MA: Addison-Wesley. 32. Van Joolingen, W., King, S., & De Jong, T. (1997). The SimQuest authoring system for simulation-based discovery learning. In B. du Boulay and R. Mizoguchi (Eds.), Artificial Intelligence in Education (pp. 79-86). Amsterdam: IOS Press / Tokyo: OHM Ohmsha. 33. Vassileva, J. (1990). An architecture and methodology for creating a domain-independent, plan-based intelligent tutoring system. Educational and Training Technology International 27 (4), 386-397. 34. Wenger, E. (1987). Artificial intelligence and tutoring systems: Computational approaches to the communication of knowledge. Los Altos, CA: Morgan/Kaufmann Publishing Co. 35. Wong, L.-H., Looi, C.-K., & Quek, H.-C. (1996). Design of an ITS for inquiry teaching. In Proceedings of The Third World Congress on Expert Systems (pp. 1263-1270). Seoul, Korea. 36. Woolf, B.P. (1992). AI in education. In Encyclopedia of Artificial Intelligence (2nd ed.) (pp. 434-444). New York: John Wiley & Sons.