El AC como modelo pedagógico en EF

TANDEM is the environment for the definition, testing and production of procedural skill based tutoring systems. Its basic methodology can be split into three distinct components, namely a domain environment definition tool (the domain construction environment (DCE)), a domain

independent tutoring engine (the general domain interpreter (GDI)) and an interface development component. The use of TANDEM by an author to develop a tutoring system can be viewed, at a basic level, as a sequential flow through these components (Figure 6.2).

DCE GDI

Interface Domain Domain

Development Construction Testing I Use

Figure 6.2 : Basic authoring sequence.

Finished System

Unfortunately, the progression through the development process is not so straight-forward. Due to the nature of domain definition, an interactive prototyping approach is more appropriate.

Initial Domain Representation Initial Set of Student Models Extended Set of Student Models Dialogues Final Set of Student Models I . Construction of domain representation by designer. 2. Development of minimal initial set of domain model by designer. 3. Incremental refinement and extension of error set by a series of dtalogues. 4. Inclusion of the models developed in the fimshed ITS.

Figure 6.3 : The Natural Laboratory; from Cerri, Cheli & Mclntyre (1992). The definition process in TANDEM is primarily concerned with the construction of models, eg. domain and task models. In this, it is similar to the Na tural Laboratory methodology as used by Cerri, Cheli and Mclntyre (1992) in their development of student models for the Nobile

p roject. The objective of this methodology is the incremental construction and refinement of student models. The basic steps to be performed can be seen in Figure 6.3. An initial model is defined and then evaluated. Incremental refinement is then used to expand the models until a final set of models have been developed.

In line with the idea of incremental construction and refinement of models is the work discussed by Kemp (1995) . He presents some preliminary work in the area of a procedural task tutor design system and provides an automated scheme for developing a procedural task tutor (Figure 6.4).

Design domain simulation using plan nets

Produce action table representation of simulation

Test domain simulation

Produce graph

from action table

Specify domain task(s) using overlay on projection graph

Test domain and task simulation using action tables

and SCRs for data

Figure 6.4 : Automated scheme for developing a procedural task tutor; from Kemp (1995).

The domain expert defines the behaviour of the environment and then incrementally tests and modifies the design until an acceptable model has been constructed.

Kemp's scheme continues his focus on the separation of domain and task, with the first three processes in his automated scheme concerned with the domain model and the next three concerned with developing the task model. The final process is the testing of both the domain and the task for model acceptance by the author.

Although this scheme was developed in conjunction with several pre­ TANDEM implementations (Smith, 1994a; Smith, 1994b; Smith, 1994c; Smith, 1994d; Smith, 1994e), a more complex scheme is necessary for the current TANDEM implementation (Figures 6.6-6.8). This scheme has been developed to allow automated validation of portions of the domain representation. Also the incorporation of addition feedback allows the developer a complete construction environment. Domain and task separation are again emphasised and an interface definition section has been included. Figure 6.5 is a high level view of the process flow for using TANDEM.

Task

Domain Interface

Figure 6.5 : High level view of the TANDEM methodology.

Each of the components of Figure 6.5 can be decomposed into its own diagram describing domain, task and interface components of the TANDEM methodology (Figures 6.6-6.8). In these figures, the boxes represent user processes while the bold text items are performed by the system.

Domain

Plan Nets Define _{Static Axioms} Domain _{Initial Situation}

Check the syntax of

the domain model

Test Step through actions and _{see the condition changes}

Conditions _{in the Plan Nets} Report inconsistencies

in the domain model

Test Use TANDEM

Domain tutoring engine

Report inconsistencies

in the domain model

Accept

Domain

POP table

Produce POP table

Figure 6.6 : Domain component of TANDEM.

Task

Generate condition hierarchy

Define

Tasks Task Model

Generate projection graph

Define

SCRs SCRs

Situated Control

Rules

Produce SCRs/STM

Student Task Model

Interface

Default Choose

Textual Custom

Interface Interface

Interface

Interface Template Template

Figure 6.8 : Interface component of TANDEM.

Rapid prototyping was used as the base methodology for the TANDEM implementa tion since, although the features and components of TANDEM had been defined, the usability of the environment was relatively unspecified . Prototyping is a useful technique for software development when system requirements are unclear (Humphrey, 1995, Sommerville, 1996; van Vliet, 1993) . Figure 6.9 shows the TANDEM implementation cycle. Through this cycle, the components of TANDEM were iteratively re-implemented. This was to improve usability and flexibility in the domain model definition process in terms of ease of use and model correctness.

Define example domain

Implement TANDEM component

Test example

domain

Figure 6.9 : TANDEM implementation cycle.

The TANDEM software environment was developed on a Power Macintosh 7100/66AV, configured with 16M of RAM, a SOOM hard disk and MacOS version 7. 1 .2 (Apple, 1994) . TANDEM is currently

implemented using LP A MacProlog32. Initial work had been completed on UNIX workstations using Poplog Prolog (Integral Solutions, 1995). Unfortunately, the available versions of Poplog and subsequent versions of SICStus Prolog (Carlsson and Widen, 1993) on the UNIX platform did not provide the graphical toolkits that would be necessary for the graphical TANDEM implementation.

LP A MacProlog32 combines advanced programming techniques with a user-friendly interface and enhanced graphics of the Apple Macintosh, making LP A MacProlog32 a rich and sophisticated programming environment. Also, LP A MacProlog32 is compatible with LPA Pro log for Windows (LPA, 1994) and Quintus Prolog (Quintus, 1996) on the UNIX platform, making is possible to port the system to other platforms if desired.

One question that can arise in the choice of programming language is that why use a high-level programming language and not an e n d - u s e r

programming tool? End-user programming tools, like HyperCard on the Macintosh have been used for CAI development and can reduce the development time for system construction. Unfortunately, end-user environments are usually too restrictive in certain areas, especially program control and interface construction (Ngan, 1 992). In an environment where a variety of different domains are to be modelled, generality in interface approaches for possible interfaces is very important. Also, selecting a language that has implementations across platforms allows greater flexibility if unforeseen circumstances require a change of platform.