Porting a Standalone Intelligent Tutoring System to the Web - PowerPoint PPT Presentation

Loading...

PPT – Porting a Standalone Intelligent Tutoring System to the Web PowerPoint presentation | free to download - id: 79fb1d-YjQyN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Porting a Standalone Intelligent Tutoring System to the Web

Description:

Porting a Standalone Intelligent Tutoring System to the Web Sherman R. Alpert Mark K. Singley Peter G. Fairweather Applied Learning Sciences Department – PowerPoint PPT presentation

Number of Views:110
Avg rating:3.0/5.0
Slides: 36
Provided by: Sa758
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Porting a Standalone Intelligent Tutoring System to the Web


1
Porting a Standalone Intelligent Tutoring System
to the Web
  • Sherman R. Alpert Mark K. Singley Peter G.
    Fairweather Applied Learning Sciences Department
  • IBM T.J. Watson Research Center POB 218 Yorktown
    Heights, NY USA alpert, ksingley,
    peterf_at_watson.ibm.com

2
Porting an ITS to the Web
  • Problems
  • Building intelligent educational software is
    difficult and time-consuming
  • Despite gt¼ century of research and even technical
    successes ITSs are, for the most part, in front
    of only a handful of real students doing real
    work on a regular basis (some exceptions, e.g.,
    CMU algebra tutors in Pittsburgh schools)
  • Web offers unprecedented opportunity to deliver
    ITSs to broad audience, in broader range of
    settings (not just classroom) and amortize
    development cost per student

3
Porting an ITS to the Web
  • We had built a standalone ITS for elementary
    algebraic equation solving (ran on Wintel
    platform -- only)
  • AlgeBrain focuses specifically on the skills and
    knowledge involved in transforming and
    simplifying equations toward the goal of solving
    for a particular variable
  • AlgeBrain offers a practice environment with the
    benefit of a coach providing advice and
    remediation

4
Porting an ITS to the Web
  • Standard problem how do deploy our ITS to reach
    real students and lots of them?
  • Solution the Web
  • But Problem Weve already built a standalone
    tutor
  • Solution Convert existing tutor to be Web-enabled

5
Standalone ITS
6
Porting our ITS to the Web Evolution, not
revolution
  • Our standalone ITS conformed to a popular,
    widely-used, standalone-ITS architecture
  • Tutorial Module, the overall "manager" of
    tutorial interactions
  • a cognitive simulation of an Expert Problem
    Solver for the tutors domain in our case,
    domain is equation solving, solver is rule based
  • the code underlying the User Interface
  • Student Model for maintaining information about
    the students knowledge over time (full
    disclosure we did not get to the point of
    implementing more than a placeholder for the
    student model component)

7
Evolving an ITS to the Web
  • We wanted to reuse our existing infrastructure
    and code as much as possible
  • We decided that there were advantages to having
    portions of the tutor reside in a centralized
    location common to all users --
  • e.g., single location for student model though
    students may log on from anywhere, the tutor
    always knows each students current knowledge
    level and position in the curriculum
  • single location for code means everyone always
    uses latest version eliminate code delivery
    logistics

8
Evolving an ITS to the Web
  • Wanted the UI component of the tutor to be highly
    interactive, responsive, and (hopefully)
    engaging, like the standalone tutor
  • required code running on the client machine

9
Evolving an ITS to the Web
  • There are lots of choices for implementing a
    Web-based app with distributed components or
    single executable (see the paper)
  • Due to all of the preceding constraints, we chose
    to
  • reuse as much of the standalone tutor code as
    possible, wrapping that into an application
    server
  • rewrite the UI component as a separate Java
    applet that would run on client machines

10
Evolving AlgeBrain to the Web
  • We started with our standalone tutors
    architecture

11
Evolving AlgeBrain to the Web
  • Eliminated the UI
  • component,
  • retaining the 3 other
  • components essentially
  • as is

12
Evolving AlgeBrain to the Web
  • Reimplemented UI component as a Java applet,
    executable in Web browser. Incorporates socket
    communication capabilities to talk to server.
  • This forms client
  • portion of the distributed
  • ITS architecture.

13
Evolving AlgeBrain to the Web
  • Implemented new module in server that
    "substitutes" for former UI component adds
    socket communication capabilities, and
    communicates with other server components as
    if it were the UI module

14
Evolving AlgeBrain to the Web
  • These 4 modules
  • -- very similar to our original standalone
  • design -- form
  • componentry of
  • server side of the distributed tutor architecture

15
Evolving AlgeBrain to the Web
  • Via communication over the Internet, the
    distributed
  • implementation behaves as a coherent whole
  • to users

16
UI Proxy Module
  • Roles of the UI Proxy in the server
  • handles socket communication (send/receive
    to/from "real" UI Module which now resides on
    client)
  • UI Proxy in essence "translates" client requests
    and sends requests to Tutorial Module in exact
    same form as when sent by standalone UI Module,
    i.e., as if sent by original standalone UI
    component (and v.v. UI Proxy accepts same input
    from Tutorial Module as did former UI Module and
    translates for client applet)
  • Hence, Tutorial Module behaves same as before --
    most code does not change!
  • (Same for Expert Solver and Student Module)
  • From standalone to application server with
    minimal changes to existing code

17
Evolving an ITS to the Web
  • Needed "language" for client/server to
    communicate
  • In standalone tutor, objects were in same memory
    space and so could just be passed around among
    objects (e.g., when user selects term(s) in eq,
    pass term object(s) to rule engine (Expert
    Solver) along with selected algebraic operation
    (e.g. "collect")
  • In distributed implementation, needed a way to
    communicate this sort of information between
    client server

18
Evolving an ITS to the Web
  • E.g., Client UI must inform server of student
    proposal for next algebraic operation
  • Current equation, which is represented internally
    by a tree structure, is linearized so each term
    has an ordinal position -- same process performed
    in both client and server
  • Then, when user selects term(s) and operator,
    client applet transmits something like this to
    server op\collect\4\5 where "4" and "5" are
    the ordinal positions of the selected terms,
    "collect" means 'collect like terms' op
  • General form for student proposed
    operator/operand op\operator\operand1\operand2
    \operand3

19
Evolving an ITS to the Web
  • Other examples of client-server 'language'
  • Client --gt Server "needHint" "needGraph"
  • Server --gt Client advicelthint
    stringgt" "neweqltequation stringgt" "rightltstudent
    proposal converted to a string1gt" "wrongltstudent
    proposal stringgt 1 e.g., "You proposed adding
    20 to both sides of the equation." These
    "right"/"wrong" proposal strings are posted to
    History View for student to later review her
    problem-solving activity.

20
UI Proxy Module
  • Again, serves 2 roles (actually 2
    sub-components)
  • network/socket communicator
  • translator

21
UI Proxy Module
  • User interacts with client UI (eg, pushes a
    button) client sends text msg to server

22
UI Proxy Module
  • User interacts with client UI (eg, pushes a
    button) client sends msg to server

23
UI Proxy Module
  • User interacts with client UI (eg, pushes a
    button) client sends msg to server

24
Standalone ITS
25
Browser-based Java UI
26
Alternative view of Web-based architecture -
(standard applet stuff)
27
Alternative view of Web-based architecture
28
Alternative view of Web-based architecture
29
Alternative view of Web-based architecture
30
Benefits of our approach
  • Students can access the tutor from a standard Web
    browser, need not own a copy of a standalone
    program -- eliminates logistical problems of
    distributing software to individuals
  • Use latest tutor code from anywhere, anytime (not
    just in school) (of course the "digital divide"
    impacts this, but hopefully libraries and
    community centers can take up slack)

31
Benefits of our approach
  • Student model for all users resides in a single
    location, on the centralized server, as opposed
    to having students models for different
    individuals on several different machines (within
    a school computer lab, for example)
  • Thus, though students may log on from anywhere,
    the tutor always knows each students current
    knowledge level and position in the curriculum
    and can use this information to inform problem
    selection and help content
  • Argues against implementing entire tutor in
    single client-based Java applet

32
Benefits of our approach
  • Java gives us animation for free (GIF animations)

e.g., used for animated AlgeBrain interface agent
and animated examples in Just in Time Dictionary
33
Benefits of our approach
  • Applet running on client allows for highly
    interactive user experience e.g,
  • intelligent selection of terms directly in
    equations with immediate visual feedback
  • interactive graphing component that responds
    immediately to user actions

34
Benefits of our approach
  • Perhaps most importantly
  • Web-based architecture we suggest adapts and
    extends an architecture for standalone ITSs that
    is in common usage
  • Limited modification to standalone architecture
    -- 3 of 4 modules remain largely unchanged --
    replace single (UI) component
  • As such it should facilitate the migration of
    existing standalone systems to the Web

35
Closing comments
  • Our architecture arose out of a project to
    convert an existing standalone tutor to a
    Web-enabled distributed system
  • The resultant architecture is certainly viable
    for constructing Web-enabled tutors from scratch
    (starting with nothing)
  • Nonetheless, remember that one of our subgoals
    was to reuse as much existing code as possible
  • If we were building a Web-enabled tutor from
    scratch we would consider the following choices
  • Use the same architecture as we have used, but
    perhaps implement the server component as a Java
    servlet (Java uses native OS threads for
    multitasking Smalltalk simulates multiprocessing
    itself and does not use native threads)
  • Perhaps, experiment with shifting some
    componentry from server to client
  • But, in any case, we would keep student model
    on server so student can use the tutor from
    anywhere, and tutor would have continuous
    representation of her knowledge and location in
    curriculum
About PowerShow.com