Arhitecture of the Cost-Effective Object-Oriented ... - Semantic Scholar

Control Knowledge and Pedagogical Aspects of the GET-BITS Model Ljubomir Jerinic1, Vladan Devedzic2, and Danijela Radovic3

2

1 Institute of Mathematics, University of Novi Sad, Trg Dositeja Obradovica 4, 21000 Novi Sad, Yugoslavia [email protected] FON - School of Business Administration, University of Belgrade, Jove Ilica 154, 11000 Belgrade, Yugoslavia [email protected] 3 University of Kragujevac, Technical Faculty Cacak, Svetog Save 65, 32000 Cacak, Yugoslavia [email protected]

Abstract. The difficulty of designing and developing more useable and costeffective intelligent tutoring systems (ITSs) has caused the realization of some new approaches in that field, the realization of intelligent tutoring shells authoring tools. Our starting point and perspective on developing ITSs shell is motivated by issues of pragmatics and usability. The paper describes pedagogical aspects and the control knowledge of the component based model of intelligent tutoring systems, called GET-BITS. The focus is on class hierarchies and design of classes for representing the pedagogical and the control knowledge in the GET-BITS model. Distinction has been made between different modes of operation of the pedagogical module in an intelligent tutoring system (teaching, examination, and consulting), resulting in the necessity for the class hierarchies to reflect specific pedagogical knowledge structure.

1 Introduction The GET-BITS (Generic Tools for Building ITS) model is an object-oriented, domain-independent model of intelligent tutoring systems (ITS) [3]. It is based on a number of design patterns and class hierarchies that have been discovered for ITS teaching and learning processes. In support of the patterns, appropriate C++ class libraries have been developed. Reimplementation of these classes in Java is a matter of current development. The class hierarchies start from a universal, abstract, and unifying concept of knowledge element. It reflects the possibility of representing all data, information and knowledge in an intelligent system in a unified way. Many meaningful subclasses that are needed for building a wide range of ITS are derived directly or indirectly from the knowledge element class (concepts like lessons, questions, tasks, answers, rules, plans, assessments, exercises, etc.).

However, semantics of knowledge representation in ITS is rather complex (though intuitively quite clear at the first glance). For example, in any ITS it is possible to talk about the knowledge for representing domain concepts, objectives, topics, theories, heuristics, etc., as well as about the knowledge for representing the student model - the student's (i.e., the user's) level of mastering the subject being taught by the ITS and his progress in learning the subject over time. Another important quality and feature of any ITS is its knowledge about how to decide what particular contents (and in what order) the system has to present to the user in different situations in order to interact with him, how to control the course of each session, how to monitor and interpret the student's reactions, check his knowledge level, etc. In other words, such knowledge is necessary in order to provide teaching control of the ITS and handle dynamics of the student's learning process. It is a common practice to refer to the kind of knowledge needed in a system in order to fulfill these needs and perform such actions, as pedagogical knowledge. The paper describes how control knowledge is treated by the recently developed object-oriented model of ITSs – the GET-BITS model. The model covers all essential aspects of control knowledge, such as generic tasks, control procedures, metareasoning, inference paradigms, etc. All these aspects are covered in an objectoriented class hierarchy, reflecting the principles, structure and organization of most important elements of control knowledge, and showing how these elements are related to other types of knowledge. The model is based on a number of design patterns and class libraries developed in order to support building the control mechanism of ITS. The processes of computer-based tutoring and learning based on the GET-BITS model are much closer to human-based instruction and that model can be easily extended to cover the needs of particular tutoring systems. The next extension to the ITSs is involving that the control knowledge of the GETBITS model is extended by adding the psychological type of the responds to some actions or questions of the user, and appropriate screen models. The control knowledge managed the domain knowledge according the student model and the teaching strategy. This component of the GET-BITS model is by generalized and abstracted If-Then rules which control the domain knowledge represented with the knowledge network of semantically connected frames. That knowledge network represents the content to be taught in terms of lessons, concepts, rules, tasks, questions, actions, and examples and their interrelationships. The control knowledge according to the users action and pre-tested psychologically type of the users managed that network and the user-computer interaction.

2 Problem Statement and Previous Work The kind of software based on the assembly of reusable, pretested, and independently upgradable components is referred to as component-based software [1]. As a natural extension of the more traditional and more common object-oriented software design, component-based software design addresses the general problem of designing systems and applications from predeveloped components. Such design requires to have a

model of the application domain, consisting of objects of the domain, interactions among the objects of the domain, and activities in the domain (sequences of tasks that need to be performed to achieve certain domain functions) [4]. Objects of the domain are treated as application building blocks that interact with each other, and the interactions may be defined in a number of ways (associations, operations, state transitions, message passing, etc.), and must conform with strictly defined interaction protocols. Domain modeling languages and supporting tools and techniques are often defined in order to facilitate design and development of such component-based software systems. Some advantages of such approach over traditional software design include:  each component can be modeled and implemented separately;  enhanced reusability, since one component can be used in many different systems due to its relatively high domain and application independence;  communication between different components within a system conforms with predefined protocols;  enhanced possibilities for system maintenance and extensions, since components can be added, replaced, improved, etc., without changing the existing overall system design;  behavior of the system can be easily modified only by changing or replacing relevant components. In order to make the process of building intelligent tutoring systems (ITS) more practical and more efficient, we have developed an object-oriented model of ITS, called GET-BITS. The model is supported by a number of software components, making it possible to build an ITS without starting from a scratch, and also not having to use an expensive ITS shell or an authoring tool. In practice, these components are used to assemble an ITS shell first (using only the components that are really needed in the particular system), and then the shell is used by a knowledge engineer and a domain expert in order to develop the desired ITS. The supporting components are classified into several categories: system components (domain-independent components for representing lessons, topics, objectives, exercises, etc.), components of pedagogical knowledge, student modeling components, and user interface components. The purpose of the paper is to formulate a framework for defining and building components of the control knowledge and pedagogical knowledge to be used in various ITS, as it is defined in the GET-BITS model. The approach taken is practically oriented: the paper shows software engineering aspects of the framework, such as analysis and design of some important components of control and pedagogical knowledge, their relationships and hierarchies, as well as examples of using the components in practical systems. The framework and the components are described explicitly and systematically, thus providing a kind of a "generic skeleton" for representing and using control and pedagogical models in different applications. However, the idea is not to list all possible such components, nor it is to go into details of implementation; rather the idea of using components for control and pedagogical modeling is promoted.

Several models of pedagogical knowledge and different pedagogical strategies have been developed so far, including those presented in [2, 4 and 5]. They can be roughly classified into three categories: model tracing, coach model, and Socratic teaching. However, literature usually describes only the ideas, meaning and purpose of pedagogical models and strategies. Design issues are seldom treated explicitly and in detail (although there is evidence that even most distinguished authors admit the importance of design issues and software engineering in general in building pedagogical models. Hence the process of building pedagogical knowledge into different ITS is usually constrained to using representation techniques and procedures provided by the integrated ITS building tools, or shells. If the integrated tools are not used, it is not a common practice that the process a/ follows an explicitly stated, systematic design procedure, and b/ is based on existing software components. As a result, redundancies occur: many groups are working apart to build different systems that have common components, with many elements being reinvented and reimplemented. The discussion in, although in a different context, further clarifies these shortcomings. Furthermore, if a component of pedagogical knowledge has to be refined or modified in any way, it often comes up that several other parts of the system must be modified accordingly, in order to accommodate the change. There is also a problem of deriving specific pedagogical components, models and strategies from existing ones. In the GET-BITS model, pedagogical knowledge is highly structured and is described by a set of concepts of different complexity (such as rules, instructions, questions, teaching procedures and actions, explanations, examples, simulations, plans, strategies, various didactic elements, etc., as well as descriptions of various dependencies and other relationships between some elements) and their relations. They are organized hierarchically and are all classified into several different levels of abstraction. In support of the model, a toolkit for representing pedagogical knowledge is developed. It contains software components and tools corresponding to the hierarchy of pedagogical concepts. Its components are flexible, easily extensible and modifiable, highly reusable, and constitute a design basis for building pedagogical modules of ITS. Software components from the lower levels of abstraction are used as building blocks for more complex components of the upper levels. All modifications and extensions are localized to a small number of software components, and are transparent to all the other parts of the toolkit. The work on the GET-BITS model is in line with currently popular stream in software engineering, the stream advocating development of component software and use of software repositories. The main idea is that, at each level of abstraction, C++ or Java classes and associated method procedures and utility functions are developed for representing the concepts and entities defined in the GET-BITS model. Then development of an ITS can be based on an assembly of such reusable, pretested, and independently upgradable software components.

3 The Levels of the Control Knowledge in GET-BITS Model The GET-BITS model defines five levels of control in an problem solving process, Fig. 1. Appropriate control knowledge is associated with each level, and should be specified explicitly in the knowledge base. Doing so guarantees maximum flexibility and maximum clarity in both the knowledge base development and the ITS operation. On the other hand, it requires an extensive set of reasoning procedures and tools to be available to the system developer (i.e., to be implemented and integrated with the shell used for the ITS development). The GET-BITS model defines a base (and abstract) class and a set of concrete subclasses describing objects that perform control at each of the five levels. Instantiating these classes with the appropriate control knowledge (e.g. attribute values, particular methods, parameters, etc.), the ITS developer defines control objects, i.e. specifies the control knowledge part of the ITS knowledge base. Level 1

(MA)

Multiple agents

Level 2

(CGT)

Complex generic task

Level 3

(GT)

Generic task

Level 4

(IE)

Inference engine

Level 5

(BO)

Basic operations

Fig. 1. The levels of the control knowledge in GET-BITS model

Based on the key abstractions, tools and techniques for representing control knowledge in ITSs can be organized as shown by the class diagram in Fig. 2. It must be stressed that although it is apparently complex, the diagram shows only a simplified version of the organizational hierarchy of relevant classes. For the sake of clarity of presentation, unnecessary details are omitted and not all the existing links between the classes are shown. A few parts of the diagram conceptually belong, in fact, to the class hierarchy of the tools and techniques for representing domain knowledge are organized according to the GET-BITS model (e.g., the Rule and Frame classes). They are shown in order to illustrate how domain and control knowledge are linked in the model and how unified the approach is, regardless of the type of knowledge elements. In the Booch notation, the inheritance relationship among two classes is denoted by a solid line with an arrow pointing to the base class. For example, the CGT class is a subclass of the K_element class, i.e. CGT inherits the properties (attributes and methods) of K_element. Double line from a class icon to another class icon, with the

point close to the first class icon, means that the first class uses the second class. The numbers at the ends of the double line (1 and n) denote the cardinalities of the corresponding classes: some classes can have only one instantiation for a particular knowledge base, and there can be n instantiations of some other classes. For example, there can be only one object of the CGT class in a particular knowledge base, but that object can use n objects of the GT class. It should be noted that GT, CGT and InfEngine classes are all subclasses of the K_element class, meaning that all control knowledge elements are treated in a unified way (together with domain and explanatory knowledge elements). HeurCl TQ_Engine

RTmonitoring Rule RTcontrol

Frame

CGT 1

...

BC_InfEngine

...

FB_InfEngine

K_element

Design_PSR 1

...

Input 1

...

FC_InfEngine InfEngine

HierCl

n 1 GT 1 1 1 1

1 1

RB_InfEngine

...

GTcontrol

1 1

1

1

ConRes

PatternMatcher

BottomUp

Output 1 n

n WME

Metacontrol

...

TopDown

1 1 Metarules

Fig. 2. The diagram of classes for representing the control knowledge

4 The Pedagogical Knowledge in GET-BITS Model Essentially, pedagogical knowledge in the GET-BITS model is represented as a set of semantically rich entities derived from and/or composed of some more primitive and possibly more abstract and more general-purpose components. Table 1 shows the objectives and semantics of components of pedagogical knowledge in the GET-BITS model at different levels of abstraction. Strictly speaking, only Levels 1 and 2 contain components corresponding to pedagogical knowledge and can be further sliced into different sublevels. Levels 3 and 4 contain the parts used for building (deriving and/or composing) components of pedagogical knowledge. Level of abstraction 1

Objectives and semantics Collaborative learning situations; combining multiple pedagogical strategies; generating multiple curricula over the same domain; distributed pedagogical knowledge; etc.

2

3

4

Pedagogical models; teaching and learning strategies; knowledge communication; inference and control methods for generating context-dependent, user-centered contents to satisfy user's requests; error handling; dedicated integrated development tools and knowledge acquisition and learning tools; etc. Representational units and functional blocks defining knowledge and control structures reflecting typical data and knowledge objects, as well as the steps and activities performed when solving common classes of problems (e.g., planners, selectors, classifiers, monitors, controllers, learning units,...); etc. Knowledge representation techniques and reasoning mechanisms, supporting various representational, reasoning and learning paradigms (e.g. production rules, frames, logic, neural networks, fuzzy sets, etc.), or a combination of two or more paradigms.

Table 1. Objectives and semantics of components of pedagogical knowledge (Levels 1 and 2) and their parts (Levels 3 and 4)

Table 2 show some kinds of pedagogical knowledge that have been identified and included in the GET-BITS model so far, from three different aspects: 1. the kinds of knowledge that have to be represented by the software components at the corresponding level of abstraction (roughly corresponding to the components themselves); 2. the procedural operations that should be performed by the components at a certain level of abstraction (the tables do not show a strict correspondence between any component-operation pair); 3. the inference and control methods that should be performed by the components at a certain level of abstraction (again, the tables do not show a strict correspondence between any component-inference/control method pair); Knowledge representation

Operations

Inference and control methods

Composite teaching Evaluation of teaching Quality control function in strategies, performance (based on collaborative learning Theory of instruction based parameters such as the situations, on causal assertions number of users Intelligent pairing (rules that relate changes successfully completing (grouping) of students (in of the teaching strategy to the teaching session, the order to optimize the possible changes in average score on a postlearning opportunities teaching performance) test, the amount of user's each affords for a partner and definition assertions time used, the amount of in collaborative learning), (which group together computer time used, Combined explanation and classes of actions or etc.),... hint generators,... effects),... Table 2. Some aspects of Level 1 components of pedagogical knowledge

Most kinds of pedagogical knowledge shown in Table 2 have intuitively comprehensible meanings. The necessary clarifications are as follows. Composite

teaching strategies allow for knowledge-based change of pedagogical strategy during the communication with the user. Critical parameters denote those parameters of the user model which are affected by applying a teaching operator. From the design point of view, terms in brackets denote either classes derived from the class immediately before the brackets, or a specific implementation of a virtual function immediately before the brackets. Roughly speaking, the concepts represented along the knowledge representation column in Table 2 can be represented as C++ classes, various operation and inference and control methods can be treated as their associated method procedures and utility functions. The toolkit developed in support of the GET-BITS model contains a number of such classes, procedures, and functions. They are all general enough to be used in a number of ITS, and can serve as a basis for deriving more specific pedagogical components. As an example, consider the class diagram in Fig. 3, showing a part of the class hierarchy of teaching strategies. The figure details to an extent how the coaching strategy is designed. The abstract class Teaching strategy is used for deriving concrete strategies. Not all of them are shown in Fig 3. Objects of the Coaching class use the Teaching operator objects in order to generate and execute teaching plans. Since teaching operators in the coaching strategy are a special form of production rules, Teaching operator is derived from the Rule class.

Rule Teaching operator

...

n 1

Teaching strategy Model tracing

Coaching

11 Dependency graph

...

Socratic teaching

...

Fig. 3. Class hierarchy of teaching strategies

Fig. 4 shows an example of how classes are designed in the GET-BITS model. The class shown is the Coaching class from Fig 3. Although variants of the coaching strategy have been reported in the literature, only a single variant is included in the GET-BITS model so far, hence no class is derived from Coaching. A control object of the pedagogical module is supposed to invoke interface functions (method procedures) of an object of the Coaching class in order to initiate the teaching process (Set target goal, Set known concepts), call a teaching planner to generate sequences of teaching operators to be executed (Generate path), select a sequence to execute (Select path), execute it (Traverse path), compare results of the student's problem solving with those of the domain expert module (Compare results), update the student model accordingly (Update student model), etc.

Name: Visibility: Cardinality: Base class: Derived classes:

Coaching Exported; visible outside the enclosing class category 1; there can be only one object as the class instance Teaching strategy; in general, a list of base classes -

Interface Operations:

Set target goal, Set known concepts, Generate path, Select path, Traverse path, Compare results, Update student model,...

Implementation Uses: classes used by this one Fields:

Dependency graph, Teaching operator,...;

a

list

of

Current topic, Current goal, Target goal, StudentModel_Ptr, TopicCollection_Ptr [],... Static; disk files

Persistency:

Fig. 4. Design of the Coaching class

The control knowledge is realized by parameterizing the actions with the combination of If-Than-Action rules. Fig 5. represents the TQ_Engine control knowledge for elaborating an answer for some task or question. Give feedback for question .........

Mal Rules

Positive encourage

Procedure for elaborate answer

Negative

Encourage = .F.

encourage

Congratuate = .T. . .

Student Model

. Elaborate = .T.

Congratulate

Psyhology = .T.

"Right" "Wrong" Second path thro-

TQ_Engine

ugh lesson

First path through lesson

Fig. 5. The control knowledge for tasks or questions

The above example of the TQ_Engine and other modules of the control knowledge are extended with psychology type of the student, which is responsible for different user interfaces in the elaborating the students answer and responding according the psychology type of the student.

5 Discussion and Conclusions The idea of organizing components of pedagogical knowledge hierarchically is not new. Accounts on such kind of knowledge organization are also reported elsewhere in the literature. The number of levels of abstraction and criteria for defining them differ from those used in the GET-BITS model. However, some mappings from the other models to GET-BITS and vice versa can be done. The main advantages of the GET-BITS model over the others is high reusability of its components, due to object-orientation, and its high extensibility. Extensions can be done easily by less common (or even new) components of pedagogical knowledge through derivation from existing classes. Some of the existing classes in the GETBITS model are fairly general to allow for including new components at practically any level of abstraction. The idea behind the organization of pedagogical knowledge presented in this paper is simple: in order to facilitate development of intelligent tutoring systems (ITS), a development kit of appropriate software components should be provided. The GET-BITS model of ITS is supported by such a development kit, and it contains a number of components for representing directly or easily deriving reusable components of pedagogical knowledge. The main contributions of the paper are: a) identification and hierarchical classification of entities/components of pedagogical knowledge, stated explicitly and systematically; b) explicit treatment of design of the components of pedagogical knowledge, from the software engineering point of view, an infrequent issue in the open literature and c) identification and hierarchical classification of entities/components of control knowledge, stated explicitly and systematically. The most challenging research problems for the future work are those concerned with identification and development of components of pedagogical knowledge in collaborative learning environments. For example, pieces of heuristic knowledge, as well as associated operations and inference methods for grouping students (in pairs or in tuples) in order to achieve maximum group learning performance is still an open issue. Another interesting set of pedagogical components of knowledge yet to be well understood and employed in ITS is that of case-based example generators.

References 1. Adler, R.M.; Emerging Standards for Component Software, IEEE Computer, 68-76, March 1995. 2. Anderson, J.R., Corbett, A.T., Koedinger, K.R., Pelletier, R.; Cognitive Tutors: Lessons Learned, persnal correspodence, manuscript in preparation, 1995. 3. Devedzic, V., Jerinic, Lj.; Knowledge Representation for Intelligent Tutoring Systems: The GET-BITS Model, in: du Boulay, B., Mizoguchi, R. (eds.): Artificial Intelligence in Education, IOS Press, Amsterdam / OHM Ohmsha, Tokyo, 1997, pp. 63-70. 4. Ketabchi, M., Jambor-Sadeghi, K.; Modeling Application Domains, Data & Knowledge Engineering, Vol.22, No.3, 1997, pp. 261-281. 5. Vassileva, J.; An Architecture and Methodology for Creating a Domain-Independent, PlanBased Intelligent Tutoring System, ETTI 27/4, 386-397, 1990.

Dear Sir,

Please find enclosed the final version of our paper for the IEA-98-AIE. The paper is numbered by 517. Will You be so kind to inform us that You received the paper on time on: Ljubomir Jerinic Institute of Mathematics, University of Novi Sad, Trg Dositeja Obradovica 4, 21000 Novi Sad, Vojvodina Yugoslavia e-mail: [email protected] FAX: +381 21 350 458 Thank You in advance. Yours Sincerely Ljubomir Jerinic