Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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}@watson.ibm.com Porting an ITS to the Web Problems: Building intelligent educational software is difficult and time-consuming Despite >¼ 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 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 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: We’ve already built a standalone tutor Solution: Convert existing tutor to be Web-enabled Standalone ITS 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 tutor’s 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 student’s knowledge over time (full disclosure: we did not get to the point of implementing more than a placeholder for the student model component) 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 student’s current knowledge level and position in the curriculum single location for code means everyone always uses latest version; eliminate code delivery logistics 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 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 Evolving AlgeBrain to the Web We started with our standalone tutor’s architecture Evolving AlgeBrain to the Web Eliminated the UI component, retaining the 3 other components essentially as is 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. 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 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 Evolving AlgeBrain to the Web Internet Via communication over the Internet, the distributed implementation behaves as a coherent whole to users 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 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 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…]…] Evolving an ITS to the Web Other examples of client-server 'language': Client --> Server "needHint" "needGraph" Server --> Client: ”advice:<hint string>" "neweq:<equation string>" "right:<student proposal converted to a string1>" "wrong:<student proposal string>” 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. UI Proxy Module Again, serves 2 roles (actually 2 sub-components): •network/socket communicator •translator UI Proxy Module User interacts with client UI (eg, pushes a button); client sends text msg to server UI Proxy Module User interacts with client UI (eg, pushes a button); client sends msg to server UI Proxy receives ASCII message on socket & sends translated msg & data to Tutorial Module as if sent by original UI Module UI Proxy Module User interacts with client UI (eg, pushes a button); client sends msg to server UI Proxy receives ASCII message on socket & sends translated msg & data to Tutorial Module as if sent by original UI Module Opposite direction involves same sort of translation by Proxy: Tutorial Module sends msg/data to UI Proxy, which sends "translated" msg to Java Client Standalone ITS Browser-based Java UI Alternative view of Web-based architecture - (standard applet stuff) Browser user surfs to the URL for the tutor Browser issues HTTP "Get" request to server HTTP server sends HTML file -- with embedded Java applet -- to browser Alternative view of Web-based architecture Browser requests Java code from server and server serves it up Alternative view of Web-based architecture Browser starts AlgeBrain Java applet/client -applet retrieves image and sound files from server Alternative view of Web-based architecture Java client opens socket connection with AlgeBrain server component for all subsequent communication 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) 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 student’s 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 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 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 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 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