The GET-BITS Model of Intelligent Tutoring Systems.
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.
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.
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
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.
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.
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.
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.
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).
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.
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
|Printer friendly Cite/link Email Feedback|
|Publication:||Journal of Interactive Learning Research|
|Article Type:||Statistical Data Included|
|Date:||Sep 22, 2000|
|Previous Article:||Formalization to Improve Lifelong Learning.|
|Next Article:||Micro-Robots Based Learning Environments for Continued Education in Small and Medium Enterprises (SMEs).|