Component-Based Student Modeling

Danijela Radovic
1
, Vladan Devedzic
2
, and Ljubomir Jerinic
3


1
Technical Faculty Cacak, Svetog Save 65, 32000 Cacak, Yugoslavia, Tel. +381-32-24113, Fax. +381-32-42101
Email: danijela@tfc.tfc.kg.ac.yu

2
Department of Information Systems, FON - School of Business Administration, University of Belgrade
PO Box 770, Jove Ilica 154, 11000 Belgrade, Yugoslavia, Tel. +381-11-2371440, Fax. +381-11-461221
Email: devedzic@galeb.etf.bg.ac.yu

3
Institute of Mathematics, University of Novi Sad, Trg Dositeja Obradovi}a 4, 21000 Novi Sad, Yugoslavia
Tel. +381-21-58888, Fax. +381-11-350458
Email: jerinic@uns.ns.ac.yu


Abstract. The paper describes a part of the GET-BITS model of intelligent tutoring
systems, the part concerned with student modeling. Student modeling in GET-BITS is
highly structured and is described by a set of concepts, relations and corresponding
software components and tools of different complexity. In support of the GET-BITS
model, several practical software components are developed. They are flexible, easily
extensible and modifiable, highly reusable, and constitute a design basis for
development of student models and other parts in a wide spectrum of intelligent
tutoring systems, both for individualized and collaborative learning. The key idea
applied for student modeling in GET-BITS is the use of a unified formalism for
representing different student models that can be built into various practical systems.
Such design of student models makes the process of designing and building intelligent
tutoring systems more systematic and more effective, and also alleviates the system
maintenantce. An illustration of designing student models using the GET-BITS model
is also presented.
1. Introduction
The kind of software based on the assembly of reusable, pretested, and independently
upgradable components is referred to as component-based software (Adler, 1995). 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. 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 called GET-BITS
(Generic Tools for Building ITS) (Devedzic and Jerinic, 1997). 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, excercises, etc.), components of pedagogical knowledge, student
modeling components, and user interface components.
This paper is concerned with student modeling components of the GET-BITS model. The main
contribution of this paper is the notion of student model as a hierarchical structure of various
knowledge elements and their relationships, supported by a set of corresponding software
components, tools, and units of different complexity. One composite component can integrate
several other components, both simple or composite. Unlike many other ways used to treat the
student modeling problem, the notion presented here stresses design issues, rather than
semantical. In other words, it starts from the semantical definitions of elements of student
models, and relates them to a highly structured set of flexible, easily extensible, widely
applicable, and reusable software components.
The paper is organized as follows. Section 2 defines the problem explicitly. In Section 3,
comments are made on some previous research on student modeling, and the essence of the
GET-BITS model is briefly overviewed. The central Sections, Section 4 and 5, show how
student models are represented and designed in the GET-BITS model. The remaining Sections
discuss and evaluate the proposed solution and illustrate by an example the benefits of using it
for building student models into practical systems.
2. Problem Statement
The purpose of the paper is to formulate a framework for defining and building components of
student models to be used in various ITS. 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 student models, 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 student 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 student modeling is promoted.
3. Previous Work
Student modeling in the GET-BITS model relies on some classical and some recent work in the
area of student modeling, as well as on some common principles that hold for the whole model.
3.1 Some relevant work on student modeling
There is a large heterogeneity and diversity in the field of student modeling. Traditionally, two
parts of student's knowledge and capabilities being modeled are his/her domain knowledge and
his/her individual psychological characteristics (Greer and McCalla, 1994). Four main and
well-known groups of models of student's domain knowledge are overlay, enumerative,
reconstructive, and generative models (Wenger, 1987). Student's individual psychological
characteristics are modeled by a set of parameters representing his/her concentration,
dominating inference method (inductive or deductive), preferred way of presenting the material
being taught (simulation, problems with/without answers, hints, etc.), learning speed, and so
on. Such parameters are very important for the pedagogical module of an ITS.
A common problem with traditional modelling techniques, as noted in (Beck et al., 1997), is
the fact that they all try to maintain a model of the student's knowledge largely based on
implicit actions performed by the students. The system is not guarranteed to deduce the set of
transformations (i.e., the path in the problem space) that the student has used in generating
his/her answer. This shortcoming, along with communication technology development and the
overall evolution of the field of ITS, has led to some recent improvements and discoveries in
the domain of student modelling and has established the following current trends in the
domain: the use of intelligent agents for student modeling and monitoring (e.g., (Wang, 1997)),
the use of cooperative student models (e.g., (Bull and Pain, 1995)), modeling of artificial
learners and learning actors (e.g., (Aimeur et al., 1997)), and student modelling for
collaborative learning situations (e.g., (Ayala and Yano, 1996)). The issue of sharing student
models also gains considerable attention recently (e.g., (Brusilovsky et al., 1997)).
3.2 The GET-BITS model
The key point at the GET-BITS model is specification of five levels of abstraction for
designing an ITS (Devedzic and Jerinic, 1997). Each level has associated concepts, operations,
knowledge representation techniques, inference methods, knowledge acquisition tools,
development tools, etc. They are all considered as dimensions along which the levels can be
analysed. The complexity and the number of concepts, operations, methods, etc. grows from
the lower levels to the higher ones. Levels of abstraction and dimensions together form a
rectangular grid. A subset of concepts, operations, etc. at each level of abstraction can be
directly mapped onto a corresponding software component or tool, and components at higher
levels are often aggregates of lower level components.
4. Proposed Solution
Relevant literature on student modelling usually describes only the ideas, meaning, and
elements of student models. Design issues are seldom treated explicitly and in detail. Hence the
process of building student models into different ITS is usually constrained to using
representation techniques and procedures provided by the integrated application building tools
used for development of such systems. 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 elements, with many elements
being reinvented and reimplemented. Furthermore, if a piece of software for student modelling
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 student models from similar existing ones (Wong et al., 1996).
We have tried to alleviate these problems during our work on the GET-BITS model. As initial
results, several software components for student modelling were developed. They are described
in the following Subsections, and are all based on well-established theories and well-known
ideas from the relevant literature. In developing the components we have built so far, we have
referred to less complex student models from the relevant literature and to all levels of
abstraction but the topmost one in the GET-BITS model. Hence we haven't yet developed more
complex components, corresponding to learner modelling agents, distributed learning, group
and cooperative models, etc.. They are subject of ongoing research. It should also be noted that
many more components can be developed for student modelling, other than those that we have
proposed in this paper. However, before any standardization is done in this domain we believe
that the components that we have developed so far can be quite useful for many applications.
4.1 Student behavior
In the GET-BITS model, the relevant knowledge about an individual student concerning the
flow of information in an ITS is referred to as Student behavior. As a high level component, it
can be seen as an aggregation of two other components: Student history and Student model.
Although some authors discuss whether student history should be naturally included in the
domain knowledge or it should exist as a separate module, that problem is not of high
importance in the GET-BITS model. Student behavior component and its parts look the same
regardless of the part of the knowledge base where they are included, their relations and
communication with other components are always the same.
4.2 Student history and student model
The Student history component is also an aggregate, consisting of the following
subcomponents: the student's Training history, his/her Current knowledge of the subject being
taught by the ITS, the nature of the student's Misconceptions and a prediction of the students
Future performance. The values of the relevant attributes of these components are dynamically
changed by the ITS during the process of teaching and affect the future steps of the teaching
(pedagogical) module.
The Student model contains a representation of certain individual characteristics of the student
which are fully domain independent, and also can affect the teaching method. According to
(Andrilovic and Cudina, 1988) the following individual psychological characteristics are in
direct correlation with the learning possibility: Motivation, Capacity and Concentration. Each
one of these characteristics is modeled in the GET-BITS model by a specific component at a
certain level of abstraction. Of course, there can be a number of different components for
representing a certain characteristic. Each characteristic has also its own measuring scales and
parameters. For instance, the Capacity characteristic, as a very important learning factor (which
includes the IQ scale) has three parts: intellectual (or mental) capacity, psychomotor
parameters, and sensor parameters. GET-BITS specifies the interface of the corresponding
Intelectual capacity, Psychomotor factor, and Sensory factor components, but leaves open their
implementation details for refinement and adaptation to a particular application.
4.3 Refining a student modeling component
As an example of a possible refinment of a student modeling component, consider the
Intelectual capacity component. According to many researchers during a long period of time
(Rot, 1980), the student's intellectual capacity can be represented presented by 7 factors. They
play the major role in solving most of complex intellectual tasks. The seven factors are:
V- verbal factor (understanding talking)
W- fluency factor (reading and writing)
M- memory factor
R- reasoning factor
N- numeric factor
S- space factor
P- perception factor
If we want to use the Intelectual capacity component effectively, one way to do it is to treat
these factors as the component's attributes, assign a numeric value (on a corresponding scale) to
each factor, and define an interface function that when inwoked will combine these values in a
certain way, giving us an overall estimate of the student's intelectual capacity. The score for all
mentioned factors can be obtained from special psychological instruments (tests). The
measurement scale depends on the applied instrument, but the estimated values for all 7 factors
can be reduced to a standard IQ test values with the medium range from 90-110.
The interpretion of those values in not so easy, and requires a good psychology knowledge.
Also, interpreting the results by a psychology novice or a student himself could do more harm
than the actual usefulness. There exists the correlation degree between all factors which takes a
global impact on the final score. For instance, the small score for one factor, doesn't mean
students bad characteristics in that field if it is good collated with some other related factor.
At the very begining of the tutoring process the system is initialized by student filling up the
questionaire. Based on the students answers the system would estimate the appropriate values
for the choosen characteristics. The student model (italic) is also subject to change as the
student history model (italic), since even that mental characteristics can't vary much, they are
dynamic values, and for each individual person can vary up to some peak (different value for
different people). The initialized model can be used for prediction of the future student
performances.
5. DESIGN Example
Figure 1 shows how the student modeling components discussed in the previous Section are
interrelated in the GET-BITS model. There is also a dedicated integrated software tool, called
COSMO (COmponents for Student MOdeling), for easy creation and maintenance of the
proposed models. COSMO runs in the PC/Windows environment.
Student
behavior
Student
model
Student
history
Student:
Ana
Motivation Concentration
Current
knowledge
Future
performance
Misconceptions
Training
history
Capacity
Intellectual
capacity
Psychomotor
factor
Sensory
factor

Figure 1. Relations between the student modeling components
The attributes of the Student behavior component are some common personal data about a
certain student, like Name, Age, Sex, Photo, etc., and also the fact weather the student agrees to
model his/her psychological characteristics. The Student behavior component is in "part of"
relationship with its aggregate components, Student model and Student history. In the case that
student is not willing to be exposed to psychological modeling, only the Student history
component will contain data about the student's presumed knowledge, misconceptions, history
of his/her training, etc., which would be implemented in the corresponding subcomponents. If
the psychological student model is going to be presented, the corresponding three components
will gather data. For instance, the component Intellectual capacity will have attributes
corresponding to the seven factors described above and their correlations. The rules about how
the correlations between some factors are done are also incorporated into the Intellectual
capacity component.
The instance component Student: Ana would contain all actual data about that student Ana
from the Student behavior class and its related classes.
6. Application Example
An example of how the GET-BITS components for student modeling are used in practical ITS
development is the student model of FLUTE, an ITS in the domain of formal languages
(Formal Languages and aUTomata learning Environment) (Devedzic and Debenham, 1997).
Student model in FLUTE has been designed using the components described above, but not
directly. It is typical for any specific application development that the components need to be
slightly adjusted in order to accommodate some special requirements. Hence Table 1 shows the
attributes of the student model in FLUTE according to the system requirements, and their
mapping to the GET-BITS components that have been used in deriving the actual student
model.
Requirements of the FLUTE's student model The GET-BITS component
used
the state of the student's current knowledge of the subject Current knowledge
the student's current progress in learning a particular lesson Training history
timing and frequency of trying various exercises and asking for
hints, explanations, and help
Concentration, Motivation
the student's performance in answering the system's questions
and solving problems (grades and timing, as well as the ratio of
correct and incorrect answers); an important part of it is a
degree of remembering "old" lessons (answers to questions
from the lessons learned during previous sessions)
Future performance
the student's learning behavior (frequencies of following
correct/incorrect paths in learning a topic or a concept)
Misconceptions
measures of how continuously and how frequently the student
learns from the system
Motivation
measures of the student's initiative in working with the system Motivation, Capacity
Table 1. Student modeling in FLUTE
Obviously, not all of the student modeling components supporting the GET-BITS model have
been used in designing the FLUTE's student model. Those that have been used have had to act
as base classes for deriving slightly more specific components, due to some necessary
adjustments. For example, some default functions for establishing attribute values in the
Motivation component have been overriden by new ones in the derived component, reflecting
the specific requirements of the actual student model. Most attribute values in the derived
components are calculated in one of the following ways:
by invoking interface functions of the components of the student model, on request from
the pedagogical module;
by applying a set of rules and simple functions from the pedagogical module to a set of
parameters that the system acquires and updates automatically during each session. (some
of the parameters are indicated in parentheses in Table 1).
The student model is saved after each session and is used in the beginning of the next session.
A new student (having a session with FLUTE for the first time) is given a set of exercises and
tests before the tutoring process starts, in order to estimate his background knowledge and
determine initial values of the attributes of the student model.
The student model is updated and maintained by the system. Only the users with special
privileges (human instructors) can modify the student model themselves.
7. Discussion
The attribute values of the student model component are subject to change over time as much
as those of the student history component, since although the student's mental characteristics
cant vary much, they are dynamic values, and for each individual person can vary within some
range. It is the task of ITS to dynamically update these attribute values of the corresponding
components during the session, starting from some initial values or from some values saved at
the end of the last session with the same student.
Techniques and methods for obtaining the student's initial psychological characteristics vary a
lot. Some of the most frequently used are interviews, questionnaires, scales of estimation, tests,
and projective techniques. However, regardless of the technique used, there is always the
problem of intepretation of results. For example, the score for the relevant factors of one's
intelectual capacity, mentioned in the previous Subsection, can be obtained from special tests.
The measurement scale for those factors is not so easy to interpret, and requires considerable
knowledge and experience. Moreover, it can be dangerous to let a novice interpret the scales.
There exists a correlation between all those factors (with different values, of course) which can
tell a lot about individual students. For instance, a small score for one factor doesnt mean the
student's bad performance in that regard if it is correlated well with some other related factor.
Thats the reason why special care is necessary when interpreting results obtained from the
scales of measurements.
Another problem in getting information about a student's personality lies in the problem of
privacy, since the score results of psychological tests are highly confidential and cant be
obtained for use by other people. Of course, there are some tests which can be obtained out of
labs, but they dont deliver appropriate knowledge about the student's individual personality.
These considerations imply the need for reliable sources of information and auxiliary software
tools when developing software components for student modeling. For example, there has to be
a dedicated tool, such as a student model editor (like COSMO), that incorporates programs for
obtaining such information. Such program can have complete knowledge about interpreting the
results obtained. Alternatively, some interpretation and correlation capabilities can be built into
components themselves. Specifying a clear distinction between what can be put into
components and what should better stay with the editor is a complex problem. Access to the
results can be restricted to any user, including the student himself. This is the approach taken in
COSMO, for privacy and security reasons. However, this restriction might also affect the
learning process and effectiveness, since there are potential benefits of giving students some
insight and control over the student model (Beck et al., 1997). Anyway, the practical
consequence and conclusion is that apart from student modeling components that take part in
an actual ITS, some external auxiliary components and tools are often necessary.
It should be stressed again that important benefits of the GET-BITS model are 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 through derivation from existing classes.
Some of the existing components that support the GET-BITS model are fairly general to allow
for including new components at practically any level of abstraction (see discussion in
(Devedzic and Jerinic, 1997)).
8. Conclusions
The way that student modeling is done in the GET-BITS model of ITS allows for reusing some
existing and building new software components for that purpose. Getting information about the
student model is an extremely difficult task, but once an initial effort is taken for doing it in an
appropriate and systematic way, it definitely pays off in future development and maintenance of
ITS. Software components can help designers of ITS build student models for particular
applications more effectively, and also let them concentrate on creative tasks of designing,
assembling, refining, improving and comparing student models. The GET-BITS model is
supported by some important software components that allow for direct representation or easy
derivation of of new and reusable components for student modeling. Because of the
hierarchical organization of the GET-BITS model, these components represent a kind of a
"generic skeleton" for student modeling.
Important contributions of the paper are:
explicit treatment of design of the components for student modeling from the software
engineering point of view, an infrequent issue in the open literature;
classification of components for student modeling according to their semantics and
complexity, and specification of their relations.
Student modeling components, as defined in the GET-BITS model, are not restricted to use in
ITS. Although ITS design is the most important field of application of student modeling
components, they can be also used in many other intelligent systems, such as expert systems
and intelligent information systems. User modeling in such systems follows some common
patterns with student modeling in ITS.
The most challenging research problems for the future work are those concerned with
identification and development of components for student modeling in collaborative learning
environments. For example, pieces of heuristic knowledge, as well as associated operations and
inference methods must be clearly defined for development of components that would support
building artificial learning companions, actors, troublemakers, etc., as well as for representing
models of groups of students (learning in pairs or in tuples). Equally important as a future
direction is development of components for building learner modelling agents. Another issue
that needs a considerable future research is the one of evaluation of student modeling
components. Finally, as in many other research areas, the question of standardization of
software components for student modeling is still wide open.
9. References
Andrilovic, V., & Cudina, M. (1988). Psychology of Learning and Teaching. Zagreb, Croatia: Skolska knjiga.
Adler, R.M. (1995). Emerging Standards for Component Software. IEEE Computer, March 1995, 68-76.
Aimeur, E., et. al. (1997). Some Justifications for the Learning by Disturbing Strategy. In: du Boulay, B.,
Mizoguchi, R. (eds.): Artificial Intelligence in Education. Amsterdam: IOS Press, 119-126.
Ayala, G., & Yano, Y. (1996). Learner Models for Supporting the Awarness and Collaboration in a CSCL
Environment. Proceedings of ITS'96, Montreal, 158-167.
Beck, J., Stern, M., & Woolf, B.P. (1997). Cooperative Student Models. In: du Boulay, B., Mizoguchi, R. (eds.):
Artificial Intelligence in Education. Amsterdam: IOS Press, 127-134.
Brusilovsky, P., Ritter, S., & Schwarz, E. (1997). Distributed Intelligent Tutoring on the Web. In: du Boulay, B.,
Mizoguchi, R. (eds.): Artificial Intelligence in Education. Amsterdam: IOS Press, 482-489.
Bull, S., & Pain, H. (1995). "Did I Say What I Think I Said, and Do You Agree with Me?": Inspecting and
Questioning the Student Model. Proceedings of the 7
th
World Conference on Artificial Intelligence in
Education, Washington D.C., USA, 501-508.
Devedzic, V., & Jerinic, Lj. (1997). Knowledge Representation for Intelligent Tutoring Systems: The GET-BITS
Model. In: du Boulay, B., Mizoguchi, R. (eds.): Artificial Intelligence in Education. Amsterdam: IOS
Press, 63-70.
Devedzic, V., & Debenham, J. (1997). Representing Knowledge of Formal Languages and Automata. Proceedings
of The 15th IASTED International Conference on Applied Informatics, Innsbruck, Austria, 290-293.
Greer, J.E., & McCalla, G.I. (eds.) (1994). Student Modelling: The Key to Individualized Knowledge-Based
Instruction. NY: Springer-Verlag.
Rot, N. (1980). Psychology of Personality. Belgrade, Yugoslavia: Zavod za udzbenike i nastavna sredstva.
Wang, H. (1997). LearnOOP: An Active Agent-Based Educational System. Expert Systems with Applications, 12,
153-162.
Wenger, E. (1987). Artificial intelligence and tutoring systems: Computational approaches to the communication
of knowledge. Los Altos, CA: Morgan/Kaufmann Publishing Co.
Wong, L.-S., Looi, H.-K., & Quek, H.-C. (1996). Design of an ITS for Inquiry Teaching. Proceedings of The
Third World Congress on Expert Systems, Seoul, Korea, 421-428.