• No se han encontrado resultados

CAPÍTULO 4: ANÁLISIS DE LOS RESULTADOS Y DISCUSIÓN

4.7. RECOMENDACIONES SOBRE LA APLICACIÓN DE LOS SISTEMAS DE EFYC EN

The th i rd major prototyping task was to evaluate a method for embedding user calls on the o pe rating system in the learning tasks themselves, thereby rendering the operating system i nvisible to the student.

The p ro posed method, as discussed in Chapter 5, was to create a n intermediate layer between the Learning S hell interface and the operating system which models the cou rse structu re (5 . 5 . 1 ). This system layer tracks the student through the course a nd m aps user interactions with Shel l components to the correct files a nd objects within Windows. A System Tree defined by the course Table of Contents is central to this reference model .

T h e prototyping steps followed were:

Chapter 6: Prototyping

• Identify system level operations req uired to support the Learning Shell.

• Specify a modular structure to best support these operations.

1 25

• I mplement system modules as classes enca psu lating the necessary data

types.

• Refine fo r modularity, reusabil ity and ease of maintenance

• Evaluate the resu lts .

6.3.1 System Tree

A table of contents is a shallow tree structure of sections and topics. This is easily represented by a list of lists. This implementation accommodates additional levels such as attaching a list of learning goals or key concepts to each topic (Figure 6.7). The System Tree is made visible to the user through the Course Explorer interface component (Fig u re 6 . 1 5)

Figure 6 .7 : System T ree with additional concept level. 6.3.2 System level operations

At the heart of the learning computer concept is navigation - tracking a nd storing the user's cu rrent position and taking them to any new position they select. An initial list of operations (Table 6.2) needed to support the Learn ing Shell's navigational logic was

Chapter 6: P rototyping 1 26

extracted from use cases a nd interaction diagrams. This included storing and providing i nformation about the cu rrent state of the system and of the student. The sequence d i a g ram for the Change Mode use case is shown in Fig u re 6 . 8 . Further sequence d ia g rams a re included in Appendix 03.

System Level O perations I nitialise System Model

Save System Model I n itialise student model Save student model

Get current student position (mode, section, topic)

Set current student position (mode, section, topic)

Get current resource (section, topic, component)

Set current resource (section, topic, component)

Get topic status - not started/attem pted/com pleted

Set topic status - not started/attem pted/completed

Save student work (section, topic, component)

Change Study Mode ( new_m ode)

Change Topic ( new_Section, new_ Topic)

Get Component List ( selected_mode) Open (this_com ponent)

Close (this_com ponent) Set Revision Mode

Table 6.2: System level operations defined from use cases .

c: "' "' :;: "' -.; -.; "0 "0 0 "0 0 0 0 ::E ::E :;: "0 "0 0 "' "' :I :I "' 0 >- (j) (j) (/) (/)

sele ctMode(Mode) »

changeMode(Mode) » updateMode(Mode)» updateModel (Mode)» «toCiose (Complist) « close (Comp) « toOpen(Complist) «open(Comp, File) getResource(Comp) » getFile «Resource (file) updateModei(Mode)»

«updateDesktop(Mode) updateMode »

saveModel »

Chapter 6: P rototyping 1 27

6.3.3 Reference model specification

In addition to the System Tree object it was found to be advantageous to subdivide the reference model into modules with specific responsibilities. lt was a lso more efficient to store certain information about the student, such as what topics they had completed , with the system data structures them selves, rather than in the separate Student Model .

The System Model object stores information about each study mode a n d learning

com ponent offered by a course . For example, it knows whether the data displayed by a com ponent can be ed ited and saved by the user o r is read-only. The System Model provides the information for swapping between study modes with in the cou rse .

The Resources Model object encapsulates the directory system that contains course learning materials. lt maps a learning component to its correct resource file, if one exists. For any topic in the course , it provides a list of all components for which resources a re ava ilable. The Reso u rce Model m ust map to the actual di rectory structu re to provide fo r updates, i n sertions , deletions and gracefu l recovery from errors (e.g. file not found).

The Student Model object stores the student's current position in the cou rse ( i . e .

section, topic a n d study mode) and a n y other data necessary t o ind ividualise the course to a particular u ser that would not otherwise be recorded .

6.3.4 I mplementation of d ata structu res

The class im plementations for the reference models are generally straightforwa rd . Each model class i s defined a s a data type with a set of public operations, and conta ins the data structure and additional fu nctions and proced ures needed to implement these operations.

Most of the data types involve the manipulation of lists of strings, wh ich are implemented using a rrays. Custom string list classes were u sed, rather than those provided by Delphi, to enable m o re d i rect support to the required operations. To initialise and permanently update the reference models, the data structures a re stored as text files (Appendix F 1 3) in the Models sub-directory of the System folder (Figure 6.9). The complete folder system for the Learning Shell is shown in Figure 6 . 1 0 .

The Resou rces Model encapsu lates the Resources folder structure. Files stored in the root Resou rces folder follow a naming pattern ind icating the learn ing component they belong to and their position in the cou rse. This file contains the names of all the resources associated with a particular component at a given point in the cou rse . These

Chapter 6: P rototyping 1 28

resou rces are stored as files in that component's subdirectory in the Resources folder (Figure 6 . 1 0).

For example, "s0 1 t021e.txt" is the file associated with the lecture component in S ection 1 . 02 of the course (Figure 6 . 1 1 ). Th is file contai ns the name of a video file and of an image file of the lecture r making the presentation , which are located in the Lecture sub­ folder of the Resources d i rectory. The lectu re component obtains th is informatio n from the Controller when its show method is cal led (Figure 6 . 1 2).

The Resources Model u ses algorithm s based on this naming pattern to return the file path for a component, a nd other related ope rations .

The Controller object u ses the i nformation supplied by the reference models to map learn i ng components to Windows forms, pass the correct data files to those forms, and then show them to the u ser (Appendix F 1 ).

� [�������1l

bleW 1 KB Te:.:t 0 o curnent 09-DcHIJ 1 2 30

1 KB Te:o:t D o curnent 1 0-Qd-01 1 2 38

8Jway�thesarne.w 1 KB Te:.:t 0 o curnent 1 4-JuH)3 1 4:<l 6

clipbo rud.M 1 KB Te:o:t 0 o curnent 25tri c.y-03 1 8:28

rodes.M 1 KE Te:.:t O o curnent 09-DcHJJ 1 2:31

OJI D U rs.1xt 1 KB Te:o:tDocurnent 29-5er:r-03 1 �:2 B

rompone nts.W l KB Te:.:t O o curnent 09-DcHJJ 1 2: 32

rontents.N 1 KB T e:o:t 0 o curnent 01 Dec-03 1 5:3 6

ronte ntsDe1ault.tx1 1 KB T e:.:t 0 o curnent 26-Sep-D3 1 4:3 0

end1t1 g s.1xt 1 KB T e:o:t 0 o curnent 09-Dct-{]3 1 2: 1 9

(;] genrom p .w 1 KE Te:.:t O o curnent 09-DcHJJ 1 2 31

� rnodoldi spi�,·W 1 KB T e:o:t 0 o curnent 09-()ct-{]3 1 231

(;] seaiort��.�ide.t.:t 1 KB Te:.:t 0 o curnent 24-J urt-{)3 1 5:<l 3

� stud model.txt 1 KB T e:o:t 0 o curnent 01-Dec-03 1 5:36

(;] stud modeiDefault M 1 KB Te:.:t 0 o curnent 02-Dct-1:13 1 5: 39

� suffio:es.1xt 1 KB T e:o:t 0 o curnent 1 3-J urr-DJ 1 8:0 7

(;] s�··smodel.t>:t l KB Te�'t O o curnent 09-0cHI3 1 2: 32

� sys1ernse�ings.N 1 KB T e:o:t 0 o curnent 1 0-()ct-{]3 1 3 06

(;] sy81ernse�ingsDefault.W 1 KB Text 0 o cument 1 0-0cHI3 1 0 01

� tmredi11xt 1 KB T e:o:t 0 o curnent 26-J urr-DJ 1 7 � 7

@ -..; sited.IXt 1 KB Text D ocument 1 0-0ct-{)3 13 06

� •.1 s�edO eioult N 1 KB T e:o:t 0 o curnent 1 0-()ct-{]3 1 2 42

objed(s) " My Computer

Chapter 6 : Prototyping

Desktop Update D rive Backup D rive

t

Imports Exports

Backups Models Resou rces Program Files Database HelpUpdates

UserEditComp1 U serEditComp2 UserEditCompN

VLM

E

Resources System

�:,.

Temp

L

Learning Comp1 Learning Comp2 Learning CompN

Figure 6 . 1 0 : Learning She l l directory structure.

s01 t02cle -Note pad

E.ile !;_dit FQ.rmat �Jew t!elp

� Olt 0 2 c l e . m p q

c h r i s . bmp -

Figure 6.1 1 : Content of "s01 t021e.txt" in Resources d i rectory.

6.3.5 Refinements to system mod u les

1 29

Thro ugh the p rototyping process the mod u lar design of the system layer was refined to improve reusability and make modification easier. Figure 6. 1 3 shows the Learn ing Shell's refined arch itecture.

A model manager object was introduced to remove any dependencies between the

Contro ller o bject and each model, for easier mod ification of the prototype. This was

important because implementations that u se Windows controls, e . g . a h idden form , a re not interchangeable with custom-bui lt classes that make no calls on the o perating system libra ries. The i nterfaces for the model managers are included in Append ix F .

Chapter 6 : P rototyping

procedure TLecture. FormShow(Sender: TObject) ;

begin

11 set lecture and image file paths

getFilel nfo; //get image

im lecture. Picture. LoadFrom File(imageFi le);

//d1splay message to user

StatusBar1 . Si mpleText : = caption+': Click picture to load.';

end; //of forms how

procedure TLecture.getFilelnfo; var begin end; i nfile: textfile; line: stri ng;

filepath:= controller. getFilePath( self.name ); try

except

end;

Assig nFile( infile, filepath ); Reset ( infi le ) ;

read l n ( i nfile, l i ne ) ;

lectureFile = LECTURE_DI R+ line; readln( i nfile, line ) ;

i f not eof( i nfile ) then

imageFile:= I MAGE_DI R+Iine

else begin

imageFile:=I MAGE_DI R+DEFAUL T _I MAGE;

end;

closeFile( i nfile );

showVLAMessage( 'Could not load lecture.' ) ; exit;

1 30

F i g u re 6.1 2: Compo ne nt show method gets data filepath from Control ler.

Mechanisms were successfully added for saving and backing up student's work, and performing management tasks like logging on and off, with minimal input from the user.

The reference models were modified to a lso support IMMEDIATE's authoring and cou rse management responsibilities. The model manager layer provides the interface to the authoring application, passing different parameters to the model layer depending on whether it is being used for learning or a uthoring. (See , for instance , the System Tree Manager class interface in Appendix F8).

6 . 3 . 6 Embedded o perati ng system

The creation of an i ntermediate system layer between the Learn ing Shell interface and the operating system , successfully embedded o perating system operations in the task domain. In particular, by d i rect manipulation of the Course Explorer, it was possible to

Chapter 6: Prototyping 1 3 1

navigate to any point within the cou rse , and to change from one study mode to a nother, with the system automatically handling the necessa ry open ing and closing of files.

However, d u ring the cou rse of prototyping the Shell it became clear that to manually define a course , and then correctly add learning materials, was a complex task requiring a thorough understanding of the Lea rn i ng Shel l's i mplementation. For the learning computer approach to be a viable altern ative to conventional cou rseware , a method had to be demonstrated for a non-prog rammer to author and update a course without being exposed to the internal complexities of the system. This i ssue is addressed further in the section on the authoring p rototype (6.6).

Generic

Enables user to User lnfo

interact with the Enables system to

system controller directly collect info Tools available in any Accessible only by

to change modes, from the user - lagon, mode. Managed by changing mode - launch i nterface backup drive, . . . the user, e.g. Student managed by system

components, etc. Notes e g Lecture Notes.

Controller API Called by components for their internal functionality

All interactions between components are channelled through here.

Manages the interface components - mode changes, etc. Interacts

with system components via respective managers.

Manager

Student Model

Holds student

into needed by

system & not stored

elsewhere,

e.g. current

topic & mode,

password Model Maps components to modes and holds other static info about system Tree Maps structure of course. Stores dynamic info - nodes (topics) visited or completed, etc Learning shell d irectory system

Resources Model Maps stored files to learning components

Figure 6 . 1 3 : Learning Shell arch itectu re.

6.4 Interface Design