an object oriented shell for - Semantic Scholar

AN OBJECT-ORIENTED SHELL FOR INTELLIGENT TUTORING LESSONS Ljubomir Jerinic1 and Vladan Devedzic2 1

Institute of Mathematics, University of Novi Sad, Trg Dositeja Obradovica 44, 21000 Novi Sad, Yugoslavia 2 FON - School of Business Administration, University of Belgrade, Jove Ilica 154, 11000 Belgrade, Yugoslavia

Abstract. Many important issues in design and implementation of ITS some functionality focuses on the way inter-object connections are represented, manipulated, and stored in the computer. However, the advancement of AI methods and techniques makes understanding of ITS more difficult, so that the teachers are less and less prepared to accept these systems. As a result, the gap between the researchers in the field of ITS and the educational staff is constantly widening. Acquiring and encoding this large amount of knowledge is difficult and time-consuming. We have been searching for efficient ways to do these knowledge engineering tasks. This paper describes our efforts toward developing uniform data and control structures that can be used by a wide circle of authors, e.g., domain experts, teachers, curriculum developers, etc., who are involved in the building of ITS.

1 Introduction The endeavors to design Intelligent Tutoring Systems and Intelligent Learning Environment [1, 5] have opened a new research direction in the application computers for educational purposes. These systems are capable to help solving difficult problems in the process of knowledge transfer, and enable an almost full individualization of the teaching process, as well as the student's advancement in the stages of acquiring knowledge and application of the new knowledge according to their capabilities, aspirations, previous knowledge and the like. Also, ITSs stimulate the use of computers in education as a new education tool and controller of the teaching process, and opened new approaches for the use of computers in education. The intensive development of the methods of knowledge engineering and reasoning enables that education by the computers could be possible. The main goal of that approach is the complete individualization of the educational process. We assume, that the tutoring is a task of helping a student or pupil to learn particulars in a certain domain. This requires a special concern about the cognitive load that the student or pupil will bear in the learning process. The research on intelligent tutoring systems [8] has produced the technology to do this task within the computer program. But, as the computers have entered teaching practice, teachers show an increasing interest in educational software systems. For these teachers, however, ITS is the most difficult one in terms of grasping the total aspects [9]. Of course, they have a chance to read articles about ITS but what they can understand through the articles is confined to the abstract level of comprehension. Experience in using ITS directly through a

system that transperentizes the inner mechanisms of ITS would be a powerful tool to help them in comprehending it. As research in ITS continues to produce more refined systems, the gap between the research community and educational community continues to become wider. The educators understanding, and usage of these research results have been much slower than the research progress. As this theory-application gap becomes wider, it becomes more difficult for educators to participate in ITS research and application, and the result of the research becomes increasingly academic and unconnected to the pragmatic aspects of teaching and learning. Also, the educational programs are different among the distinct countries. Then, the required knowledge for learning some lesson in some domain is not the same even in one country itself (the north south problems, country - town, etc.). The teachers want to have the active role in design and eventually update and improvements of intelligent tutors. The ITS tools (the authoring tools or ITS shells) are investigate in the last decade in the theory of ITS design. The IDE system [11], a hypertext based support tool for course design was one of the first attempts at authoring an ITS. Also the DOMINIE [12], GTE [1], COCO [5] and KAFITS [9] presents a set of authoring tools designed for use by teachers to enable them to build ITSs. But, all of them have the knowledge engineers between the teacher and the ITS. In view of the above trends and research issues, the goal of designing the EduSof [7] system was to construct a conceptual framework for representing the objects, events, responses, reactions, and relationships involved in tutoring. Also, the aim was to build a highly-usable knowledge acquisition interface for rapid prototyping and easy creation, modification, deletion, and testing of both teaching concepts and tutorial strategies. Finally, our intention was to produce a system that enables teachers to build their own lessons without any computer or AI specialist.

2 Object-Oriented Model Of Knowledge The background for developing the OBOA model was several different ideas coming from the fields of knowledge and data modeling, representation and management [2]. Gruber and Cohen [6] have described a hierarchy of knowledge representation techniques and tools, starting from most primitive ones to quite complex knowledge structures. Debenham [3] has developed an object-oriented formalism for modeling all the data, information and knowledge in application in the same way. It is possible to think of an ITS knowledge base as a logical entity composed of three related parts: the domain knowledge, control knowledge (i.e., a model of the ITS), and the third part that we call explanatory knowledge. Domain knowledge is represented using one or more knowledge representation techniques. In the most general case, domain knowledge is a structured record of many interrelated knowledge elements. These elements describe relevant domain models and heuristics, and can vary a lot in their nature, complexity, and representation. They can be everything from simple data to instantiated knowledge primitives such as frames, rules, logical expressions, procedures, etc., and even more complex knowledge elements represented using either simple aggregations of the knowledge primitives or conceptually different techniques based on the knowledge primitives and other (but

simpler) knowledge elements. Semantic nets are the best known kind of such complex knowledge elements, and are frequently used for representing deep knowledge about the problem domain. Speaking of the complexity and hierarchy of knowledge elements, it may be noted that even knowledge primitives are complex enough themselves, and their parts can be also treated as (less complex) knowledge elements. For example, the knowledge elements of a frame are its slots, its subframes, its demons, etc., and the knowledge elements of a rule are its If-clauses and its Then-clauses. There is a natural constraint in further dividing simpler knowledge elements. For example, an attribute-value pair has its attribute and its value, but the attribute is a simple part that cannot be further divided. Parts of a knowledge element of a certain type are either collections of other knowledge elements (e.g., the If-part, or the Left-Hand Side (LHS) of a production rule is usually a collection of If-clauses), or single elements (e.g., the attribute part of an attribute-value pair). Knowledge elements of the domain knowledge are usually grouped to create meaningful collections. One possible criterion of defining such a collection (the one used in the OBOA model) is the type of knowledge element that will be included in the collection. Therefore we can speak of collections of rules, frames, etc., or collections of more complex knowledge elements. Each such collection is homogeneous regarding the type of knowledge elements it contains. Generally, domain knowledge can be composed of n collections of knowledge elements, and there can be zero or more collections of elements of a particular type. The primary purpose of the part of the knowledge base that we refer to as the explanatory knowledge is to define the contents of explanations and justifications of the ITS reasoning process, as well as the way they are generated. Other needs for explanatory knowledge may include some forms of intelligent assistance such as useroriented high-level descriptions of the knowledge base contents (e.g. knowledge browsers), intelligent Help systems, support for natural language communication, etc. Explanatory knowledge is related to both domain and control knowledge and is often treated as a part of the other two components of knowledge bases. However, in the OBOA model it is treated as a distinct knowledge component, in which the knowledge about the reasoning process explanation, knowledge elements explanation, control strategies explanation, and other types of intelligent assistance is represented explicitly and is treated in its own right. Among the knowledge elements that this component can include are: canned text associated with rules and other knowledge elements in the other two components; templates that are filled by the explanation module when required (in order to generate the full explanation text in a given situation); presentation functions needed for explanation of certain knowledge elements (e.g., some knowledge elements are best explained by using tables, others require the use of graphics, etc.); user models necessary for generating explanations in accordance to the user's knowledge level; criteria used by the explanation module when deciding about what knowledge elements to include in the explanation and what to skip, as well as what level of details must feature the explanation. It must be stressed that apart from the explanatory knowledge, the explanation module uses extensively the knowledge from the other two parts of the knowledge

base as well when generating explanations. Therefore, the explanatory knowledge may also contain explicit descriptions of explanation control strategies. These can be specified in the form of control rules like, for example: "If the explanation type is WHY, then 1/ show the current goal, and 2/ show the current domain rule instantiation, and 3/ show the meta-rule that was last applied".

3 EduSof Architecture Since EduSof is intended to be a well-designed, universal, and widely used a programming tool for the application in educational process, there appears a need for representing knowledge in various ways. EduSof knowledge consists of: some textual information or textual knowledge represented by means of text, and/or pictures (graphic representation of knowledge), as almost an obligatory element of all educational sequences, especially in the field of natural sciences, and/or simulations, because experiments are part of educational process in many fields, so there is a need for certain simulation capabilities as a part of representing knowledge in the computer systems. The EduSof, as the generator of the intelligent tutoring lessons, can be defined as the intelligent, special-purpose systems with the response and the inference mechanisms. It is consisted of: Expert, Student, Tutor, Diagnostic and Interface, like almost all intelligent tutoring systems. We extended that definition by adding the Explanation module. The interface module is the mechanism by which the student and the tutor communicate. No communication can exist without this component, and therefore it has been a part of every ITS developed to date. Presenting this module as a component of the ITS architecture reflects the current view of the importance of a well-designed user interface to any interactive program. The general goal of the user interface is to use the available devices, usually keyboard, mouse, monitor, etc., to display to the student the necessary information, and use these devices to obtain students' responses. In EduSof we use the menu-driven, the icon managed, and an easy-to-use user interface (Fig. 1.). The expert module consist of the domain knowledge to be tutored. This component of the ITS is assigned task of generating problems and evaluating the correctness of the student's solutions. This module entails a general problem in AI: How do we represent domain knowledge? In EduSof the expert module is 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. It can be taught of as more than just a network of facts. The knowledge network in EduSof could be coupled to a domain expert, or could be a collection of text, pictures, simulation procedures, and/or voice.

File

Edit

Create

System

Help

Con cep t Qu estion

Picture

Resp on se

Simulation Exp lanation

Text Alternative

Edu sof - TEA

Create: Lesson

Figure 1 The EduSof lesson creation The tutor module is responsible for deciding on how and when the domain knowledge is to be presented to the student. Because the tutor needs to know information about the student to be able to make these decisions, the tutoring module relies heavily on the student modeling module. In EduSof the tutor module consists of various teaching strategies, the rules that decide what should be taught to the student given the current state of the student model. This is realized by parameterizing the semantic network of frames, with the combination of If-Than-Action rules. An error or diagnostic module in EduSof consists of the rules used to identify student misunderstandings, updates the student model, manages the teaching rules, if it is necessary, and stores the student common mistakes and errors. The student model is the representation of what the student has learned and currently knows. No intelligent communication can take place between two entities without a certain amount of understanding between the two entities. It means that the student modeling module represents the knowledge and skill of the student so that the ITS may communicate effectively with that student. In EduSof the student model serves as a representation of the student's knowledge of the domain. Therefore, the student model is the overlay model. The domain is essentially a tree, where each node is a piece of domain knowledge and any parent-child link in the tree implies that in order for the student to be able to understand the knowledge of the parent node, he must also understand the knowledge of the child’s node.

4 OBOA Representation Of Knowledge In EduSof In this section the usage of the OBOA model in the knowledge representation of the Expert module of EduSof is briefly presented. That knowledge representation is concerning some particular and concrete type of knowledge elements that are

necessary for the realization of the Expert module in any ITS shell. One of the most important elements of knowledge for designing the intelligent tutoring lesson is the model of Lesson, and this is basic class needed for modeling the learning process. Any lesson is consisted of one or more issues, modeled by the class Topic in the OBOA model. We assume that the student must learn these issues, during mastering that lesson. The basic attributes of the lesson are: the name (Name), current topic (CurrentTopic, the issue or the problem introduced, defined and/or explained in the present moment), the task that is currently solved, the level of prerequisites for the student (StudentLevel), and so on. The class Lesson, used for describing that elementary knowledge is inherited from the more general class Frame, and in the OBOA model that class is defined with: Name: Visibility: Cardinality: Base classes: Derived classes: Generic parameters: Public Interface Operations:

Lesson Exported n Frame FirstLesson, LastLesson, HardLesson, EasyLesson, ... -; only for generic class SetTopic, GetTopic, UpdateTopic, DeleteTopic, CreateTopicCollection, GetTopicCollection, ...

Implementation Uses: Topic, Goal, ... Fields: Title, CurrentTopic, CurrentGoal, StudentLevel, TopicCollection_Ptr [], ... Persistence: Static The issues that student must learn (class Topic) are realized with separate type of knowledge elements in the EduSof system. Any topic could be introduced with text information (Information), graphically (the pictures and/or the diagram - Image), and/or with the simulation of some event (Simulation). Also, the additional or further explanation (Explanation) for that theme, or some suggestions (Hints) could be defined. The class Topic in EduSof is made for specifying and defining the issues or notions needed for lesson creation. That class in OBOA model is: Name: Topic Visibility: Exported Cardinality: n Base classes: Frame Derived classes: BasicTopic, DerivedTopic, MultidisciplinaryTopic, ... Generic parameters: Public Interface Operations: SetInfo, GetInfo, UpdateInfo, ... Implementation Uses: Topic, Goal, ... ; Fields: Name, InformationPtr, ImagePtr, LessonPtr,

Persistence:

SimulationPtr, Explanation, Hints, QuestionPtr [ ], TaskPtr [ ], ... Static

Abstract class TQ served for description of the common elements for the two comparable and connected classes, one for the definition of tasks or assignments (class Task) and the other class for the realization of questions or problems (class Question). The instances of that class are given to the student during the learning process. The definition of the class TQ is: Name: TQ Visibility: Exported Cardinality: 0; Base classes: Frame Derived classes: Task, Question, ... Generic parameters: Answer, SolutionType, ... Public Interface Operations: SetInfo, GetInfo, UpdateInfo, ... Implementation Uses: Topic, Goal, ... Fields: Name, InformationPtr, ImagePtr, LessonPtr, SimulationPtr, Solution, NextAction, ... Persistence: Dynamic The part of explanation are realized by the following OBOA elements: Name: Visibility: Cardinality: Base classes: Derived classes:

Interface Operations: Implementation Uses: Fields: Persistency:

Explanation Exported n Frame EndUserExplanation, DeveloperExplanation, StudentExplanation, SystemExplanation, TQExplanation, TopicExplanation,... SetExplanation, GetExplanation, UpdateExplanation, DeleteExplanation,... Rule, Frame, K_chunk, Goal, Topic,... CannedText, TopicCollection_Ptr [], RuleCollection_Ptr [],... Static/Dynamic

where is: Name: Visibility:

Rule Exported

Cardinality: Base classes: Derived classes: Interface Operations:

Implementation Uses: Fields: Persistency: Name: Visibility: Cardinality: Base classes: Derived classes: Interface Operations: Implementation Uses: Fields: Persistency:

n K_element RuleCf, FuzzyRule, ActionRule,... SetRule, GetRule, UpdateRule, DeleteRule, CreateRuleCollection, GetRuleCollection, AttachRuleToFrame,... IfClauses, ThenClauses,... RuleName, IfPart, ThenPart Static Frame Exported n K_element Lesson, Topic, TQ, Explanation,... SetFrame, GetFrame, UpdateFrame, DeleteFrame, CreateFrameCollection, GetFrameCollection,... Rule, RuleCollection, K_chunk,... ParentFrame, SubframeList, SlotList, DemonList, InitValList, GoalValList,.. Static

where K_chunk is an abstract class whose derived classes define slots, demons, etc. On the similar way the other classes [4, 7] are defined in the OBOA model, which are needed in the creation of intelligent tutoring lessons.

5 Discussion And Conclusions The purpose of the proposed OBOA model of knowledge bases and knowledge base management is to make a basis for applying the ideas of object-oriented software design methodology to ES knowledge organization, representation, and access. It covers all important aspects of knowledge bases, like their contents, knowledge representation techniques, using, updating, extending and maintaining the knowledge, etc. However, it is important to stress again that the OBOA model should be regarded as an open framework for developing ITS knowledge bases, rather than as a closed set of design rules and organizational hierarchies. In fact, the model has several open ends. The first open end is the possibility of extension by including new knowledge representation techniques. The presented method for building a knowledge base suitable for the educational purpose is currently under development and the realization in the present form. In the current development state we test usage of EduSof in some summer schools in various subjects (chemistry, history, geography etc.). With introduced

approach in building the intelligent tutors we realize the one of the goals we set down before the start of the realizing of the above concepts. The teacher's independents in design of the intelligent tutoring lessons were almost 90% after an hour of explanation how to use the EduSof shell. The rest 10% is used for the professional programmers time for designing the simulation procedures. It is supposed that the teacher have some knowledge of using the computers, a little knowledge in computer graphics, and some help of professional programmers' in making the simulation's procedures.

REFERENCES 1. Barna, P., Ohlsson, S., Pain, H., (Eds.): Proceedings of AI-ED 93, World Conference on Artificial Intelligence in Education. AACE Press, Charlottesville, VA, USA (1993). 2. Booch, G.: Object-Oriented Design with Applications. Redwood City, CA, Benjamin Cummings (1990). 3. Debenham, J.K.: Objects for Knowledge Modeling. Proceedings of The Second World Congress on Expert Systems, (1994) 979-985 4. Devedzic, V.: Knowledge-Based Control of Rotary Kiln. Proceedings of The 1995 IEEE International Conference on Industrial Automation and Control: Emerging Technologies, (1995) 452-458. 5. Frasson, C. (Ed.): Proceedings of Intelligent Tutoring Systems 1988, ACM Press, USA (1988). 6. Gruber, T., Cohen, P.: Knowledge Engineering Tools at the Architecture Level. Proceedings of The 10th IJCAI, Vol.1, (1987) 100-103. 7. Jerinic Lj., 1994, Frames Technique, Inference Mechanisms and Knowledge representation in Design Educational Software. In Proc. SYM-OP-IS '94, (1994) 107-110. 8. Kearsley, G.: Artificial Intelligence and Instruction: Application and Methods,. Addison-Wesley Publishing Company, Reading MA, USA (1987). 9. Murray, T., Woolf, B. P.: A Knowledge Acquisition Tool for Intelligent Computer Tutors. SIGART Bulletin Vol. 2, No. 2 (1990) 1-13. 10. Ohlsson, S.: Some Principles of Intelligent Tutoring. In Lawer & M. Yazdani (Eds) AI and Education, Vol. 1., Albex, Norwood, New Jersey (1987). 11. Russell, D., Moran T. P., Jordan, D. S.: The instructional design environment. In J. J. Psotka, L. D. Massey and S. A. Mutter (Eds) Intelligent Tutoring Systems: Lesson Learned, Lawrence Erlbaum Associates (1988). 12. Spensley, F.: DOMINIE: Trainer interface. CITE Technical Report No. 44, Institute of Educational Technology, The Open University (1988).