INTELLIGENT ACTIVE COACHING AN EXECUTABLE PLAN APPROACH

Transcription

1 INTELLIGENT ACTIVE COACHING AN EXECUTABLE PLAN APPROACH S. A. Gamalel-Din Al-Azhar University, Systems & Computers Engineering Dept. قرب. يو من رجال التعليم ا ن التعليم التفاعلى الذى يعتمد على وجود المدرس مع الطالب يعطى نتاي ج ا فضل من طرق التعليم الا خرى. فى التعليم التفاعلى يقوم المدرس بدور المدرب الذى يوجه الطالب ويقيمه ويساعده على حل المشكلات كوسيلة تدريب عن فى هذا البحث يراقب "المدرب الذكى" الصحيحه ا و ا لى ا همية مراجعة بعض المواد الدراسية. الطالب ا ثناء حل المساي ل والتمارين ويوجهه ا ذا لزم الا مر ا لى طرق الحل وبذلك يوفر هذا المدرب الذكى البعد التفاعلى فى برامج المفقود التعليم الا ليه وخاصة على شبكة الا نترنت. ABSTRACT. Many educators believe that the most effective means for teaching is through one-on-one interactions with students. It is not surprising, then, that an effective way to teach programming is to give students immediate feedback on exercises and problems that they have just solved. Unfortunately, such one-on-one teaching scenarios are becoming increasingly difficult to arrange. Computerized coaching is in urgent need to overcome such difficulties. Intelligent computerized coaches would monitor student actions during problem solving sessions and advise him when needed. In this article, we introduce an Intelligent Coaching System (ICS) that we called it Smart Coach and that is supposed to integrate to ITS systems. Smart Coach is a prototype that is implemented to support students studying Lisp programming. In this research we identify the characteristics of an intelligent coaching system as opposed to other active support systems, such as intelligent assistants and active intelligent help systems. We also introduce a novel approach for action plan recognition, which is more suitable for the special characteristics of coaching systems. This approach is based on architecture of an executable Action Plan Machine (APM) that arranges planned actions into a DFD network of active nodes. This novel architecture made the plan recognition process as well as student advising easily automated. Smart Coach organizes instructor s pre-defined plans in a breakdown Action Plan Hierarchy (APH) of an AND/OR tree. New correct plans that student introduce are learned by the system to automatically enrich its knowledgebase. The novel architecture of Smart Coach allows it to give students comprehensive reports on their performance. Those reports use graphical depictions of expert s as well as student s action plans so as to provide improved communication and hence powerful and effective coaching. KEY WORDS: Intelligent Tutoring Systems, Intelligent Coaching, Active Help Systems, Plan Recognition, Case-based Reasoning, Intelligent Assistant Agents, Dataflow Graphs, and Student Models. 1. INTRODUCTION. Computer-based learning environments appeared decades ago [4] with one advantage over human tutors, which is individualized interactive learning support. Such systems have utilized multimedia and GUI interfaces to facilitate the individualized learning process. Since then researchers and industry have worked hardly to improve the computerized learning process. Incorporating artificial intelligence technology was one of the directions of improvement that resulted in a new generation of tutoring systems that are called Intelligent Tutoring Systems (ITS). ITSs attempts have provided more effective personalized training. The research directions in the area of ITS has several interests that mainly focus on how to present the training material to the student in a more effective manner that best matches his profile [1]. ITS systems do not provide support to on-the-job training that is considered as a major technique in professional training. In

2 other words, ITS systems focus on the knowledge component of training and ignore the coaching component. Studies [17, 18, 19, 20] have revealed that immediate feedback coaching of controlling tutors in problem-solving yields the most efficient learning model than those that do not provide such feedback. Those students who received coaching advises were able to complete the testing and training problems the fastest and hence, these researches suggested that explicit guidance is required to improve the efficiency of training. This observation had motivated our research. In this research we focus on what we analogously called it Intelligent Coaching Systems (ICS) that attempt to cross the coaching gap in ITSs. In this article we present an ICS prototype for coaching Lisp programmers, though the framework presented is more of generic. We called this coaching prototype Smart Coach (SC). Conducting an analogy between human tutors and human coaches could help identifying differentiators between ICSs and ITSs. A coach watches the trainee at work and provides coaching support when need is either requested by the trainee or recognized by the coach. In contrast with ITS systems, ICS does not only evaluate the student based on his final responses to quizzes and exercises but also on the ways and plans he considered in reaching those responses. A student might reach a problem solution correctly, however, the coach doesn t accept his followed approach, as it doesn t match the taught concepts that were the subject of the current training. In addition, ITS systems do not usually interfere with the student during his exercise session while a coach interferes for several reasons among them are correcting misconceptions, providing hints and supports, increasing the student moral, and highlighting better or more advanced approaches [2]. Therefore, a coach should be active, alert, and ignited all the time during problem solving sessions that are the only in-duty periods for a coach. On the other hand, we have recognized that coaching has several features in common with both active help systems [8] and intelligent assistants [3]. Such systems monitor their users, predict and evaluate his action plans, and give him advices on correct or more optimum directions. The following discusses some of the major unique characteristics of an intelligent coach in contrast to both help and assistant systems. This discussion is aimed at highlighting the design directions of an ICS system: The coach does not care to be maximally helpful since its learning goal outweighs the goal of having the task done [3]. If a coach sees that a particular action needs to be done next, unlike an assistant, it doesn t have to interfere immediately, but rather waits and gives the student a chance to come up with a next action on his own. When there is an action to be done, the coach usually decides to let the student do the action himself; though it might point him to the direction or to helpful reference material to review. Coaches should be able to suggest what to do next. This is identified through monitoring the student actions and steps taken in solving the problem, predicting the action plan, and correcting paths whenever needed. Coaches explain why a certain suggestion is made; this establishes deeper understanding and transfers the coach experience to the student in a practical fashion. An effective strategy is to provide the student with high-level hints, when required, and leave the student to dig the details himself. A coach may as well provide the student with low-level detailed help only to manage frustrations and moral. In some cases, learning by example may be the mechanism a coach sees more appropriate; so demonstrating how a similar problem could be tackled is an essential capability of an intelligent coach. Smart Coaches, unlike assistants and critiquing systems, should be able to provide the appropriate level of mentoring according to the student level and profile, and hence should be interacting with the student model in a bi-directional fashion. This means that what is considered sub-optimal action plan for an advanced student may be considered as just appropriate for a novice. Because the student is still in his training stage, he might not follow a correct plan straightforwardly, but rather he might switch back and forth from one solution plan to another till reaching a final solution. In fact, this specific feature is an essential differentiator and a key driver to our novel approach of action plan tracking.

3 Because of these similarities and dissimilarities, techniques used in the areas of intelligent assistance and active sensitive help systems have been borrowed in designing the Smart Coach prototype, yet adapted to suit these unique characteristics. We found a need for active machines to support the active behavior of the coach, hence, we have introduced what we called it Action Plan Machines that are executable and dynamically constructed plan models. Those machines are networks of intelligent components that automatically detect student actions and predict his solution plans, and hence, give him the appropriate feedback and support expected from a coach. In Section 2 we review some related work, while in Section 3 we introduce the proposed model for the intelligent coaching system. In this section we review the proposed Action Plan Hierarchy and Action Plan Machine, and study how they act at execution to provide the appropriate expected feedback. In Section 4 we review the agent-based architecture of the environment that is to accommodate the active machine. The conclusion is discussed in Section BACKGROUND AND RELATED WORK. Two decades ago, researchers have recognized the need for more active help systems to support computer users more intelligently as opposed to the older generation context sensitive help. This support took different shapes: active help, critiquing systems, intelligent assistant systems, and tutoring systems. Action plan recognition took a wide space of those researches and is considered a core component of such systems. In this section, we review some earlier research work along those directions. An early research direction for helping users to fulfill their goals was in the area of critiquing user actions as a method of educating the user of better ways of fulfilling his goals. In critiquing systems the user is advised and the decision is left to him whether or not to follow the advice. Fischer et al [12] have introduced one of the early works in the area of critiquing systems. They had developed Janus as their first prototype for investigating their new approach of critiquing. Janus is a knowledge-based system that provided critiques to engineers designing kitchens. A comprehensive survey is done by Siverman [11] who have presented a survey of expert critiquing systems for which he laid down a general framework. In his study, he reviewed and compared over 11 systems that he reviewed their theories, concepts, philosophies, and techniques. Another early research area is in intelligent help systems. Intelligent help systems are Knowledge-based, while active help systems are planner-based systems. Some help systems might contain both. Fischer et al [8] had classified help systems into passive and active systems. They defined Active systems as those that not only respond to user errors but also notice user s sub-optimal actions and give him an advice accordingly. Activist is their early prototype for an active help system for users of the EMACS editor. Silber [9] has introduced PAL, an active help system that is linked to a molecular design support system. PAL not only provides active help for sub-optimal plans but also personalizes its help to the user s model. PAL, like Activist, had used finite state transition automata to follow up on the user actions. Quinn and Russell [10] discussed the requirements for a strong user model and provided an example of how such a model might be integrated into a planner-based intelligent interface. Research in help systems continued till recently. Hefley [13] have reviewed few help systems: Apple s GUIDE, Eurohelp, Microsoft help, and other systems in an attempt to classify help systems and come up with taxonomy. Knight, Kilis, and Cheng [14] have proposed an intelligent active help system (IHS) for text editors with GUI interfaces. The architecture and the various components of the system are described. These included the user and expert modeling, plan recognition, and guidance generation. Quast [7] introduced HYPLAN as an intelligent help system for Excel. HYPLAN used AND/OR trees for modeling the structure of a plan while timing constraints are described in relational expressions. Intelligent assistants are another research area that is highly related to coaching. AISA [6] provides intelligent assistance to business executives and administrators. Gutierrez and Hidalgo in their article have provided an overview of AISA with emphasis on the module that proposes to administrator the next item that he should give attention to, and also suggests to him the appropriate action to perform with respect to that item. Expertise in the domain is represented by Horn-clause declarative knowledge that could be expanded incrementally. AISA is a collaborative multi-agent system that employed both breakdown and opportunistic

4 problem solving approaches. Davis et al [3] have introduced an intelligent assistant for air travel planning applications. This assistant is built using collaborative interface agents. In their article, they also shed light on several of the characteristics that differentiate an assistant from a tutor, which have been considered in our research. Yet some researchers have recognized the power of instant feedback to students/users as a tutoring mechanism. Shaw et al [2] introduced Adele, a pedagogical agent that is designed to support students working through problem-solving exercises that are integrated into instructional materials delivered over the Internet. Adele support medicine students and physicians during diagnosing simulated patients. Adele design is agent-based that employs the opportunistic problem-solving approach. It organizes plans into hierarchies and allows physicians to perform actions in whatever order they wish. It used functional descriptions and the pre/post conditions approach to express plans. Shah and Kumar [15] presented a tutoring system that teaches parameter passing mechanisms to programmers. This research was interesting to ours as it works in similar domain as that selected for our prototype, namely, teaching functional programming languages. This tutoring system was able to automatically generate problems (in this case programs with functions and parameters) as parameterized instances of predefined templates, specified in pseudo-bnf notation. In addition, InSTEP [16] is an online tutoring system for beginning C programmers. In their research with InSTEP, Hash and Zachary have studied the effect of the constructivist effect of immediate feedback on the effectiveness of the tutoring process. InSTEP is unlike our approach in which it does not monitor student actions but rather compiles the student programs and return the compilation results if it is not passed. If compilation is passed correctly, InSTEP runs it against test cases and reports the results to the student. ACT [20] is a cognitive tutor that helps students learn to write programs in Lisp, Prolog, and Pascal. ACT specifies plans in terms of productions. Corbett and Trask have conducted experiments on ACT students to evaluate the effect of feedbacks and model tracing on the efficiency of learning. Their results were in favor of coaching. 3. THE INTELLIGENT COACH ACTION PLANS MANIPULATION. Users interact with computer systems in multi-different ways and for so many reasons. They do so for achieving certain tasks and reaching specific goals. In this process the user interacts with the computer system via a sequence of actions that take the shape of commands or events. The user when doing those actions is following a certain action plan that he believes should lead him to the goal. Monitoring user actions and predicting his action plan is a key to helping and assisting him. Therefore, action plan recognition is an essential component that must exist in all active help systems, assistance systems, and critiquing systems. Fortunately, coaching share this property with those systems except with few major differences that make the techniques used by those supporting systems not ideal for a coaching system. In coaching systems, the action plans have some unique characteristics that motivated this research to identify a better approach for predicting the action plan followed by a student to solve a certain given problem. Some of these characteristics can be highlighted as follows: The goal is already known in advance; it is the solution to the given problem. Therefore, the coach is not puzzled with what the student is trying to achieve. Knowing the goals in advance, means that the space of solutions, and hence action plans, is limited and known. From among the space of known solutions and action plans, the student previous knowledge, with a focus on those subjects under current training, will further narrow down the space to a subset of the solution space. Those characteristics led this research to a novel approach for handling student action plans, though inspired by some previous works. In the following sections, we discuss how Smart Coach handles action plans recognition through using an executable Action Plan Machine (APM) that is designed specifically for that purpose Plan Hierarchy: Researchers have identified several problem-solving strategies. Simon [5], the Godfather of AI, had identified problem reduction as the most commonly used technique. Problem reduction is the technique of decomposing a problem into a set of easier-to-solve sub-problems. This is also called the top-down

5 structured approach. This approach could be translated into a hierarchical structure representation where the root node is the goal and all intermediate nodes are the sub-goals and the terminal leaves are the primitive actions or events. A sub-goal node can also be viewed as a root of a sub-tree for solving a reduced problem, the sub-goal. It should be noted that most problems might be solved by several correct ways. The student needs to follow only one single approach of them. Accordingly, AND/OR tree was the structure of our choice to represent action plans; we called it the Action Plan Hierarchy (APH). The instructor identifies an APH for each problem. The root of the tree represents the problem s main plan. The next level below the root is either OR or AND branches but not both: AND branches indicate that this plan requires all the sub-plans to be done to achieve its goal, and OR branches indicate that there are several possible correct sub-plans. Similarly, all intermediate tree nodes are recursively defined. The leaves of the tree are the student actions or events that are required to achieve the action plan. Figure 1 illustrates this structure with the aid of a Lisp example. It is worth noting that the Action Plan Hierarchy is a top-down breakdown structure while student actions lie at the bottom of the hierarchy and hence, plan recognition goes bottom-up, which adds to the complexity of coaching job. The Problem: P Write a Lisp function call that takes the lists (a b c), (d e f), and (g h i j) and returns (a f e d i j). Two Solutions Solution 1: (cons (car (a b c)) (append (reverse (d e f)) (cddr (g h i j)) ) Problem Breakdown AND/OR Action Plan Hierarchical Structure S1 P S2 Plan Recognition Solution 2: (append (rplacd ( a b c) (reverse (d e f)) ) (nthcdr 2 (g h i j) ) e iv Strategies Strategy S1: a. Extract a from (a b c). b. Reverse the list (d e f). c. Extract the sub-list (i j) from (g h i j). d. Combine 2 lists into ( f e d i j). e. Combine into the final list (a f e d i j). Strategy S2: i. Reverse the list (d e f). ii. Combine 2 lists into (a f e d). iii. Extract the sublist (i j) from (g h i j). iv. Combine into the final list (a f e d i j). b d c Elementary Actions Indexing and Coaching Information Supported Topic: T9 Tested Student Level: intermediate Node S1.b: (a section for each node) Reference Material: T5, T2. Messages: expert: xx, intermediate: yy,. etc.. etc. etc a reverse append cddr nthcdr2 car replacd cons append Figure 1: A Problem Case Frame for a Lisp Example. iii ii i The APH is a representation for the static structure of the problem breakdown, i.e., the composition of solution plans into their constituent sub-plans. In addition, plans are usually interacting with each other. The student not only must perform those sub-plans in a specific order but also might switch from one plan to another back and forth until reaching the final goal. For an automated coach to judge the student s solution plans, the sequence of actions is as important as the breakdown structure. Sequences of actions are represented by what we called it Action Plan Machine (APM). In the next section, we discuss the different interaction types between action plans that led to the design of the APM that is reviewed in the following section.

6 3.2. Interacting Action Plans: Action plans may not only have multiple threads but also might interact with other actions or sub-action plans whether intentionally or unintentionally. Two action plans can have one of the following interrelationship models [6]: Conjunctive and parallel: the two action plans are concurrent and coordinating to reach the goal. Conjunctive and serial: the two action plans are coordinating but should run sequentially one after another. Disjunctive and parallel: the two action plans are different alternatives for the solution plan and the student tries them alternately. Disjunctive and serial: the two action plans are alternatives but there is one that is either commonly or expectedly used. Priority might be entailed and preferred by the instructor as to support the currently studied subjects. This classification is still insufficient for plan recognition. Plans interaction during execution follow indefinite scenarios [7]. Those scenarios can be further modeled as shown in Figure 2. Figure 2 presents each model with a briefing, a Gantt chart, and a supporting example of plans from the example of Figure 1, if any. It is worth noting that both overlapping and unstructured branched plans interaction models are not usually followed except at execution time when a struggling student tries different action plans in a hope to reach a solution. This is an expected behavior because the student is still in his training process and is not necessarily mastering the techniques and concepts of the current training. Embedded Plans: One plan is fully a part of another overlapping plan. Branched Plans: An action plan branches to another action plan and then resume later. Unstructured Branched Plans: Branched plans that cannot be stacked.. Overlapping Plans: A sub-plan is a suffix for one plan and prefix for another. plan 1 plan 2 plan 1 plan 2 plan 3 plan 1 plan 2 plan 3 plan 1 plan 2 Figure 2: Interacting Action Plans Plan 1: append : S1.d Plan 2: reverse : S1.b Plan 1: append : S2.iv Plan 2: replacd : S2.ii Plan 3: reverse : S2.i These types are due to trial and error approach of a student who is not yet at the target mastering level. Therefore, action plans heavily interact with each other. Furthermore, the interacting plans are not necessarily among the solution plans of the given problem; students are still at their learning processes. Recognizing those new active plans and identifying the correct directions by the coach in order to provide the appropriate coaching assistance is then troublesome and is a complicated process. Static representations of the plans will not sufficiently support the monitoring and hence the predicting processes. In the following section we present a novel approach for that purpose that introduces what we called it Action Plan Machine (APM) an active and executable Dataflow machine that is designed specifically for expressing and evaluating interacting action plans at their run The Executable Action Plan Machine: The plans of Figure 2 indicate that students mostly follow several interacting threads when solving problems. Some of those threads might be in the correct direction and are actual sub-plans towards the final solution, while others have nothing to do with the solution and are only investigative trials in the learning process. Multiple threads are usually active concurrently and the student swaps from one thread to another. In fact, the picture is much cluttered for complex problems where so many threads are active concurrently; a snapshot might have new threads created, others are given up, and yet others are acting in the middle. Concurrency is the theme. Therefore, our research has investigated the use of Dataflow graphs (DFG) as an active pictorial means for representing such concurrency behavior, and hence, has introduced what we called

7 it Action Plan Machine (APM) as adapted from DFG. The graphical depiction of action plans by APM is not only easy to construct by instructors but also easier to communicate solution strategies to students. The constructs of the APM are only action nodes and directed links. Each action node represents one strategy step (or sub-strategy) of the problem solution. Those action nodes are connected together through the directed links to compose an Action Plan Network (APN). The action nodes in an APN are organized in such a way to reflect the order of execution for a correct plan. Therefore, both sequences and concurrencies are natively represented. The inputs to each action node are the parameters (or data) required for that substrategy to work; hence, it might be an external input data or an intermediate result from another interlinked intermediate sub-strategy. Alternative strategies (OR branches in the Action Plan Hierarchy) are represented by separate nodes internal to the mother strategy node. The inputs to the mother strategy node are also inputs to each alternative substrategy, and so are the outputs. Figure 4 depicts an Action node for the sub-strategy S1.c or S2.iii of the example of Figure 1. Those alternative nodes are mutually exclusive. The construction process of APM starts from the Action Plan Hierarchy. Each action node in the APM corresponds to a strategy node in the APH. AND nodes are interconnected by links to their mother strategy node in the tree. OR nodes are alternative action plans that are represented internal to their mother node in the tree. Associated with each action node is its corresponding terminal action in the tree. Also input data are represented as input links. In fact, A node is an active actor that contains all necessary information for the coach to perform its job, e.g., messages, coach responses, etc. Therefore, each action node is an active mini-coach for the sub-goal it represents. It is worth noting that the constructed machine can be verified for consistency by verifying that all inputs to the modeled sub-strategy are consumed by the different action nodes. Figure 3 demonstrates two interacting APMs for the example of Figure 1. Note that some nodes exist in both machines expressing common sub-strategies. (g h i j) S1.c (d e f) S1.b S1.d S1.e cdr cdr (a b c) S1.a (g h i j) cddr (d e f) (a b c) S2.i S2.ii S2.iv nthcdr (g h i j) S2.iii Figure 3: Example APM Figure 4: Nested Alternative APM for Strategy S1.c 3.4. The Action Plan Machine at Run: The APM is an active machine that when initiated executes. Student actions drive the machine from one state to another. The initial state of the machine places tokens at each input to indicate the availability of those input parameters at the student disposal. Associated with each action node is an activation action, e.g., node S1.b has the activation action reverse, which if the node is triggered and the student action matches that activation action, the node is fired to pass a token to its output links. A node is said to be triggered if tokens exist at its entire input links. This way, tokens navigate through the APN tracing the student actions and hence, automatically highlighting his action plans. Each token carries a time stamp so that event/action orders are identifiable.

8 An action node can be in any one of three possible states: Inactive: no tokens at its input links. This means that the strategy represented by that node is not yet recognized by the student. Triggered: either partially or fully when some or all of its input nodes carry tokens. A fully triggered node is awaiting the proper student action to fire. Fired: when the node is fully triggered and the activation action occurred. The state of each action node identify the appropriate coach response to the student for the different events, such as time-out (no action for a pre-specified time), help (student asks for help), and hint student asks for a hint). Table 1 reviews some possible coach responses for triggered nodes as per Smart Coach. Of course, these responses are part of the definitions of the active action nodes and hence, responses are made automatically by those active nodes themselves based on their current states. Table 1: Smart Coach Responses to Student Events. Partially Triggered Fully Triggered Time-out Help Hint Suggest actions for triggering Forward him to reference one or more of the input links. material and concepts to fire Follow links backwardly. backwardly connected nodes. backward action nodes. Suggest the appropriate Forward him to reference activation action. material and concepts for the appropriate activation action. Do the appropriate activation action to fire one of the Do the appropriate activation action to fire the action node in behalf of the student. The Explanation Component of Smart Tutor reports the student performance at the end of each problem session or upon the student request. The report contains the sequence of student actions ordered according to their corresponding tokens time stamps. Each reported action is remarked by the coach to highlight tutoring instructions and comments. The plans diagram with highlighting the activated nodes and augmented with the user actions, events and results is also reported to the student. This diagram is considered an effective and powerful coaching and communication tool. Closely studying the APM at run, two complex situations might occur. The first, when a single activation action fires more than one action node at the same time. If the fired nodes are of the same action plan, the underneath environment should detect it and hence interrogate the student to resolve the ambiguity. On the other hand, it is possible that those fired nodes be at different action plans, at which case the APM fires all nodes but marking them as unsure-fired; and it waits until successive student actions are clearly following a specific plan, at which time all related unsure-fired nodes are unmarked. To explain, reverse activation action in the above example will lead to marking both action nodes S1.b and S2.i as unsure-fired until the successive actions indicate which of the two plans, S1 or S2, is the one that the student intended. The second complex situation, when an action that does not belong to any of the predefined plans is activated. This unknown action may be incorrect action, but it may also be part of a correct plan that is not considered by the instructor. In such case, new action nodes are dynamically added to the APN as student actions progress, e.g., the cdr cdr node of Figure 4. Those dynamically added action nodes, and hence plans, are specially marked as unknown-plan. If it turned out that the unknown-plan is a correct one, the learning component of Smart Coach uses it to update the knowledgebase and the solution space by accommodating this new plan in both the APH and the corresponding APM. 4. SMART COACH ARCHITECTURE. Smart Coach is a component of the Smart Tutor ITS system (ST) [1]. Figure 5 demonstrates an agent-based high-level architecture for Smart Coach where its integration to both ST and the Student Model is also shown. In this design, the Coach Agent (CA) and the APM Processor (APMP) are the heart of the system. The CA receives the coaching requests from ST as required by the selected tutoring strategy and approach. CA fetches one of the coaching problems supporting the Lectlet under study from the Problem Bank (PB). PB contains problem frames as indicated by the example of Figure 1. The chosen problem frame contains the APH for the different known solution strategies for the chosen problem. From the APH, the CA

9 composes the APN and passes it to the APMP. Simultaneously, The Coach Agent presents the problem statement to the student via the Coach Interface Agent (CIA). Each student action is then tracked by the APM Processor that uses the Working APN storage for that purpose. New student plans that were proven correct and that were not previously considered by the instructor (or the course designer) would then be Smart Tutor ITS Problem Bank Update Frame Coach Agent (CA) Smart Coach APM Processor (APMP) Coaching Interface Agent User Modeling System History Plan Cases Base Reporting & Explanation Agent Working APN Figure 5: Smart Coach System Architecture identified by the Coach Agent and hence, used to update the problem frame in the Problem Bank. Student actions may take many forms: solution actions and event-request actions. The student can interact with his coach through a set of interface buttons through which he can ask for: Hint, Help, or even go back to the ITS for reviewing certain material. The CA detects when the students take longer than expected for the next move and accordingly issue a time-out event. Based on the state of the APM the CA responds as indicated by Table 1. In addition, the student can request a report on his performance to which the CA reviews the Working APN and the token time stamps, and then reports a full detailed history of the student actions and events during solving a specific problem. The APN is also drawn augmented with the correct path, followed paths, and coaching comments for each incorrect or unjustifiable student move. In responding to the student requests, the CA considers the student mode: his cognitive model and mastery level. It also takes into consideration the student problem-solving history. Previously solved problems or sub-problems are treated differently than those faced for the first time. Historical Plan Cases are retrieved by the CA and presented to the student either when he is stuck or when he used a different correct/incorrect plan. The environment supporting Smart Coach is an agent-based having several cooperative agents. 5. CONCLUSION AND FUTURE WORK. We quoted the term Intelligent Coaching Systems (ICS) to represent those educational systems that monitor the student actions during problem-solving sessions, predict his action plans and solution strategy, interfere to advise him or to suggest directions and/or reference materials. In this paper we present the ICS Smart Coach part of the Smart Tutor ITS system that coaches students studying Lisp programming, though the concepts and design presented in this paper are generic. Smart Coach is a prototype that is partially implemented using WASP machine technology and is written in the C language. It has been recognized that although there are several common backgrounds between ICSs and intelligent help and assistance systems, there are also unique features that make the design of ICSs different. A major differentiator is the hesitation mode that usually dominates student s problem-solving sessions due to the learning process in effect, which results in the student activating many action plans and swapping from one plan to another abruptly as a means of investigation. Therefore, plans are unclear, although mostly known in advance. In this research we have introduced the Action Plan Machine (APM), an executable plan representation that is dynamically created and executed to track student actions and automatically identify his solution plans. Dataflow graphs

10 are the bottom line of the APM, while AND/OR trees are used for expressing expert s solution plans. Casebases are used to store student experience in solving problems and sub-problems. This research convinced us more that intelligent coaching is an effective component that would empower e- training systems considerably. However, experimental work still needs to be conducted to assess the amount of leverage achieved by employing ICS components. REFERENCES. 1. S. Gamalel-Din, The Smart Tutor: Student-Centered Case-Based Adaptive Intelligent e-tutoring, in the Proceedings of the First International Conference on Informatics and Systems, INFOS E. Shaw, W. Johnson, and R. Ganeshan, Pedagogical Agents on the Web, in the Proceedings of the Third Annual Conference on Autonomous Agents, J. Davies, A. Gertner, N. Lesh, C. Rich, C. Sidner, and J. Rickel, Incorporating Tutorial Strategies Into an Intelligent Assistant, in the Proceedings of the 6th International Conference on Intelligent User Interfaces, R. Waters, The Programmer s Apprentice: knowledge-based Program Editing, in Interactive Programming Environments, ed. B. Barstow, H. Shrobe, and E. Sandewall, McGraw-Hill, Inc., H. Simon, The Science of Artificial Intelligence, MIT press, second edition, C. Gutierrez and J. Hidalgo, Suggesting What to Do Next, in the Proceedings of the 1988 ACM SIGSMALL/PC Symposium on ACTES, K. Quast, Plan recognition for Context Sensitive Help, in the Proceedings of the 1st International Conference on Intelligent User Interfaces, G. Fischer, A. Lemke, T. Schwab, Knowledge-based Help Systems, in the Proceedings of the CHI '85 Conference on Human Factors in Computing Systems, J. Silber, PAL: An Intelligent Help System, in the Proceedings of the Third International Conference on Industrial and Engineering Applications of Artificial Intelligence and Expert Systems - Volume 2, L. Quinn and D. Russell, Intelligent Interfaces: User Models and Planners, in ACM SIGCHI Bulletin, Conference Proceedings on Human Factors in Computing Systems, B. Silverman, Survey of Expert Critiquing Systems: Practical and Theoretical frontiers, Communications of the ACM, Vol. 35, No. 4, April G. Fischer, A. Lemke, T. Mastaglio, A. Morch, Using Critics to Empower Users, in the Proceedings of the Conference on Empowering people: Human factors in computing systems: special issue of the SIGCHI Bulletin, March W. Hefley, Helping Users Help Themselves, IEEE Software magazine, Vol. 11, No. 2, March/April G. Knight, D. Kilis, and P. Cheng, An Architecture for an integrated Active Help System, in the Proceedings of the 1997 ACM Symposium on Applied Computing, H. Shah and A. Kumar, A Tutoring System for Parameter Passing in Programming Languages, in the Proceedings of the 7th Annual Conference on Innovation and Technology in Computer Science Education, E. Hash and J. Zachary, Automated Feedback on Programs Means Students Need Less Help From Teachers, in the ACM SIGCSE Bulletin, Proceedings of the Thirty Second SIGCSE Technical Symposium on Computer Science Education, Volume 33 Issue 1, February A. Corbett, J. Anderson, Locus of Feedback Control on Computer-Based Tutoring: Impact on Learning Rate, Achievement, and Attitudes, Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, U. Abdullahi and J. Alty, How Useful is Online Help? An Observational Study, in the Proceedings of the Australian Computer Human Interaction Conference, R. Amant and M. Dulberg, An Experiment with Navigation and Intelligent Assistance, in the Proceedings of The 3rd International Conference on Intelligent User Interfaces, A. Corbett and H. Trask, Instructional Interventions in Computer-Based Tutoring: Differential Impact on Learning Time and Accuracy, in the ACM CHI Letter, the Proceedings of the CHI 2000 Conference on Human Factors in Computing Systems, Vol. 2, issue 1, April 2000.