The GET-BITS Model of Intelligent Tutoring Systems.

This article describes an object-oriented model of intelligent tutoring systems (ITS), called GET-BITS. The article 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 it 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 n umber 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 article 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.

ITSs are concentrated on the domain knowledge they are supposed to present and teach. Hence, their control mechanisms are often domain-dependent (Anderson, Boyle, Corbett, & Lewis, 1990; Lajoie & 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 & Mizoguchi, 1994; Murray, 1997; Shute, 1995; Van Joolingen, King, & DeJong, 1997; Vassileva, 1990). The mainstream of current research in the field is dominated by issues such as collaborative learning (Suthers & Jones, 1997), web-based teaching and learning (Brusilovsky, Ritter, & Schwartz, 1997; Stern & Woolf, 1998), and pedagogical agents (Johnson, 1998).

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 GEneric Tools for Building ITSs (GET-BITS), and is essentially a specific extension of a more general, recently developed model of intelligent systems, called OBject-Oriented Abstraction (OBOA), (Devedzic & Radovic, 1999).

In this article, we present the essentials of the GET-BITS model from an ITS design and development perspective. This article is organized into five parts as follows. (a) the problem is defined more precisely, (b) the OBOA model from which the GET-BITS model has come out is discussed, (c) the main ideas of the GET-BITS model are described, (d) we show how this model of ITSs is used in developing a practical ITS, and (e) we state the advantages of the GET-BITS model, as well as the possibilities for its further development.

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 (Anderson et al., 1990), (Ikeda & Mizoguchi, 1994), (Lajoie & Derry, 1993), (Shute, 1995), (Wong, Looi, & Quek, 1996). On the other hand, there are many more differences 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.

4. An example of how the GET-BITS model is used in developing an ITS in the domain of formal languages and automata.

PREVIOUS WORK

The essence of the OBOA model is a unified abstraction of different knowledge representation techniques and different models of human knowledge (Devedzic & 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 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 such as production rules, frames, semantic networks, and so forth, as well as problem solving strategies (e.g., 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.

THE GET-BITS MODEL

Key Ideas

Applying the principles of the OBOA model, we can define appropriate class hierarchies for developing ITSs. GET-BITS 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 also 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 the dynamics of ITSs. GET-BITS also specifies classes of these control objects.

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 students.

* 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, specifying control objects, and 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 and 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.

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 well-known idea of orthogonal software architecture from the field of software engineering (Rajlich & Silva, 1996).

Semantics of the levels of abstractions are 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 such as rules, frames, and different utility functions. These are then used as parts of certain building blocks that exist in every ITS, for example, 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, and methods 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.

The complexity and the number of these components and tools grow from the lower levels to the higher levels. 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 are 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 by using the topic, objective, pedagogical point, goal, plan, question, exercise, and quiz classes, as well as primitive data types, such as strings and numbers.

Design Details

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 type 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).

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 end-users--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, and 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.

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.

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, Helm, Johnson, & Vlissides, 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 shed 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, flexible, and robust.

We have used a number of well-known design patterns when developing the class libraries that support the 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 an 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.

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 made by the system, the GET-BITS hint generator may provide clues 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.

Authoring Aspects

There are two broad categories of integrated software tools for the development of ITSs: development shells and authoring tools. ITS development shells are integrated software environments that support the development of ITSs but are usually low-level tools. In other words, they require software design specialists to use the shell when developing practical systems. The role of the specialists is to make it 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 for 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 dyna mically 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 & 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 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 the 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.

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 (Szyperski, 1998). However, it is only recently that it draws significant attention in the community of researchers working in the area of ITSs (Koedinger, Suthers, & Forbus, 1998; Ritter, Brusilovsky, & Medvedeva, 1998). One of the goals of the GET-BITS model is to support the design of component-based ITSs. An elaborated discussion of how software components are treated in GET-BITS is presented in Devedzic, Radovic, and Jerinic (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 with other components to contribute to the global system's behaviour. Component-based 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, and 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 ne wly 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.

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 relationship 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 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, that is, the kind of relations and communication between software components (Radovic, Devedzic, & Jerinic, 1998). There are similar research ideas such as this (Chen, Hayashi, Kin, Ikeda, & Mizoguchi, 1998; Ikeda,Kazuhisa, & Mizoguchi, 1997; Mizoguchi, Tijerino, & Ikeda, 995; Mizoguchi, Sinista, & Ikeda, 1996; Suthers & 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 & 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.

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 & 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.

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 (Vassileva, 1990). In FLUTE, pedagogical structure of the domain is defined as a set of directed graphs showing, explicitly, precedent 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 to answer the student's questions and provide desired explanations (Jerinic & Devedzic, 1997). The student model in FLUTE is an object of a class derived from the corresponding GET-BITS class.

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 also be useful in development of some other ITSs. 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 to 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 lesson are sets of objectives and goals, sets of topics, concepts, facts, theorems, etc., taught in that lesson along with 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 seems 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 the use of 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.

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, 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 user.

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 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 from which to start 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 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 a 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).

CONCLUSIONS

The GET-BITS model of intelligent tutoring systems, presented in this article, allows for easy and natural conceptualization and design of a wide range of ITS applications due to its object-oriented 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 of selecting the teaching strategy from a predefined palette, thus adapting the ITS to individual 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 detail. 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.

References

Anderson, J.R., Boyle, C.F., Corbett, A.T., & Lewis, M.W. (1990). Cognitive modelling and intelligent tutoring. Artifical Intelligence, 42 (1), 7-49.

Arnold, K., & Gosling, 3. (1996). The Java programming language. Reading, MA: Addison-Wesley.

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. 482-489). Amsterdam: LOS Press/Tokyo: OHM Ohmsha.

Chen, W., Hayashi, Y., Kin, L., Ikeda, M., & Mizoguchi, R. (1998). Ontological issues on an intelligent authoring tool. Proceedings of the ECAI'98 workshop on model-based reasoning for intelligent education environments (pp. 138-148). Brighton, England.

Devedzic, V. (1998). Components of pedagogical knowledge. Proceedings of the Fourth World Congress on Expert Systems, WCES4 (Vol.2, pp. 715-722). Mexico City, Mexico.

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, & V.J. Shute (Eds.), Lecture notes in computer science, 1452 (pp. 504-513). New York: Springer-Verlag.

Devedzic, V., & Debenham, J. (1998). An intelligent tutoring system for teaching formal languages. In B.R. Goettl, H.M. Halff, C.L. Redfield, & V.J. Shute (Eds.), Lecture notes in computer science, 1452 (pp. 514-523). New York: Springer-Verlag.

Devedzic, V., & Radovic, D. (1999). A framework for building intelligent manufacturing systems," IEEE transactions on systems, man, and cybernetics (to appear in 1999).

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns. Elements of reusable object-oriented software. Reading, MA: Addison-Wesley.

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.

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.

Jerinic, Lj., & Devedzic, V. (1997). OBOA model of explanation in an intelligent tutoring shell. ACM SIGCSE Bulletin 29(3), 133-135.

Johnson, W.L. (1998). Pedagogical agents. In Proceedings of The ICCE '98 International Conference on Computers in Education, Vol.] (pp. 11-20). Beijing, China.

Johnson, W.L. (1990). Understanding and debugging novice programs. Artificial Intelligence 42(1), 51-97.

Koedinger, K.R., Suthers, D.D., & Forbus, K.D. (1998). Component-based construction of a science learning space. B.R. Goettl, H.M. Halff, C.L. Redfield, & V.J. Shute (Eds.), Lecture notes in computer science, 1452 (pp. 166-175). New York: Springer-Verlag.

Kong, H.P. (1994). An intelligent, multimedia-supported instructional system. Expert Systems with Applications, 7(3), 451-465.

Lajoie, S., & Derry, S.(Eds.)(1993). Computers as cognitive tools. Hillsdale, NJ: Lawrence Erlbaum.

Mizoguchi, R., & Ikeda, M.(1996). Towards ontology engineering (Technical Report No. AI-TR-96-1). Osaka University: ISIR.

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.

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. Lisbon, Portugal.

Mizoguchi, R., Tijerino, Y., & Ikeda, M. (1995). Task analysis interview based on task ontology. Expert Systems with Applications 9(1), 15-25.

Murray, T. (1997). Authoring knowledge based tutors: Tools for content, instructional strategy, student model, and interface design. Journal of the Learning Sciences. [Online]. Available: http://www.cs.umass.edu/[sim]tmurray/

Murray, T. (1996). Toward a conceptual vocabulary for intelligent tutoring systems. [Online]. Available: http://www.cs.umass.edu/[sim]tmurray/papers.html

Radovic, D., Devedzic, V., & Jerinic, L. (1998). Component-based student modeling. Proceedings of the Workshop on Current Trends and Applications of Artificial intelligence in Education (pp. 73-82). Mexico City, Mexico.

Radovic, D., & Devedzic, V. (1998). Towards reusable ontologies in intelligent tutoring systems. Proceedings of the CONTI'98 Conference (pp. 123-130). Timisoara, Romania.

Rajlich, V., & Silva, J.H. (1996). Evolution and reuse of orthogonal architecture. IEEE Transactions on Software Engineering 22(2), 153-157.

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, & V.J. Shute (Eds.), Lecture notes in computer science, 1452 (pp. 554-563). New York: Springer-Verlag.

Shute, V. (1995). SMART: Student modeling approach for responsive tutoring. User Modeling and User-Adapted Interaction 5(l), 1-44.

Stern, M.K., & Woolf, B.P. (1998). Curriculum sequencing in a web-based tutor. In B.R. Goettl, H.M. Halff, C.L. Redfield, & V.J. Shute (Eds.), Lecture notes in computer science, 1452 (pp. 574-583). New York: Springer-Verlag.

Suthers, D., & Jones, D. (1997). An architecture for intelligent collaborative educational systems. B. du Boulay & R. Mizoguchi (Eds.), Artificial intelligence in education (pp. 55-62). Amsterdam: IOS Press / Tokyo: OHM Ohmsha.

Szyperski, C. (1998). Component software: Beyond object-oriented programming. Reading, MA: Addison-Wesley.

Van Joolingen, W., King, S., & De Jong, T. (1997). The SimQuest authoring system for simulation-based discovery learning. B. du Boulay & R. Mizoguchi (Eds.), Artificial intelligence in education (pp. 79-86). Amsterdam: IOS Press / Tokyo: OHM Ohmsha.

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.

Wenger, E. (1987). Artificial intelligence and tutoring systems. Computational approaches to the communication of knowledge. Los Altos, CA: Morgan/Kaufmann.

Wong, L.-H., Looi, C.-K., & Quek, H.-C. (1996). Design of an ITS for inquiry teaching. Proceedings of The Third World Congress on Expert Systems (pp. 1263-1270). Seoul, Korea.

Woolf, B.P. (1992). Al in education. In Encyclopedia of Artificial intelligence (2nd ed.) (pp. 434-444). New York: John Wiley & Sons.

             The GET-BITS Model: Some Components and Tools for
                                ITS Design
Level of abstraction Role                  Components and tools
1 - Integration      Domain knowledge      Curriculum composers, ontology
                                           editors
                     Pedagogical knowledge Communities of pedagogical
                                           agents, theories of instruction
                     Explanation           Explanation composing tools for
                                           distributed learning environments
                     Student model         Multiple student models, group
                                           models, cooperative student
                                           models, shared student models
2 - System           Domain knowledge      Curriculum, pedagogical structure
                                           of the domain
                     Pedagogical knowledge Pedagogical agents, teaching
                                           planners, learning actors,
                                           learning companions, troublemakers
                     Explanation           Explanation planners, simulators,
                                           hint generators, example
                                           generators
                     Student model         Student modeling agents and
                                           tools
3 - Blocks           Domain knowledge      Lesson, topic, objective,
                                           pedagogical point, goal, plan,
                                           question, exercise, quiz
                     Pedagogical knowledge Teaching and learning strategies,
                                           hints, errors
                     Explanation           Explanations (explanations of the
                                           knowledge elements, explana
                                           tions of the learning process,
                                           explanations of the teaching
                                           strategies), examples, simulations
                     Student model         Overlay, enumerative, recon-
                                           structive, generative
4 - Units            Domain knowledge      Rule, frame, picture
                     Pedagogical knowledge Problem/question templates, quiz
                                           templates, result checkers
                     Explanation           Explanation templates, explana-
                                           tion presentation functions
               Student model         State, operator, transition,
                                     problem space, path, temporal
                                     belief, misconception, conflict
                                     detector
5 - Primitives Domain knowledge      Slot, logical expression, clause
               Pedagogical knowledge Exercise/problem difficulty,
                                     example suitability
               Explanation           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
               Student model         State parameters, state transition
                                     codes, learning speed, know-
                                     ledge level, current progress,
                                     level of concentration, level of
                                     performance, student's capacity
                 Partial Lists of Software Components for
                ITSs (by ITS modules) in the GET-BITS Model
Domain knowledge Pedagogical              Explanation    Student model
components       components               components     components
Lesson           Teaching strategy        Explanation    Motivation
Topic            Teaching operator        Example        Concentration
Exercise         Teaching planner         Simulation     Capacity
Question         Path selector            Hint generator Misconception
Goal             Model of task difficulty Template       Current
                                                         knowledge
                    The GET-BITS model: (a) the levels
                            of abstraction
Level of    Objective   Semantics
abstraction
Level 1     Integration Multiple agents or systems
Level 2     Systems     Single agent or system
Level 3     Blocks      System building blocks
Level 4     Units       Units of blocks
Level 5     Primitives  Parts of units
                         Design of the Lesson class
Name:            Lesson
Visibility:      Exported
Cardinality:     n
Base class:      Frame
Derived classes:
Interface
Operations:      SetTopic, GetTopic, UpdateTopic, DeleteTopic,
                 Create TopicCollection, GetTopicCollection,...
Implementation
Uses:            Topic, Goal,...
Fields:          Title, Current Topic, CurrentGoal, StudentLevel,
                 TopicCollection_Ptr [],...
Persistency:     Static
Name
Visibility       visible outside the enclosing
                 class category
Cardinality      there can be more than one such
                 object
Base class       in general, a list of base
                 classes
Derived classes: in general, a list of derived classes
Interface
Operations
Implementation
Uses             in general, a list of classes, used
                 by this one
Fields
Persistency      disk files
                      Design of the Explanation class
Name            Explanation
Visibility      Exported
Cardinality     n
Base class      Frame
Derived classes EndUserExplanation, DeveloperExplanation,
                StudentExplanation, SystemExplanation,
                PQExplanation, TopicExplanation,...
Interface
 Operations     SetExplanation, GetExplanation, UpdateExplanation,
                DeleteExplanation,...
Implementation
 Uses           Rule, Frame, K_chunk, Goal, Topic,...
 Fields         CannedText, TopicCollection_Ptr[], Rule Collection_Ptr[],...
Persistency     Static/Dynamic
Name
Visibility      visible outside the enclosing class
                 category
Cardinality     there can be more than one such
                 object
Base class      in general, a list of base classes
Derived classes
Interface
 Operations
Implementation
 Uses
 Fields
Persistency     disk files for some parts only
                         Design of the Rule class
Name            Rule
Visibility      Exported
Cardinality     n
Base class      K_element
Derived classes RuleCf, FuzzyRule, ActionRule,...
Interface
 Operations     SetRule, GetRule, UpdateRule,
                DeleteRule, CreateRule-
Collection,     GetRuleCollection, AttachRule
                ToFrame,...
Implementation
 Uses           K_chunk
 Fields         RuleName, IfPart, ThenPart
Persistency     Static
Name
Visibility      visible outside the enclosing class
                 Category
Cardinality     there can be more than one
                 such object
Base class      in general, a list of base classes
Derived classes
Interface
 Operations
Collection,
Implementation
 Uses           for If-clauses and Then-clauses
 Fields
Persistency     disk files
                       Design of the T-Lesson class
Name            T-Lesson
...
Base class      Lesson
Derived classes --
Interface
 Operations     Set Theorem, Get Theorem, Delete Theorem,
                 Create TheoremCollection, GetTheoremCollection,
                 SetSkipProofs_Flag, SetSkipLC_Flag
Implementation
Uses            Theorem
Fields          SkipProofs_Flag, SkipLC_Flag
Persistency     Static                                           disk files