Revista Iberoamericana de Tecnologías del/da - IEEE-RITA

Transcrição

Revista Iberoamericana de
Tecnologías del/da
Aprendizaje/Aprendizagem
(Latin-American Learning Technologies Journal)
Una publicación de la Sociedad de la Educación del IEEE
Uma publicação da Sociedade de Educação do IEEE
A publication of the IEEE Education Society
AGO. 2009
VOL. 4
#ÚMERO/#UMBER 3
(ISS# 1932-8540)
Editorial (en español) …...….………………………………............. Martín Llamas y Manuel Castro
Editorial (en português)…….…………………................................. Martín Llamas y Manuel Castro
i
ii
ARTÍCULOS SELECCIO#ADOS /ARTIGOS SELECIO#ADOS SIIE2008
Editores Invitados: J. Ángel Velázquez Iturbide y Francisco José García Peñalvo
Presentación…………………………………..……………..……………............................................
………………...……………………...J. Ángel Velázquez Iturbide y Francisco José García Peñalvo
171
Procesamiento de Documentos XML Dirigido por Lenguajes en Entornos de E-Learning...................
…............... Antonio Sarasa-Cabezuelo, José-Luis Sierra-Rodríguez, y Alfredo Fernández-Valmayor
175
DidaktosOnLine: uma ferramenta para a construção social do conhecimento ………………………..
………………..……………............................................ Francislê .eri de Souza e António Moreira
184
Diseño de videojuegos colaborativos y educativos centrado en la Jugabilidad......................................
.........................................................................….....atalia Padilla Zea, José Luís González Sánchez,
Francisco L. Gutiérrez, Marcelino J. Cabrera, Patricia Paderewski
191
Generador Sc@ut: Sistema de Creación de Comunicadores Personalizados para la Integración……..
.………………………...............................................Álvaro Fernández, José Luís González Sánchez,
Luz Mª Roldán, Mª José Rodríguez-Fórtiz, Mª Visitación Hurtado-Torres, .uria Medina-Medina
199
Formação de Licenciados em Computação no Brasil - Desenvolvimento e Utilização do ROBOKIT..
…………...…………… Marcia Elena Jochims Kniphoff da Cruz, Werner Haetinger, Fabiano Horn
206
Asistentes Interactivos para el Aprendizaje de Algoritmos Voraces ………….....................................
........................ J. Ángel Velázquez Iturbide, Carlos A. Lázaro Carrascosa, e Isidoro Hernán Losada
213
(Continúa en la Contraportada...)
IEEE-RITA (http://webs.uvigo.es/cesei/RITA)
COSEJO/COSELHO EDITORIAL
Presidente (Editor Jefe):
Martín Llamas Nistal,
Universidad de Vigo, España
Vicepresidente (Coeditor):
Manuel Castro Gil, UNED, España
Miembros:
Melany M. Ciampi, COPEC, Brasil
Javier Quezada Andrade,
ITESM, México
Carlos Vaz do Carvalho,
INESP, Portugal
Edmundo Tovar, UPM, España
Secretaría:
Pedro Pimenta, Universidade do
Minho, Portugal
Francisco Mur, UNED, España
COMITÉ CIETÍFICO
Alfredo Fernández Valmayor,
Universidad Complutense de
Madrid, España
Antonio J. López Martín,
Universidad Estatal de Nuevo
Méjico, USA
Antonio J. Méndez,
Universidad de Coimbra,
Portugal
António Vieira de Castro,
ISEP, Oporto, Portugal
Arturo Molina, ITESM,
México
Baltasar Fernández,
Madrid, España
Carlos Delgado, Universidad
Carlos III de Madrid, España
Carlos M. Tobar Toledo,
PUC-Campinas, Brasil
Claudio da Rocha Brito,
COPEC, Brasil
Daniel Burgos, Universidad
Abierta de Holanda, Holanda
Fernando Pescador, UPM,
España
Francisco Arcega,
Universidad de Zaragoza,
España
Francisco Azcondo,
Universidad de Cantabria,
España
Francisco Jurado,
Universidad de Jaen, España
Gustavo Rossi, Universidad
Nacional de la Plata,
Argentina
Héctor Morelos, ITESM,
México
Hugo E. Hernández Figueroa,
Universidad de Campinas,
Brasil
Ignacio Aedo, Universidad
Inmaculada Plaza,
Universidad de Zaragoza,
España
Jaime Muñoz Arteaga,
Universidad Autónoma de
Aguascalientes, México
Jaime Sánchez, Universidad
de Chile, Chile
Javier Pulido, ITESM,
México
J. Ángel Velázquez Iturbide,
Universidad Rey Juan Carlos,
Madrid, España
José Bravo, Universidad de
Castilla La Mancha, España
José Carpio, UNED, España
José Palazzo M. De Oliveira,
UFGRS, Brasil
José Valdeni de Lima,
UFGRS, Brasil
Juan Quemada, UPM, España
Juan Carlos Burguillo Rial,
DOI (Digital Object Identifier) Pendiente
J. Fernando Naveda
Villanueva,
Universidad de Minnesota,
USA
Juan M. Santos Gago,
Luca Botturi, Universidad de
Lugano, Suiza
Luis Anido, Universidad de
Vigo, España
Luis Jaime Neri Vitela,
ITESM, México
Manuel Caeiro Rodríguez,
Manuel Fernández Iglesias,
Manuel Lama Penín,
Universidad de Santiago de
Compostela, España
Manuel Ortega, Universidad
de Castilla La Mancha,
España
M. Felisa Verdejo, UNED,
España
Maria José Patrício
Marcelino, Universidad de
Coimbra, Portugal
Mateo Aboy, Instituto de
Tecnología de Oregón, USA
Miguel Angel Sicilia Urbán,
Universidad de Alcalá,
España
Miguel Rodríguez Artacho,
UNED, España
Óscar Martínez Bonastre,
Universidad Miguel
Hernández de Elche, España
Paloma Díaz, Universidad
Paulo Días, Universidade do
Minho, Portugal
Rocael Hernández,
Universidad Galileo,
Guatema
Rosa M. Vicari, UFGRS,
Brasil
Regina Motz, Universidad de
La República, Uruguay
Samuel Cruz-Lara, Université
Nancy 2, Francia
Víctor H. Casanova,
Universidad de Brasilia,
Brasil
Vitor Duarte Teodoro,
Universidade Nova de Lisboa,
Portugal
Vladimir Zakharov,
Universidade Estatal Técnica
MADI, Moscú, Rusia
Xabiel García pañeda,
Universidad de Oviedo,
España
Yannis Dimitriadis,
Universidad de Valladolid,
España
IEEE-RITA Vol. 4, Núm. 3, Ago. 2009
i
Editorial
Martín Llamas, Senior member, IEEE, y Manuel Castro, Fellow, IEEE
Como ya comentamos en el anterior
número de Febrero de 2009, hemos
cambiado la frecuencia de aparición de
nuestra revista IEEE-RITA de la inicial
semestral a la definitiva trimestral,
reservando en principio los números de
Febrero y Agosto para números especiales,
y Mayo y Noviembre para números
normales. ¡Y cómo no!: aunque esta sea la
regla general, puede haber excepciones, y
así en el pasado número de Mayo de 2009,
tuvimos la primera al tener la selección de
los mejores artículos del ICALT2008 en
lengua española y portuguesa.
En el presente número vamos a
presentar una selección de los mejores
artículos de los congresos SIIE2008 y
CITA2009. El alcance de cada congreso así
como los artículos seleccionados están
descritos en las respectivas presentaciones
hechas por los editores invitados: José
Ángel Velázquez Iturbide y Francisco José
García Peñalvo para la selección del
SIIE2008, y Xabiel García Pañeda y Álvaro
Rendón Gallón para la selección de
CITA2009.
Así mismo queremos comunicar que
hemos empezado los trámites para la
inclusión de IEEE-RITA en el IEEE Xplorer,
la obtención del DOI (Digital Object
Identifier) y que, una vez conseguidos,
empezaremos los trámites para la inclusión
de IEEE-RITA en el JCR (Journal Citation
Report).
Creemos que con la inclusión en este
prestigioso Índice, culminaríamos la tarea
de conseguir que IEEE-RITA sea la
herramienta de difusión de la investigación y
experiencias dentro del ámbito de la
Sociedad de la Educación en Iberoamérica
que nos planteamos al principio. A partir de
ahí sólo resta seguir animando a la
comunidad científica a hacer uso de ella,
para que realmente sea el vehículo de
difusión científico que todos queremos que
sea.
Martín
Llamas
Nistal
es
Ingeniero
de
Telecomunicación (1986) y Doctor Ingeniero de
Telecomunicación (1994), ambos títulos por la
Universidad Politécnica de Madrid. Desde 1987 es
profesor en la ETSI de Telecomunicación de Vigo (de
la que fue subdirector en el período 1994-1997);
actualmente es profesor titular en el Departamento
de Ingeniería Telemática de esa misma Universidad.
Ha dirigido varios proyectos de investigación en el
área de Telemática y es autor o co-autor de más de
200 publicaciones en revistas, capítulos de libros y
congresos nacionales e internacionales. Desde
Diciembre de 1998 a Septiembre de 2003 fue
Director del Área de Tecnologías de la Información y
las Comunicaciones de la Universidad de Vigo.
Miembro de ATI, de ACM, Senior Member del IEEE y
miembro del Comité de Administración de la
Sociedad de Educación del IEEE. Desde Abril de
2008 es Chairman del Capítulo Español de la
Sociedad de Educación del IEEE.
Manuel Castro Gil es Doctor Ingeniero Industrial y
Catedrático de Universidad. Ha sido Vicerrector de
Nuevas Tecnologías de la UNED, así como
Subdirector de Ordenación Académica y de
Investigación en la Escuela de Ingenieros
Industriales de la UNED, y Director del Centro de
Servicios Informáticos de la UNED, siendo
actualmente Director de Departamento. Ha
participado en numerosos proyectos de investigación
como investigador, coordinador y director y ha
publicado artículos técnicos en revistas y congresos,
tanto nacionales e internacionales. Ha publicado
igualmente diversos libros y material multimedia
dentro de sus líneas de investigación y docencia,
tanto en temas de innovación educativa, docencia e
investigación. Es Fellow del IEEE así como miembro
del Comité de Administración de la Sociedad de
Educación del IEEE y Fundador y Pasado-Presidente
del Capítulo Español de la Sociedad de Educación
del IEEE.
ISSN 1932-8540 © IEEE
ii
Editorial
Martín Llamas, Senior member, IEEE, e Manuel Castro, Fellow, IEEE
(Traduzido por Carlos Vaz de Carvalho)
Como já comentamos no número
anterior de Fevereiro de 2009, alteramos a
frequência da nossa revista IEEE-RITA
passando de um modelo semestral ao
definitivo trimestral, reservando em princípio
os números de Fevereiro e Agosto para
números especiais e Maio e Novembro para
números normais. No entanto, embora esta
seja a regra geral, pode haver excepções, e
assim no número de Maio de 2009, tivemos
a primeira ao ter a selecção dos melhores
artigos do ICALT2008 em língua espanhola
e portuguesa.
Neste número vamos apresentar uma
selecção dos melhores artigos dos
congressos SIIE2008 e CITA2009. O
alcance de cada congresso assim como os
artigos seleccionados estão descritos nas
respectivas apresentações feitas pelos
editores convidados: José Ángel Velázquez
Iturbide e Francisco José García Peñalvo
para a selecção do SIIE2008 e Xabiel
García Pañeda e Álvaro Rendón Gallón
para a selecção de CITA2009.
Queremos ainda comunicar que
iniciamos os trámites para a inclusão de
IEEE-RITA no IEEE Xplorer, a obtenção do
DOI (Digital Object Identifier). Uma vez
conseguidos, iniciaremos os trámites para a
inclusão de IEEE-RITA no JCR (Journal
Citation Report).
Cremos que com a inclusão neste
prestigioso Índice, culminaríamos a tarefa
de conseguir que IEEE-RITA seja a
ferramenta de difusão da investigação e de
experiências no âmbito da Sociedade da
Educação em Iberoamerica a que nos
propusemos no início. A partir daí só resta
seguir animando a comunidade científica a
fazer uso dela, para que realmente seja o
veículo de difusão científico que todos
queremos que seja.
Martín
Llamas
Nistal
é
Engenheiro
de
Telecomunicações (1986) e Doutor Engenheiro de
Telecomunicações
(1994),
pela
Universidad
Politécnica de Madrid. Desde 1987 é professor na
ETSI de Telecomunicación de Vigo (da que foi
subdirector no período 1994-1997); actualmente é
professor titular no Departamento de Engenharia
Telemática dessa mesma Universidade. Dirigiu
vários projectos de investigação na área da
Telemática e é autor ou co-autor de mais de 200
publicações em revistas, capítulos de livros e
congressos nacionais e internacionais. Desde
Dezembro de 1998 a Setembro de 2003 foi Director
da Área de Tecnologias da Informação e
Comunicação da Universidad de Vigo. Membro de
ATI, de ACM, Senior Member do IEEE e membro do
Comité de Administração da Sociedade de Educação
do IEEE. Desde Abril de 2008 é Chairman do
Capítulo Espanhol da Sociedade de Educação do
IEEE.
Manuel Castro Gil é Doutor Engenheiro Industrial e
Catedrático de Universidade. Foi Vice-reitor de
Novas Tecnologias da UNED, assim como
Subdirector de Ordenação Académica e de
Investigação na Escuela de Ingenieros Industriales
da UNED, e Director do Centro de Serviços
Informáticos da UNED, sendo actualmente Director
de Departamento. Participou em numerosos
projectos de investigação como investigador,
coordenador e director e publicou em revistas e
congressos, tanto nacionais como internacionais.
Publicou igualmente diversos livros e material
multimédia dentro das suas linhas de investigação e
docência. É Fellow do IEEE e membro do Comité de
Administração da Sociedade de Educação do IEEE.
ISSN 1932-8540 © IEEE
171
Informática Educativa y Educación en
Informática
J. Ángel Velázquez Iturbide, Member, IEEE, y Francisco José García Peñalvo
Editores Invitados
Title— Computing in Education and Computing Education
Abstract— This invited editorial is an introduction to the
special issue of selected papers of SIIE’08, the X International
Symposium on Computers in Education, held in Salamanca,
Spain, in October 2008. The articles selected deal with a number
of issues on Computers and Education. This editorial consists of
two parts. First, it gives an overview of the history of the SIIE
symposium. Second, it introduces the six articles, classified into
two groups: Computers in Education, and Education in
Computing.
Index Terms—
education.
Educational
technology,
computers
&
I. INTRODUCCIÓN
E
STE número especial contiene una selección de seis
comunicaciones presentadas en SIIE’08, el X Simposio
Internacional de Informática Educativa (http://siie08.usal.es/).
Las comunicaciones seleccionadas tienen un perfil conforme
con IEEE-RITA, orientado a la educación en ingeniería o al
uso de la ingeniería para la educación, en este caso con el
papel destacado de una ingeniería concreta, la Informática.
SIIE es un foro internacional para la presentación y debate
de los últimos avances en el uso de las Tecnologías de la
Información y las Comunicaciones en la educación. También
pretende ser un punto de encuentro destacado entre
investigadores, técnicos, representantes institucionales o
empresariales y profesores que desean compartir sus puntos de
vista, su conocimiento y su experiencia.
El Simposio goza de una larga tradición y reconocido
prestigio en Iberoamérica, y es actualmente una obligada
referencia en el área de la Informática Educativa. La primera
edición del SIIE se celebró en 1999 en Aveiro, Portugal.
Desde entonces, se celebra alternativamente en España y
Portugal. Las ediciones celebradas en España fueron
J. Ángel Velázquez Iturbide pertenece al Departamento de Lenguajes y
Sistemas Informáticos I, Universidad Rey Juan Carlos, C/ Tulipán s/n,
Móstoles 28933, Madrid, España (autor de contacto, Tel.: +34 91 664 74 54;
Fax: +34 91 488 85 30; e-mail: [email protected]).
Francisco José García Peñalvo pertenece al Departamento de Informática y
Automática, Universidad de Salamanca, Facultad de Ciencias, Plaza de los
Caídos s/n, 37008 Salamanca, España (e-mail: [email protected]).
DOI (Digital Object Identifier) Pendiente.
organizadas por la Asociación para el Desarrollo de la
Informática Educativa, ADIE, http://www.adie.es/) y una
universidad local. Desde esta última edición, SIIE incorpora
como organizador al Capítulo Español de la Sociedad de la
Educación del IEEE (http://www.ieec.uned.es/ES/).
A. X Simposio Internacional de Informática Educativa,
SIIE’08
SIIE’08 (http://siie08.usal.es/) se celebró en Salamanca,
España, los días 1-3 de Octubre de 2008. El organizador local
fue la Universidad de Salamanca. En esta edición se recibieron
165 propuestas, que se sometieron a un proceso de revisión
por dos miembros del Comité de Programa (a veces, tres o
cuatro) o por revisores adicionales propuestos por aquéllos. Se
aceptó un total de 69 envíos como comunicaciones y 20 como
pósters [1]. Por tanto, ha quedado garantizado un alto nivel de
calidad en las propuestas aceptadas, similar al de otros
congresos prestigiosos. La tasa de aceptación fue del 42% para
las comunicaciones, y del 54% si también contamos los
pósters. Las contribuciones aceptadas cubrieron una gran
variedad de temas, repartidas en 21 sesiones de
comunicaciones y 2 sesiones de pósters. Los autores de las
contribuciones aceptadas han procedido de 12 países: España,
Portugal, Brasil, Colombia, Chile, Méjico, Alemania,
Argentina, Costa Rica, Cuba, Italia, Uruguay y Venezuela.
Estamos especialmente satisfechos de destacar la
consolidación de la investigación en Informática Educativa en
varios países iberoamericanos, con más de una contribución en
el programa del Simposio.
Como en las ediciones anteriores del Simposio, se
organizaron sesiones plenarias con conferenciantes invitados
de renombre internacional. Queremos agradecer a los
profesores Claudio Dondi (de Scienter y Presidente de
EFQUEL) y a Gorka Palacio (de la Universidad del País
Vasco, España) por haber aceptado nuestra invitación para
compartir su conocimiento y experiencia en las áreas en las
que son conocidos expertos.
La tarea de difusión de las novedades presentadas no acabó
con el cierre del Simposio. Se han realizado varias selecciones
de las mejores comunicaciones para ser publicadas en números
monográficos de revistas. Aquí presentamos una selección de
seis comunicaciones que comparten un interés en la educación
en ingeniería o en el uso de la ingeniería para la educación. La
ISSN 1932-8540 © IEEE
172
selección se hizo a partir de las puntuaciones obtenidas en el
proceso de revisión y de su adecuación a la temática de la
revista IEEE-RITA.
II. LOS ARTÍCULOS
Presentamos en esta sección los seis artículos seleccionados,
agrupados en dos categorías complementarias de la
Informática Educativa y educación de la (Ingeniería)
Informática. La catalogación de un artículo en una de estas
categorías depende del énfasis dado en el propio artículo. Los
de la categoría primera inciden en la tecnología, que puede
aplicarse a cualquier disciplina, mientras que los segundos
usan tecnología informática, pero para la formación específica
en Ingeniería Informática.
A. Informática Educativa
El término Informática Educativa es muy amplio, ya que
cubre cualquier técnica hardware o software aplicada a la
educación. No es, por tanto, de extrañar que el espectro de
tecnologías presentadas sea muy dispar.
Sarasa Cabezuelo, Sierra Rodríguez y Fernández-Valmayor
son los autores de “Procesamiento de documentos XML
dirigido por lenguajes en entornos de e-learning”. Su artículo
describe un entorno de procesamiento de XML, llamado
XLOP y basado en gramáticas de atributos. Su objetivo es
sistematizar el procesamiento de documentos XML en
entornos de e-learning. Los autores describen el lenguaje de
especificación y el flujo de trabajo de XLOP. Dada una
especificación de un lenguaje, XLOP genera un procesador de
XML en Java con dos capas diferenciadas: sintáctica y de
lógica específica de la aplicación. En el artículo también se
muestra su aplicación a dos casos concretos.
El artículo “DidaktosOnLine: uma ferramenta para a
construção social do conhecimento” tiene como autores a Néri
de Souza y Moreira. El trabajo se enmarca en
DidaktosOnLine, que es un sistema hipermedia con funciones
propios de la Web 2.0 y diseñado según la llamada “teoría de
flexibilidad cognitiva” para el aprendizaje de materias
complejas. En el artículo se presenta una evaluación de su uso
con estudiantes reales. Se describen las características de la
evaluación y se presentan los resultados, centrados
principalmente en las dificultades encontradas por los
estudiantes.
El artículo de Padilla Zea y otros autores “Diseño de
videojuegos colaborativos y educativos centrados en la
usabilidad” presenta pautas de diseño de videojuegos
educativos y colaborativos. En el artículo se presenta el
concepto de jugabilidad, los atributos que la caracterizan y las
facetas o puntos de vista desde los que puede estudiarse.
También incluye una guía que ayuda al diseñador a alcanzar
varios componentes del aprendizaje colaborativo mediante
videojuegos. Las aportaciones anteriores se ilustran mediante
extractos del videojuego infantil “Leoncio y sus amigos”, que
tiene como objetivo el aprendizaje de las vocales.
Fernández y otros autores presentan el artículo “Generador
Sc@ut: sistema de generación de comunicadores
personalizados para la integración”. El trabajo se centra en la
Plataforma Sc@out, un sistema cuyo objetivo es ayudar a
niños con problemas de comunicación en el centro escolar. La
plataforma consta de un generador y de comunicadores. Un
generador es un sistema de creación de comunicadores. Un
comunicador es un sistema de ayuda a la comunicación, que
puede implementarse en varios dispositivos. El artículo
describe los distintos elementos del generador y el modelo
hipermedia resultante, definido como una jerarquía de varios
niveles de naturaleza distinta. Por último, los autores resumen
la experiencia de uso de Sc@ut.
B. Educación en la Informática
La Informática Educativa puede aplicarse a cualquier
disciplina y por tanto también a la propia Ingeniería
Informática. Los dos artículos incluidos se centran en la
enseñanza de robótica y de algoritmos.
Los autores de “Formação de licenciados em computação no
Brasil – desenvolvimento e utilização do ROBOKIT” son
Jochims Kniphoff da Cruz, Haetinger y Horn. En el marco de
la enseñanza universitaria de Ingeniería Informática, describen
el proyecto ROBOKIT, concebido para que sus estudiantes
puedan realizar prácticas en colegios de familiarización con la
Informática. El artículo presenta el proceso de desarrollo de
ROBOKIT, lo describe desde un punto de vista técnico y
expone varias experiencias de uso.
El artículo de Velázquez Iturbide, Lázaro Carrascosa y
Hernán Losada “Asistentes interactivos para el aprendizaje de
algoritmos voraces” presenta varios ayudantes interactivos
para que los estudiantes de Ingeniería Informática
experimenten durante el aprendizaje de la técnica de
algoritmos voraces. El artículo comienza identificando los
objetivos educativos de los ayudantes educativos para después
describirlos. Se dedica especial atención a los aspectos de
análisis, evaluación y visualización de resultados de los
algoritmos, así como a su uso para experimentación
interactiva. También se presentan los resultados de sesiones de
evaluación en los que se ha medido su usabilidad y eficacia
educativa. En concreto, los resultados de las evaluaciones de
usabilidad han sido muy útiles para mejorar los ayudantes y
conseguir herramientas robustas y usables de software.
AGRADECIMIENTOS
Queremos agradecer al editor de la revista, Martín Llamas
Nistal, la oportunidad de difundir una parte destacada de las
contribuciones de SIIE’08 entre la comunidad ingenieril
iberoamericana. Este trabajo se ha financiado en parte con los
proyectos TIN2008-02670-E/TSI y TIN2008-04103/TSI del
Ministerio de Ciencia e Innovación de España.
REFERENCIAS
[1]
J. Á. Velázquez-Iturbide, F. J. García-Peñalvo, y A. B. Gil-González
(eds.), X Simposio Internacional de Informática Educativa. Salamanca,
España: Ediciones Universidad de Salamanca, 2008.
ISSN 1932-8540 © IEEE
VELÁZQUEZ ITÚRBIDE Y GARCÍA PEÑALVO: INFORMÁTICA EDUCATIVA Y EDUCACIÓN EN ...
J. Ángel Velázquez Iturbide es Licenciado en
Informática (1985) y Doctor en Informática (1990) por
la Universidad Politécnica de Madrid, España.
Ha sido profesor desde 1985 en la Facultad de
Informática de la Universidad Politécnica de Madrid.
En 1997 se incorporó a la Universidad Rey Juan
Carlos, donde actualmente es Catedrático de
Universidad y director del Laboratorio de Tecnologías
de la Información en la Educación (LITE). Sus áreas
de investigación son innovación docente y software
educativo para la enseñanza de la programación, visualización del software,
visualización de la información, e interacción persona-ordenador.
El Dr. Velázquez es miembro de IEEE Computer Society, ACM y ACM
SIGCSE. También es secretario de la Asociación para el Desarrollo de la
Informática Educativa (ADIE) y vocal de la Junta Directiva de la Asociación
Interacción Persona-Ordenador (AIPO).
173
Francisco José García Peñalvo es Licenciado en
Informática (1994) por la Universidad de Valladolid y
Doctor en Informática (2000) por la Universidad de
Salamanca, España, universidad en la que actualmente
es Profesor Titular y Vicerrector de Innovación
Tecnológica. Es director del GRupo de investigación en
InterAcción y eLearning (GRIAL), donde confluyen
líneas de investigación interdisciplinares en las áreas
del eLearning, la Interacción Persona-Ordenador y la
Ingeniería del Software. Es miembro de la Asociación para el Desarrollo de la
Informática Educativa (ADIE) y de la Asociación Interacción PersonaOrdenador (AIPO).
ISSN 1932-8540 © IEEE
175
Procesamiento de Documentos XML Dirigido
por Lenguajes en Entornos de E-Learning
Antonio Sarasa-Cabezuelo, José-Luis Sierra-Rodríguez, y Alfredo Fernández-Valmayor
Title— Language-Oriented Processing of XML Documents in
e-Learning Environments
Abstract— This paper proposes the use of attribute grammars
in order to systematize the processing of XML documents in
e-Learning environments. For this purpose, it presents XLOP
(XML Language-Oriented Processing), an XML processing
environment based on this technique. It also illustrates how
XLOP is used in two different e-Learning contexts: languagedriven production of educational applications, and processing of
metadata documents for reusable learning objects.
Index Terms— XML processing, Socratic Tutorial, Learning
Objects, Metadata, Attribute Grammar
I. INTRODUCTION
X
ML es el formato de representación e intercambio básico
utilizado en la práctica totalidad de los escenarios de
e-Learning. Como ejemplo representativo de la importancia
que cobra XML en el dominio de e-Learning puede
examinarse
cualquiera
de los actuales esfuerzos
estandarizadores, donde, aparte de proponerse modelos de
información para representar aspectos relevantes de los
sistemas e-Learning (e.g., evaluaciones, diseños educativos, o
perfiles de estudiante), también se proponen vinculaciones de
dichos modelos con vocabularios XML específicos [5]. Por lo
tanto, la implantación práctica de cualquier solución
e-Learning implicará, desde el punto de vista tecnológico, una
fuerte componente de procesamiento de documentación XML.
De esta forma, el disponer de mecanismos que faciliten el
desarrollo de dicha componente de procesamiento se convierte
en un factor clave de dicha implantación.
XLOP (XML Language-Oriented Processing) es un entorno
que utiliza gramáticas de atributos para describir cómo
procesar documentos XML marcados con un determinado
vocabulario. Las gramáticas de atributos son un formalismo
declarativo ampliamente utilizado en la descripción de la
sintaxis, las restricciones contextuales (semántica estática), y
A.Sarasa es miembro del Departamento de Sistemas Informáticos
y Computación de la Universidad Complutense de Madrid. Email:
[email protected]. J.L.Sierra y A.Fernández-Valmayor son
miembros del Departamento de Ingeniería del Software e Inteligencia
Artificial de la Universidad Complutense de Madrid. Email:
{jlsierra,Alfredo}@fdi.ucm.es
la traducción de los lenguajes informáticos [8][9]. De esta
forma, XLOP sigue un paradigma dirigido por lenguajes en el
desarrollo de los programas de procesamiento de documentos
XML [3]. De acuerdo con este paradigma, dichos programas
se entienden como procesadores de lenguaje, y el proceso de
desarrollo en sí se entiende como el proceso de construcción y
mantenimiento de dichos procesadores. De hecho, utilizando
XLOP es posible generar automáticamente tales procesadores
a partir de especificaciones de alto nivel expresadas como
gramáticas de atributos.
XLOP se ha diseñado para ser integrado con Java.
Efectivamente, las funciones semánticas que se utilizan en las
gramáticas de atributos XLOP se implementan como métodos
en Java. De esta forma, XLOP ofrece una flexibilidad
comparable a la de los marcos de procesamiento genéricos
para XML (e.g., SAX, DOM, StAX, etc.) [3], y, al mismo
tiempo, un nivel de usabilidad comparable al de enfoques
específicos (e.g., los ofrecidos por lenguajes de transformación
como XSLT) [3]. De hecho, XLOP permite estructurar las
aplicaciones de proceso de XML en dos capas perfectamente
diferenciadas:
- Una capa de lógica específica de la aplicación, que
incluye la maquinaria necesaria para soportar la
funcionalidad de dicha aplicación (e.g., un marco de
aplicación para la representación interna de un tutor
inteligente, o un conjunto de clases para el procesamiento
de metadatos).
-
Una capa lingüística de procesamiento XML dirigido por
la sintaxis. Esta capa se especifica como una gramática de
atributos, especificación que se traduce automáticamente a
una implementación ejecutable mediante un generador
XLOP.
La conexión entre ambas capas se realiza mediante una
clase semántica, que implementa en Java las funciones
semánticas utilizadas en la gramática de atributos XLOP, y
que media entre las dos capas anteriores. De esta forma, el
modelo de desarrollo dirigido por lenguajes de XLOP
propugna la separación explícita de estas dos capas, así como
facilita el desarrollo y el mantenimiento de la capa lingüística,
ya que ésta se especifica a un nivel mucho más alto que el
conseguido con una implementación directa en Java o en
cualquier otro lenguaje de programación. De hecho, el
formalismo de las gramáticas de atributos es también de más
ISSN 1932-8540 © IEEE
176
SpecXLOP::= {Regla}+
Regla ::= +oTerminal ‘::=’ { ElementoSintactico }* '{' { Ecuacion }* '}'
ElementoSintactico ::= +oTerminal | #pcdata | ElementoXML
ElementoXML ::= EtiquetaApertura { ElementoSintactico }* EtiquetaCierre | EtiquetaElmVacio
Ecuacion ::= ReferenciaAtributo '=' ExpresionSemantica
ExpresionSemantica ::= Funcion '(' (ExpresionSemantica { , ExpresionSemantica }*)? ')' |
ReferenciaAtributo
ReferenciaAtributo ::= Atributo of ( +oTerminal | #pcdata | EtiquetaApertura) ( '(' +umeroOcurrencia ')' )?
Figura 1. Sintaxis del lenguaje de especificación de XLOP.
alto nivel que una descripción basada en esquemas de
traducción [1], del tipo de los soportados por otros enfoques al
procesamiento de XML dirigido por lenguajes (e.g., ANTXR
[19], un entorno construido sobre la herramienta ANTLR, y
RelaxNGCC [7], una extensión del lenguaje de esquema
documental RelaxNG utilizada para especificar esquemas de
traducción y que permite la generación automática de
traductores recursivos descendentes [1]).
En este artículo se describe el entorno XLOP, haciendo
énfasis en su lenguaje de especificación, así como en su
aplicación al procesamiento de XML en entornos de
e-Learning. Para ello, en la sección II se comienza
describiendo el entorno en sí. En la sección III se ejemplifica
el uso del entorno en el desarrollo de un traductor para
<e-Tutor>, un sistema para la producción de tutoriales
socráticos. En la sección IV se ejemplifica su uso en la
comprobación de restricciones sobre documentos de metadatos
en Chasqui, un sistema para la creación de repositorios de
objetos de aprendizaje en dominios especializados. Por último,
en la sección V se resumen las conclusiones obtenidas, así
como se esbozan algunas líneas de trabajo futuro. Este trabajo
es una versión extendida de [11].
II. EL ENTORNO XLOP
A. Gramáticas de Atributos
XLOP se basa en el formalismo de las gramáticas de
atributos. Este formalismo fue propuesto por Donald E. Knuth
a finales de los sesenta como un mecanismo para añadir
semántica a los lenguajes incontextuales [8][9]. Una gramática
de atributos consta de:
- Una gramática incontextual que caracteriza la sintaxis
estructural del lenguaje mediante un conjunto de reglas
sintácticas o producciones.
-
Un conjunto de atributos semánticos añadidos a los
símbolos de la citada gramática. Estos atributos pueden
ser de dos tipos: atributos sintetizados y atributos
heredados. Los atributos toman valores en los nodos de
los árboles sintácticos impuestos por la gramática
incontextual sobre las sentencias. Los valores de los
atributos sintetizados representan la semántica de los
fragmentos de sentencia que penden de los nodos,
mientras que los de los atributos heredados representan
información de contexto. Los atributos sintetizados en un
nodo se computan a partir de los sintetizados de sus hijos
y de los propios atributos heredados del nodo. Por su
parte, los atributos heredados se computan a partir de los
sintetizados de los hermanos y de los heredados del padre.
-
Un conjunto de ecuaciones semánticas para cada
producción. Estas ecuaciones indican cómo computar los
valores de los atributos sintetizados de la cabeza y de los
atributos heredados de los símbolos del cuerpo. Para ello
aplican funciones semánticas sobre los atributos utilizados
en dicho cómputo.
El axioma de la gramática también puede tener atributos
heredados. Así mismo, los terminales también pueden tener
atributos sintetizados, que se denominan atributos léxicos. Los
valores de estos atributos se fijarán externamente (e.g., los
atributos léxicos se fijarán durante el análisis léxico).
Durante la preparación de una gramática de atributos no es
necesario especificar explícitamente en qué orden tienen que
aplicarse las ecuaciones semánticas para encontrar los valores
de los atributos en los árboles sintácticos (es decir, para
evaluar dichos atributos). De esta forma, las gramáticas de
atributos son mecanismos descriptivos de más alto nivel que
los esquemas de traducción soportados por las herramientas
típicas de construcción de procesadores de lenguaje (e.g.,
JavaCC, ANTLR, YACC, o CUP), en los que sí es necesario
explicitar el orden de ejecución de las acciones semánticas.
Por el contrario, en una gramática de atributos el orden de
evaluación se deriva de las dependencias entre los atributos
introducidas por las ecuaciones semánticas. El método de
evaluación en sí puede ser estático o dinámico. Los métodos
estáticos analizan la gramática durante la generación del
evaluador para encontrar un orden de evaluación que funciona
para cualquier sentencia. Por su parte, los métodos dinámicos
deciden el orden de evaluación para cada sentencia particular.
En XLOP se adopta un método de evaluación dinámica, ya
que los métodos dinámicos aceptan una clase más amplia de
gramáticas de atributos que los estáticos, aún a consta de una
ligera pérdida de eficiencia.
B. El Lenguaje de Especificación de XLOP
El lenguaje de especificación de XLOP es un metalenguaje
para describir gramáticas de atributos para lenguajes de
marcado definidos mediante XML. La Figura 1 muestra la
sintaxis de este lenguaje.
La gramática incontextual subyacente a una especificación
XLOP representa la estructura lógica de un tipo de
documentos XML (los detalles de más bajo nivel relativos a la
estructura física del documento se ignoran, ya que estos serán
tratados por entornos de análisis de XML convencionales [3]).
ISSN 1932-8540 © IEEE
SARASA-CABEZUELO et al.: PROCESAMIENTO DE DOCS. XML DIRIGIDO POR LENGUAJES
Como puede observarse en la Figura 1, las gramáticas XLOP
pueden incluir los siguientes tipos de símbolos terminales:
- El símbolo #pcdata. Este símbolo denota un fragmento
de contenido textual en el documento procesado.
-
Etiquetas de apertura (e.g., <Tutorial>) y de cierre
(e.g., </Tutorial>). Estas etiquetas dependerán del
lenguaje particular que se está procesando, y deberán, así
mismo, ser convenientemente anidadas.
Así mismo, las gramáticas XLOP pueden contener los
símbolos no terminales que se consideren necesarios para
representar de manera apropiada el resto de la estructura
lógica del lenguaje de marcado a procesar.
En lo que se refiere a los atributos léxicos, el símbolo
#pcdata soporta únicamente un atributo léxico: text. El
valor de este atributo será el contenido textual particular
representado por el símbolo. Las etiquetas de apertura pueden
tener también atributos léxicos, que se denominarán atributos
de elemento, y que se corresponderán con los atributos que se
especifican explícitamente en los elementos del documento.
Por último, los símbolos no terminales pueden tener atributos
sintetizados y heredados arbitrarios. En XLOP no es preciso
distinguir explícitamente qué atributos son los sintetizados y
cuáles los heredados, sino que este hecho se infiere del uso de
los mismos en las ecuaciones. Por último, obsérvese que en la
referencia a los atributos, que se lleva a cabo utilizando una
notación del tipo atributo of refSímbolo, es posible utilizar un
número de orden a fin de desambiguar el símbolo concreto al
que pertenece el atributo, cuando éste aparezca más de una vez
en la producción.
Finalmente, es importante notar que el lenguaje XLOP no
proporciona mecanismos para definir las funciones semánticas
utilizadas en las ecuaciones. Dichas funciones deberán ser
definidas externamente, como métodos de la clase semántica.
C. El Generador en XLOP
XLOP incluye un generador que, tomando como entrada
una gramática descrita en el lenguaje de especificación de
XLOP, produce una implementación del procesador asociado
escrita en CUP [2]. CUP es un sistema de generación de
Generador
XLOP
Documento
XML a
Procesar
Especificación
XLOP
Procesador
177
embebe en el proceso de análisis sintáctico mediante un
mecanismo de ejecución retardada, según el cuál la
evaluación de las ecuaciones semánticas se hace depender de
la disponibilidad de valores para los atributos que intervienen
en las expresiones semánticas correspondientes (véase [12]
para más detalles del mecanismo).
La ejecución de los procesadores generados requiere,
además, la clase semántica que implementa las funciones
semánticas, los componentes que conforman la lógica
específica de la aplicación, y también una serie de clases de
conveniencia que configuran el entorno de ejecución XLOP.
Entre éstas últimas destaca la implementación de un
analizador léxico genérico que transforma el recorrido de la
estructura lógica de los documentos (en orden documental) en
la secuencia de componentes léxicos esperada por el
procesador generado. Este componente conecta con un marco
estándar de análisis de documentos XML basado en SAX (un
API para el procesamiento al vuelo de documentos XML) [3].
El componente en sí y la estrategia de interconexión con el
parser SAX son análogos a los descritos en [10]. La Figura 2
resume la cadena de generación implementada en XLOP.
III. PRODUCCIÓN DIRIGIDA POR LENGUAJES DE APLICACIONES
EDUCATIVAS: <E-TUTOR>
A. Generación de tutoriales con <e-Tutor>
En esta sección se ejemplifica el uso de XLOP en el
desarrollo de una versión simplificada de <e-Tutor>
[13][14][16][17], un sistema para el desarrollo de tutores
socráticos basado en los trabajos seminales de Alfred Bork y
su equipo durante los ochenta [4]. Este tipo de sistemas fue
muy popular durante las dos últimas décadas del siglo pasado,
y, a pesar de las críticas recibidas acerca de su idoneidad
pedagógica y de la dificultad de su producción y
mantenimiento, aún hoy existe una comunidad muy activa
trabajando en estos temas, así como iniciativas tan interesantes
como las descritas en [20]. Así mismo, el funcionamiento de
este tipo de sistemas está en la base de los mecanismos de
adaptación de las últimas versiones de especificaciones
e-Learning tan relevantes como QTI [6]. En cualquier caso, el
papel jugado por <e-Tutor> no es tanto pedagógico como
tecnológico, a fin de permitir experimentar con distintos
métodos, técnicas y herramientas de producción y
mantenimiento de aplicaciones e-Learning (e.g., desarrollo
Implementación
en CUP
java
Generador
CUP
Implementación
en JVM
Implementación
en Java
Clase
semántica y
entorno de
ejecución
XLOP
Piensa en el nombre
del país …
¿Cuál es la capital
de Brasil?
(1)
javac
(1)
¡No! Esa es dónde
los carnavales ;)
Figura 2. Cadena de generación en XLOP
traductores para Java que soporta gramáticas LALR(1), la
clase de gramáticas más expresiva para la que es posible
generar analizadores sintácticos compactos y eficientes. En la
implementación CUP generada, la evaluación de atributos se
Brasilia
Río de
Janeiro
(2)
¡No! La respuesta
correcta es Brasilia
Otra
¡No! Piensa en el
nombre del país…
ISSN 1932-8540 © IEEE
(1)
¡Eso es! Vamos
con otra pregunta
(2)
Prueba con otra…
Figura 3. Fragmento de un tutorial socrático
178
<!ELEMENT Tutorial
(Start,(Speech|Question|Answer|Feedback)+,
End)>
<!ELEMENT Start EMPTY>
<!ATTLIST Start next IDREF #REQUIRED>
<!ELEMENT Speech (#PCDATA)>
<!ATTLIST Speech id ID #IMPLIED
next IDREF #REQUIRED>
<!ELEMENT Question (#PCDATA)>
<!ATTLIST Question id ID #REQUIRED>
<!ELEMENT Answer (#PCDATA)>
<!ATTLIST Answer id ID #REQUIRED
forQuestion IDREF #REQUIRED
default (yes|no) "yes">
<!ELEMENT Feedback EMPTY>
<!ATTLIST Feedback counter NMTOKEN #REQUIRED
forAnswer IDREF #REQUIRED
speech IDREF #REQUIRED>
<!ELEMENT End EMPTY>
<!ATTLIST End id ID #REQUIRED>
Figura 4. DTD para el lenguaje de <e-Tutor>.
<Tutorial>
<Start next="..."/>
...
<Question id="q1">
¿Cuál es la capital de Brasil</Question>
<Answer id="a11" forQuestion="q1">
Brasilia</Answer>
<Answer id="a12" forQuestion="q1">
Río de Janeiro</Answer>
<Answer id="a13" forQuestion="q1"
default="yes"/>
<Feedback counter="1"
forAnswer="a11" speech="s1"/>
<Speech id="s1" next="...">
¡Eso es! Vamos con otra pregunta</Speech>
<Speech id="s2" next="s3">
¡No! Esa es dónde los carnavales ;)</Speech>
<Speech id="s3" next="q1">
Piensa en el nombre del país...</Speech>
<Speech id="s4" next="s5">
¡No! La respuesta correcta es
Brasilia</Speech>
<Speech id="s5" next="...">
Prueba con otra...</Speech>
<Speech id="s6" next="q1">
¡No! Piensa en el
nombre del país...</Speech>
...
<End id="..."/>
</Tutorial>
Figura 5. Codificación XML del fragmento de tutorial de la Figura 3
documental, siguiendo un enfoque precursor de XLOP [17],
desarrollo de aplicaciones web educativas dirigido por
lenguajes [13][14], o prototipado rápido de lenguajes de
modelado educativo [16]).
<e-Tutor> interpreta descripciones de tutoriales en los
cuáles el estudiante se somete a problemas, para los cuáles
construye soluciones a través de un diálogo socrático
(maestro – discípulo). El sistema analiza las respuestas del
estudiante a las preguntas planteadas, proporciona al mismo
una realimentación apropiada, y decide el próximo paso a
llevar a cabo en el proceso de aprendizaje. La realimentación
dada se puede adaptar a distintos itinerarios de aprendizaje. En
el caso más general el proceso de adaptación podría depender
de la historia completa de la interacción del estudiante con el
sistema, aunque en <e-Tutor> se adopta un mecanismo simple
basado en contadores, al estilo de los trabajos de Bork. El
sistema asocia contadores a cada posible respuesta de cada
pregunta. Cada vez que el estudiante da una respuesta,
incrementa el contador asociado. De esta forma, la
realimentación y el siguiente paso a dar pueden depender del
valor de dichos contadores. La Figura 3 muestra
esquemáticamente un ejemplo de este tipo de tutorial. Las
cajas con esquinas redondeadas representan puntos de
respuesta, donde el alumno debe proporcionar una respuesta a
la pregunta realizada. Dichos puntos de respuesta están
conectados con potenciales respuestas, que se encierran en una
caja compartimentada. Las cajas sombreadas representan las
realimentaciones. El flujo de aprendizaje se representa
mediante flechas. Las etiquetas numéricas en las flechas que
unen compartimentos de respuestas con realimentaciones
indican los valores que deben tomar los contadores para que
las flechas sean aplicables.
<e-Tutor> incluye un lenguaje de marcado basado en XML
para describir tutoriales como documentos XML, que,
debidamente procesados, permiten ejecutar dichos tutoriales.
La DTD de la Figura 4 muestra una versión simplificada de
Tutorial
next
start
*
<<interface>>
TElement
0..1
Speech
Question
*
Answer
End
for
for
speech
*
feedback
Figura 6. Esbozo de la capa de lógica específica de la aplicación en <e-Tutor>
dicho lenguaje XML (la simplificación omite detalles
estructurales y presentacionales irrelevantes; véase [17] para
una versión más detallada). La Figura 5 muestra una
representación XML del fragmento de tutorial de la Figura 3.
A continuación se describe brevemente la refactorización de
<e-Tutor> utilizando XLOP.
B. La Capa de Lógica Específica de la Aplicación
La Figura 6 muestra las principales componentes (clases e
interfaces) que configuran esta capa, así como sus
interrelaciones. Estos componentes constituyen un marco de
aplicación para la representación de tutoriales. Dado que en
este artículo se está presentando una versión simplificada de
ISSN 1932-8540 © IEEE
179
Tutorial ::= <Tutorial> <Start/> TElements <End/> </Tutorial> {
finalUnlinkedTutorialh of TElements = addStartAndEnd(next of <Start>, id of <End>,
unlinkedTutorial of TElements)
tutorial of Tutorial = tutorial of TElements }
TElements ::= TElements TElement {
unlinkedTutorial of TElements(0) = addElement(element of TElement, unlinkedTutorial of TElements(1))
finalUnlinkedTutorialh of TElements(1) = finalUnlinkedTutorialh of TElements(0)
tutorial of TElements(0) = link(element of TElement,tutorial of TElements(1)) }
TElements ::= TElement {
unlinkedTutorial of TElements = addElement(element of TElement,newTutorial())
tutorial of TElements(0) = link(element of TElement,finalUnlinkedTutorialh of TElements) }
TElement ::= <Speech> #pcdata </Speech> {
element of TElement = newSpeech(id of <Speech>,next of <Speech>,text of #pcdata) }
TElement ::= <Question> #pcdata </Question> {
element of TElement = newQuestion(id of <Question>,next of <Question>,text of #pcdata) }
TElement ::= <Answer> #pcdata </Answer> {
element of TElement = newAnswer(id of <Answer>,forQuestion of <Answer>,default of <Answer>,
text of #pcdata)
}
TElement ::= <Feedback/> {
element of TElement = newFeedback(counter of <Feedback>,forAnswer of <Feedback>,
speech of <Feedback>) }
Figura 7. Especificación XLOP de la capa lingüística de <e-Tutor>.
<e-Tutor>, este marco es una versión simplificada del más
detallado descrito en [17].
C. La Capa Lingüística
La capa lingüística queda definida por la especificación
XLOP que se muestra en la Figura 7. Dicha capa lingüística
traduce descripciones XML de tutoriales en instanciaciones
del marco de aplicación de la Figura 6.
La gramática incontextual subyacente representa el mismo
lenguaje de marcas expresado por la DTD de la Figura 4. La
diferencia es que esta gramática incontextual impone una
estructura bien definida sobre los contenidos de los elementos
(más concretamente, especifica la secuencia de elementos del
tutorial mediante un no terminal TElements, y utiliza
recursión a izquierdas en las producciones que definen dicho
no terminal, ya que este tipo de recursión es tratada de forma
muy eficiente por los analizadores LR subyacentes a la
implementación de XLOP). Mientras que dicha estructura no
es relevante a nivel de la validación genérica de un documento
XML con respecto a su DTD o su esquema, la estructura en sí
es fundamental para añadir significado al lenguaje.
Por su parte, la traducción se concibe en dos etapas: una
etapa de creación de los componentes del tutorial, y otra etapa
de enlace de dichos componentes. De esta forma:
- La etapa de creación se lleva a cabo asociando un atributo
sintetizado unlinkedTutorial con TElements (la
secuencia de elementos del tutorial). Este atributo se
utiliza para construir un tutorial en el que los elementos
aún no están conectados. Cada elemento en sí se sintetiza
mediante un atributo element en TElement (categoría
sintáctica que representa cada elemento individual).
-
La etapa de conexión supone propagar el tutorial no
conectado a lo largo de la secuencia de elementos. Esto se
consigue
asociando
un
atributo
heredado
finalUnlinkedTutorialh con TElements. Así
mismo, esta etapa supone también sintetizar el tutorial
final, conectando cada elemento al resto. Esto se consigue
asociando un atributo sintetizado tutorial con
public class TSemClass {
...
public Tutorial link(TElement e,Tutorial t) {
String idnext = e.idNext();
if (idnext != null)
e.setNext(t.get(idnext));
return t;
}
...
}
Figura 8. Fragmento de la clase semántica para <e-Tutor> que muestra la
implementación de la función semántica link.
TElements, así como con Tutorial
representará el tutorial finalmente construido).
(éste
D. La Clase Semántica
Por último, es necesario proporcionar la clase Java que
implementa las funciones semánticas utilizadas en la
especificación XLOP. En el caso de <e-Tutor>, dichas
funciones instanciarán clases del marco de aplicación, e
invocarán a métodos sobre los objetos resultantes para
conectar los mismos. La Figura 8 esboza un fragmento de
dicha clase, en el que se detalla la implementación de la
función semántica link. Nótese que, aunque desde un punto
de vista estrictamente formal las funciones semánticas
deberían estar libres de efectos laterales, en esta especificación
particular los valores de los atributos de entrada a las
funciones destructivas, como link, no volverán a utilizarse,
lo que permite modificar destructivamente los valores (objetos
Java) a los que se refieren.
IV. PROCESAMIENTO DIRIGIDO POR LENGUAJES DE
DOCUMENTOS DE METADATOS: CHASQUI
A. Restricciones sobre metadatos en Chasqui
En esta sección se ilustra el uso de XLOP para soportar un
procesamiento no trivial de documentos de metadatos de
objetos de aprendizaje en Chasqui. Chasqui es una plataforma
ISSN 1932-8540 © IEEE
180
e-Learning que ha evolucionado a partir de varios sistemas
web utilizados en la virtualización de dos museos
universitarios con fines educativos en la Universidad
Complutense (Museo de Historia de la Informática García
Santesmases y Museo de Arqueología y Etnología Antonio
Ballesteros) [18]. Actualmente es un sistema independiente de
dominios concretos y reutilizable en toda experiencia
<!ENTITY % Constraint "(And|Or|Not|Contains)">
<!ELEMENT And (%Constraint;,%Constraint;)>
<!ELEMENT Or (%Constraint;,%Constraint;)>
<!ELEMENT Not (%Constraint;)>
<!ELEMENT Contains (It,Val)>
<!ELEMENT It (#PCDATA)>
<!ELEMENT Val (#PCDATA)>
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<Or>
<Contains>
<It>Descripción</It>
<Val>gramática</Val>
</Contains>
<Contains>
<It>Formalismo</It>
<Val>gramática</Val>
</Contains>
</Or>
Items (Item+)>
Item (Name,Value)>
Name (#PCDATA)>
Value (#PCDATA)>
Figura 9. Lenguaje de marcado (simplificado) para los documentos de
metadatos Chasqui.
<Items>
<Item>
<Name>Descripción</Name>
<Value>Informe sobre gramáticas
l-atribuidas</Value>
</Item>
<Item>
<Name>Aspecto especificado</Name>
<Value>semántica</Value>
</Item>
<Item>
<Name>Formalismo</Name>
<Value>gramáticas de atributos</Value>
</Item>
<Item>
<Name>tipo de objeto</Name>
<Value>informe</Value>
</Item>
</Items>
Figura 11. Lenguaje de marcado (simplificado) para las restricciones sobre
metadatos.
Figura 12. Un ejemplo de restricción
<Check>
<Constraint>
...
</Constraint>
<Items>
...
</Items>
</Check>
Figura 13. Esquema de la entrada al proceso de comprobación de
restricciones.
AssertionStore
EResul
+addAssertion(String i, String v)
+boolean checkAssertion(String i, String v)
+boolean yields(String i, String v)
+boolean valueOf()
+SIterator newIterator()
+int supportSize()
SIterator
Figura 10. Un documento de metadatos.
e-Learning que involucre la creación y uso educativo de
repositorios de objetos de aprendizaje.
Los objetos de aprendizaje en Chasqui tienen asociados
documentos XML de metadatos que describen la asignación de
valores a ítems de metadatos1 organizados jerárquicamente.
Tales ítems no están predeterminados a priori, sino que se
crean de manera colaborativa, conforme se añaden nuevos
objetos al repositorio, en un enfoque próximo a las tendencias
emergentes en etiquetado colaborativo en el contexto de los
escenarios Web X.0 (véase [15] para más detalles).
A fin de evitar detalles que nos aparten del principal
propósito de este trabajo, en la discusión que sigue omitiremos
la naturaleza jerárquica de los ítems de metadatos en Chasqui.
De esta forma, la DTD que se muestra en la Figura 9 describe
(una versión simplificada de) el lenguaje de marcado utilizado
en Chasqui para estructurar los documentos de metadatos. De
acuerdo con este lenguaje, cada ítem de metadatos posee un
nombre (Name) y un valor (Value). Los documentos en sí
son secuencias de estos ítems. La Figura 10 muestra un
ejemplo de documento de metadatos.
El carácter abierto y evolutivo de los metadatos en Chasqui
hace necesario introducir algunos mecanismos de control a fin
1
En Chasqui los ítems de metadatos se denominan atributos. No obstante, en
este trabajo evitaremos tal denominación para evitar confusiones.
+next()
+String item()
+String value()
produces
Figura 14. Lógica específica de la aplicación para la comprobación de
restricciones en documentos de metadatos Chasqui.
de garantizar la calidad y consistencia de los documentos de
metadatos. Para tal fin, los instructores que lideran la
construcción del repositorio de objetos de aprendizaje pueden
imponer restricciones sobre los documentos asociados con los
objetos que se añaden al repositorio. De esta forma, cuando los
alumnos añadan nuevos objetos, el sistema podrá chequear
dichas restricciones, así como avisar a dichos alumnos de las
potenciales violaciones de las mismas.
En Chasqui las restricciones que pueden formularse
involucran un repertorio completo de asertos básicos, que
pueden combinarse utilizando los operadores booleanos
habituales (and, or y not). Por motivos de simplicidad,
restringiremos nuestra discusión a asertos de tipo Contiene. Un
aserto de tipo Contiene obliga a que cada ocurrencia de un
ítem de metadatos dado contenga cierta cadena especificada en
el aserto.
En Chasqui las restricciones también se representan
internamente utilizando un lenguaje de marcado basado en
XML. La Figura 11 muestra la DTD de dicho lenguaje. La
ISSN 1932-8540 © IEEE
181
CheckDoc ::= <Check><Constraint>C</Constraint> Is</Check> {
basicAssertionsh of Is = basicAssertions of C
checkedBasicAssertionsh of C = checkedBasicAssertions of Is
val of CheckDoc = val of C
basicAssertions of CheckDoc = checkedBasicAssertions of Is}
C ::= <And> C C </And> {
basicAssertions of C(0) = comb(basicAssertions of C(1),basicAssertions of C(2))
checkedBasicAssertionsh of C(1) = checkedBasicAssertionsh of C(0)
val of C(0)= valOfAnd(val of C(1),val of C(2),checkedBasicAssertionsh of C(0))}
C ::= <Or> C C </Or> {
basicAssertions of C(0) = comb(basicAssertions of C(1),basicAssertions of C(2))
val of C(0)= valOfOr(val of C(1),val of C(2),checkedBasicAssertionsh of C(0))}
C ::= <Not> C </Not> {
basicAssertions of C(0) = basicAssertions of C(1)
val of C(0) = valOfNot(val of C(1))}
C ::= <Contains> <Attr>#pcdata</Attr> <Val>#pcdata</Val> </Contains> {
basicAssertions of C = newCons(text of #pcdata(0),text of #pcdata(1))
val of C = valOfC(text of #pcdata(0),text of #pcdata(1), checkedBasicAssertionsh of C)}
Is ::= <Items> IList</Items> {
basicAssertionsh of IList = basicAssertionsh of Is
checkedBasicAssertions of Is = checkedBasicAssertions of IList }
IList ::= IList I {
basicAssertionsh of IList(1) = basicAssertionsh of IList(0)
checkedBasicAssertions of IList(0) = check(checkedBasicAssertions of IList(1),item of I,val of I) }
IList ::= I {
checkedBasicAssertions of IList = check(basicAssertionsh of IList, item of I,val of I) }
I ::= <Item> <Name>#pcdata</Name> <Value>#pcdata</Value> </Item> {
item of I = text of #pcdata(0)
val of I = text of #pcdata(1) }
Figura 15. Especificación XLOP de la capa lingüística para la comprobación de restricciones sobre metadatos en Chasqui.
Figura 12, por su parte, muestra un ejemplo de restricción que
fuerza a que el término gramática ocurra en todos los valores
del ítem Descripción, o en todos los valores del ítem
Formalismo. La Figura 13 muestra el tipo de entrada que
recibe el servicio Chasqui que chequea las restricciones (un
documento XML que agrupa bajo el elemento Check una
restricción y un documento de metadatos Chasqui).
B. La Capa de Lógica Específica de la Aplicación
La Figura 14 esquematiza la lógica específica de la
aplicación utilizada en la comprobación de restricciones sobre
documentos de metadatos Chasqui. Dicha lógica específica
incluye una clase para almacenar la información necesaria
sobre los asertos básicos (AssertionStore), una segunda
clase para contener los resultados de evaluación de las
restricciones (EResul), y una tercera clase para iterar sobre
tales resultados (SIterator).
C. La Capa Lingüística
La Figura 15 muestra la gramática de atributos XLOP que
caracteriza el proceso de comprobación de restricciones sobre
documentos de metadatos en Chasqui. La gramática
incontextual subyacente representa la estructura del
documento de tipo Check descrito anteriormente. De nuevo, y
por los motivos a los que se ha hecho ya alusión en la sección
III, se utiliza recursión a izquierdas para representar la
secuencia de ítems en el documento de metadatos. En lo que
respecta al procesamiento, éste se concibe en tres etapas
diferentes: una primera etapa de recolección en la que se
recolectan todos los asertos básicos, una segunda etapa de
chequeo en la que se comprueba si dichos asertos básicos se
satisfacen o se violan, y una última etapa de evaluación, en la
que se comprueba la satisfacción o violación de la restricción
en su totalidad. De esta forma:
- La etapa de recolección se lleva a cabo sintetizando un
atributo basicAssertions que referirá al almacén de
asertos (instancia de AssertionStore) utilizado para
almacenar los asertos básicos referidos en la restricción.
Este almacén se propaga por las estructuras asociadas al
documento de metadatos utilizando un atributo heredado
basicAssertionsh.
-
La etapa de chequeo se lleva a cabo sintetizando un
atributo
checkedBasicAssertion
que
hará
referencia al almacén de asertos una vez que cada ítem de
metadatos haya sido comprobado con respecto a los
asertos básicos. El almacén resultante es realimentado de
nuevo sobre la estructura de la restricción utilizando un
atributo heredado checkedBasicAssertionh.
-
En la etapa de evaluación se sintetiza un atributo val
para la restricción. Este atributo contiene un valor de
verdad asociado a la restricción y un conjunto de asertos
básicos que justifican dicho valor denominado soporte
(esta información se almacena en instancias de EResul).
Para asertos básicos, el valor de verdad se obtiene
consultando el almacén de asertos. En condiciones
afectadas por el operador +ot se complementa el valor de
verdad de la condición y se mantiene el conjunto soporte
de la condición. El valor de una condición And depende
de los valores de sus argumentos: si ambos valores son
ISSN 1932-8540 © IEEE
182
public class CheckingSemanticClass {
private AssertionStore astore;
public CheckingSemanticClass() {
astore = new AssertionStore();
}
public AssertionStore newCons(String i,
String v) {
astore.addAssertion(i,v);
return astore;
}
public AssertionStore comb(AssertionStore a1,
AssertionStore a2) {
return astore; } ... }
[2]
[3]
[4]
[5]
[6]
[7]
Figura 16. Fragmento de la clase semántica para la comprobación de
restricciones sobre metadatos en Chasqui.
[8]
verdad, el valor final es verdad y el soporte es la unión de
los soportes de los argumentos, y en caso contrario el
valor de verdad es falso y el conjunto soporte es el
conjunto más simple que justifica dicho valor. Por último
el valor de una condición Or es el dual de una condición
And.
[9]
D. La Clase Semántica
La Figura 16 muestra un fragmento de la clase semántica
para el procesamiento descrito en esta sección. Obsérvese que
la clase maneja internamente estado con el fin de mejorar la
eficiencia del procesador finalmente generado. Efectivamente,
la clase permite reutilizar el mismo almacén de asertos en
todas las operaciones. Esta optimización no compromete, sin
embargo, el carácter declarativo de dicha especificación.
V. CONCLUSIONES Y TRABAJO FUTURO
XLOP proporciona una abstracción dirigida por lenguajes
que introduce dos capas bien diferenciadas en la construcción
de componentes y/o aplicaciones e-Learning que hacen un uso
intensivo de documentación XML: una capa con la lógica
específica de la aplicación, y una capa lingüística. La capa
lingüística se especifica a alto nivel, como una gramática de
atributos, y se conecta con la capa de la lógica específica
mediante una clase semántica, que implementa las funciones
semánticas utilizadas en la gramática. XLOP facilita el
desarrollo y mantenimiento de las capas lingüísticas, ya que
éstas se especifican a un grado muy alto de abstracción.
Actualmente se están realizando distintas extensiones del
lenguaje de especificación de XLOP (e.g., operadores
definidos por el usuario, funciones semánticas no estrictas,
capacidades de modularización, o tipado estático de las
especificaciones). Como trabajo futuro se buscará la
integración de XLOP con lenguajes para gramáticas
documentales XML. Así mismo se desarrollará un entorno
gráfico de depuración. Por último, se aplicará XLOP a
experiencias e-Learning adicionales.
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
Appel, A.W. 1997. Modern Compiler Implementation in Java.
Cambridge Univ. Press
Birbeck, M et al. 2001. Professional XML 2nd Edition. WROX Press,
Birminghan,UK
Bork, A. 1985. Personal Computers for Education. Harper & Rows
Fernández-Manjón, B., Sierra, J.L., Moreno-Ger, P., Martínez-Ortiz, I.
Uso de Estándares Aplicados a TIC en Educación. Informe Técnico 16,
Centro Nacional de Información y Comunicación Educativa (CNICE),
ares.cnice.mec.es/informes/16/
IMS.
IMS
Question
and
Test
Interoperability
2.1.
www.imsglobal.org/question/
Kawaguchi, K. 2002. Flexible Data-Biding with RelaxNGCC. Extreme
Markup Languages 2002, 4-9 Agosto, Montreal, Canada
Knuth, D. E. 1968. Semantics of Context-free Languages. Math. Syst.
Theory 2(2), 127–145. Ver también Math. Syst. Theory 5(1), 95–96
Paaki, J. 1995. Attribute Grammar Paradigms – A High-Level
Methodology in Language Implementation. ACM Comp. Surveys,
27(2), 196-255.
Sarasa, A., Navarro, I., Sierra, J.L, Fernández-Valmayor, A. 2008.
Building a Syntax Directed Processing Environment for XML
Documents by Combining SAX and JavaCC. 3rd Int. Workshop on
XML Data Management Tools & Techniques. DEXA’08. 1-5 Sept.,
Turin, Italia
Sarasa, A., Sierra, J.L., Fernández-Valmayor, A. 2008. Procesamiento
de documentos XML dirigido por lenguajes en entornos de e-Learning.
SIIE’08, 1-3 Oct., Salamanca, España.
Sarasa, A., Temprado, B., Sierra, J.L., Fernández-Valmayor, A. 2008.
XML Language-Oriented Processing with XLOP. 5th Int. Symp. on Web
and Mobile Information Services. AINA’09. 26-29 Mayo, Bradford, UK
Sierra, J.L., Fernández-Manjón, B., Fernández-Valmayor, A. 2007.
Language-Driven Development of Web-Based Learning Applications.
Advances in Web Based Learning - ICWL 2007, LNCS 4823, 520-531
Sierra, J.L., Fernández-Manjón, B., Fernández-Valmayor, A. 2008. A
Language-Driven Approach for the Design of Interactive Applications.
Interacting with Computers 20(1), 112-127
Sierra, J.L., Fernández-Valmayor, A. 2008. Tagging Learning Objects
with Evolving Metadata Schema. ICALT’08. 1-5 Julio, Santander,
España.
Sierra, J.L., Fernández-Valmayor, A., Fernández-Manjón, B. 2007. How
to Prototype an Educational Modeling Language. SIIE’07, 14-16 Nov.,
Porto, Portugal.
Sierra, J.L., Fernández-Valmayor, A., Fernández-Manjón, B. 2008.
From Documents to Applications Using Markup Languages. IEEE
Software 25(2), 68-76
Sierra, J.L., Fernández-Valmayor, A., Guinea, M., Hernánz, H. 2006.
From Research Resources to Virtual Objects: Process model and
Virtualization Experiences. J. of Ed. Tech. & Society, 9(3), 56-68.
Stanchfield, S., ANTXR: Easy XML Parsing based on The ANLR
Parser Generator. Java Due.com, Hillcrest Comm. & FGM, Inc.
javadude.com/tools/antxr/index.html
XTutor web site. 2007. icampus.mit.edu/xtutor. Vis. 21 Abril 2008
AGRADECIMIENTOS
El grupo de investigación UCM 921340 y los proyectos
TIN2005-08788-C04-01,
TIN2007-68125-C02-01,
y
Santander/UCM PR34/07-15865 han financiado este trabajo.
REFERENCIAS
[1]
Aho, A.V., Lam, M.S., Sethi, R., Ullman, J.D. 2007. Compilers:
principles, techniques and tools (second edition). Addison-Wesley
ISSN 1932-8540 © IEEE
Antonio Sarasa-Cabezuelo es Licenciado en Ciencias
Matemáticas por la Universidad Complutense de
Madrid (España), dónde actualmente ejerce como
Profesor Colaborador. Coautor de más de 50 artículos
publicados en actas de conferencias y revistas,
colabora también con RED.ES y el Ministerio de
Industria, Turismo y Comercio de España en diversas
iniciativas e-Learning (especificación LOM-ES y
proyecto AGREGA). Sus intereses investigadores
incluyen la creación y despliegue de objetos educativos
estandarizados, y el procesamiento de documentos
XML dirigido por lenguajes, campo este último en el
que está realizando su Tesis Doctoral.
José-Luis Sierra-Rodríguez es Doctor en Informática
por la Universidad Complutense de Madrid (España),
dónde actualmente ocupa una plaza de Profesor
Titular de Universidad. El Dr. Sierra es coautor de más
de 70 artículos de investigación publicados en revistas
y actas de conferencias internacionales. Sus intereses
investigadores incluyen la Ingeniería del Software
orientada a lenguajes, los lenguajes de marcado y el
desarrollo dirigido por lenguajes de Sistemas eLearning.
Alfredo Fernández-Valmayor es Doctor en Ciencias
Físicas por la Universidad Complutense de Madrid
(España), y Profesor Titular de Universidad en dicha
universidad, dónde también dirige el Campus Virtual
de la institución. El Dr. Fernández-Valmayor es
coautor de más de 70 artículos científicos publicados
en revistas y actas de conferencias internacionales. Sus
intereses investigadores se centran en los usos
educativos de los lenguajes de marcado y en el
desarrollo y autoría de materiales para sistemas de
educación basados en web.
ISSN 1932-8540 © IEEE
183
184
DidaktosOnLine: uma ferramenta para a
construção social do conhecimento
Francislê Neri de Souza e António Moreira
Title— DidaktosOnLine: a tool for the social construction of
knowledge
Abstract—This paper proposes a reflection around the
instruments and strategies developed within Educational
Technology (ET) practical classes, with two groups of students at
the University of Aveiro, Portugal. Students were asked to
collaboratively develop educational materials based on Cognitive
Flexibility Theory (CFT). DidaktosOnLine (DOL), which has
Social Web characteristics (http://didaktos.ua.pt) and was
developed by University of Aveiro researchers, offers an
environment for social construction and interaction, rich in
context dependent information, discussion and critical
questioning. Results show that students in both groups adhered to
DOL, working collaboratively, evidencing some difficulties in
diverse domains, reported in this paper.
Index Terms — Web 2.0, eLearning, DidaktosOnLine,
Cognitive Flexibility Theory (CFT).
S
I. INTRODUÇÃO
PIRO e colaboradores propuseram uma teoria de
aprendizagem e de ensino que enfatiza a necessidade de
trabalhar conhecimentos complexos e pouco-estruturados em
contraste a conhecimentos simples e de domínios bemestruturados. A aprendizagem é encarada como um processo
de reconstrução a partir da experiência e do ambiente onde se
contextualiza, devendo este proporcionar ao aluno múltiplas
interpretações [1, 2].
A Teoria da Flexibilidade Cognitiva (TFC) preocupa-se
com a aquisição de nível avançado de conhecimento complexo
e pouco-estruturado, como o comprovam vários estudos (por
exemplo, [3-5] e sugere que se apresente a complexidade em
pequenas unidades, sendo estas analisadas através de múltiplas
perspectivas, que vão facultar uma melhor compreensão do
assunto em análise. Caracteriza-se pela interacção de vários
conceitos que são pertinentes na aplicação a um caso, sendo a
combinação desses conceitos inconsistente em casos do
mesmo tipo. Este domínio é tratado por Moreira et al. [6, 7]
F. Neri de Souza, Departamento de Didáctica e Tecnologia Educativa,
CIDTFF, Campus de Santiago, Universidade de Aveiro, 3810-193 Aveiro,
Portugal (e-mail [email protected]).
A. Moreira, Departamento de Didáctica e Tecnologia Educativa, CIDTFF,
Campus de Santiago, Universidade de Aveiro, 3810-193 Aveiro, Portugal (email [email protected]).
como um domínio holístico-integrativo do conhecimento. Este
facto não é uma limitação da teoria, mas uma especificidade
que até então nunca tinha sido proposta.
Se pretendemos que os alunos usem de modo flexível o
conhecimento, ele deve ser ensinado de uma forma flexível.
Spiro et al. [8] consideram os sistemas hipertexto e hipermédia
adequados e convenientes para implementar a teoria, uma vez
que estes sistemas podem proporcionar múltiplas travessias de
uma dada paisagem cognitiva e sua integração em múltiplos
casos e mini-casos. De forma resumida, os pressupostos de
base da TFC assentam nos princípios de que para se aprender
num domínio de estruturação holístico-integrativa, isto é, num
domínio pouco estruturado de nível avançado, detentor de
complexidade, é necessário cruzar esse domínio (ou paisagem
conceptual) a partir de pontos de vista diferenciados. Esse
domínio, pelas suas características, deve ser representado por
casos ilustrativos do mesmo, e estes, por sua vez, decompostos
em unidades menores, cognitivamente manejáveis (minicasos), que tornem salientes as especificidades do domínio.
Tal decomposição promoverá o desenvolvimento da
flexibilidade cognitiva necessária à sua compreensão,
evitando os enviesamentos redutores próprios da rigidez
cognitiva, com especial relevo para a utilização de analogias
múltiplas capazes de compreender toda a complexidade de um
dado fenómeno. Isto é conseguido por recurso a Hipertextos
de Flexibilidade Cognitiva que, por fomentarem um ensinoaprendizagem de acesso aleatório, permitem cruzamentos de
uma dada paisagem conceptual mediante preceitos de
revisitação dos mesmos conceitos a partir de um ponto de vista
fundamentado na repetição não replicada do conhecimento.
Quer isto dizer que, num dado momento, o mesmo conceito é
visitado no âmbito de elementos contextuais diversos dos que
o contextualizarão numa outra visita.
Embora a TFC possa ser implementada em ambientes
multimédia do tipo Web 1.0, mesmo que numa filosofia open
source [9], é certamente em contextos Web 2.0 que as
características de trabalho colaborativo flexível e distribuído
poderão ser melhor aplicadas.
Os sites considerados Web 2.0 ou Web Social permitem aos
utilizadores fazer muito mais do que apenas aceder a
informações em diferentes formatos ou em diferentes
sequências; permitem desconstruir e construir socialmente os
conteúdos desejados. Os utilizadores podem construir
conhecimento de forma interactiva numa plataforma na rede de
computadores, podem executar aplicações de software através
de um browser vulgar, colocar os próprios dados em rede e
exercer controlo sobre estes dados. Os sites Web 2.0 são
ISSN 1932-8540 © IEEE
NERI DE SOUZA Y MOREIRA: DIDAKTOSONLINE: FERRAMENTA PARA CONSTRUÇÃO DO ...
considerados por O’Reilly [10] como aqueles que
proporcionam um efeito de rede através de uma "arquitectura
de participação", que encoraja o envolvimento activo dos seus
utentes, em vez de os transformar em utilizadores passivos. O
conceito de Web como plataforma de participação e interacção
tem muitas das características que necessitamos para
promover, em contexto educacional, a aprendizagem activa,
colaborativa e rica em casos, mini-casos e travessias
conceptuais.
De acordo com diversos autores [10, 11] as características
da Web 2.0 são as seguintes: participação activa do utilizador,
rica em experiência, conteúdo dinâmico, meta dados, padrão
Web, escalabilidade, abertura, liberdade e inteligência
colectiva por meio de participação do utente.
II. OBJECTIVOS E FERRAMENTAS WEB 2.0 DO ESTUDO
Um ambiente distribuído é aquele em que os alunos podem
desenvolver colaborativamente a desconstrução e a construção
do conhecimento, e onde todos podem ter acesso ao trabalho.
O factor portabilidade é crítico, pois a aprendizagem
colaborativa exige não somente um ambiente distribuído, mas
também multi-plataforma. Tal portabilidade é possível com a
plataforma DidaktosOnLine (DOL) - http://didaktos.ua.pt [6,
7]. Os objectivos deste trabalho foram introduzir os conceitos
subjacentes à TFC e incentivar o desenvolvimento de
projectos através da utilização do DOL. Também procurámos
compreender quais as principais dificuldades sentidas pelos
estudantes nas vertentes teórica, prática e de trabalho de grupo.
185
Considerando que Web 2.0, como reconhece O’Reilly [10],
não tem fronteiras rígidas, mas antes, um núcleo gravitacional
onde os conceitos de Web Social são caracterizados, o DOL é
uma plataforma Web 2.0 pelas razões que passamos a
descrever. DIDAKTOS é um acrónimo para “Didactic
Instructional Design for the Acquisition of Knowledge and
Transfer to Other Situations”, desenvolvido por Moreira e
colaboradores [6, 7], para utilização local. O DidaktosOnLine
é um sistema de hipertexto de flexibilidade cognitiva inspirado
nos pressupostos da Teoria da Flexibilidade Cognitiva e que
dele derivou, em formato distribuído. Pode ser usado na
desconstrução e construção de conteúdos de qualquer área
disciplinar numa perspectiva holístico-integrativa.
O DidaktosOnLine é uma open shell que permite aos
utilizadores (professores e alunos), mediante a escolha prévia
de um número específico de conteúdos (casos), dividi-los em
pequenas unidades (mini-casos) que minimizem a sobrecarga
cognitiva para o utilizador final (alunos). No entanto, os minicasos são conceptualmente ricos e detentores de
complexidade. Outra funcionalidade do DidaktosOnLine é a
possibilidade de inclusão de actividades no decorrer do estudo
dos casos e dos mini-casos, tais como a formulação de
perguntas ou a elaboração de uma explicação sobre
determinado aspecto ou travessia conceptual. Na figura 1,
apresentamos o aspecto geral do DidaktosOnLine e exemplos
de mini-casos.
A seguir apresentamos um Caso de um projecto
desenvolvido no Centro Competência Nónio – Século XXI da
Fig. 1. Aspecto geral de um caso no DidaktosOnLine.
ISSN 1932-8540 © IEEE
186
Universidade de Aveiro, desenvolvido por Leonel Rocha, para
alunos de Ciências do 8º ano de escolaridade (13-14 anos).
“Caso: O Dióxido de Carbono - O mau da fita.
Descrição do caso: Devido ao Aquecimento Global, o Dióxido de Carbono
é apelidado do "mau da fita". Será que é mesmo? O desenvolvimento deste
caso é baseado no texto de Tomás de Montemor publicado no Notícias
Magazine de 08.Set.2002 com o titulo "O Gás Indeciso"
Mini-casos
- O papel do Dióxido de Carbono...
- Os irmãos Carbono feitos prisioneiros!
- O plano de fuga do irmão "Carbono 1"
- O "Carbono 2" torrando ao Sol...
- Na paisagem queimada ainda restava como prisioneiro o "Carbono 3"
- O "Carbono 1" levou um tiro e ...”
Na Figura 2 apresentamos o Mini-caso “Os irmãos Carbono
feitos prisioneiros!”
Para uma descrição mais detalhada do sistema ver [7, 12].
III. DESCRIÇÃO DO ESTUDO
Antes do início do semestre lectivo foi discutida com o
professor da disciplina de Tecnologia Educativa a
implementação de algumas estratégias para a utilização do
DOL. A inovação na disciplina teve em conta um trabalho que
procurava analisar os desafios de inserir a TFC em duas
turmas de formação de professores (inicial e em serviço) do
ano anterior [5].
“Results show that the in-service group is more pro-active
and committed to discussion of the theory and its
application, showing higher levels of interaction between
its members. Future implementations of the ET course
under the same format will have to pay special attention
to CFT jargon and associated concepts, offering
strategies that may overcome these comprehension
problems, and also the provision of a variety of good
commented examples of the application of CFT,
rendering it clearer for the students. A set of guidelines
and a glossary are also instruments under construction,
Área onde se podem
disponibilizar recursos:
Som, Vídeo, Imagem etc.
Fig. 2. Mini-caso “Os irmãos Carbono feitos prisioneiros!”
ISSN 1932-8540 © IEEE
along with an array of FAQ for the benefit of all using
DidaktosOnLine” [5].
Com base neste estudo prévio e no repensar dos objectivos
de investigação utilizámos os seguintes instrumentos:
1. Uma plataforma LMS para a comunicação online
(Blackboard).
2. Uma plataforma para o desenvolvimento de um
projecto segundo a TFC (DidaktosOnLine – DOL)
3. Uma ficha com conceitos fundamentais sobre a Teoria
da Flexibilidade Cognitiva no contexto do DOL.
4. Uma ficha com perguntas genéricas auxiliares para ser
usada nos momentos de questionamento por escrito.
5. Uma ficha com critérios para a desconstrução do
conhecimento
com
base
no
incentivo
ao
questionamento e um exemplo de projecto
desconstruído segundo a TFC.
6. Tutorial, manual e textos disponibilizados no
Blackboard e no DOL.
Todos estes instrumentos foram utilizados no contexto de
diversas estratégias que procuravam incentivar os estudantes a
desenvolverem produtos didácticos inovadores, a partir duma
atitude reflexiva e crítica sobre o ensino e sobre a
aprendizagem, devidamente fundamentadas em resultados da
mais recente investigação nas áreas da didáctica da
especialidade e da tecnologia educativa. Em geral as
estratégias
pretendiam
ajudar
os
estudantes
no
desenvolvimento de competências, tais como:
1) Articulação e integração dos conhecimentos oriundos da
investigação em didáctica e em tecnologia educativa no
desenvolvimento e implementação de produtos didácticos;
2) Adopção de atitudes reflectidas, críticas e de
questionamento, devidamente fundamentadas, face ao ensino e
à aprendizagem, particularmente sobre os produtos didácticos
de utilização em sala de aula que medeiam o processo;
3) Trabalho em equipa, partilhando esforços, resolvendo
eventuais problemas, aceitando opiniões divergentes;
4) Reconhecimento do valor acrescentado da dimensão
social na construção do conhecimento e, por conseguinte, na
formação profissional, através da participação em fóruns de
discussão;
5) Formulação de perguntas (adequadas a cada momento de
ensino) e de modos de estimular a formulação perguntas
(através de instrumentos e estratégias adequados) dos próprios
alunos, visando promover atitudes de questionamento
consequente.
A disciplina de Tecnologia Educativa desencadeou-se em
regime misto (b-learning), de acordo com o calendário das
sessões presenciais distribuído, e acompanhado a distância, na
plataforma Blackboard, nos períodos que permeavam as
sessões presenciais. Nas sessões presenciais, as aulas
desenrolaram-se no formato de debate colectivo, induzido por
perguntas orientadoras (ficha de perguntas genéricas),
propostas pelo docente, e/ou actividades desenvolvidas em
grupo, seguidas de relato por um porta-voz e discussão
(centrada nas perguntas dos colegas).
187
Nas sessões não-presenciais, os alunos, em grupo ou em
nome individual, na comunidade então criada, poderiam
debater as perguntas formuladas (utilizando as “perguntas
genéricas”) emergentes em torno do trabalho que se encontram
a desenvolver.
O semestre lectivo foi desenvolvido em aproximadamente
cinco fases de formação que apresentamos a seguir:
1ªFASE Teórico-prática. Sobre a Teoria da Flexibilidade
Cognitiva (~3 sessões)
2ªFASE Teórico-prática. Fundamentos e exemplos do
DidaktosOnLine (~2 sessões).
3ªFASE Prática. Exploração (individual e em grupo) de
projectos no DOL (1 sessão).
4ªFASE Prática. Elaboração de um projecto em DOL (~6
sessões).
5ªFASE Prática. Apresentação oral dos projectos
desenvolvidos em DOL (1 sessão).
Os trabalhos desenvolvidos pelos estudantes pelas duas
turmas envolvidas neste estudo foram objecto de uma
avaliação contínua, de pendor formativo, e de uma avaliação
final, somativa. A avaliação final foi o resultado da
combinação entre a avaliação contínua e o cômputo sobre o
projecto no DOL propriamente dito e a sua apresentação oral.
A evolução das competências de questionamento ao longo do
semestre foi também objecto de avaliação.
Tanto a turma de formação inicial como a de formação em
serviço trabalharam em grupos de 2 a 4 estudantes para
desenvolver o seu projecto no DOL. As estudantes da
formação inicial (todas do género feminino) desenvolveram
projectos relacionados com temas ligados à sua licenciatura
(1º CEB), tais como: Higiene pessoal, Alimentação, Educação
Ambiental, Multiculturalidade, Meios de Comunicação e
Transporte. Os estudantes da turma de formação em serviço
desenvolveram projectos variados e transdisciplinares,
aproveitando assim as diversas especialidades que cada grupo
de professores leccionava, tais como: comportamentos de
risco, a evolução dos computadores, o terramoto de Lisboa,
distúrbios alimentares.
IV. RESULTADOS
No inicio do semestre lectivo foi aplicado um questionário a
ambas as turmas com o objectivo de conhecer a opinião e
expectativas dos estudantes sobre alguns aspectos da sua
participação na disciplina de Tecnologia Educativa. Um
segundo questionário semelhante ao primeiro foi aplicado no
final do semestre com o objectivo de avaliar a opinião dos
estudantes sobre os instrumentos, estratégias e dificuldades no
desenvolvimento do projecto. Nestes questionários existiam
questões de cariz mais quantitativo e questões abertas que
exigiam análise de conteúdo. Também realizámos cinco
entrevistas no final do semestre lectivo, 3 na turma de
formação inicial e 2 na turma de formação em serviço. Uma
importante fonte de dados foi as notas de campo do
investigador, obtidas através de observação participante em
todas as aulas das duas turmas. Também os relatórios finais,
ISSN 1932-8540 © IEEE
188
tarefas e reflexões escritas pelos estudantes foram objecto de
análise deste estudo. No entanto, neste artigo trataremos
apenas de alguns dados relacionados com as expectativas e
dificuldades dos estudantes de ambas as turmas na utilização
do DOL e no trabalho em grupo. Para tratar os dados
qualitativos contámos com o apoio do software para análise
qualitativa NVivo7 e, para os aspectos mais quantitativos dos
questionários, utilizámos o SPSS.
Apresentaremos a seguir alguns dos resultados obtidos a
partir dos dois questionários aplicados a ambas as turmas. Por
uma questão de mais fácil designação chamaremos Turma 1 à
turma de Formação Inicial (1º CEB), e Turma 2 à turma de
Formação em Serviço. Na Tabela 1 apresentamos a opinião
dos estudantes sobre as dificuldades encontradas na utilização
do DOL.
TABELA I
SOBRE O DIDAKTOSONLINE – (2º QUESTIONÁRIO)
Turma 1
A
B
C
D
Discordo
16
69,6%
-
Sem
Opinião
2
8,7%
-
5
21,7%
2
8,7%
4
17%
6
26%
Turma 2
Concordo
5
21,7%
23
100%
14
60,9%
15
65,2%
Discordo
22
75,9%
1
3,4%
5
17,2%
4
13,8%
Sem
Opinião
1
3,4%
4
14%
4
14%
Concordo
6
20,7%
28
96,6%
20
69,0%
21
72,4%
A - Tive muitas dificuldades em utilizar o DOL.
B - Sei colocar imagens, vídeos e outros recursos no DOL.
C- Sinto que aprendi a trabalhar com muitos outros softwares e recursos ao usar o DOL.
D - As minhas maiores dificuldades centraram-se mais na aplicação da TFC do que na
utilização do DOL.
Em geral, mais de 70% dos estudantes de ambas as turmas
atestaram que não tiveram dificuldade em utilizar o DOL,
sabendo colocar os recursos que necessitavam (imagens, som,
vídeo) na plataforma. Neste sentido, uma quantidade
semelhante de estudantes concordaram que aprenderam a
trabalhar com outros softwares e recursos ao usar o DOL.
Numa outra parte deste questionário, todos os estudantes da
Turma 2 (formação em serviço) consideraram serem capazes
de aplicar as TIC nas suas práticas de ensino e 72% planeavam
utilizar os projectos desenvolvidos no DOL com os seus
futuros alunos.
A última linha da Tabela 1 mostra que quase 70% dos
estudantes confirmaram que as maiores dificuldades que
tiveram foram sempre na aplicação da TFC e não na utilização
do DOL. Para compreender melhor esta e outras dificuldades
recorremos à análise de conteúdo de uma questão aberta do 1º
e do 2º questionário. No questionário aplicado no início do
semestre, perguntámos: “Considerando as suas competências e
conhecimentos actuais, onde prevê que sentirá maior
ou na parte
dificuldade nesta disciplina: na parte teórica
prática ? Porquê?” Era suposto os alunos assinalarem com
um √ a caixa correspondente. Na Tabela 2, a seguir, podemos
perceber que os estudantes de ambas as turmas prevêem que
suas dificuldades se centrarão na parte teórica da disciplina,
uma vez que já utilizam os computadores e se sentem
confiantes para executar novas tarefas na sua utilização
prática.
TABELA II
PREVISÃO DE DIFICULDADES NA DISCIPLINA (1º QUESTIONÁRIO)
Prática
Teórica
Ambas
Não Sabe
Turma 1 (N=34)
1 (3%)
20 (59%)
4(12%)
10 (29%)
Turma 2 (N=33)
8 (24%)
18 (55%)
9(27%)
8(24%)
Em muitos dos casos os estudantes assinalaram dificuldades
com a parte prática ou teórica, mas acabaram por justificar por
escrito que previam dificuldades em ambas as dimensões
(prática e teórica).
Nestes casos, as codificações foram feitas em mais de uma
categoria, razão pela qual os valores percentuais totais são um
pouco superiores a 100%.
Surpreendentemente, no final do semestre, ao serem
questionados onde efectivamente “sentiram maior dificuldade
na disciplina: na parte teórica ou na parte prática? e Porquê?”,
os estudantes da turma 1 (75%) afirmaram que foi na parte
prática, enquanto que os estudantes da turma 2 continuaram,
na sua maioria, a assinalarem a parte teórica da disciplina.
TABELA III
DIFICULDADES ENCONTRADAS NA DISCIPLINA (2º
QUESTIONÁRIO)
Prática
Teórica
Ambas
Não
Responde
u
Turma 1 (N=24)
18 (75%)
0
0
4 (17%)
Turma 2 (N=28)
7(25%)
21(75%)
3 (11%)
2 (7%)
Considerando apenas aqueles que justificaram as suas
respostas podemos verificar pela Tabela 4 que os estudantes
prevêem dificuldades na parte teórica porque as suas
preferências pessoais e estilo de estudo lhes favorecem a parte
prática. São exemplos destas justificações:
• “Porque ao longo do meu percurso escolar sempre tive
mais facilidade em estudar as disciplinas mais práticas, pondo
a parte teórica mais de parte” (Turma 2 – 1º Questionário)
• “Porque sei lidar melhor praticamente com o computador,
ao invés de saber os seus componentes, conhecer os seus
programas, entre outros” (Turma 1 – 1º Questionário).
TABELA IV
TIPOS DE DIFICULDADES PREVISTAS (1º QUESTIONÁRIO)
Turma 1
Turma 2
1 – DidaktosOnLine
0
1
2 – Associação/Aplicação
0
0
3 – Preferência/Estilo
12
11
4 – Conceitos Informáticos
8
5
5 – TFC
0
0
6 – Disciplina
0
0
A concepção, revelada pela última citação, de lidar com os
computadores como “caixas negras”, onde o que interessa é
apenas o seu funcionamento prático, pode ser reconhecida na
declaração de outros estudantes:
ISSN 1932-8540 © IEEE
• “A prática já não é desconhecida. Trabalho com o
computador todos os dias” (Turma 1 – 1º Questionário)
• “A parte teórica penso que é mais desinteressante, pois o
nosso interesse pelos computadores é sempre em utilizá-los, ou
seja, o nosso interesse é mais pela parte prática” (Turma 1 – 1º
Questionário).
Alguns justificam que já são utilizadores de computadores
há bastante tempo e, embora não tenham os conceitos
informáticos bem claros, resolvem na prática os seus
problemas de utilização dos computadores. A previsão de
dificuldades com os conceitos informáticos pode ser percebida
pelos seguintes exemplos:
• “Os conceitos teóricos no que se refere à informática e às
novas tecnologias da comunicação, são hoje em dia
susceptíveis de algumas dificuldades” (Turma 1 – 1º
Questionário).
• “Julgo que será na componente teórica que irei sentir
maior dificuldade, uma vez que depois de assimilados e
compreendidos os conteúdos, a passagem para a prática será
mais ‘fácil’” (Turma 2 – 1º Questionário).
Investigando mais aprofundadamente a mudança de opinião
dos estudantes sobre o foco das dificuldades, de “teórica” no
início para “prática” no final do semestre lectivo, podemos
encontrar na análise de conteúdo da questão aberta do 2º
questionário as razões para tal mudança (ver tabela 5).
TABELA V
TIPOS DE DIFICULDADES ENCONTRADAS (2º QUESTIONÁRIO)
Turma 1
Turma 2
1 – DidaktosOnLine
10
4
2 – Associação/Aplicação
8
4
3 – Preferência/Estilo
0
1
4 – Conceitos Informáticos
0
2
5 – TFC
0
7
6 – Disciplina
0
5
• “Porque inicialmente foi difícil entender o objectivo do
Didaktos” (Turma 1 – 2º Questionário).
• “Sobretudo devido às dificuldades sentidas na elaboração
do projecto no Didaktos” (Turma 1 – 2º Questionário).
• “Pela dificuldade em articular o projecto DOL com a
TFC” (Turma 1 – 2º Questionário).
• “Na parte teórica, porque era um assunto completamente
novo e só consegui entender o Didaktos depois de ter
trabalhado com muitos "Casos", "Mini-casos", "Temas",
"Actividades" e "Sequências" (Turma 2 – 2º Questionário).
• “Porque os ambientes informáticos (software) não
constituem grande dificuldade para mim. No entanto, a lógica
associada à aplicação foi um pouco difícil de assimilar durante
algumas aulas” (Turma 2 – 2º Questionário).
Estas duas últimas citações foram escritas por estudantes de
formação em serviço que assinalaram nas alternativas que
sentiram dificuldade na parte teórica.
Contudo, analisando as justificações para as mesmas
questões, podemos perceber que tiveram na verdade
dificuldade na aplicação prática dos conceitos da TFC no
DOL.
189
Assim, podemos ter mais uma confirmação, do ponto de
vista metodológico, que os dados quantitativos podem ser
melhor interpretados quando acompanhado por dados de cariz
mais qualitativo.
Na Tabela 6 apresentamos a opinião dos estudantes sobre a
plataforma de comunicação Blackboard (BB).
Embora o DOL tenha muitas das características da Web 2.0,
não tem todas as ferramentas de comunicação de um LMS.
Por essa razão, além do DOL utilizámos o BB,
principalmente nos fóruns que proporcionavam discussões e
questionamentos online.
Os estudantes, em geral, consideraram que não tiveram
dificuldades em utilizar o BB e quase metade deles admite que
o BB proporcionou uma maior interacção entre os colegas do
grupo, considerando que sem o BB a gestão da disciplina
ficaria muito mais difícil.
TABELA VI
SOBRE A UTILIZAÇÃO DO BLACKBOARD (2º QUESTIONÁRIO)
Turma 1
Turma 2
A
B
C
D
Discordo
1
4,3%
4
17,4%
17
73,9%
1
4,3%
Sem
Opinião
8
34,8%
2
8,7%
4
17,4%
Concordo
22
95,7%
11
47,8%
4
17,4%
18
78,3%
Discordo
6
20,7%
7
24,1%
10
34,5%
3
10,3%
Sem
Opinião
4
13,8%
10
34,5%
3
10,3%
5
17,2%
Concordo
19
65,5%
12
41,4%
16
55,2%
21
72,4%
A - Não tive dificuldades em utilizar o BB.
B - Considero que o BB proporcionou maior interacção entre os meus colegas do grupo.
C - Para mim o BB serviu apenas para obter os materiais da disciplina.
D -. Considero que sem o BB a gestão da disciplina ficaria muito mais difícil.
Particularmente, sobre a relação com os colegas no trabalho
em grupos, observamos a partir da Tabela 7, que os estudantes
de ambas as turmas gostaram de trabalhar com os colegas do
grupo.
TABELA VII
SOBRE O TRABALHO EM GRUPO (2º QUESTIONÁRIO)
Turma 1
Turma 2
A
B
C
D
Discordo
2
8,7%
13
56,5%
3
13,0%
19
82,6%
Sem
Opinião
3
13,0%
4
17,4%
3
13,0%
1
4,3%
Concordo
18
78,3%
6
26,1%
17
73,9%
3
13,0%
Discordo
1
3,4%
17
58,6%
3
10,3%
22
75,9%
Sem
Opinião
1
3,4%
6
20,7%
3
10,3%
3
10,3%
Concordo
27
93,1%
6
20,7%
23
79,3%
4
13,8%
A - Gostei de trabalhar com os meus colegas de grupo.
B - No meu grupo de trabalho sugiram muitos problemas.
C - Conseguimos dividir e articular bem o trabalho com os membros do grupo.
D - Preferia ter feito o projecto no DOL sozinho(a).
Embora alguns estudantes (~20%) admitam que surgiram
problemas no grupo de trabalho, mostram que estes problemas
foram superados porque admitem (~79%) que conseguiram
dividir e articular bem o trabalho com os membros do grupo,
ISSN 1932-8540 © IEEE
190
concluindo que não prefeririam realizar o projecto no DOL
sozinhos. A relação entre as dificuldades encontradas
relativamente às características do DOL e do Blackboard
resume-se àquilo que diferencia uma plataforma dedicada (o
DOL) e concebida mediante preceitos teóricos definidos
(TFC) de uma plataforma que, na sua essência, é um LMS (o
Blackboard). Com efeito, enquanto que a utilização do
Blackboard exige uma compreensão de mecanismos e
funcionalidades meramente tecnológicas de gestão de
ambientes distribuídos de aprendizagem, já o DOL, para além
desses conhecimentos, exige uma compreensão aprofundada
dos princípios teóricos da TFC.
Tal envolve, não só a compreensão dos preceitos didácticos
do ensino baseado em casos, como dos pressupostos
subjacentes à aprendizagem de acesso aleatório. Poderíamos
quase afirmar que se trata de uma dimensão meta-didáctica de
conceber o modo como a informação é tratada, num dado
domínio de conhecimento, de modo a transformá-la em
percursos diferenciados de uma mesma paisagem conceptual.
V. COMENTÁRIOS FINAIS
Quando pensamos na aprendizagem em domínios
complexos e avançados de conhecimento deparamo-nos com
alguns problemas ligados à pouca flexibilidade das
ferramentas Web 1.0 na sua implementação centrada nos
alunos. Ao pensarmos no DOL como uma ferramenta Web
2.0, que tem subjacente a TFC, podemos ter a flexibilidade
necessária à co-construção partilhada de conhecimento,
actividade implementada em verdadeiras comunidades de
prática. Na dimensão profissional docente, a mais valia deste
tipo de ferramentas é a constituição de comunidades que se
entre-ajudam, co-criticam e apoiam, enriquecendo mutuamente
as visões que detêm sobre os conteúdos que leccionam. O
beneficiário último desta actividade é sempre o aluno,
nomeadamente quando o professor, liberto já de receios de
exposição e detentor de confiança na utilização destas
ferramentas, decide associar o aluno a uma nova comunidade,
no mesmo ambiente, mas desta feita, uma comunidade de
aprendizagem.
AGRADECIMENTOS
Os autores agradecem ao Centro de Investigação Didáctica
e Tecnologia na Formação de Formadores e à Fundação para a
Ciência e a Tecnologia pelo apoio e financiamento deste
estudo.
Processes in Reading, B. Britton and S. Glynn, Eds. New Jersey:
Lawrence Erlbaum Associates, 1987, pp. 177-199.
[3] S. Heath, J. Higgs, and D. R. Ambruso, "Evidence of Knowledge
Acquisition in a Cognitive Flexibility-Based Computer Learning
Environment," Med Educ Online, vol. 13, 2008.
[4] F. Neri de Souza and A. Moreira, "DidaktosOnLine: Uma plataforma
Web 2.0 fundamentada na TFC," in X Simposio Internacional de
Informática Educativa, Salamanca, 2008.
[5] F. Neri de Souza, A. Moreira, M. J. Loureiro, and C. Guerra,
"Challenges to the implementation of CFT in initial and in-service
teacher education," in Current Developments in Technology-Assisted
Education. vol. I, A. Méndez-Vilas, A. S. Martín, J. A. M. González,
and J. M. González, Eds. Badajoz, Spain: Formatex, 2006, pp. 323-327.
[6] A. Moreira, Pedro, L., Almeida, P., "DidaktosOnLine: Princípios
subjacentes à sua conceptualização e prototipagem para a constituição
de comunidades de prática," in IV Conferência Internacional de
Tecnologias de Informação e Comunicação na Educação Challenges’2005, Braga, 2005, pp. 753-764.
[7] A. Moreira and L. F. M. G. Pedro, DidaktosOnLine: Teoria da
Flexibilidade Cognitiva e Ensino Baseado em Casos. Aveiro:
Universidade de Aveiro, 2006.
[8] R. Spiro, P. Feltovich, M. Jacobson, and R. Coulson, "Cognitive
Flexibility, Constructivism and Hypertext: random access instruction
for advanced knowledge acquisition in ill-structured domains,"
Educational Technology vol. 31, pp. 24-33, 1991.
[9] V. M. Chieu, "An Operational Approach for Building Learning
Environments Supporting Cognitive Flexibility," Educational
Technology & Society, vol. 10 pp. 32-46, 2007.
[10] T. Oreilly, "What is Web 2.0: Design Patterns and Business Models for
the Next Generation of Software," Communications & Strategies vol. 1,
pp. 17-37 (Available at SSRN: http://ssrn.com/abstract=1008839),
2007.
[11] D. Best, "Web 2.0 Next Big Thing or Next Big Internet Bubble?,"
Lecture Web Information Systems Technische Universiteit Eindhoven,
2006.
[12] A. Moreira, L. F. M. G. Pedro, and P. Almeida, "DidaktosOnLine:
concepts and prototyping principles for the constitution of communities
of practice," in ICTATLL 2005 - ICT, Analysis, Teaching and Learning
of Languages, Aveiro, 2005.
F. <eri de Souza PhD in Science Education (2006), MA in
Computational Chemistry (1998), Undergraduate in
Chemistry (1995). He currently works as a researcher at the
University of Aveiro where he also supervises students in
Science Education, and as a lecturer on the use of qualitative
analyses software (NVivo). He is the author of papers and
book chapters in the field of active learning, questioning,
chemistry education and educational technology.
A. Moreira holds a PhD in Didactics of Languages and is
currently the Director of the Masters degree and the Doctoral
Program in Multimedia in Education, at the University of
Aveiro, where he also coordinates the Digital Contents
Laboratory and the Nónio Competence Centre for teacher
education in ICT. He supervises several MA, PhD and PostDoctoral students, both in Didactics and in ICT in Education.
He is also the general editor of the online journal Indagatio Didactica. He is
the author of papers and book chapters in the fields of education, ICT in
education, Distance Learning and Teacher Education.
REFERÊNCIAS
[1]
[2]
R. Spiro and J. Jehng, "Cognitive Flexibility, random access instruction
and hypertext: Theory and technology for the nonlinear and multidimensional traversal of complex subject matter," in The “Handy
Project”. ew Directions in Multimedia Instruction, D. Nix and R.
Spiro, Eds. Hillsdale, NJ: : Lawrence Erlbaum, 1990, pp. 163-205.
R. Spiro, W. Vispoel, J. Schmitz, A. Samarapungavan, and A. Boerger,
"Knowledge Acquisition for Application: Cognitive Flexibility and
Transfer in Complex Content Domains," in Executive Control in
ISSN 1932-8540 © IEEE
191
Diseño de videojuegos colaborativos y
educativos centrado en la Jugabilidad
Natalia Padilla Zea, José Luís González Sánchez, Francisco L. Gutiérrez, Marcelino J. Cabrera,
Patricia Paderewski
Title— Design of collaborative and educational videogames
based on Playability.
Abstract— In this paper we propose some guidelines to design
educational and collaborative videogames from the viewpoint of
playability. Player’s experiences are empowered in order to
produce implicit learning during the game process. Also, these
guidelines are intended to take advantage of collaborative
learning compared to others traditional learning processes.
Index Terms— CSCL, Design of Educational Videogames,
Playability, User Centred Design.
I. INTRODUCCIÓN
L
AS personas, a través de la historia, han tenido la
habilidad de administrar su ocio y hacer de él un factor en
el desarrollo cultural. De acuerdo con Huizinga [1], el juego y
las relaciones sociales, unidas a las habilidades
físicas/cognitivas que los jugadores obtienen de jugarlo, han
sido los aspectos más importantes en la evolución sociocultural del hombre.
Además, está ampliamente demostrado que los juegos
pueden ayudar a desarrollar cualidades y/o habilidades
psicológicas, cognitivas, físicas y/o sociales, por lo que se han
ido incorporando poco a poco a las aulas como complementos
curriculares y mediadores del proceso de aprendizaje [2].
A lo largo de este artículo se analiza el papel de los
videojuegos en las aulas, centrándonos en el uso de los mismos
como herramientas educativas. Nos centraremos en las
experiencias del usuario al jugar y en los aspectos del
aprendizaje colaborativo, con objeto de paliar las deficiencias
de los sistemas educativos interactivos actuales. Para ello, se
propone una guía de estilo y se presenta un ejemplo de
Todos los autores pertenecen al Laboratorio de Investigación en
Videojuegos y E-Learning (LIVE) del Grupo de Investigación GEDES.
Departamento de Lenguajes y Sistemas Informáticos. Universidad de
Granada.
Natalia Padilla Zea: [email protected] (Autor de contacto. Tlf.: +34
958240849)
José Luís González Sánchez: [email protected] (Tlf.: +34 958242812)
Francisco L. Gutiérrez: [email protected] (Tlf.: +34 958242812)
Marcelino J. Cabrera: [email protected] (Tlf.: +34 958242809)
Patricia Paderewski: [email protected] (Tlf.: +34 958243178)
videojuego educativo para el aprendizaje de las vocales. Para
terminar, exponemos nuestras conclusiones y trabajos futuros.
II. VIDEOJUEGOS EN LAS AULAS
Según el informe de la Asociación Española de
Distribuidores y Editores de Software de Entretenimiento
(aDeSe) de 2008, en el año 2007 se facturaron en España
1.454 millones de euros, 400 más que el cine y un 50% más
que en el año anterior. Con estos datos podemos deducir que
los videojuegos se han convertido en el tipo de juego
preferido, siendo mecanismos de gran influencia a nivel
cultural y social en niños, adolescentes y adultos [3].
Desde una perspectiva educativa, son numerosos los
estudios e informes [4], [5] que abogan por los beneficios de
los videojuegos como excelentes herramientas educativas,
destacando que su uso aporta las siguientes ventajas:
1) Éxito escolar: Los alumnos que utilizaron videojuegos
incrementaron notablemente su capacidad de compresión
lectora.
2) Habilidades cognitivas: Los videojuegos proponen
ambientes de aprendizaje basados en el descubrimiento y
en la creatividad.
3) Motivación: Los videojuegos suponen un estímulo para
los niños, lo que facilita el proceso de aprendizaje y
aumenta considerablemente la asistencia a clase.
4) Atención y Concentración: Los juegos incrementan la
atención del alumnado y su concentración en la resolución
de problemas concretos debido a su naturaleza lúdica.
Como resultado de lo anteriormente expuesto, parece
razonable pensar que el uso de juegos educativos apoya
sustancialmente la tarea de enseñanza / aprendizaje. Y es que,
si bien existen diversos juegos multimedia cuyo objetivo es
enseñar de forma lúdica, es cierto que dichas propuestas no
terminan de satisfacer las expectativas de ocio/diversión de los
escolares, ya que no existe proceso de juego y los alumnos
pierden la motivación asociada al ocio y a la diversión [5].
Nos encontramos ante meras unidades didácticas multimedia,
en cuya elaboración no ha intervenido el usuario.
Por otra parte, no debemos olvidar la componente social
intrínseca a todo ser humano, la cual empieza a desarrollarse
en las edades más tempranas. Esta faceta interactiva permite
obtener puntos de vista y actitudes diferentes a las propias que
enriquecen distintas habilidades y favorecen actitudes de
ISSN 1932-8540 © IEEE
192
respeto y tolerancia. En el ámbito escolar, esta interacción
reduce la tendencia de los estudiantes a simplificar conceptos
complejos en su proceso de aprendizaje, ya que los miembros
del grupo aportan diferentes visiones del concepto que
enriquecen a sus compañeros.
En resumen, nuestros trabajos se centran en el diseño de
videojuegos educativos que solventen los dos problemas
básicos planteados: deficiencias en la experiencia del usuario y
trabajo puramente individualista y competitivo.
III. APRENDER JUGANDO, JUGANDO A APRENDER
Los videojuegos pueden ser una buena herramienta
pedagógica si tenemos en cuenta una serie de factores que
afectan directamente al usuario. Estos factores, que deben
potenciarse durante el diseño del videojuego para hacer el
proceso de aprendizaje lo más efectivo posible, son:
Motivación [6], atención [7], concentración [8] y emoción [9].
Nuestra propuesta de diseño de videojuegos educativos
arranca con la idea de que el principal objetivo del niño debe
ser jugar. La consecuencia de dicha acción (jugar) será que el
jugador aprenda los contenidos educativos implícitos en el
videojuego. Denominamos a este proceso “Aprender jugando,
jugando a aprender”. Los contenidos educativos deben estar
“ocultos” en la propia mecánica del juego. Nuestro videojuego
actuará como mediador del proceso de aprendizaje de acuerdo
al modelo planteado por Vygostky [10].
En el modelo de aprendizaje propuesto, los estudiantes
pueden aprender mediante la interacción con el resto del grupo
y acercar posturas. Puesto que los miembros del grupo
dependen unos de otros, se ayudan entre sí y asumen la
responsabilidad del éxito o el fracaso común [11]. Siguiendo
las tesis de Piaget [12], las actividades colaborativas permiten
al individuo llegar a dominar tareas que antes era incapaz de
realizar de manera individual, gracias al desequilibrio
cognitivo positivo entre los participantes que ayuda a
desarrollar la habilidad cognitiva individual.
En resumen, nuestro objetivo es que los niños aprendan más
fácilmente gracias a la estimulación conseguida por el proceso
de juego y el trabajo conjunto con los compañeros.
IV. LA EXPERIENCIA DEL JUGADOR
Como se ha comentado anteriormente, para que un juego
sea “jugable” es importante que ofrezca las mejores
expectativas de ocio y diversión al jugador.
De la misma manera que la usabilidad nos muestra atributos
y propiedades que determinan que un software sea usable en
determinadas condiciones y entornos, la jugabilidad denota las
experiencias del jugador ante un videojuego.
Formalizar la jugabilidad es un proceso difícil, ya que es un
concepto abstracto que tiene características funcionales
inherentes a los videojuegos como sistemas interactivos, y no
funcionales relativas a la experiencia del jugador y al carácter
lúdico, y a veces artístico, de los videojuegos.
Aunque la jugabilidad siempre ha interesado a la comunidad
científica, se ha enfocado considerando distintos objetivos y
desde distintos puntos de vista [13], [14]. Se puede decir que
la jugabilidad es el conjunto de factores que satisfacen a un
jugador a la hora de jugar. Formalmente podemos definir la
jugabilidad como el conjunto de propiedades que describen la
experiencia del jugador ante un sistema de juego determinado,
cuyo principal objetivo es divertir y entretener “de forma
satisfactoria y creíble” ya sea solo o en compañía [15].
Es importante remarcar los conceptos de satisfacción y
credibilidad. El primero es mucho más difícil de conseguir que
en un sistema interactivo tradicional debido a sus objetivos no
funcionales; el segundo dependerá del grado de asimilación e
implicación de los jugadores en el juego. Por otro lado, la
jugabilidad viene caracterizada por una serie de atributos que
ya existen en la usabilidad pero que en un videojuego tienen
matices distintos. Por ejemplo, el “aprendizaje” en un
videojuego puede ser elevado, lo cual puede provocar que el
jugador se vea satisfecho ante el reto que supone aprender a
jugarlo, y posteriormente desarrollar lo aprendido dentro del
juego. Por otro lado, la “efectividad” en un juego no busca la
rapidez por completar una tarea, pues entra dentro de la
naturaleza del videojuego que el usuario esté jugando el
máximo tiempo posible. Los atributos que proponemos para
caracterizar la jugabilidad son:
1) Satisfacción: Agrado o complacencia del jugador ante el
videojuego.
2) Aprendizaje: Facilidad para comprender el sistema y la
mecánica del videojuego, es decir, los conceptos definidos
en el Gameplay / Game Mechanic [13], [14] del juego:
objetivos, reglas y formas de interaccionar con el
videojuego.
3) Eficiencia y Efectividad: Tiempo y recursos necesarios
para lograr los objetivos propuestos en el videojuego.
4) Inmersión: Capacidad para creerse lo que se juega e
integrarse en el mundo virtual mostrado en el juego.
5) Motivación: Característica del videojuego que mueve a la
persona a realizar determinadas acciones y persistir en
ellas para su culminación.
6) Emoción: Impulso involuntario, originado como respuesta
a los estímulos del videojuego, que induce sentimientos y
que desencadena conductas de reacción automática.
7) Socialización: Atributos y elementos del juego que
fomentan el factor social o la experiencia en grupo, lo cual
provoca apreciar el videojuego de distinta manera, gracias
a las relaciones que se entablan con otros jugadores o con
otros personajes del juego y que complementan las
acciones a realizar y retos a resolver en la dinámica del
videojuego.
Sin embargo, el análisis de la jugabilidad de un videojuego
es un proceso lo suficientemente complejo como para necesitar
descomponerlo en base a diferentes puntos de vista. Para ello,
hemos realizado una descomposición basada en las facetas de
la jugabilidad, de tal forma que cada una nos permita
identificar más fácilmente los distintos atributos de la
ISSN 1932-8540 © IEEE
PADILLA ZEA et al.: DISEÑO DE VIDEOJUEGOS COLABORATIVOS Y EDUCATIVOS
jugabilidad. Las facetas de la jugabilidad son las siguientes:
1) Jugabilidad Intrínseca: Es la jugabilidad medida en la
propia naturaleza del juego, es decir, en las reglas,
objetivos, retos… y cómo éstos se proyectan al jugador.
Está ligada al diseño del Gameplay y a la
“implementación” del Game Mechanic, analizando cómo
se representan las reglas, objetivos, ritmo y mecánica del
videojuego.
2) Jugabilidad Mecánica: Es la jugabilidad asociada a la
calidad del videojuego como sistema software. Está ligada
al Game Engine, haciendo hincapié en características
como la fluidez de las escenas cinemáticas, la correcta
iluminación,
sonido,
movimientos
gráficos
y
comportamiento de los personajes del juego y del entorno,
sin olvidar los sistemas de comunicación en videojuegos
multijugador.
3) Jugabilidad Interactiva: Es la faceta asociada a todo lo
relacionado con la interacción con el usuario, diseño del
interfaz de usuario, mecanismos de diálogo y sistemas de
control. Está fuertemente unida al Game Interface.
4) Jugabilidad Artística: Asociada a la calidad y adecuación
artística y estética de todos los elementos del videojuego a
la naturaleza de éste. Entre ellos estarán la calidad gráfica
y visual, los efectos sonoros, la banda sonora y melodías
del juego, la historia y la forma de narración de ésta, así
como la ambientación realizada de todos estos elementos
dentro del videojuego.
5) Jugabilidad Intrapersonal: O simplemente jugabilidad
personal o perceptiva. Esta faceta tiene como objetivo
estudiar la percepción que tiene el propio usuario del
videojuego y los sentimientos que éste le producen. Tiene
un alto valor subjetivo.
6) Jugabilidad Interpersonal: O jugabilidad en grupo.
Muestra las sensaciones o percepciones de los usuarios y
la conciencia de grupo, que aparecen cuando se juega en
compañía ya sea competitiva, cooperativa o
colaborativamente.
Se puede entonces deducir, a la vista de lo anterior, que la
jugabilidad de un juego viene dada como el valor de cada uno
de los atributos en las distintas facetas presentadas y que debe
ser lo más adecuado posible para que las experiencias /
sensaciones del jugador a la hora de jugarlo sean las mayores
posibles y las más adecuadas a la naturaleza del propio
videojuego.
V. EL APRENDIZAJE COLABORATIVO
Otra característica del tipo de videojuegos educativos que
proponemos es que el aprendizaje se alcance realizando
actividades de carácter colaborativo. Por tanto, la evaluación
de la jugabilidad debe ir acompañada de un proceso de
fomento del aprendizaje colaborativo. Para que el aprendizaje
colaborativo funcione debemos tener en cuenta cinco
componentes esenciales [16]:
193
1) Interdependencia positiva: Los estudiantes son
conscientes de que son un equipo y de que el trabajo de
uno repercute en los demás.
2) Exigibilidad personal: Cada miembro del grupo debe ser
capaz de aportar su conocimiento al grupo y de aprender
lo que sus compañeros le aporten, con el fin de beneficiar
a todo el grupo (“No vale descansarse sobre los demás”).
3) Interacción positiva cara a cara: Se produce cuando los
alumnos comparten sus conocimientos, discuten distintos
puntos de vista, ayudan al resto con las dificultades…
4) Habilidades interpersonales y de grupo: Los estudiantes
deben organizar el trabajo y tomar decisiones,
manifestando sus dotes de liderazgo, conciliación…
5) Autoanálisis del grupo: El grupo debe autoanalizarse para
saber si su trabajo está siendo efectivo, si se alcanzan las
metas y si se está trabajando en el ambiente adecuado.
Esto permite que los miembros del grupo fortalezcan sus
habilidades de trabajo y fomenta el compromiso de todos
con los objetivos comunes.
En el siguiente punto presentamos una guía de estilo para el
diseño de videojuegos educativos que tengan en cuenta la
jugabilidad y la colaboración, con objeto de poder
introducirlos en las aulas como refuerzo efectivo a los métodos
tradicionales de enseñanza.
VI. GUÍA DE ESTILO EN VIDEOJUEGOS COLABORATIVOS Y
EDUCATIVOS
¿Se puede asegurar la jugabilidad de un videojuego en todas
las fases de su desarrollo y producción? Los videojuegos,
como sistemas interactivos, deben diseñarse pensando en los
jugadores, centrando el desarrollo en el jugador e
implicándolo tanto como sea posible, ya sea en el equipo de
diseño y desarrollo, como en el equipo de pruebas. Estas ideas
básicas que forman los pilares de la Ingeniería de la
Usabilidad deben introducirse dentro de la Ingeniería de
Videojuegos. De esta forma podremos exigir una calidad en la
jugabilidad equivalente a la usabilidad en los sistemas
interactivos tradicionales.
Así, proponemos introducir la jugabilidad a lo largo del
proceso de diseño y desarrollo de un videojuego como sistema
interactivo, siguiendo las ideas mostradas en la metodología de
Diseño de Videojuegos Centrados en el Jugador [15]. Para
ello debemos partir de una especificación de requisitos de
jugabilidad. Estos requisitos pueden ser analizados según las
distintas facetas de la jugabilidad [17], viendo qué
requerimientos de jugabilidad afectan a cada uno de sus
atributos. En esta fase de diseño debemos adaptar patrones de
diseño de videojuegos [18] existentes, donde se muestren qué
atributos de jugabilidad se ven afectados y cómo mejorar la
jugabilidad asociada a éstos. Por otro lado, es necesaria una
guía de estilo que favorezca el desarrollo de la jugabilidad a
partir de sus distintas propiedades [19], [20]. Finalmente,
debemos ofrecer una serie de pruebas de jugabilidad, en base
a estas propiedades, que indiquen si el proceso de desarrollo
ISSN 1932-8540 © IEEE
194
nos ha llevado a obtener un videojuego que satisfaga los
requisitos de jugabilidad de los que partíamos.
De la misma forma, en el análisis de requisitos debemos
tener en cuenta los componentes esenciales del aprendizaje
colaborativo. Tomando como punto de partida los trabajos
previos [19], [20] se indican los elementos y características
que deben incluirse en la fase de diseño del juego para lograr
un aprendizaje colaborativo efectivo.
A. Interdependencia Positiva
Se desea que los alumnos sean conscientes de que el trabajo
de uno repercute en el de los demás, de forma que el éxito o el
fracaso individual lo es de todo el grupo. Desde este punto de
vista, es necesario que todos los miembros del grupo
compartan:
1) Objetivos: El videojuego debe tener objetivos comunes
para el grupo, tanto didácticos como lúdicos, que
constituirán la meta a la que se dirigen todos los miembros
del grupo.
2) Responsabilidad de equipo: Para evitar que los intentos
de consecución de una meta u objetivo sean infinitos, el
videojuego debe incorporar un sistema de “vida de
equipo”. Esta vida será común para todos los miembros
del grupo y será modificada en función de la actuación de
cada miembro durante su intervención.
3) Evaluación: Gran parte del proceso de evaluación se
realizará sobre el grupo.
4) Puntuación: No sólo existe una puntuación individual,
sino que hay una puntuación de grupo que se ve afectada
principalmente por el trabajo en equipo.
A continuación presentamos los requisitos / guías que se
derivan de esta propiedad:
1) Plantear una meta para el grupo: La meta de todos los
miembros del grupo es la misma y deben conseguirla
juntos.
2) Hay un conjunto de personajes “buenos” (protagonistas)
con los que los jugadores se identifican. Esto facilita la
identidad del grupo.
3) La superación de pruebas se premia con recompensas
individuales que deberán ser compartidas a lo largo del
juego con el resto del grupo.
4) Recompensas en la puntuación / vida del grupo si todos
los miembros alcanzan un mínimo en los objetivos
planteados.
5) Proponer actividades en las que cada miembro del grupo
resuelva una parte o construya algo para todos.
6) Asignar a cada jugador del grupo factores multiplicativos
de la puntuación conseguida en la prueba de tal forma que
tendrá mayor factor el miembro que necesite mayor
refuerzo en la prueba que se está planteando. Puede darse
factor 0 a los participantes que ya han superado ese
objetivo para “obligar” a que lo realice el que más lo
necesita.
7) Evaluar conjuntamente las pruebas: Los participantes sólo
ven una puntuación que corresponde al grupo. No tiene
porqué haber puntuaciones individuales visibles para los
miembros del grupo.
8) Competir con otros grupos. Es importante mostrar en qué
situación se encuentran los otros grupos y la posición
respecto a ellos.
9) Establecer reglas de avance de nivel grupales: Todos los
miembros deben superar un nivel mínimo para alcanzar la
siguiente fase del juego.
10) Plantear el problema en el dispositivo de un miembro
distinto al que debe resolverlo, facilitando la
comunicación y la puesta en común de objetivos.
B. Exigibilidad Personal
Cada uno de los integrantes del grupo debe dar lo mejor de
sí para que el aprendizaje personal y grupal sea efectivo.
Además, es posible que alguno de los miembros del grupo no
alcance el mínimo necesario para superar las fases, y por tanto
no alcance los objetivos. En estos casos es necesario que el
juego sea capaz de equilibrar las posturas de forma camuflada,
para que estas acciones se entiendan por parte del grupo como
parte del desarrollo normal del juego. Así, se proponen
algunas guías para conseguir este objetivo:
1) Asignación, a cada jugador del grupo, de factores
multiplicativos de la puntuación conseguida en la prueba.
2) Recompensas a la puntuación / vida del grupo por
actividades individuales.
3) Establecer el rol de líder y rotarlo entre los miembros del
grupo.
4) Competición con otros grupos. Todos los miembros del
grupo deben aportar lo máximo posible para poder
competir de forma efectiva.
5) Asignar pruebas sorpresa que equilibren la actividad de
todos los miembros.
6) Inclusión de gráficos de la aportación de cada miembro a
la puntuación del grupo.
C. Interacción Positiva Cara a Cara
La interacción cara a cara pretende que se establezcan
relaciones sociales entre los integrantes del grupo, de tal forma
que a lo largo de las sesiones de aprendizaje colaborativo se
establezcan redes sociales que favorezcan la confianza entre
los miembros del grupo y se aumente el nivel de compromiso
con el resto de los integrantes. Algunas consideraciones a
seguir para facilitar la interacción cara a cara son:
1) Introducir pruebas o situaciones dentro del juego en los
que todos los miembros del grupo tengan que contestar /
interactuar de la misma manera: Consenso.
2) Los miembros del grupo deben decidir quién resuelve la
prueba: Consenso.
3) Pruebas o situaciones del juego en las que cada miembro
construye / resuelve una parte. La comunicación entre los
miembros del grupo será un factor fundamental para saber
qué hay que resolver y cómo lo van a hacer.
4) Competición con otros grupos. Favorecemos la unión y la
comunicación en el grupo, ya que necesita estrategias
comunes para ganar al resto de los equipos.
ISSN 1932-8540 © IEEE
5) Realimentación a otro miembro del grupo para que se
establezcan discusiones.
6) Plantear el problema a un miembro distinto al que debe
responder, favoreciendo la comunicación en la
explicación del problema.
D. Habilidades Interpersonales y de Grupo
Puesto que se está realizando un trabajo grupal, es necesario
que los miembros del grupo desarrollen capacidades de
relación entre ellos. A veces resulta difícil debido a que los
sistemas educativos tradicionales se centran en el trabajo
personal más que en la participación activa e interactiva de los
alumnos [16]. Por este motivo, es necesario que los alumnos se
conviertan en constructores activos del conocimiento y
promotores de la motivación de sus compañeros de grupo.
Para promover este tipo de actitudes y, así, la construcción del
conocimiento de forma colaborativa debemos:
1) Establecer el rol de líder y rotarlo entre los miembros del
grupo. Puede dirigir el trabajo del grupo asignando
miembros a tareas, entre otras cosas.
2) Introducir pruebas o situaciones en las que todo el grupo
tenga que contestar lo mismo. La respuesta será
construida por todos los miembros del grupo.
3) Plantear situaciones donde el grupo deba elegir quién
resuelve la prueba. De esta forma favorecemos
habilidades como la planificación, el debate y el consenso.
4) Organizar competiciones entre grupos para ver en qué
situación se encuentran los otros grupos y la posición
respecto a ellos.
5) Dar la realimentación a otro miembro del grupo para
establecer discusiones.
6) Plantear el problema en el dispositivo de un miembro y no
permitir que lo resuelva, debiendo comunicar el problema
a otro miembro del grupo.
E. Autoanálisis del Grupo
Es necesario que el grupo tome conciencia de tal y sea
capaz de evaluar cómo de bien se está desarrollando su
trabajo, no sólo a nivel educativo, sino de funcionamiento
como grupo. Los miembros del grupo deben ser capaces de
discernir si aspectos como el compromiso con la meta común,
el fomento del aprendizaje, la motivación… están llevándose a
cabo adecuadamente. Para ello, podemos incluir en el
videojuego:
1) Evaluación conjunta de las pruebas: Para avanzar en el
juego deben superar evaluaciones comunes.
2) Gráficos por habilidades, miembros, recompensas
conseguidas,…
3) Competición con otros grupos para comparar su
evolución.
El autoanálisis del grupo favorece su propia adaptación. Si
los errores de un jugador están afectando el avance del grupo,
será el propio grupo quien decida cambiar la asignación de
objetivos para mejorar su puntuación.
195
VII. LEONCIO Y SUS AMIGOS
Usando como bases de diseño las ideas mostradas en este
artículo, presentamos el videojuego “Leoncio y sus Amigos”
[21] donde se propone el diseño de un videojuego educativo
colaborativo para aprender las vocales.
Durante el proceso de diseño de este videojuego se han
tenido en cuenta las consideraciones que se expusieron
anteriormente. Como muestra de aplicación del desarrollo
centrado en el jugador, la Tabla 1 muestra los requisitos de
jugabilidad y cómo éstos se han materializado en el
videojuego.
El mundo del videojuego está compuesto por 5 islas, que
son las fases del juego. Al inicio del juego se asigna una vocal
a cada uno de los 5 participantes, la cual aprenderá en esa
partida. Las fases se corresponden con distintos contenidos
procedimentales, regulando la dificultad de las actividades en
los niveles.
El objetivo de equipo del videojuego es vencer al malvado
“Perfecte” y conseguir el conjuro que vuelva a reunir a los 5
“Leoncios” en uno solo. Durante el juego cada jugador tiene
una vida y una puntuación individual, manteniendo a la vez
una vida y una puntuación de equipo. Los valores individuales
serán modificados por las actuaciones del jugador
(exigibilidad personal) y las de equipo por las actividades
conjuntas (interdependencia positiva). Si un jugador pierde
todas sus vidas el grupo puede decidir usar el “dinero”
(puntos) común para “comprar” vida a este participante. Otra
posibilidad es que algún miembro del grupo “ceda” o “preste”
parte de su vida a este compañero. Si la vida que se agota es la
común, finaliza el juego.
Para mantener la conciencia de grupo el videojuego ofrece
la situación y logros del equipo a cada miembro. Para ello,
mostraremos el grado de consecución de cada utensilio
rellenándolo proporcionalmente de color, manteniendo el
fondo del color asociado al jugador que está consiguiendo
dicho utensilio, tal como se muestra en la Figura 1, en la
pantalla superior. Durante todo el juego es posible conseguir
recompensas extra mediante la realización de diferentes
pruebas.
Al final de cada fase el grupo, de forma conjunta, deberá
vencer a un “secuaz” de “Perfecte”. Para ello, cada uno deberá
demostrar lo que ha aprendido en los distintos niveles,
evaluando así el proceso individual de aprendizaje: cada
participante deberá escribir su vocal respetando la secuencia
propuesta (ver Figura 2, izquierda). Además, los miembros del
grupo deben “validar” su utensilio para contribuir con él al
trabajo común. El objetivo de la prueba común es introducir a
los alumnos en el desarrollo de interacciones grupales, de tal
forma que deban ponerse de acuerdo para conseguir un
objetivo. En nuestro juego, los miembros del grupo deben
construir juntos el medio de transporte para alcanzar la
siguiente isla. Para hacerlo tienen que decidir el orden en que
se utilizan cada uno de los utensilios, aportando cada uno el
suyo en el momento o los momentos adecuados. Cuando se
supera este trabajo común se ha superado la fase
ISSN 1932-8540 © IEEE
196
completamente y el equipo viaja a la siguiente isla (ver Figura
2, derecha).
La consecución de utensilios y la superación de la prueba
final de fase suponen haber superado también los objetivos
educativos implícitos en las pruebas. Si se detecta que alguno
de los componentes no ha participado suficientemente o que
necesita algún tipo de refuerzo podemos añadir dificultades a
la superación de la prueba final de fase. Por ejemplo, si
estamos utilizando el martillo y su usuario no cumple los
objetivos educativos mínimos correspondientes a la fase,
podemos hacer que este martillo se rompa durante el uso,
obligando a conseguir un nuevo martillo para superar la
prueba final. Esta medida puede tomarse para varios usuarios y
varias veces, hasta asegurar que se ha alcanzado el objetivo
didáctico de manera adecuada.
TABLA I
REQUISITOS DE JUBABILIDAD DE “LEO.CIO Y SUS AMIGOS”
Faceta
Jugabilidad
Intrínseca
Jugabilidad
Mecánica
Jugabilidad
Interactiva
Jugabilidad
Artística
Jugabilidad
Intrapersonal
Jugabilidad
Interpersonal
Atributo
Satisfacción
Aprendizaje
Efectividad
Inmersión
Motivación
Emoción
Social
Satisfacción
Aprendizaje
Efectividad
Inmersión
Motivación
Emoción
Social
Satisfacción
Aprendizaje
Efectividad
Inmersión
Motivación
Emoción
Social
Satisfacción
Aprendizaje
Efectividad
Inmersión
Motivación
Emoción
Social
Satisfacción
Aprendizaje
Efectividad
Inmersión
Motivación
Emoción
Social
Satisfacción
Aprendizaje
Efectividad
Inmersión
Motivación
Emoción
Social
Requisitos a cumplir en el Videojuego
Valoración del Sistema de Juego
Objetivos incrementales divididos en fases. Aprendizaje de una vocal en cada partida.
Número de intentos para unir vocal con pictograma
Se ha de viajar cada isla y de una isla a otra, superando obstáculos
Disminución de corazones (vida) por errores
Cinemática para aprender valores de la amistad
Ayuda entre compañeros para superar las pruebas
No apreciación de retrasos ni sincronizaciones
Adaptación del número de conceptos según dificultad
Áreas envolventes para detecciones táctiles por pictograma
Reconocimiento de stylus, controles y voz.
Tiempos de carga mínimos para evitar esperas
Efectos de fundido ante cambios de Fase - Misterio
Mecanismos WI-FI para multijugador
Múltiples formas de interacción: Voz, stylus, controles
Compresión del menú y navegación
Analogía entre el stylus y el lápiz para la escritura
Uso de dos pantallas: Causa y Consecuencia
Corazones, y Recompensas visuales y sonoras
Pictogramas que se diluyen y cambian de posición
Uso de micrófono y envío de mensajes
El diseño de los personajes gusta a los niños
Se identifica cada pictograma con su letra asociada
Es fácil reconocer a “los buenos” y a “los malos”
Se eligen elementos típicos de la cultura infantil
Gesticulación que anime a continuar con un reto
Gesticulación que muestre éxito y fracaso
Gesticulación positiva al trabajar en grupo
Se usa el juego antes que el método en libreta
Se comprenden los conceptos del juego sin ayuda exterior
Se progresa rápidamente por la propia acción del juego
El niño se hace partícipe de la historia
El niño pide el juego para seguir jugando
El niño se alegra ante la superación de un reto
Incentivar el trabajo en grupo
Mecanismos de gestión de recursos para el juego
Diferenciar retos individuales de colectivos
Número de intentos por grupo en resolver retos
Comunicación y control del mundo virtual
Agrado y valoración de las recompensas por grupo
Fomentar sentimientos grupales en cada reto
Fomentar la planificación para resolver objetivos
ISSN 1932-8540 © IEEE
197
VIII. CONCLUSIONES Y TRABAJOS FUTUROS
Fig. 1. Escritura de la vocal ‘a’ y pantalla de realimentación al grupo.
A lo largo de este trabajo se han presentado los videojuegos
como complemento a la enseñanza tradicional, mostrando las
ventajas que aportan al desarrollo cognitivo de los alumnos.
Además, se ha planteado la inclusión de pruebas y situaciones
colaborativas dentro del videojuego para fomentar la
interacción dentro de los grupos de alumnos y aprovechar las
ventajas que se derivan del aprendizaje colaborativo.
Por otro lado, se ha realizado un análisis de la jugabilidad
para ver qué factores afectan a la experiencia del usuario para
mejorar la eficacia del videojuego como herramienta de
aprendizaje.
Así, hemos presentado una guía de estilo para el diseño de
videojuegos educativos colaborativos y se ha aplicado al
ejemplo de “Leoncio y sus amigos”,
Actualmente, trabajamos en los métodos de evaluación del
aprendizaje y de la colaboración en sí misma. De estos análisis
se desprenderán técnicas de adaptación / personalización de la
acción del juego y de los contenidos didácticos en función de
las necesidades de cada individuo, con objeto de fomentar la
jugabilidad. Además, se realizarán ensayos en centros
escolares para comprobar nuestras teorías por medio del
empleo de videojuegos como “Leoncio y sus amigos”, entre
otros. Para evaluar y mejorar la guía de estilo se
implementarán otros videojuegos y se estudiarán sobre
videojuegos existentes.
Fig. 2. Pruebas final de fase. Construcción del Puente.
Puesto que los niños a los que se les enseñan las vocales
difícilmente tienen la capacidad de planificar, podemos
introducir un rol de líder que lo ejerza el tutor o profesor del
área en cuestión, de forma que sea él quien reparta el trabajo
cuando se dé el caso. De esta forma se establecen también
lazos de colaboración con el profesor. Otra función del líder
será mediar en la toma de decisiones, por ejemplo, a la hora de
determinar qué componente del grupo debe “ceder” o
“prestar” vidas al compañero que ha agotado sus intentos.
El juego termina cuando el grupo completa la última fase y
vence a “Perfecte”. En este momento los jugadores obtienen el
conjuro que les permite reunirse en un solo “Leoncio”.
Es obvio que el aprendizaje de las vocales debe hacerlo
cada individuo de forma particular, ya que los conocimientos
del área de la lecto-escritura básica no pueden debatirse: las
letras son las que son y los alumnos que aprenden a leer y
escribir no tienen capacidades desarrolladas para establecer
debates. Por ello, la colaboración se va a manifestar en las
tareas del videojuego propiamente dicho, fomentando la
participación, la motivación y la atención del alumno en
actividades que le son atractivas y que además le ayudan a
adquirir conocimientos.
AGRADECIMIENTOS
Este trabajo está financiado por el Ministerio de Ciencia e
Innovación de España, como parte del proyecto DESACO
(TIN2008-06596-C02-2) y el programa F.P.U.
REFERENCIAS
[1]
Huzinga, J.: Homo Ludens. Ed. Alianza (2000).
[2]
Valiño, G.: La relación Juego y Escuela: aportes teóricos para su
comprensión y promoción. Revista Conceptos. Año 77. Num 2. Boletín
de la Universidad del Museo Social Argentino. ISBN: 03277860.
Argentina (2002).
[3]
Provenzo, E.: Video kids. Cambridge: Harvard University Press (1991).
[4]
Nussbaum, M., Rosas, R., Rodríguez, P., Sun, Y., Valdivia, V.: Diseño,
desarrollo y evaluación de video juegos portátiles educativos y
autorregulados. Ciencia al Día. 3, vol. 2, 1-20 (1999)
[5]
McFarlane, A., Sparrowhawk, A., Heald, Y.: Report on the educational
use of games: An exploration by TEEM of the contribution which
games
can
make
to
the
education
process,http://www.teem.org.uk/publications/teem_gamesined_full.pdf
(2002)
[6]
Malone, T.W. and Lepper, M.R. "Intrinsic Motivation and Instructional
Effectiveness in Computer-based Education", In R.E. Snow & M.J.Farr
(Eds.) Aptitude, Learning and Instruction, Volume 2: Conative and
affective process analyses, Lawrence Erlbaum Associates, Hillsdale, N.
J., pp. 243-286. (1987)
[7]
Keller, J.M., and Kopp, T.W. “An application of the ARCS model of
motivational design”, Instructional theories in action: Lessons
illustrating selected theories and models, C.M. Regeluth (eds.).
Lawrence Erlbaum Associates. New York, pp. 289-320. (1987)
ISSN 1932-8540 © IEEE
198
[8]
Csíkszentmihályi, M. Flow: The Psychology of Optimal Experience,
Harper and Row, New York. (1990)
[9]
Norman, D. A. Emotional Design: Why We Love (or Hate) Everyday
Things, Basic Books, New York. (2004)
[10] Money, C. Theories of Childhood: An Introduction to Dewey,
Montessori, Erikson, Piaget & Vygotsky, Redleaf Press. (2000)
[11] Jong, B., Chan, T., Wu, Y., Lin, T.: Applying the adaptive learning
material producing strategy to group learning. En: First International
Conference Edutainment. LNCS, vol. 3942, pp: 39-49. (2006)
[12] Piaget, J., Inhelder, B. Psicología del niño, Ed. Morata (1971)
[13] Rollings, A. and Morris, D. Game Architecture and Design, Ed. New
Riders Games. (2003)
[14] Salen, K. and Zimmerman, E. Rules of Play: Game Design
Fundamentals, Ed. The MIT Press. (2003)
[15] González Sánchez, J. L.; Padilla Zea, N.; Gutiérrez, F. L and Cabrera,
M. “Playability: The Secret of the Educational Videogame Design”, In
2nd European Conference on Games Based Learning (EGBL). pp. 147156 (2008)
[16] Johnson, D. W. and Johnson, R. T. “Learning Together”. Sharan, S.
(ed.), Handbook of Cooperative Learning Methods, Greewood Press,
Connecticut (1994)
[17] González Sánchez, J. L.; Padilla Zea, N.; Gutiérrez, F. L and Cabrera,
M. “De la Usabilidad a la Jugabilidad: Diseño de Videojuegos
Centrado en el Jugador”, In IX Congreso Internacional de Interacción
Persona-Ordenador (INTERACCION). pp. 99-108 (2008)
[18] Björk, S., Lundgren, S., Holopainen, J.: Game Design Patterns. Ed.
Copier, M. & Raessens, J. Proceedings of Digital Games Research
Conference (2003).
[19] González Sánchez, J. L.; Cabrera, M.; Gutiérrez, F. L.: Diseño de
Videojuegos aplicados a la Educación Especial. VIII Congreso
Internacional de Interacción Persona-Ordenador (INTERACCION). pp.
35-45 (2007).
[20] González Sánchez, J. L.; Gutiérrez, F. L.; Cabrera, M.: Diseño de
Videojuegos colaborativos adaptados a la Educación Especial. V Taller
en Sistemas Hipermedia Colaborativos y Adaptativos. ISSN: 19883455. Vol 1, Núm 7. pp. 17-24 (2007).
[21] Padilla Zea, N.; González Sánchez, J. L.; Gutiérrez, F. L.; Cabrera, M.
and Paderewski, P. “Diseño de Videojuegos Educativos Multijugador.
Una Visión desde el Aprendizaje Colaborativo”, In IX Congreso
Internacional de Interacción Persona-Ordenador (INTERACCION). Pp.
29-38 (2008)
.atalia Padilla Zea: Miembro del grupo de investigación
GEDES, en el Departamento de Lenguajes y Sistemas
Informáticos de la Universidad de Granada. Su línea de
investigación se centra en la adaptación de las técnicas de
aprendizaje colaborativo a los videojuegos educativos, con
objeto de introducirlos en las aulas
José Luís González Sánchez: Desarrolla su labor
investigadora en el Departamento de Lenguajes y Sistemas
Informáticos de la Universidad de Granada, en el grupo
GEDES, dedicado al diseño de videojuegos y jugabilidad.
Está interesado en el uso de videojuegos como herramienta
educativa en las aulas.
Francisco L. Gutiérrez: Doctor en Informática. Profesor en
el Departamento de Lenguajes y Sistemas Informáticos de la
Universidad de Granada. Desarrolla su labor investigadora en
el grupo GEDES, acerca de sistemas interactivos, diseño de
interfaces de usuario, y diseño de sistemas colaborativos. Está
interesado en el uso de videojuegos en educación.
ISSN 1932-8540 © IEEE
Marcelino J. Cabrera: Profesor en el Departamento de
Lenguajes y Sistemas Informáticos de la Universidad de
Granada. Desarrolla su labor investigadora en el grupo
GEDES, dedicado a técnicas de adaptación y personalización,
adaptando los contenidos educativos de los videojuegos al
perfil del usuario. Ha colaborado con Nintendo España.
Patricia Paderewski: Doctora en Informática. Profesora en
el Departamento de Lenguajes y Sistemas Informáticos de la
Universidad de Granada. Desarrolla su labor investigadora en
el grupo GEDES, en el contexto de las arquitecturas software,
evolución y adaptación, y agentes software distribuidos para
entornos de trabajo colaborativo y aulas de clase.
199
Generador Sc@ut: Sistema de Creación de
Comunicadores Personalizados para la
Integración
Álvaro Fernández, José Luís González Sánchez, Luz Mª Roldán, Mª José Rodríguez-Fórtiz,
Mª Visitación Hurtado-Torres, Nuria Medina-Medina
Title— Sc@ut Generator: System for creating personalized
communicators for integration
Abstract— This paper presents Sc@ut Generator as a powerful
tool that allows the design of personalized communicators. It can
be used by teachers or people responsible for a person with
communication problem. Communicators run on PC or mobile
devices like Pocket PC or the video-console $intendo DS. Its use
in education special schools helps the adaptation of the educative
context to the user needs and capabilities. Besides, it facilitates
the user integration with his social environment.
Index Terms— autism, AAC, user impairments adaptation,
personalization, hypermedia systems, disabilities.
I. INTRODUCCIÓN
L
AS principales organizaciones internacionales han
emprendido en los últimos años iniciativas consensuadas
que abogan por el derecho a que todos los niños y niñas se
eduquen juntos, independientemente de sus condiciones
físicas, intelectuales, sociales, emocionales etc., ya que la
inclusión e integración es posible desde el punto de vista
educativo y social [1].
Existe un porcentaje de población que padece deficiencias
psíquicas, físicas y sensoriales. Suelen ser personas, a los que
en el campo de la educación se les cataloga como "alumnos
con necesidades educativas especiales".
Frecuentemente son susceptibles de comunicarse, pero el
lenguaje oral está seriamente limitado por graves trastornos en
A. Fernández tiene un contrato de investigación en la Universidad de
Granada y participa en el proyecto Sc@ut (tlf: +34-958243178; fax: +34958243179; e-mail: [email protected]).
J. L. González-Sánchez es un investigador de la Universidad de Granada,
participa en el proyecto Sc@ut y en la actualidad está finalizando su tesis
doctoral.
L. M. Roldán es Ingeniera en Informática y profesora de un instituto de
educación secundaria de Granada. Ha participado en el proyecto Sc@ut. (email: luzmaria.roldan@)gmail.com).
M. J. Rodríguez-Fórtiz es coordinadora del Proyecto Sc@ut y responsable
del grupo de investigación GEDES de la Universidad de Granada (e-mail:
[email protected]).
M. Hurtado y N. Medina son profesoras de la Universidad de Granada y
participan en el proyecto Sc@ut. ([email protected], [email protected]).
su aparato fonoarticulador o por una lesión cerebral, debido a
múltiples factores (Parálisis Cerebral Infantil, deficiencia
auditiva o mental, etc.). Ellos de forma natural utilizan formas
primitivas de comunicación, por ejemplo el llanto o la risa,
cuando son pequeños. A medida que crecen presentan unas
pautas comunicativas peculiares, pues un porcentaje del 90%
usa formas comunicativas disruptivas y presenta conductas
problemáticas que suponen un grave riesgo para la
convivencia y el aprendizaje.
Para esta población es necesario recurrir a otros sistemas de
comunicación no verbal, adaptados a la persona y a su
entorno. Se deben proporcionar sistemas favorecedores de la
capacidad de expresión, pues suelen ser un sustituto inmediato
del lenguaje oral. A estos sistemas se les conoce con el nombre
de Sistemas Alternativos o Aumentativos de Comunicación
(SAC) o comunicadores. Son una serie de estrategias o ayudas
puestas al servicio de personas seriamente limitadas a nivel de
lenguaje oral, y de las cuales pueden servirse para establecer
relaciones comunicativas. Tamarit [2] los define como un
conjunto estructurado de códigos no vocales, necesitados o no
de soportes físicos, los cuales, enseñados mediante
procedimientos específicos de instrucción, sirven para llevar a
cabo actos de comunicación (funcional, espontánea y
generalizable) por sí solos o en conjunción con códigos
vocales, o como apoyo parcial a los mismos. Ejemplos de SAC
son la lengua de signos, los paneles o tableros de
comunicación que usan pictogramas y los comunicadores
eléctricos o electrónicos que además incorporan sonidos.
Los SAC deben adaptarse a los sujetos que los usan. En la
mayoría de los casos se usan no sólo como herramienta de
comunicación sino también como soporte para el aprendizaje.
Cada persona debe progresar en función de lo que es capaz de
hacer, teniendo en consideración el bagaje con el que ya
cuenta, sus capacidades, habilidades, necesidades e
inquietudes. Es necesario respetar el al ritmo de trabajo
personal de cada uno, proporcionar herramientas
personalizadas y enseñanza individualizada.
Con el objetivo de apoyar en el aula y conseguir una
enseñanza individualizada e integradora, surge la plataforma
Sc@ut [3][4]. Se pretende con ella:
• Crear comunicadores adaptados y estimulantes para
usuarios reales, de tal forma que incluyan las imágenes
(pictogramas, fotografías y dibujos) y los sonidos
ISSN 1932-8540 © IEEE
200
(palabras y frases) que cada usuario utiliza habitualmente
para la comunicación con las personas de su entorno que
comparten el mismo lenguaje. La retroalimentación
auditiva es importante como apoyo al lenguaje, refuerzo al
usuario, y ayuda a los interlocutores.
•
Es uno de nuestros principales objetivos que los
comunicadores creados sean programas que puedan
ejecutarse en el ordenador y en dispositivos móviles que
sean llevados y usados en cualquier escenario de la vida
diaria donde el sujeto los necesite para comunicarse.
•
Los comunicadores deben poder ser modificados cuando
se desee, según la evolución del usuario, los cambios en
su entorno y en su perfil, y sus progresos en la forma de
comunicarse o en el lenguaje utilizado para ello. Esta
adaptación deben hacerla por sí mismos los tutores o
profesionales que conocen al sujeto, sin necesidad de
tener que recurrir a personal técnico especializado.
•
Las plantillas de comunicación deben poder ser usadas
también como plantillas de conocimiento, que presenten
contenidos de unidades didácticas, y como agenda de
actividades que deben hacerse en un orden concreto. En
este último caso se deberá informar al usuario de qué
acciones han sido ya realizadas y de cuáles quedan por
hacer.
•
Se debe recoger información de la interacción del usuario
que puede ser usada para evaluar el uso durante
determinados períodos de tiempo. Esto permitiría, por
ejemplo, asignar una puntuación o tomar decisiones de
cuáles deben ser los cambios necesarios para hacer una
mejor adaptación al usuario.
GE$ERADOR
Perfil de Usuario
Dominio del conocimiento:
Escenarios
COMU$ICADOR
Modelo Hipermedia:
Navegación
Adaptación
Educador (autor)
Existen versiones del comunicador Sc@ut para PC, pero
con el objetivo de conseguir portabilidad y que el usuario sea
lo más independiente posible, también hemos creado versiones
para dispositivos portátiles como PDAs (Fig. 2), teléfonos
móviles con sistema operativo Windows y la consola de
videojuegos Nintendo DS™ [6].
Las versiones para PC, PDA y teléfono están disponibles
para su descarga de forma gratuita en la página web del
proyecto: http://scaut.ugr.es. La versión para DS está en fase
de pruebas.
El generador se ejecuta en un ordenador y su funcionalidad
será descrita en la siguiente sección.
Figura 2. Comunicador Sc@ut en PDA.
II. GENERADOR DE COMUNICADORES
El generador Sc@ut es la herramienta que permite construir
los comunicadores adaptados a cada persona. Es usada
también para realizar cambios sobre comunicadores ya
creados, con el fin de ajustarse mejor al usuario, teniendo en
cuenta sus progresos, sus cambios de comportamiento, y de su
entorno.
Esta herramienta surgió con el objetivo de cumplir los
siguientes requisitos:
• Facilidad de uso: Los tutores de las personas con
discapacidad, padres o profesionales de la educación, que
lo usarán deben ser lo más autónomos posibles, de tal
forma que no requieran conocimientos de informática ni
se condicione su trabajo a que un informático les
programe lo que necesitan.
•
Flexibilidad/Versatilidad: Se debe permitir personalizar
los comunicadores, facilitando la reutilización de
información y recursos (componentes, imágenes, sonidos,
etc.). Además, debe evitarse obligar al tutor a seguir
itinerarios rígidos de edición de los comunicadores.
•
Escalabilidad: La plataforma Sc@ut se encuentra en
continua evolución, fruto de la experiencia de los
profesionales que la están usando cada día en su
aplicación real. Dicha evolución supone normalmente
modificaciones en la interfaz de usuario y en las
informaciones manejadas (perfiles, plantillas, etc.), por lo
que la herramienta en su diseño debe ser fácilmente
adaptable y ampliable.
Persona
discapacitada (lector)
Figura 1. Niveles de la Plataforma Sc@ut
La plataforma Sc@ut tiene los siguientes niveles (Fig. 1):
•
El comunicador Sc@ut: es la aplicación que permite a los
usuarios (lectores) visualizar sus comunicadores. Un
comunicador es el conjunto de plantillas y recursos
multimedia (imágenes, sonidos y vídeo) que constituyen
los datos para un determinado usuario.
•
El generador Sc@ut: es la herramienta utilizada por el
educador o tutor del lector (autor) para crear y modificar
un comunicador que se adapte al lector [5].
Son varios los aspectos que se tienen que tener en cuenta
para hacer un comunicador y que pueden ser configurados por
ISSN 1932-8540 © IEEE
FERNÁNDEZ et al.: GENERADOR SC@UT: SIST. DE CREACIÓN COMUNICADORES PERSONALIZADOS
el generador (Fig. 1). En primer lugar, debemos conocer al
usuario, y tener en cuenta algunas de sus características para
determinar cómo será su interacción con el comunicador
(perfil de usuario). Después, debemos considerar los
escenarios en los que necesita comunicarse, qué objetos y
acciones se corresponden con esos escenarios y qué relaciones
se pueden dar entre ellos. Para establecer la comunicación se
siguen las relaciones que el usuario o sus tutores entienden que
deben existir (navegación entre objetos y acciones). Por
último, debemos observar cómo usa el individuo el
comunicador y si ha habido cambios en su perfil o en su
mundo, para extraer información que nos permita adaptarlo
mejor a él. A continuación describimos cómo el Generador
configura cada una de estas características.
A. Perfil de Usuario
A la hora de mostrar en pantalla los diversos componentes
de las plantillas de los distintos escenarios hay que tener en
cuenta que algunos usuarios tienen limitaciones físicas o
cognitivas para interaccionar con los comunicadores. Para
conseguir la máxima flexibilidad del sistema, de modo que sea
realmente adaptable, se define un perfil específico para cada
usuario (Fig. 3).
201
que también se recoge información de cada usuario (nombre,
fotografía, calendario, plantillas asociadas, etc.) (Fig. 4).
Figura 4. Creación y selección de Usuarios
B. Dominio de Conocimiento
En cada momento, la comunicación puede basarse en un
dominio de conocimiento o mundo conceptual que variará
dependiendo del escenario en el que se encuentre el usuario.
Una de las principales características del Generador Sc@ut
es que permite al tutor diseñar la red semántica del
comunicador, correspondiente al dominio de conocimiento,
mediante la elaboración de un grafo conceptual formado por
componentes y enlaces entre éstos (post-requisitos) (Fig. 5).
Figura 5. Diseño de Plantillas
Figura 3. Personalización del perfil de usuario
Aspectos que se recogen en el perfil de usuario son: el tipo
de interacción (pulsación, pulsación resaltada, barrido y
barrido mixto), la especificación del número de componentes
(celdas) que aparecerán en pantalla en cada momento
(ajustando su tamaño), la opción de mostrar texto junto a cada
imagen, mostrar la secuencia de componentes seleccionados
hasta el momento y/o escuchar su sonido, establecer el tiempo
entre pulsaciones (para evitar errores de pulsación), el tiempo
de espera para dar una respuesta, o incluir algunos
componentes de forma automática en todas las plantillas
(llamados atajos por ser usados de forma frecuente).
En la mayoría de los casos, el Generador Sc@ut será
empleado por un tutor o responsable de varias personas por lo
A cada concepto percibido, al que denominamos
componente, se le asocia al menos una imagen, sonido o texto
que debe adaptarse al usuario (Fig. 6).
Las imágenes pueden ser pictogramas de cualquier lenguaje
de símbolos, fotografías o dibujos que sean conocidos por el
usuario. Los sonidos serán frases o palabras grabadas por
personas (cercanas o no al usuario) o bien creadas con un
sintetizador de voz. A los conceptos pueden asociárseles otras
propiedades como el número de veces que pueden ser
seleccionados, si se desactivan si este número se agota, etc.
La red conceptual puede construirse para permitir formular
frases, establecer un conjunto de objetos que pueden ser
pedidos o acciones que pueden ser realizadas en un escenario
concreto, o crear unidades didácticas para su uso en clase en el
proceso de aprendizaje del usuario.
ISSN 1932-8540 © IEEE
202
le puede asociar una subplantilla. Así, tras seleccionarse un
componente concreto, se mostrarán aquellos que sean
navegables desde el mismo.
También es posible establecer relaciones de pre-requisito,
obligando al usuario a seleccionar un componente antes que
otro, con el objetivo de inducir conductas o guiar en la
navegación para mostrar hábitos o rutinas.
Para completar el modelo de navegación, para cada usuario
y cada día de la semana, puede establecerse un calendario
(Fig. 8) añadiendo actividades, asociándoles un horario (con
hora de inicio y hora fin) y asignándoles una plantilla. El
calendario ayuda al usuario a realizar una estructuración
temporal y espacial.
Figura 6. Configuración de componentes
El generador también permite al usuario crear plantillas
simplemente escribiendo frases, en las que las palabras se
etiquetan como sujeto, verbo o complemento (Fig. 7). Las
frases son luego transformadas a una red semántica gráfica, y
de ellas se puede realizar una validación gramatical para
comprobar su correctitud. Es posible etiquetar algunas
palabras como indefinidas para evitar la validación si no se
exige una estructura sintáctica fija.
Figura 8. Calendario de actividades para un usuario
En definitiva, el modelo hipermedia sigue la jerarquía
siguiente (Fig. 9):
Figura 7. Edición de plantillas con frases
Además de facilitar la creación y edición de componentes,
la herramienta permite la reutilización de éstos al incorporar
una biblioteca de componentes. En dicha biblioteca es posible
almacenar aquellos componentes más utilizados, junto con sus
recursos multimedia (imágenes y sonidos) asociados. Para
reutilizar un componente es suficiente con arrastrarlo desde la
biblioteca al tapiz donde se diseña el grafo conceptual y se
creará un nodo nuevo que se podrá enlazar con la red.
Una vez diseñada una plantilla, podemos visualizar cómo
quedaría en el comunicador para PDA mediante la función de
simulación.
C. Modelo Hipermedia
La red semántica se completa con unas reglas de
navegabilidad. Hemos visto que pueden establecerse enlaces
mediante post-requisitos entre los distintos componentes, los
cuales ofrecen una visualización clara y sencilla de las reglas
de navegación. Además, a un componente de una plantilla se
Figura 9. Estructura de la red semántica completa.
•
La primera página se corresponde con el primer nivel de
la red, el nivel Perfil, por lo que se mostrará una lista con
los usuarios del comunicador que tendrán distinto perfil.
ISSN 1932-8540 © IEEE
•
La segunda página se corresponde con el nivel
Calendario, mostrando los escenarios y actividades que
correspondan al día de la semana del usuario
seleccionado.
•
Las sucesivas páginas corresponden con el nivel Plantilla
y en ellas se muestran todas las plantillas de un usuario
relacionadas con el escenario seleccionado, siguiendo el
orden de presentación que se corresponde con la
navegación diseñada para ellas.
203
D. Adaptación al Usuario
Para asistir en el proceso de adaptación se hace un análisis
de la interacción del usuario con el comunicador, aplicando
reglas para observar anomalías en ésta. Se deduce entonces
qué posibles cambios necesita el comunicador para ajustarse
mejor al usuario, de tal forma que se mantenga la integridad
del comunicador tras los cambios. Se guía al educador en el
proceso de adaptación. Para ello, se le sugiere en cada
momento qué modificaciones seguras puede hacer y se espera
a que él finalmente decida [7][8]. La investigación que
estamos realizando en este nivel aún está en fases tempranas y
no se han realizado implementaciones.
Chatbox, Alphatalker, Deltatalker, Canon Communicator,
SideKick, Lighwriter SL-20, Cheap Talk, TwinTalk y
VocabPC. En la comparativa, que puede consultarse en [10],
vemos que nuestro sistema incluye todas las características
deseables que sugieren Basil y otros, y algunas más como son:
flexibilidad en el uso de cualquier imagen y sonido, control de
aprendizaje y uso, pantalla táctil para facilitar la interacción,
conectividad wifi o por cable, posibilidad de conectar
pulsadores, posibilidad de utilizar el mismo dispositivo por
varios sujetos y fácil de programar.
También hemos comparado nuestro generador de
comunicadores con otros similares como SICLA, Plaphoons y
BoardMaker, viendo que éstos sólo generan comunicadores
para PC, por lo que nuestra herramienta es más potente.
Además, BoardMaker no es gratuito y se limita a los símbolos
de SPC [11], siendo los otros dos y el nuestro más versátiles.
El inconveniente que tiene nuestro generador a día de hoy es
que aún no está terminado totalmente. Son los profesionales
que están usándolo cada día con personas reales los que nos
están dando sugerencias de mejora, y detectando fallos que
vamos solucionando. Esperamos que en breve pueda estar
depurado y pueda ser ampliamente difundido.
E. Creación de Comunicadores
Una vez diseñado un comunicador es necesario generarlo
para su ejecución en el programa Comunicador Sc@ut. Se ha
creado un asistente para indicar si el comunicador será
utilizado por un único usuario o, por el contrario, englobará
los comunicadores de varios usuarios (este parámetro es
importante porque en muchos casos un conjunto de usuarios
compartirá un mismo dispositivo como sistema de
comunicación). Así, los comunicadores podrán editarse por
separado en el Generador Sc@ut y juntarse en última instancia
en un único comunicador compilado. También puede
configurarse cual es el dispositivo donde va a ser ejecutado el
comunicador. La herramienta ajustará automáticamente
algunas características del mismo como el tamaño de las
imágenes o el formato de los ficheros. Como hemos
comentado, los dispositivos donde se puede ejecutar el
Comunicador Sc@ut son: PC o teléfono móvil con Windows,
PDA y Nintendo DS
Si el dispositivo de destino es una PDA, el Generador puede
transferir el comunicador creado directamente a la misma
empleando una conexión a través de un cable USB. En el caso
de ser una consola DS, la transferencia se realiza a una tarjeta
de memoria para este dispositivo.
B. Evaluación
El comunicador y el generador de plantillas han sido
utilizados por niños, adultos y sus educadores dentro de un
proyecto subvencionado por la Fundación la Caixa, y en el que
intervienen las asociaciones ASPROGRADES y APROMPSI,
siendo utilizado por 47 sujetos, niños y adultos con diferentes
patologías (autismo, síndrome de Down, TGD, PCI, etc). El
Centro de Iniciativas para la Cooperación y el Desarrollo de la
Universidad de Granada también subvenciona una experiencia
de uso de la versión del comunicador Sc@ut para Nintendo
DS en la Fundación Purísima Concepción de Granada, donde
participan 8 niños con autismo y síndrome de Down. Por
último, la Consejería de Educación de la Junta de Andalucía
financia la difusión del comunicador en varios colegios
públicos de la comunidad Andaluza desde el curso 2005-2007,
siendo usando el comunicador en la actualidad por
aproximadamente 40 niños con muy diferentes necesidades
especiales.
A partir de nuestra experiencia en estos centros durante los
últimos tres años, hemos observado que el comunicador
Sc@ut es beneficioso en los siguientes aspectos:
• Incrementa la intención comunicativa del niño y mejora su
sociabilidad.
•
Ayuda en la estructuración temporal, fundamental para
autismo.
•
Mejora el lenguaje y la composición de frases.
•
Ayuda a eliminar conductas disruptivas.
III. EVALUACIÓN
A. Comparativa
Basil y otros [9] exponen que las principales características
de un comunicador deben ser: facilidad de uso, portabilidad,
económico, de interfaz intuitiva, adaptable a las limitaciones
físicas del usuario, y a los requisitos de lenguaje y cognitivos.
Hemos comparado nuestro comunicador con otros sistemas de
comunicación aumentativos y alternativos, en concreto,
Esta información ha sido extraída de cuestionarios que
hemos pasado a los profesionales que trabajan con los niños, y
para los que se ha hecho una evaluación continua. En concreto,
los cuestionarios utilizados han sido: examen de habilidades de
comunicación, valoración de uso de sistemas aumentativos de
ISSN 1932-8540 © IEEE
204
comunicación [12] seguimiento del entrenamiento en
comunicación con soporte electrónico, y entrevista de
comunicación para detectar y valorar conductas disruptivas.
IV. CONCLUSIONES Y TRABAJOS FUTUROS
En este artículo se ha presentado la plataforma Sc@ut como
un sistema integral que permite crear comunicadores
individualizados para personas con problemas de
comunicación. Los comunicadores creados les permiten
interaccionar con las personas de su entorno e integrarse con
ellas. Además, pueden crearse unidades didácticas que usadas
en el aula ayudarán en el proceso de aprendizaje.
El generador Sc@ut tiene un papel fundamental dentro de la
plataforma ya que:
• Unifica en un único programa todas las funcionalidades
necesarias para poder crear y personalizar los
comunicadores para múltiples usuarios de un aula.
•
Ofrece un entorno visualmente atractivo para el tutor y
muy sencillo de usar.
•
Facilita el proceso iterativo de adaptación de los
comunicadores, permitiendo introducir cambios de forma
fácil e ir aumentando la complejidad del sistema con el
objetivo de expresar un dominio de conocimiento mayor y
contextualizarse al proceso de aprendizaje.
•
Implica directamente al tutor o responsable de la persona
con necesidades, dejando en sus manos el desarrollo del
sistema de comunicación y aprendizaje. Esta persona, ya
sea profesional o familiar, seguramente será quién mejor
sepa cómo personalizar el comunicador de manera que sea
óptimo.
Tenemos otras investigaciones y trabajos en marcha, en
concreto:
• Se está trabajando en conectar vía Internet el Generador
con el portal del proyecto de forma que a la hora de
construir los comunicadores, puedan escogerse los datos
multimedia de una base de datos con pictogramas,
fotografías, dibujos y sonidos. Esto permitirá compartir
recursos y facilitar el trabajo.
•
Se está realizando una investigación encaminada a
modelar la verificación de integridad del generador,
necesaria para realizar la adaptación de un comunicador
de forma semi-automática.
•
También se está trabajando en el modelado del uso
colaborativo de los comunicadores por parte de varios
usuarios y supervisado por un educador, de tal forma que
una plantilla de comunicación también pueda ser utilizada
como una unidad didáctica en clase.
•
Gracias a un proyecto nacional, se va a ampliar el uso de
los comunicadores en dispositivos móviles para controlar
el entorno de los usuarios, su casa y su salud. Se está
desarrollando un middleware que permite el manejo y la
conexión de diferentes aplicaciones, usuarios y una red de
sensores y actuadores.
•
Por último, se está investigando cómo utilizar las últimas
novedades en el mercado de videojuegos como soporte de
comunicador o para el desarrollo de unidades didácticas
para personas con discapacidad [13]. Fruto de este trabajo
se ha desarrollado una versión del Comunicador Sc@ut
especialmente diseñada para la consola Nintendo DS, tal y
como hemos visto, denominado Sc@ut DS. También se
están estudiando las posibilidades que ofrece la
programación del mando de la consola Wii™ de Nintendo
para su uso en la creación de videojuegos educativos y
adaptativos para el aprendizaje comunicativo y el
desarrollo social.
AGRADECIMIENTOS
Este trabajo está financiado por el Ministerio de Ciencia e
Innovación, proyectos TIN2008-06596-C02-2 y TIN200805995/TSI, la Universidad de Granada (CICODE) y la
Fundación la Caixa.
REFERENCIAS
[1] Programa Mundial de las Naciones Unidas sobre discapacidad.
http://www.un.org/spanish/esa/social/disabled/unpgm.htm
[2] Tamarit, J. (1988). “Los trastornos de la comunicación en deficiencia
mental y otras alteraciones evolutivas: intervención mediante sistemas de
Comunicación Total”. En Basil, C. y Puig, R. Eds. Comunicación
Aumentativa. Madrid: INSERSO, Col, Rehabilitación.
[3] Paredes, M. D.; Rodríguez, M .J.; González, M.; López, E. 2006. A
Platform for Creating Adaptive Communicators. 10th International
Conference on Computers Helping People with Special Needs. Lecture Notes
in Computer Science, Vol-4061, 847–854
[4] Hurtado, M.V.; Medina, N.; García-Cabrera, L.; Rodríguez, M.L. 2005.
An Augmentative Communication System Based on Adaptive Evolutionary
Hypermedia System. EUROCAST 2005: Lecture Notes in Computer Science,
Vol-3643, 223-228
[5] Fernández, A.; Roldán, L. M.: Generador Sc@ut. Proyecto Fin de Carrera.
Tutoras: M.V. Hurtado Torres y N. Medina Medina. 2007. Titulación
Ingeniería Informática. Dpto. Lenguajes y Sistemas Informáticos. Universidad
de Granada.
[6] González Sánchez, J. L.; Cabrera, M. 2006. Sc@ut DS: Sistema de Ayuda
a la Comunicación y al Aprendizaje. IV Internacional Conference on
Multimedia and Information and Communication Technologies in Education
(m-ICTEE2006), 1116-1120.
[7] Rodríguez, M. J.; Paderewski, P.; Rodríguez, M. L.; Gea, M. 2004.
Unanticipated Runtime Adaptation of a Communicator for Autistic Children.
En Proceedings del Workshop on Foundations of Unanticiped Software
Evolution, FUSE (Barcelona, España, 2004), 40-47
[8] Medina, N.; Rodríguez, M. L.; Hurtado, M. V.; García-Cabrera, L. 2005.
An Adaptative Model to Suort Changes in the Development of
Communicational Augmentative Systems. Proceedings of the Iadis
International Conference, (Porto, Portugal, 2005), 170-177.
[9] Basil, C., Soro-Camats, E. and Rosell, C. 1998. Sistemas de Signos y
Ayudas Técnicas para la Comunicación Aumentativa y la Escritura.
Barcelona: Masson.70-72.
[10] Rodríguez-Fórtiz, M. J. 2007. Comunicador Aumentativo para Niños
Autistas. Investigación e Innovación en Autismo- Premios “Angel Riviere”
2006. Obra Social Caja Madrid, AETAPI, 129-166.
[11] Johnson, R. M. , Richman L. G. 1985. Picture Communications
Symbols Book. USA: Mayer-Johnson Company.
[12] Vandeerheiden, G y Lloyd, L.L. 1986. Communication Systems and their
Components. Augmentative communication: an introduction. Rockville:
American Speech Language Hearing Association, 46-163.
ISSN 1932-8540 © IEEE
[13] González Sánchez, J. L.; Cabrera, M.; Gutiérrez, F. L. 2007. Using
Videogames in Special Education. R. Moreno-Díaz et al. (Ed): EUROCAST2007, Lecture Notes in Computer Science, Vol-4739, 360-367.
Álvaro Fernández López es Ingeniero en Informática
(2008) por la Universidad de Granada (España).
Comenzó a investigar en el desarrollo de software
educativo a partir de su proyecto final de carrera, siendo
coautor del Generador de Comunicadores para Sc@ut.
Actualmente realiza estudios de postgrado en el Dpto.
de Lenguajes y Sistemas Informáticos y disfruta de un
contrato de investigación de la Universidad de Granada.
José Luís González Sánchez es Ingeniero en
Informática (2006) por la Universidad de Granada.
Desarrolla su labor investigadora en el Departamento de
Lenguajes y Sistemas Informáticos de la Universidad de
Granada, en el que ha sido profesor durante un año. Su
investigación se centra en el diseño de videojuegos y
jugabilidad. En la actualidad está finalizando su tesis
doctoral, relacionada con en el uso de videojuegos
como herramienta educativa en las aulas. Ha recibido el
premio Imagine’CUP 2007, de Microsoft España, por
su contribución al proyecto Sc@ut.
Luz María Roldán Vílchez es Ingeniera Técnica en
Informática de Sistemas (2005) e Ingeniera en
Informática (2009) por la Universidad de Granada
(España). Comenzó a trabajar en el desarrollo de
software educativo a partir de su proyecto final de
carrera, siendo coautora del Generador de
Comunicadores para Sc@ut. Actualmente, sigue
vinculada al campo de la educación como profesora de
Informática.
María José Rodríguez Fórtiz es Doctora en
Informática, profesora y responsable de un grupo de
investigación del departamento de Lenguajes y Sistemas
Informáticos de la Universidad de Granada. Ha sido
investigadora principal de varios proyectos de
investigación I+D+I, incluido el proyecto Sc@ut, y ha
publicado en revistas y congresos nacionales e
internacionales. Su investigación gira en torno a los
sistemas hipermedia, la evolución del software y el uso
de tecnologías por parte de personas con necesidades
especiales.
María Visitación Hurtado es Doctora en Informática y
profesora del departamento de Lenguajes y Sistemas
Informáticos de la Universidad de Granada. Ha
participado en numerosos proyectos de investigación
I+D+I, incluido el proyecto Sc@ut, y ha publicado en
revistas y congresos nacionales e internacionales. Su
investigación gira en torno a los sistemas de
información, los sistemas colaborativos y los sistemas
hipermedia. Es miembro del comité editorial de la
revista Information & Management.
$uria Medina Medina es Doctora por la Universidad
de Granada desde el año 2004 y profesora en el
departamento de Lenguajes y Sistemas Informáticos de
Granada a partir del año 2002. Sus principales líneas de
investigación son: hipermedia y adaptación de usuario.
Ha trabajado también en otras áreas: Internet, elearning, ingeniería web, evolución del software y
colaboración; y recientemente ha comenzado una
investigación en bioinformática. Es miembro del
proyecto Sc@ut desde sus inicios.
ISSN 1932-8540 © IEEE
205
206
Formação de Licenciados em Computação no
Brasil - Desenvolvimento e Utilização do
ROBOKIT
Marcia Elena Jochims Kniphoff da Cruz, Werner Haetinger, Fabiano Horn
Title—Forming Computer Teachers - Development and Use of
ROBOKIT.
Abstract—In this paper, we describe the current rules for
teacher training in Brazil and the importance to prepare them to
work with educational robotics. There are not many robotic kits
manufacture in Brazil, therefore the ROBOKIT was developed to
help in the training of teacher’s and to motivate the national
production of robotic kits.
Index Terms— Teacher training in Brazil, undergraduation in
teaching of computing, educational robotics, ROBOKIT.
I. INTRODUÇÃO
O
ensino diretivo raramente oportuniza ao estudante atuar
no planejamento e construção de objetos que utilizem
tecnologia. Porém, as atividades de criação são encontradas
em quase todos os campos da atividade funcional humana.
Existe, portanto, uma necessidade de introduzir no Ensino
Fundamental o conteúdo da automação e dos robôs,
possibilitando novas metodologias pouco exploradas ou
desconhecidas pelos professores desse nível de ensino.
A ênfase atual é dada a formas de aprendizagem
multidisciplinares,
inter-relacionadas
e voltadas ao
desenvolvimento
de
competências
tecnológicas
e
comunicacionais exigidas pela sociedade. Assim, torna-se
imprescindível a criação de equipamentos e softwares para a
efetivação de práticas inovadoras no cotidiano escolar, que
utilizem bases teóricas consistentes, para que os professores
possam efetivamente acompanhar o desenvolvimento dos
alunos nos momentos em que interagem com tais
equipamentos. Baseado na realidade apresentada e buscando
M. E. J. K. Cruz, UNISC – Universidade de Santa Cruz do Sul,
Departamento de Informática, Av. Independência, 2293, CEP 96815-900
Santa Cruz do Sul - RS – Brazil, Fone/Fax: 55 (51) 3717-7393 (e-mail:
[email protected]).
W. Haetinger, UNISC – Universidade de Santa Cruz do Sul, Departamento
de Informática, Av. Independência, 2293, CEP 96815-900 Santa Cruz do Sul
- RS – Brazil, Fone/Fax: 55 (51) 3717-7393, (e-mail:[email protected]).
F. Horn, Imply Tecnologia Eletrônica. Rua 28 de setembro, 1713. CEP
96810-530 Santa Cruz do Sul - RS – Brazil. Fone: 55 (51) 2106 8000, Fax:
55 (51)3715-5858 (e-mail: [email protected]).
produzir um equipamento para contribuir com o Ensino
Fundamental e o fomento ao pensamento operacional dos
estudantes, este artigo apresenta considerações sobre a
formação de futuros professores e o desenvolvimento de um
kit de robótica educativa operado por programação. O kit foi
idealizado por alunos e professores do Curso Licenciatura em
Computação da Universidade de Santa Cruz do Sul – UNISC
em parceria com empresa.
O ROBOKIT visa suprir a lacuna existente na produção de
equipamentos para o trabalho com robótica educativa no
Brasil, uma vez que existem poucos fabricantes nacionais
destes produtos. Um diferencial contundente do ROBOKIT é a
possibilidade de trabalho com materiais alternativos, enquanto
os kits importados oferecem peças prontas para encaixe e
montagem de modelos pré-elaborados disponíveis em manuais
sequenciais.
O projeto ROBOKIT corrobora a teoria de Berto e Nakano
[1], uma vez que foi originado em uma pesquisa acadêmica e
atualmente vem sendo comercializado.
Neste ínterim, o presente artigo é organizado da seguinte
forma: a seção II descreve o projeto pedagógico do curso
Licenciatura em Computação, no qual o ROBOKIT foi
idealizado e é utilizado; na seção III é descrito o ROBOKIT,
sua funcionalidade e aplicação; na seção IV são apresentadas
as metodologias de utilização do produto; e na seção V são
feitas as considerações finais.
II. FORMAÇÃO DE PROFESSORES NO BRASIL PARA O
TRABALHO COM TECNOLOGIA DA COMPUTAÇÃO
O curso Licenciatura em Computação da Universidade de
Santa Cruz do Sul, Rio Grande do Sul, Brasil, prima pela
formação dos alunos, futuros docentes, assegurando a
qualidade e o cumprimento de todos os aspectos necessários à
formação ética e comprometida com mudanças educacionais
significativas. A legislação vigente no Brasil para a formação
de professores, através da Lei de Diretrizes e Bases da
Educação Nacional, estabelece normas no Art. 621. O projeto
pedagógico do curso Licenciatura em Computação atende
1
A formação de docentes para atuar na educação básica far-se-á em nível
superior, em curso de licenciatura, de graduação plena, em universidades e
institutos superiores de educação, admitida, como formação mínima para o
exercício do magistério na educação infantil e nas quatro primeiras séries do
ensino fundamental, a oferecida em nível médio, na modalidade Normal [2].
ISSN 1932-8540 © IEEE
JOCHIMS, HAETINGER Y HORN: FORMAÇÃO DE LICENCIADOS EM COMPUTAÇÃO NO BRASIL...
efetivamente todos os aspectos legislados: do total deste
componente, 1800 horas são dedicadas às atividades de
ensino/aprendizagem e as demais 200 horas para outras formas
de atividades de enriquecimento didático, curricular, científico
e cultural. Estas 2000 horas de trabalho para execução de
atividades científico-acadêmicas somadas às 400 horas da
prática como componente curricular e às 400 horas de estágio
curricular supervisionado são o campo da duração formativa
em cujo terreno se planta a organização do projeto pedagógico
planejado para um total mínimo de 2800 horas. A formação é
realizada em 4 anos, sendo que a lei dita que não pode ser
realizada em tempo inferior a 3 anos para todos os cursos de
licenciatura, inclusive o curso normal superior. Em resumo,
estabelece:
1) 400 (quatrocentas) horas de prática como componente
curricular, vivenciadas ao longo do curso;
2) 400 (quatrocentas) horas de estágio curricular
supervisionado a partir do início da segunda metade do
curso;
3) 1800 (mil e oitocentas) horas de aulas para os conteúdos
curriculares de natureza científico-cultural;
4) 200 (duzentas) horas para outras formas de atividades
acadêmico-científico-culturais.
O curso também segue as diretrizes da Sociedade Brasileira
de Computação (SBC) [3] a qual estabelece que as
competências específicas e de docência das áreas de
computação e de educação devem nortear o currículo, a
avaliação, a organização institucional e a gestão pedagógica de
maneira coerente e integrada na formação e na sua prática. A
SBC, dentre outras indicações, sugere um currículo
multidisciplinar. Incentiva a preparação de profissionais para
tratar as áreas de computação e de educação, desenvolvendo
competências para o uso educacional efetivo das ferramentas
computacionais de maneira integrada a problemas em outros
domínios de conhecimentos. Alguns princípios formativos são
essenciais: modelagem, especificação, desenvolvimento,
implantação e manutenção de soluções computacionais para
abordagem de problemas em contextos educacionais e de
educação corporativa, bem como, o uso e seleção de software
e hardware adequados às demandas das escolas, instituições de
ensino e organizações em geral.
Nesse sentido, o curso Licenciatura em Computação da
Universidade de Santa Cruz do Sul (UNISC) sente-se
comprometido com a prescrição da lei e com o fomento para a
inserção da tecnologia na Educação Básica. Para dar conta
destas, possui disciplinas denominadas Práticas Articuladoras
em Computação e Estágio Supervisionado em Computação e
horas práticas em diversas disciplinas.
O curso incentiva e evidencia a importância da programação
na educação em várias disciplinas componentes do currículo
regular, abordando aspectos práticos e teóricos, essenciais à
formação dos futuros docentes. Especificamente as disciplinas
de Programação I, Programação II e Linguagens de
Programação para a Educação trabalham a programação para a
aprendizagem do aluno do referido curso e para a aplicação na
Educação Básica.
207
A partir do primeiro semestre de 2005, na disciplina
Linguagem de Programação para a Educação, foi estudada a
importância da programação para crianças e adolescentes em
idade de escolarização. A disciplina permitiu o estudo sobre a
importância da programação para o desenvolvimento
cognitivo, afetivo e social dos alunos e suas possibilidades na
escola. Durante a disciplina percebeu-se a carência na
produção brasileira de equipamentos para o trabalho com
robótica educativa, sendo que os equipamentos mais utilizados
pelas escolas consultadas através de páginas de Internet eram
importados.
Inicialmente, foi observado que as escolas que possuíam
equipamentos para o trabalho com robótica educativa
constituíam o grupo da rede particular de ensino, empregando
valores financeiros significativos para a aquisição de kits. Na
maioria dos casos, os kits eram compostos por motores, LED e
peças de encaixe para montagem de estruturas previamente
descritas em manuais.
Durante a disciplina de Linguagens de Programação para a
Educação, foi iniciada a proposta de parceria com uma
empresa da área de desenvolvimento tecnológico para a
implementação de um kit que utilizasse materiais alternativos e
para que os alunos da Licenciatura em Computação tivessem
este diferencial na formação docente. Da parceria estabelecida
surgiu o ROBOKIT.
III. O ROBOKIT
O ROBOKIT consiste em um objeto de aprendizagem
composto por uma caixa multicontroladora, programável,
dotada de microcontrolador, memória, teclado, display e altofalante, que permite conectar simultaneamente diversos
motores, lâmpadas, LED’s e relés. O produto foi desenvolvido
de forma colaborativa entre os alunos e professores do curso
de Licenciatura em Computação-UNISC, que orientaram as
funcionalidades, elaboraram o manual e uma vídeo-aula. A
fabricação ficou a cargo da empresa Imply Tecnologia
Eletrônica, que acolheu a proposta.
O ROBOKIT permite elaborar atividades e momentos em
sala de aula em que se propicia a ação do aluno frente a um
problema, na formulação de conceitos e ideias processuais. O
potencial pedagógico do ROBOKIT está na possibilidade de
programação pelo aluno que o utiliza. A programação é
desenvolvida conforme objetivos estabelecidos pelo grupo de
alunos envolvidos no projeto. Preferencialmente é incentivada
a elaboração de jogos pedagógicos que envolvam conteúdos
estudados, elaborados na íntegra pelos alunos, sob orientação
do professor. Tais projetos permitem aos alunos participação
em todas as fases do jogo, da ideia a ser abordada, às regras
que devem ser seguidas, além dos materiais alternativos com
os quais o jogo será construído. Inúmeras habilidades são
trabalhadas enquanto o projeto é desenvolvido. Cabe, assim ao
professor estar presente para orientar o raciocínio dos alunos
em certa direção através de materiais (conhecimento da
criança, imagens mentais, esquemas motores) e instrumentos
lógicos (estrutura de raciocínio, hábitos intelectuais) [12],
auxiliando no ambiente promotor de aprendizagem. As
crianças produzem pequenos inventos mecânicos, maquetes e
ISSN 1932-8540 © IEEE
208
protótipos de movimentação autônoma que são construídos
com materiais alternativos de baixo custo. Estas máquinas,
sempre criadas com um aspecto pedagógico, têm a sua ação e
animação levada a efeito através da programação no
ROBOKIT.
A. Como surgiu o ROBOKIT
O ROBOKIT surgiu a partir de uma pesquisa realizada na
disciplina Linguagens de Programação para a Educação, do
curso Licenciatura em Computação que, a partir dos
resultados, objetivou desenvolver um kit de robótica para
aplicação no Ensino Fundamental e para a formação de
professores, primando por materiais alternativos e de baixo
custo, e ainda desenvolver oficinas e acompanhar a
aprendizagem dos alunos participantes, através do Método
Clínico Piagetiano [4, 12]. A pesquisa teve seu
encaminhamento considerando que a programação é uma
atividade necessária em qualquer idade, portanto, sua
abordagem formal na escola é indispensável. A proposta do kit
foi apresentada à empresa Imply Tecnologia Eletrônica para
que o produzisse, conforme orientações dos alunos e
professores do curso. Todos os encaminhamentos foram dados
em parceria efetiva, sendo que a empresa implementava e os
alunos e professores testavam e elaboravam uma listagem de
sugestões para retornar à empresa para novas melhorias no kit.
O ROBOKIT foi submetido a vários testes realizados pelos
alunos até ser considerado ideal para utilização em escolas de
Ensino Fundamental, conforme ilustrado na Figura 1. Várias
modificações no software foram realizadas tornando a
linguagem acessível e de fácil compreensão para crianças em
fase de escolarização. O display da caixa multicontroladora do
ROBOKIT apresenta os resultados da programação com texto
que incentiva a criação a pensar sobre a ação que se deseja
executar. O resultado imediato (feedback) permite que a
criança observe se seu comando está sendo executado
conforme desejado ou se necessita adequação. A criança, ao
programar o ROBOKIT assume uma posição de comando e
controle, tornando-se autora de uma sequência de instruções
para animar seu invento, maquete ou jogo pedagógico.
Local da Figura 1
Fig. 1. Alunos da Licenciatura em Computação UNISC testando o
ROBOKIT.
O Método Clínico [4], segundo Piaget [12] é desenvolvido
através de um conjunto de perguntas e experimentos utilizados
para descobrir os aspectos do funcionamento e da estruturação
da mente da criança, enquanto ela organiza os objetos sobre os
quais age, para analisar como ela desenvolve as relações. Este
método é um aliado fundamental para o trabalho pedagógico,
consistindo em conversar livremente com os alunos sobre
determinado assunto, acompanhando os desvios do seu
pensamento para reconduzi-lo ao tema, através de
questionamentos ou contra argumentações, sem dar a resposta
ao aluno. Conforme as respostas dadas pela criança ou
adolescente entrevistado é possível classificar a estruturação
do seu pensamento, sendo que a maioria dos entrevistados
apresentou contextos de esforço e interesse em direção à
reflexão. Poucas crianças entrevistadas apresentam contextos
mentais de fabulação ou brincadeira, nos quais as respostas
são desconexas ao assunto proposto pelo professor
entrevistador. Um exemplo retrata o quanto as crianças se
envolvem e apreciam programar o ROBOKIT. O exemplo é de
uma criança de 8 anos que trabalhava com o ROBOKIT pela
segunda vez:
Entrevista realizada ao aluno A: O que este robô faz? – Liga
e faz música. Com que ele se parece? – Com uma calculadora.
– O que é preciso fazer para que ele funcione? – Comandar
ele. Outros robôs também são comandados para funcionar ou
eles sabem o que fazer sozinhos? – !ão sabem. Todos
precisam ser comandados por uma pessoa e eles também
podem estragar e alguém arruma de novo.
Assim, é fundamental oportunizar aos alunos essa
experiência, através de uma linguagem acessível que incentive
o desenvolvimento da capacidade de formular problemas e de
lançar respostas para solucioná-los, incentivando a introdução
ao pensamento científico e à programação.
Borges et al [5] implementaram um ambiente didático para
operação remota de robô manipulador, apresentando as
características do ambiente e a testagem durante o
desenvolvimento. Miranda, Sampaio e Borges [6]
desenvolveram um ambiente de programação visual para o kit
de robótica educacional RoboFácil. Cruz et al [7] apresentam a
importância da preparação de professores para o trabalho com
robótica e programação no Ensino Fundamental e a validação
do ROBOKIT realizado com alunos de quinta e sexta série de
escola e alunos da graduação. Da mesma forma Haetinger [8]
desenvolveu uma interface controladora de motores através de
um computador de mesa. Estes motores eram adaptados a
inventos diversos criados por alunos de graduação.
Diante dos resultados da pesquisa e dos dados agregados
para as proposições futuras, considera-se que o produto
desenvolvido, o ROBOKIT, atingiu plenamente os objetivos,
tendo ao final de 2007 sua utilização aplicada a treze escolas
diferentes da região de Santa Cruz do Sul – RS e a diversos
grupos de estudo da universidade.
O produto foi planejado para atender as necessidades do
Ensino Fundamental, que carece de materiais para o trabalho
com programação e acionamento de motores, LED’s e sons.
Os kits de robótica existentes são importados e apresentam
custo elevado, inviabilizando a aquisição destes materiais para
ISSN 1932-8540 © IEEE
a grande maioria das escolas. Em geral, a rede particular de
ensino tem maior acesso a kits importados. Algumas escolas
municipais conseguem estabelecer contratos com importadoras
de kits.
Considerando a necessidade da introdução à programação e
ao manuseio de materiais relacionados à robótica no Ensino
Fundamental e observando o crescente consumo de produtos
importados
pelas
escolas,
considerou-se
que
o
desenvolvimento de um kit nacional era favorável ao mercado
e uma oportunidade de ampliar a aproximação universidadeempresa como exemplo de cadeia produtiva.
Para regular os aspectos relacionados à propriedade
intelectual e à exploração comercial do produto, foi
estabelecido um contrato de parceria entre o curso
Licenciatura em Computação - UNISC e a empresa Imply
Tecnologia Eletrônica, objetivando a execução conjunta do
kit.
B. Descrição técnica do ROBOKIT
A estrutura do ROBOKIT foi planejada para ser o mais
econômica possível, representando uma relação viável entre
custo-benefício ao usuário. Na Figura 2 apresenta-se o
diagrama de blocos com as principais funcionalidades do
ROBOKIT.
Local da Figura 2
Fig. 2. Diagrama de blocos do ROBOKIT .
Foi utilizado um microcontrolador [9] Microchip, modelo
PIC16F873A-I/P. Este componente centraliza e executa todas
as atividades do ROBOKIT.
Internamente há dois tipos de memória que são mantidas
mesmo na falta de energia:
- uma do tipo flash, residente diretamente dentro do
microcontrolador e armazena os programas de controle e
gerenciamento intrínsecos do ROBOKIT.
- a outra é do tipo Erasable Programmable Read-Only Memory
(EEPROM com barramento I2C) que grava e recupera os
programas feitos pelos alunos. Esta memória é externa ao
microcontrolador, sendo conectada a ele com apenas 2 I/O’s e
possui capacidade para 32.768 bytes, o que permite gravar e
recuperar até 64 programas feitos pelos alunos. Esta memória
209
de programas é tratada como uma fila, permitindo inserir e
remover comandos sempre no final.
O visor é constituído por um LCD (Liquid Crystal Display)
com 2 linhas e 16 caracteres dotado de backlight. O teclado
constitui a interface de entrada de dados e programas e foi
desenvolvido especialmente para o ROBOKIT em função do
layout, das teclas e da arte. O ROBOKIT pode operar através
de uma fonte externa ou através da sua bateria interna, do tipo
recarregável 12 V DC. Esta bateria lhe confere maior
mobilidade e uma autonomia média de 2 horas.
O motor de passo pode ser programado para girar para a
direita ou para a esquerda, além de poder variar o intervalo de
tempo entre cada passo em milissegundos. Este tipo de motor
é muito preciso em seus movimentos, permitindo executar
movimentos com ângulos muito pequenos. O motor de
corrente contínua pode ter o valor da sua velocidade
controlada dentro de uma ampla faixa de valores através de
PWM (Pulse Width Modulation), que já vem implementado
em hardware. Cada um dos LED’s pode ter especificado o seu
tempo de acionamento em segundos. As notas musicais foram
implementadas diretamente no microcontrolador.
O teclado funciona de forma multiplexada, através de uma
varredura feita pelo microcontrolador. A varredura retorna
códigos ASCII para cada tecla. Estes códigos são associados a
comandos que correspondem ao nome das teclas na capa de
policarbonato.
Internamente as micro-instruções são organizadas em um
formato onde a primeira posição corresponde ao tipo de
comando (motor de passo, motor contínuo, LED’s, SOM, etc)
e as demais posições são os parâmetros modificáveis conforme
a instrução (sentido de rotação, número de passos,
velocidade). Este formato é transparente ao aluno e o seu
emprego dispensa a criação de uma linguagem específica para
o estudante fazer a programação do ROBOKIT. Para
programar, ele digita uma seqüência de teclas na ordem
desejada.
A programação do ROBOKIT é feita através do teclado e
os comandos são visualizados no LCD, proporcionando um
feedback imediato ao aluno. Os comandos de repetição foram
incluídos para permitir executar os blocos de programas por
várias vezes.
Vários layouts foram criados para o ROBOKIT, sendo que
foi escolhido o mais ergonômico, apresentado na Figura 3.
Local da Figura 3
Fig. 3. Layout do ROBOKIT .
ISSN 1932-8540 © IEEE
210
IV. METODOLOGIAS DESENVOLVIDAS
C. Manuais e Vídeo-aula
O texto do manual, com 23 páginas, foi elaborado pelos
professores alunos do curso de Licenciatura em Computação
da UNISC, contando com a orientação e a revisão de
professores. Adotou-se o formato livreto pela economia e
mobilidade. A capa, Figura 4, foi feita com papel do tipo
couchet e todas as páginas internas são coloridas. Também
acompanha o produto uma carta de mesa que resume os
principais comandos e funcionalidades do ROBOKIT. O
manual é considerado um caderno pedagógico com texto
dirigido aos pais e professores. O teor dos textos do manual
enfatizam a importância da programação, da criação com
materiais alternativos e a possibilidade de relacionar inventos,
jogos pedagógicos e maquetes a conhecimentos que as
crianças já possuem. Estas características são o diferencial na
comparação com demais kits que apresentam a montagem de
inventos passo a passo com peças pré-moldadas.
Fig. 4. Manual do ROBOKIT.
Além de descrever os componentes do ROBOKIT, seus
conectores, ligações e operação, o manual também apresenta
sugestões de projetos e jogos educativos, tais como:
Montagem de Maquetes, Elaboração de Inventos, Telas
Artísticas e Criativas, Datas Comemorativas, Aprenda Futebol
Brincando, Jogo do Raciocínio, Jogo das Formas Geométricas,
Jogo Ritmos Musicais, Montando o Mapa do Brasil, Bingo da
Multiplicação, Alfabeto das Cores, Trilha das Cores.
A vídeo-aula, que é distribuída em CD, apresenta
explicações teórico-pedagógicas, exemplos de inventos e jogos
pedagógicos, visando à formação docente para o trabalho na
escola. O funcionamento do ROBOKIT é apresentado passo a
passo.
A atividade de criação dos alunos das escolas de Ensino
Fundamental inicia na elaboração dos seus inventos que são
montados pela integração de materiais alternativos, que podem
ser os mais diversos, incluindo: cartolina, madeira, metal,
plástico, rodas, correias, eixos, engrenagens, motores, LED’s,
entre outros. Estes elementos são conectados ao ROBOKIT e
após é realizada a sua programação. Os diferentes tipos de
motores que podem ser ligados permitem que os inventos
adquiram movimento e ação.
Para ativar o seu invento, o iniciante digita instruções no
ROBOKIT, criando um programa que segue uma lógica
estabelecida no projeto. A capacidade interativa
proporcionada pelo ROBOKIT torna a atividade mais atrativa
e interessante para o aprendiz, favorecendo, assim, o processo
de ensino-aprendizagem.
O professor orientador procura conduzir as atividades
práticas incentivando montagens com caráter lúdico e
envolvendo tópicos relativos ao conteúdo desenvolvido em
aula, d’ABREU [10]. A interação com os demais colegas
também é evidenciada pela troca constante de ideias e
necessidade de tomada de decisões grupais.
Foram analisados os resultados de aprendizagem de 22
crianças entre 6 e 12 anos. Foram aplicados questionários às
crianças sobre a concepção de robótica e assuntos adjacentes,
solicitando que traçassem um paralelo entre programar no
ROBOKIT e programar grandes robôs ou robôs sofisticados
apresentados na TV.
Para exemplificar apresenta-se parte das respostas dadas por
três alunos de 8 anos, nas quais a resposta final indica a
formação da sua estrutura de pensamento:
Aluno B
Entrevistador: - Para o ROBOKIT funcionar o que é preciso
fazer?
Resposta do aluno: - Programar ele.
Entrevistador: - Como?
Resposta do aluno: - Apertando nos botões.
Entrevistador: - E se ele estragar?
Resposta do aluno: - Alguém arruma.
Entrevistador: - E os robôs da TV? Alguém necessita
programar estes robôs?
Resposta do aluno: - Não eles sabem tudo sozinhos.
Aluno C
Resposta do aluno: - Não precisa ser programado eles são
robôs inteligentes, mas se estragar alguém precisa arrumar.
Aluno D
Resposta do aluno: - Qualquer robô precisa ser programado
para funcionar.
A análise das respostas permite concluir o nível de
pensamento no qual se encontra cada aluno. É possível,
classificar, através das respostas como o aluno está
estruturando seu pensamento, se consegue estabelecer relações
entre a programação do ROBOKIT e um outro robô mais
sofisticado, mas fora do seu alcance físico. Nas respostas é
ISSN 1932-8540 © IEEE
possível identificar que o aluno B ainda possui a fabulação em
seu pensamento, mas se direciona para o desencadeamento de
um pensamento mais elaborado. O aluno C já se encontra em
nível mais avançado e o D já está na crença espontânea,
segundo a metodologia clínica de Piaget.
Segundo Piaget [11], o conhecimento construído está
incorporado aos esquemas mentais que são colocados para
funcionar diante de situações problemas ou desafios. Esse
processo ocorre mediante a tomada de consciência, que é
entendida como uma construção que decorre das relações do
sujeito com o objeto, sendo a mesma vista como uma
conceituação, isto é, uma passagem da assimilação prática para
a assimilação por meio de conceitos.
Para exemplificar, um dos inventos consistiu em um jogo
composto por cartolina, caixa de sapato e cartas de papel. Na
cartolina foi desenhada uma trilha com casas numeradas. As
cartas, também numeradas, continham problemas relativos ao
conteúdo de Geometria Plana e indicações para acerto ou erro.
A caixa de sapato foi encapada com papel numerado e no
centro suportava o motor de passo com um ponteiro ligado ao
seu eixo. Através da programação, o ROBOKIT fazia o
controle do giro do motor, apontando o número de casas a
serem percorridas sobre a trilha. A última casa alcançada
indicava a carta a ser retirada pelo jogador. Mediante
resolução do problema, o jogador poderia avançar ou recuar.
O planejamento, o estabelecimento de regras e o
desenvolvimento do jogo, apresentado na Figura 5, ficou a
cargo dos alunos com a orientação do professor.
Fig. 5. Jogo pedagógico elaborado com material alternativo e controlado pelo
ROBOKIT .
Outro exemplo da praticidade e ergonomia do ROBOKIT é
sua produção adaptada às necessidades escolares. A maleta
possui alça e pode ser levada a qualquer ambiente. Esta
característica foi desenvolvida pela observação feita durante os
estágios dos alunos da Licenciatura em Computação, uma vez
que os professores das escolas desejam utilizar diferentes
ambientes para desenvolvimento e apresentação de trabalhos.
Tanto na fase de criação de maquetes, jogos e inventos como
em apresentações para pais e comunidade escolar o ROBOKIT
pode ser levado e utilizado em diferentes ambientes, conforme
Figura 6. O Kit possui: uma caixa controladora, uma fonte
211
Fig. 6. Crianças utilizando o ROBOKIT em ambiente descontraído sobre
tapete.
para alimentação, dois motores contínuos, um motor de passo
e 4 led’s. Além destes componentes, o kit contém um manual
pedagógico, uma carta de mesa com exemplos de comandos
para programação e um CD contendo a vídeo-aula.
V. CONSIDERAÇÕES FINAIS
O Curso de Licenciatura em Computação da UNISC atende
todas as normas estabelecidas pelo Ministério da Educação do
Brasil. Os alunos realizam estágios em escolas da região.
O ROBOKIT supre a necessidade de equipamentos, pois
muitas escolas não possuem recursos para adquirir materiais
de robótica, que são importados e apresentam custo muito
elevado.
Os estagiários da Licenciatura em Computação levam o
ROBOKIT até as escolas para desenvolver atividades nas salas
de aula utilizando metodologias apropriadas e criativas
planejadas pelos mesmos e que utilizam materiais alternativos.
São elaborados jogos de cunho pedagógico, maquetes e
inventos controlados pelo acionamento de leds, motores e sons
pelo ROBOKIT. Questões são feitas aos alunos
individualmente para coleta de dados e conhecimento dos
resultados de aprendizagem através do Método Clínico
Piagetiano.
Inventos controlados através de programação surgem como
uma ferramenta relevante para desvelar novas formas de
construção do raciocínio. O aluno aprende fazendo e errando,
definindo visões, buscando o conhecimento de forma próativa, tudo dentro de uma cultura tecnológica favorável em que
o contexto criativo é evidenciado. Combina-se o uso de
materiais alternativos e equipamentos de robótica incentivando
o raciocínio lógico da criança.
A sala de aula transforma-se num ambiente de alta difusão
tecnológica, através da ampliação do contato dos alunos com
novos equipamentos e conceitos. O lúdico aliado às novas
tecnologias resulta em maior eficiência no engajamento do
estudante no processo educativo enfocando a introdução da
ISSN 1932-8540 © IEEE
212
programação no Ensino Fundamental, que pela legislação
brasileira é composto de nove anos.
Como proposição futura pretende-se desenvolver um
ambiente de controle do ROBOKIT pela Internet e por celular,
objeto de pesquisa em andamento no ano de 2008 e 2009,
além do acoplamento de sensores para novas aplicações.
Marcia Elena Jochims Kniphoff da Cruz é
licenciada em Matemática e Biologia e mestre em
Educação pela Universidade Federal do Rio Grande
do Sul (Brasil). É professora do Departamento de
Informática e atual Coordenadora da Licenciatura em
Computação, da Universidade de Santa Cruz do Sul.
Suas linhas de pesquisa são Robótica e Informática
Educativa.
AGRADECIMENTOS
Agradecemos aos alunos e professores participantes do
projeto, à UNISC – Universidade de Santa Cruz do Sul pelo
apoio logístico e financeiro dado a esta pesquisa e à empresa
Imply
Tecnologia
Eletrônica
pela
fabricação
e
comercialização do ROBOKIT.
REFERÊNCIAS
BERTO, Rosa M. V. S. e NAKANO, Davi Noboru. 2000 A produção
científica nos anais do encontro nacional de engenharia de produção:
um levantamento de métodos e tipos de pesquisa. Escola Politécnica da
Universidade de São Paulo Departamento de Engenharia de Produção.
Anais ENEGEP, São Paulo.
[2] Brasil. PARECER CNE/CP 28/2001. Despacho do Ministro em
17/1/2002, publicado no Diário Oficial da União de 18/1/2002, Seção 1,
p. 31.
[3] SBC – Sociedade Brasileira de Computação. 2002 Currículo de
Referência para Cursos de Licenciatura em Computação. CR-LC/2002 Versão homologada em Assembleia da SBC em julho de 2002.
[4] DELVAL, Juan. 2002 Introdução à prática do método clínico:
descobrindo o pensamento das crianças. Porto Alegre: Artmed.
[5] BORGES, Emanuel N. 2006 Ambiente didático para operação remota
de robô manipulador. In: XXVI ENEGEP - Fortaleza, CE, Brasil:
ENEGEP 2006 ABEPRO 1 (EESC/USP).
[6] MIRANDA, Leonardo C, SAMPAIO, Fábio F. e BORGES, José A.
2007 ProgrameFácil: Ambiente de Programação Visual para o kit
Robótica Educacional RoboFácil. Anais do XVIII Simpósio Brasileiro
de Informática na Educação, São Paulo.
[7] CRUZ, Marcia K. et al. 2007 Formação Docente para Trabalho com
Robótica Educativa.
Anais do XVIII Simpósio Brasileiro de
Informática na Educação, São Paulo.
[8] HAETINGER, Werner. 2004 Construção de robôs para ensinar os
conceitos de programação orientada a objetos. In: 6º SIMPOSIO
INTERNACIONAL DE INFORMATICA EDUCATIVA - SIIE 2004.
Caceres: Universidad de Extremadura.
[9] PEREIRA, Fábio. 2003 Microcontroladores PIC: Programação em C.
6°. ed. São Paulo: Érica.
[10] d’ABREU, João Vilhete Viegas. 1996 Desenvolvimento de Projetos em
Parceria Professor-Aluno na Oficina de Robótica Pedagógica. Anais do
VII Congresso Internacional Logo. Porto Alegre, RS, novembro, 1995 e
Anais do III Congresso Iberoamericano de Informática. Barranquilla,
Colômbia, julho.
[11] PIAGET, Jean. 1997 A Tomada de Consciência. São Paulo:
Melhoramentos Universidade de São Paulo.
[12] __________. 2005 A Representação do Mundo na Criança: com
concurso de onze colaboradores. Aparecida, São Paulo: Idéias & Letras.
Werner Haetinger é licenciado em Física e mestre
em Ciência da Computação pela Universidade
Federal do Rio Grande do Sul (Brasil). É professor
assistente do Departamento de Informática da
Universidade de Santa Cruz do Sul. Suas linhas de
pesquisa são Robótica e Informática Educativa.
[1]
ISSN 1932-8540 © IEEE
Fabiano Horn é Técnico em Automação Industrial
e atualmente é Diretor de Tecnologia da empresa
IMPLY Tecnologia Eletrônica (Brasil), na qual
dirige a gestão de projetos nas áreas de hardware,
firmware e software.
213
Asistentes Interactivos para el Aprendizaje de
Algoritmos Voraces
J. Ángel Velázquez Iturbide, Member, IEEE, Carlos A. Lázaro Carrascosa, e Isidoro Hernán Losada
Title— Interactive Assistants for Learning Greedy Algorithms
Abstract— The design of educational software must be based
on clear pedagogical objectives. In this article we introduce two
interactive assistants, each one intended to assist in a specific
greedy algorithm: AMO for the knapsack problem and SEDA for
the activity selection problem. We describe their educational
objectives by means of the levels in Bloom’s taxonomy and the
functions these assistants provide to support such levels. We also
describe the method and results of several usability evaluations
performed, which were highly positive.
Index Terms— Algorithms, educational technology, interactive
systems, user interface human factors.
I. INTRODUCCIÓN
L
A informática en general y la informática educativa en
particular han alcanzado niveles muy altos de
sofisticación. Sin embargo, este alarde tecnológico no tiene
porqué ir acompañado de su éxito educativo.
Un ejemplo claro lo encontramos en las animaciones de
algoritmos que, a pesar de su madurez y amplia oferta de
sistemas, no ha alcanzado el éxito prometido. Una de las
principales razones [1] de este relativo fracaso es la gran carga
de trabajo que supone la construcción de animaciones
(normalmente, para los profesores), pero también que su uso
no siempre garantiza una mayor eficacia educativa [2].
El trabajo aquí presentado es una contribución dentro de
una línea de investigación centrada en el desarrollo de
aplicaciones educativas de animación de programas para
técnicas de diseño de algoritmos. Dicha línea [3] comenzó con
un estudio de las características de las visualizaciones de
algoritmos, clasificadas por técnica de diseño. También
partimos de nuestra experiencia en el uso de la taxonomía de
Bloom [4] como marco educativo para el diseño de
Manuscrito recibido el 28 de Febrero de 2009.
J. Ángel Velázquez Iturbide pertenece al Departamento de Lenguajes y
Móstoles 28933, Madrid, España (autor de contacto, Tel.: +34 91 664 74 54;
Fax: +34 91 488 85 30; e-mail: angel.velazquez@ urjc.es).
Carlos A. Lázaro Carrascosa pertenece al Departamento de Lenguajes y
Móstoles 28933, Madrid, España (e-mail: carlos.lazaro@ urjc.es).
Isidoro Hernán Losada pertenece al Departamento de Lenguajes y
Móstoles 28933, Madrid, España (e-mail: isidoro.hernan@ urjc.es).
aplicaciones educativas [5]. Sobre estas bases, hemos
desarrollado sistemas para la animación de la recursividad [6]
y de algoritmos de divide-y-vencerás [7].
En este artículo se presentan dos aplicaciones educativas
diseñadas para ayudar a los alumnos en el estudio de los
algoritmos voraces. AMO [8] está concebido para ayudar al
estudio del problema de la mochila [9] y SEDA [10], para el
problema de la selección de actividades [11]. Ambas
aplicaciones afrontan los dos retos antes citados para sistemas
de animación. Por un lado, las animaciones se generan
automáticamente, sin esfuerzo por parte del usuario. Por otro
lado y lo más importante para el objetivo de esta
comunicación, afrontamos la eficacia educativa mediante su
diseño en el marco de la taxonomía de Bloom.
La estructura del artículo es la siguiente. En el apartado
siguiente describimos nuestros objetivos pedagógicos. El
apartado tercero contiene una descripción detallada de ambas
aplicaciones. En el apartado cuarto se describen los resultados
de varias evaluaciones de usabilidad. Por último, comentamos
algunos trabajos relacionados e incluimos nuestras
conclusiones y líneas de trabajo futuro.
II. OBJETIVOS PEDAGÓGICOS
Hemos clasificado los objetivos educativos de nuestras
aplicaciones según la taxonomía de Bloom [4]. Se trata de un
marco, muy conocido, para medir el grado de conocimiento o
aprendizaje de una materia por el alumno. La taxonomía
establece una jerarquía de seis niveles:
• Nivel de conocimiento. El estudiante puede recordar
información, sin que sea necesario entender su contenido.
• Nivel de comprensión. El estudiante puede entender y
explicar el significado de la información recibida.
• Nivel de aplicación. El estudiante puede seleccionar y
utilizar datos y métodos para solucionar una tarea o
problema.
• Nivel de análisis. El estudiante puede distinguir,
clasificar y relacionar hipótesis y evidencias de la
información dada, así como descomponer un problema
en sus partes.
• Nivel de síntesis. El estudiante puede generalizar ideas y
aplicarlas para solucionar un nuevo problema.
• Nivel de evaluación. El estudiante puede comparar,
criticar y evaluar métodos o soluciones para solucionar
un problema.
ISSN 1932-8540 © IEEE
214
Si buscamos objetivos de aprendizaje para las distintas
técnicas de diseño de algoritmos, encontramos que todas ellas
buscan los niveles de comprensión de la técnica y de análisis
del comportamiento de los algoritmos desarrollados. Sin
embargo, también encontramos diferencias entre las distintas
técnicas. En concreto, en los algoritmos voraces, juegan el
papel principal los niveles de aplicación (de patrón de código
de muy alto nivel), síntesis (de demostración de optimidad y
de programación del algoritmo) y evaluación (de estrategias
alternativas).
Conviene comentar una dificultad adicional. Los algoritmos
voraces se basan en unos conceptos comunes y un patrón de
alto nivel. Sin embargo, sus códigos fuentes son tan distintos a
dicho patrón que resultan irreconocibles como instancias del
mismo. La visualización de cada algoritmo voraz también es
particular del mismo [3]. En consecuencia, propusimos diseñar
una familia de asistentes, cada uno dedicado a un problema
voraz diferente.
Cada asistente debe ayudar en los siguientes niveles
educativos:
• Comprensión. El alumno comprenderá el problema
planteado y el algoritmo voraz que lo resuelve. El
algoritmo será independiente de la estrategia voraz
elegida (es decir, del criterio de selección de los
candidatos), por lo que puede contener fragmentos de
pseudocódigo.
• Análisis. El alumno analizará el efecto de aplicar a unos
datos de entrada el mismo algoritmo voraz, pero con
diversas estrategias voraces.
• Evaluación. El alumno evaluará el efecto de cada
estrategia voraz y seleccionará (empíricamente) la
óptima.
Obsérvese que la selección de la estrategia óptima se realiza
a partir de los resultados obtenidos experimentalmente. A
pesar de esta evidencia empírica, la optimidad de la estrategia
correspondiente sólo puede afirmarse tras su demostración
formal, que se realizará sin la ayuda del asistente.
III. DESCRIPCIÓN DE LOS ASISTENTES INTERACTIVOS
AMO y SEDA se han diseñado para ayudar al aprendizaje
de los problemas de la mochila [9] y de la selección de
actividades [11], respectivamente. La mayor parte de sus
características son comunes. Sin embargo, SEDA se desarrolló
tras AMO, por lo que contiene algunas mejoras introducidas
tras una sesión de evaluación de usabilidad de AMO. Al estar
más avanzado, comenzamos presentando SEDA, para exponer
después las características específicas de AMO.
A. Descripción de SEDA
Podemos definir informalmente el problema de selección de
actividades de la siguiente manera [11]. Dado un conjunto de n
actividades, cada una con un instante de comienzo ci y un
instante de fin fi, deseamos seleccionar un subconjunto de
máximo tamaño de actividades que no se solapen.
Por ejemplo, dado el conjunto de actividades de la Tabla I,
el subconjunto compuesto por las actividades {0,6,9} es una
solución válida, mientras que el subconjunto {2,7,6,3} es una
solución de tamaño máximo.
TABLA I.
UN EJEMPLO DEL PROBLEMA DE SELECCIÓN DE ACTIVIDADES
i
0
1
2
3
4
5
6
7
8
9
si
1
9
28 11
7
6
19 24
28 23
fi
14
17
29 15 14
26 23 28
29 30
La Fig. 1 muestra el aspecto de la interfaz de usuario de
SEDA. Se distinguen claramente tres zonas, aparte del menú
principal y la barra de iconos. En la parte superior se encuentra
el panel del problema, que muestra gráficamente los datos de
entrada (en la figura, tras ejecutar el algoritmo para el ejemplo
anterior). En la parte inferior izquierda se encuentra el panel
de teoría. Consta de dos pestañas: la pestaña del problema
contiene su enunciado, y la del algoritmo (visible en la figura),
su codificación en Java. Finalmente, la parte derecha contiene
el panel de resultados, que a su vez contiene las pestañas de
datos de entrada y de resultados (visible).
Fig. 1. Interfaz de usuario de SEDA.
El usuario puede consultar el enunciado del problema y el
código del algoritmo voraz en cualquier momento. Sin
embargo, sólo podrá usar el resto de funciones de SEDA tras
introducir datos de entrada. Entonces, SEDA muestra
gráficamente los datos en el panel del problema.
A partir de este momento, el usuario puede seleccionar una
estrategia voraz y ejecutar el algoritmo según el orden de
selección dado por ésta. SEDA ofrece 9 estrategias:
• Aleatoria.
• Índice de la actividad en orden creciente/decreciente.
• Comienzo de la actividad en orden creciente/decreciente.
• Fin de la actividad en orden creciente/decreciente.
• Duración de la actividad en orden creciente/decreciente.
ISSN 1932-8540 © IEEE
VELÁZQUEZ ITÚRBIDE et al.: ASISTENTES INTERACTIVOS PARA APRENDIZAJE DE ALGORITMOS...
215
Fig. 2. Visualización de actividades en SEDA en orden decreciente de comienzo.
Fig. 3. Visualización de actividades en SEDA en orden decreciente de duración.
Fig. 4. Tabla de evaluación de las estrategias en SEDA.
SEDA visualiza las actividades en formato bidimensional
sobre un eje temporal horizontal. La visualización muestra
tantas filas como actividades hay. Cada actividad se representa
mediante una barra comprendida entre los instantes de
comienzo y fin.
Las actividades se colorean con tonos según la estrategia
voraz seleccionada, correspondiendo los tonos más oscuros a
las actividades que antes se seleccionarán con dicha estrategia.
Obsérvese que un número alto de objetos producen un
problema visual ya que las personas somos incapaces de
distinguir una gama de tantos tonos. Para que las
visualizaciones (y el propio ejemplo) sean manejables, SEDA
impone la restricción de un máximo de 12 actividades e
instantes comprendidos entre 0 y 30.
La Fig. 2 muestra el mismo ejemplo que la Fig. 1 (es decir,
las diez actividades de la Tabla I según la estrategia de orden
decreciente de comienzo), pero al comienzo de la ejecución.
Obsérvese que la primera actividad en ser seleccionada será la
tercera (situada en la parte superior derecha), mientras que la
de la fila primera será la última.
La Fig. 3 muestra las mismas actividades reordenadas
(recoloreadas) en orden decreciente de duración.
Una vez seleccionada una estrategia, el usuario puede
ejecutar y animar el algoritmo mediante dos controles: paso a
paso o de forma completa. En el primer caso, el usuario puede
observar cómo se seleccionan actividades iteración tras
iteración según la estrategia activa. Cada actividad
seleccionada se colorea de gris si es válida (indicando que no
puede volver a seleccionarse) o de rojo si es inválida (es decir,
si se solapa con alguna seleccionada antes). El usuario también
puede retroceder la animación para volver a examinar los
pasos anteriores.
El beneficio producido por las distintas estrategias se
muestra en la tabla del panel de resultados. La Fig. 4 muestra
dicha tabla tras aplicar 5 estrategias con los datos de entrada
de las figuras anteriores. Cada fila contiene, de izquierda a
derecha, columnas con la estrategia, el valor asignado a cada
actividad, las actividades seleccionadas y valor de la función
objetivo (en este problema, número de actividades). La tabla
permite ordenar sus filas según la columna de número de
actividades, conociendo inmediatamente las estrategias con
mejor resultado.
SEDA es un sistema sencillo, con sólo algunas facilidades
más. El usuario puede introducir datos de entrada por teclado,
generarlos aleatoriamente o leerlos de un fichero; también
puede modificarlos interactivamente. Las visualizaciones
individuales y las animaciones pueden almacenarse en ficheros
de formatos gráficos estándar. La tabla de resultados puede
exportarse en formato de texto. Por último, puede
seleccionarse el idioma de la aplicación (español e inglés).
ISSN 1932-8540 © IEEE
216
Fig. 5. Visualización de los objetos y la mochila en AMO.
Fig. 6. Tabla de evaluación de las estrategias en AMO.
Hagamos un resumen de las principales características de
SEDA agrupadas por los objetivos educativos que soporta:
• Nivel de comprensión. Está soportado por el panel de
teoría (con sus pestañas de problema y de algoritmo). A
su vez, las funciones de entrada de datos, selección de
estrategia y avance/retroceso de la animación facilitan
que el alumno analice el comportamiento del algoritmo
con cada estrategia.
• Nivel de análisis. Está soportado por las visualizaciones
y la animación del panel del problema. La representación
gráfica facilita identificar los límites de las actividades y
sus solapamientos. Además, los tonos facilitan
determinar el orden de selección de las actividades y el
gris, descartar las ya consideradas. Los controles de
avance/retroceso de la animación facilitan el análisis
temporal de cada estrategia. Por último, la tabla de
resultados permite conocer fácilmente el efecto de cada
estrategia y analizarla de forma resumida.
• Nivel de evaluación. Está soportado por la tabla de
resultados. Su examen permite conocer qué estrategias
maximizan el número de actividades y sus diferencias.
Obsérvese que el soporte a un nivel refuerza el apoyo a otros.
Por ejemplo, el soporte al análisis favorece la evaluación.
B. Uso Educativo
En general sugerimos el siguiente método de trabajo:
1. Leer el problema y el algoritmo incluidos.
2. Introducir datos de entrada.
3. Seleccionar diversas estrategias y ejecutar el algoritmo,
analizando el efecto de utilizar cada una.
4. Evaluar el resultado de las distintas estrategias para
determinar la óptima.
Para el paso 2, cada fuente de entrada tiene sentido en
situaciones distintas: el teclado se usa para introducir un
ejemplo concreto, el azar para crear un ejemplo rápidamente y
los ficheros para reproducir ejemplos concretos o de tamaño
grande.
Es muy probable que varias estrategias produzcan el mismo
resultado para unos datos de entrada. Por tanto, rara vez se
seguirá linealmente el método propuesto y habrá que repetir
los pasos 2-4 varias veces, cada vez con datos nuevos.
C. Descripción de AMO
AMO es igual que SEDA, salvo en detalles propios del
problema abordado, como la visualización de los datos, las
estrategias, el formato de la tabla de resultados y otros detalles
menores (p.ej. el diálogo de entrada de datos). Además, debido
a las fechas de desarrollo, AMO carece de algunas funciones
de SEDA.
Comencemos por enunciar el problema de la mochila [12].
Sea una mochila de capacidad c y n objetos, tales que la suma
de todos sus pesos excede la capacidad de la mochila. Cada
objeto i, 0≤i≤n-1, tiene un peso pi y un beneficio asociado bi.
Cada objeto puede partirse, de forma que si se introduce una
fracción xi en la mochila, se consigue la parte proporcional de
su beneficio xi·bi. El objetivo consiste en llenar la mochila de
forma que se maximice el beneficio conseguido.
Por ejemplo, sea una mochila de capacidad c=162 y siete
objetos con pesos {90,74,31,42,59,56,14} y beneficios
{72,66,21,8,100,27,26}. Si introducimos los objetos en la
mochila en orden creciente de peso, caben enteros los objetos
2,3,5,6 y 19/59 del objeto 4, produciendo un beneficio
114’203. En cambio, si seleccionamos los objetos en orden
decreciente de la tasa beneficio/peso, se introducen enteros los
objetos 1,4,6 y 15/90 del objeto 0, produciendo el beneficio
máximo 204.
Las visualizaciones de AMO muestran los objetos y la
mochila. Los objetos se muestran en formato vertical, de
manera que el ancho es proporcional a su peso y la altura a su
beneficio. Asimismo, la mochila es un recipiente de anchura
proporcional a su capacidad (en peso). La Fig. 5 ilustra estas
ISSN 1932-8540 © IEEE
visualizaciones para el ejemplo anterior. Como en SEDA, los
candidatos exhiben distintos tonos de color según la estrategia
voraz seleccionada y los candidatos ya seleccionados se
presentan en gris.
Para que los problemas y las visualizaciones sean
manejables, AMO impone la restricción de un máximo de 10
objetos. Por otro lado, AMO ofrece 11 estrategias:
• Aleatoria.
• Índice en orden creciente/decreciente.
• Beneficio en orden creciente/decreciente.
• Beneficio/peso en orden creciente/decreciente.
• Peso en orden creciente/decreciente.
• Peso/beneficio en orden creciente/decreciente.
La última diferencia destacable es el formato de la tabla de
resultados. En AMO consta de cinco columnas. Las columnas
primera, segunda y última son iguales que en SEDA:
estrategia, valores de selección y valor de la función objetivo
(en el caso de la mochila, el beneficio conseguido). Las
columnas tercera y cuarta contienen, respectivamente, el orden
de selección de los objetos y el porcentaje introducido de cada
uno. La Fig. 6 muestra una tabla para los datos del ejemplo.
IV. EVALUACIÓN DE LOS ASISTENTES INTERACTIVOS
Hemos realizado diversas evaluaciones de ambos asistentes,
cuya organización y resultados presentamos en este apartado.
A. Diseño y Evaluaciones de Experto
El diseño de ambos asistentes ha sido una tarea laboriosa,
especialmente de AMO, que fue el desarrollado en primer
lugar. Se realizó un primer diseño de la interfaz de usuario
para dar soporte a los objetivos educativos. Este primer diseño
ya incluía el formato de visualización, que es una mejora del
propuesto en Sedgewick [9]. Posteriormente, fueron
realizándose evaluaciones de experto para garantizar la
usabilidad, coherencia y calidad de la interfaz. En total, se
realizaron cinco evaluaciones de experto.
El desarrollo de SEDA fue similar, con la ventaja de que se
basó en AMO. En consecuencia, sólo se realizaron dos
evaluaciones de experto. La visualización es una
simplificación de la ilustración encontrada en Cormen,
Leiserson y Rivest [11], que consigue el mismo efecto gracias
a la dimensión del tiempo en la animación.
B. Protocolo de Sesiones de Evaluación
Se han realizado dos evaluaciones experimentales con
usuarios finales. La sesión de evaluación de AMO se realizó
en enero de 2008 en la asignatura troncal “Diseño y Análisis
de Algoritmos”, de tercer curso de Ingeniería Informática.
Participaron 40 alumnos. La sesión de SEDA se realizó en
mayo de 2008 en la asignatura optativa “Estructuras de Datos
y Algoritmos Avanzados”, también de tercer curso de
Ingeniería Informática. Participaron 11 alumnos. Ambas
sesiones se integraron en una sesión de laboratorio.
Cada sesión duró dos horas. Los alumnos se descargaron de
la web de la asignatura (con la que ya estaban familiarizados)
217
todo el material necesario para realizarla: enunciado, asistente
y modelo de informe. Además, se les entregó en papel un
cuestionario de opinión sobre el asistente. El cuestionario
constaba de preguntas abiertas y preguntas tipo test, con
valores en una escala de Linkert de 1 (muy mala) a 5 (muy
buena).
El enunciado de la práctica contenía la especificación del
problema y una breve descripción del asistente a evaluar. Se
pedía que realizaran tres tareas:
1. Utilizar el asistente para determinar una estrategia óptima
entre las ofrecidas por el asistente.
2. Rellenar y entregar electrónicamente un breve informe,
siguiendo el modelo proporcionado. Su estructura era muy
sencilla: estrategia seleccionada, justificación razonada y
ejemplos que proporcionan evidencia.
3. Rellenar y entregar por escrito el cuestionario de opinión
sobre el asistente.
En la primera sesión se les permitió realizar la práctica y
entregar el informe en parejas, pero el cuestionario debía ser
individual. En la segunda evaluación, todo el trabajo se realizó
individualmente.
En los apartados siguientes presentamos los resultados de
usabilidad y de eficacia obtenidos en estas sesiones.
C. Usabilidad de AMO
En Tabla II incluimos los resultados de las preguntas tipo
test sobre AMO. Omitimos la opinión sobre la calidad de
algunos elementos rutinarios de la interfaz de usuario.
TABLA II.
RESULTADOS DE LA EVALUACIÓN DE AMO
Pregunta
Fácil de usar
Ha ayudado a analizar el efecto de cada estrategia
voraz
Ha ayudado a identificar la estrategia óptima
Calidad general
Calidad de panel de datos de entrada
Calidad de panel de datos de salida
Calidad de pestaña de problema
Calidad de pestaña de código
Calidad de pestaña con datos de entrada
Calidad de pestaña con tabla de resultados
Calidad de introducción/generación de datos
Calidad de formato de almacenamiento
En conjunto ha gustado
4’54
Desv.
típica
0’64
4’20
0’99
4’55
4’19
4’05
4’28
3’60
3’80
4’03
4’18
4’30
3’48
4’25
0’75
0’95
0’88
0’85
1’03
0’94
0’92
1’01
0’76
1’01
0’87
Media
La facilidad de uso de AMO obtuvo una calificación media
de 4’54, resultado de ser calificada de buena o muy buena por
parte de 36 alumnos, neutral por parte de 3 y una respuesta en
blanco.
Esta opinión se corrobora con la falta de preguntas durante la
sesión. Asimismo, 36 respuestas abiertas no citaron ningún
aspecto de difícil uso o elogiaron su sencillez de uso. Las
cuatro críticas recibidas son: incomprensión de algunos iconos,
formato de la tabla de resultados, imposibilidad de suprimir
filas en la tabla de resultados y falta de una función para
ejecutar todas las estrategias.
ISSN 1932-8540 © IEEE
218
Preguntados sobre su utilidad tanto para analizar el efecto de
seleccionar cada estrategia como para identificar la estrategia
óptima, hubo un consenso en su utilidad alta o muy alta. Con
respecto al análisis de cada estrategia, solamente 4 la
calificaron de forma neutral y 2 de muy mala. Con respecto a
la identificación de la estrategia óptima, el resultado fue aún
mejor: sólo 2 respuestas la calificaron de mala.
En cuanto a su calidad general para analizar el efecto de
distintas estrategias, la media de AMO fue de 4’19, con sólo
una respuesta neutral y dos muy malas; hubo 4 respuestas en
blanco.
Se obtienen resultados similares sobre la calidad de
elementos concretos. La mayor parte de las opiniones fueron
buenas o muy buenas (297 de 400, frente a 66 respuestas
neutrales y 37 negativas). Como puede observarse en Tabla II,
los aspectos mejor valorados fueron la visualización de la
mochila, los diálogos de entrada de datos y la pestaña de
resultados. Por el contrario, los peor valorados fueron las
pestañas de problema y código y el formato de
almacenamiento en fichero.
Por último, AMO gustó bastante o mucho a casi todos los
alumnos, salvo a uno neutral, a otro que le gustó poco y a otro
nada; hubo 4 respuestas en blanco.
Recurrimos a las respuestas abiertas para tener su opinión
detallada sobre los aspectos positivos y negativos de AMO.
Los elementos que más comentaron haberles gustado fueron el
diseño de visualización de los datos, la tabla de evaluación y el
almacenamiento de datos en fichero.
También encontramos algunas respuestas que muestran que
no se ha comprendido la utilidad o el formato de algunas
funciones, por lo que deberán explicarse mejor en el futuro:
• Formato de almacenamiento de datos de entrada.
• Utilidad de la generación aleatoria y la lectura de fichero
de datos de entrada.
• Dinámica a seguir con el asistente.
• Dinámica de ejecución de distintas estrategias.
Sin calificarlos de negativos, algunos alumnos suprimirían
las siguientes funciones:
• La configuración del color de los objetos.
• Las pestañas de problema y de algoritmo.
También encontramos sugerencias de mejorar algunas
funciones:
• Facilitar el paso de una estrategia a la siguiente con un
icono específico.
• Mejorar la pestaña de problema, haciendo que
desaparezca tras la lectura inicial.
• Mejorar la pestaña de código, haciéndola interactiva
(p.ej. mostrando su ejecución paso a paso).
• Mejorar la calidad de la visualización: representación
gráfica, información de la ventana que emerge al situar el
ratón sobre un objeto, mayor número de colores de
configuración.
• Aumentar la flexibilidad del control de la animación,
permitiendo que una estrategia pueda ejecutarse varias
veces o permitiendo pasos hacia atrás.
• Revisar el formato de la tabla de evaluación y añadir
operaciones: suprimir filas, y que al situarse sobre una
fila, se muestre el resultado de su estrategia asociada.
• Revisar el formato de almacenamiento en fichero de la
tabla de evaluación.
• Explicar los menús y las estrategias.
• Incluir más formatos de almacenamiento en fichero,
compatibles con presentaciones (DOC, RTF, PDF).
• Cuestiones menores de comprensión (iconos) o
coherencia de la interfaz.
Por último, hay sugerencias para añadir funciones nuevas:
• Exportación de visualizaciones.
• Función de ejecución de varias o todas las estrategias.
• Identificación final y justificación de la estrategia óptima.
• Asistente más genérico para algoritmos voraces.
Algunas de estas sugerencias se recogieron durante el
desarrollo de SEDA:
• Se simplificó el control de animación.
• Se flexibilizó el control de la animación, permitiendo que
una estrategia pueda ejecutarse varias veces, que la
ejecución retroceda o incluso que se abandone.
• Se añadieron varias facilidades sobre la tabla de
evaluación: operación de suprimir una fila y que, al
seleccionar una fila, se visualice el resultado de ejecutar
su estrategia asociada.
• Se añadió la facilidad de exportar a un fichero la
visualización presente en pantalla.
Por último, y para facilitar su uso académico, se
internacionalizó la interfaz de usuario. El usuario puede
seleccionar inglés o español como idioma de interacción. Su
extensión a otros idiomas es sencilla puesto que sólo hay que
incorporar los textos de la interfaz en un fichero.
D. Usabilidad de SEDA
En Tabla III incluimos los resultados de las preguntas tipo
test sobre SEDA. Omitimos la opinión sobre la calidad de
algunos elementos rutinarios de la interfaz de usuario.
TABLA III.
RESULTADOS DE LA EVALUACIÓN DE SEDA
Pregunta
Fácil de usar
Ha ayudado a analizar el efecto de cada estrategia
voraz
Ha ayudado a identificar la estrategia óptima
Calidad general
Calidad de panel de visualización de datos
Calidad de pestaña de problema
Calidad de pestaña de código
Calidad de pestaña con datos de entrada
Calidad de pestaña con tabla de resultados
Calidad de introducción/generación de datos
Calidad de formato de almacenamiento
En conjunto ha gustado
4’64
Desv.
típica
0’50
4’50
0’53
3’60
4’00
4’18
3’91
4’09
4’18
4’18
4’45
4’00
4’27
0’84
0’67
0’98
0’70
0’83
0’87
0’87
0’69
1’18
0’47
Media
La facilidad de uso de SEDA obtuvo una calificación de
buena o muy buena por parte de todos los alumnos. Al igual
ISSN 1932-8540 © IEEE
que en AMO, esta opinión se corrobora con la falta de
preguntas durante la sesión. Además, tres de los 11 alumnos
citaron la facilidad de uso entre los aspectos positivos de
SEDA. Solamente un alumno citó un elemento de difícil uso:
distinguir los tonos de las distintas actividades.
Preguntados sobre su utilidad concreta para analizar el
efecto de seleccionar cada estrategia, hubo un consenso en su
utilidad alta o muy alta para analizar el efecto de cada
estrategia. Sin embargo, no la veían tan útil para identificar la
estrategia óptima, ya que 6 consideraban que les había
ayudado bastante o mucho, 3 que les había ayudado regular y
uno que le había ayudado poco.
En cuanto a su calidad general para analizar el efecto de
distintas estrategias, la media de SEDA fue de 4’00, con sólo
dos respuestas neutrales. Se obtienen resultados similares
sobre la calidad de elementos concretos. La mayor parte de las
opiniones fueron buenas o muy buenas (79 de 99). Sólo hubo
dos opiniones negativas, sobre una característica secundaria: el
formato del fichero donde se guarda la tabla de evaluación. La
puntuación más alta se concede a los diálogos de generación
de datos de entrada.
Por último, SEDA gustó bastante o mucho a todos los
alumnos.
De nuevo, recurrimos a las respuestas abiertas para tener su
opinión detallada sobre los aspectos positivos y negativos de
SEDA. Los elementos que más les gustaron fueron:
• El diseño de visualización de los datos.
• La tabla de evaluación.
• El almacenamiento de datos en fichero.
También encontramos algunas respuestas que muestran que
no se ha comprendido la utilidad o el formato de algunas
funciones, por lo que deberán explicarse mejor en el futuro:
• Función para almacenar los datos de entrada.
• Posibilidad de ordenar la tabla de resultados según el
número de actividades.
Sin calificarlos de negativos, algunos alumnos suprimirían
las siguientes funciones:
• La configuración del color de los objetos.
• La pestaña con datos de entrada, por redundante.
También encontramos algunas sugerencias de mejora:
• Ampliar el número máximo de actividades y su duración
(ahora son 10 y 20, respectivamente).
• Mejorar la calidad de la visualización: aumentar el
contraste de tonos, reforzar los tonos con índice del
orden de selección de candidatos, mostrar el tiempo
ocupado por las actividades seleccionadas.
• Destacar la estrategia seleccionada.
• Revisar el formato de la tabla de evaluación y el nombre
dado a sus columnas (p.ej. “valores de selección”).
• Revisar el formato de almacenamiento en fichero de la
tabla de evaluación.
• Incluir más formatos de almacenamiento en fichero
(texto, XML, Excel, compatibles con páginas web).
• Errores menores de coherencia o eficiencia.
Por último, hay sugerencias para añadir funciones nuevas:
219
• Edición visual de los datos de entrada.
• Función de ejecución de todas las estrategias.
• Comparación de los resultados de distintos datos de
entrada.
E. Resultados de Eficacia
Ambas sesiones se realizaron en una clase de prácticas. En
ambos casos, la práctica planteada era sencilla, supuesto que
se comprenden los fundamentos de los algoritmos voraces.
En la sesión con AMO se permitió que entregaran el
informe en el plazo de una semana, por lo que lo entregaron
más alumnos que los que participaron en la sesión. En total, se
entregaron 28 informes, 25 realizados en parejas y 3
individuales.
Los informes entregados obtuvieron la calificación de
sobresaliente en 6 casos, notable en 13, aprobado en 6 y
suspenso en 3. Los alumnos con sobresaliente identificaron
dos estrategias óptimas; su justificación era aceptable y la
evidencia se basaba en ejemplos ejecutados con bastantes
estrategias e ilustrados con volcados de la tabla de resultados o
con el fichero de resultados. Los alumnos con notable también
identificaron dos estrategias óptimas, pero apenas las
justificaron o evaluaron los ejemplos con pocas estrategias. Al
otro extremo, los suspensos ni incluían justificación ni sus
ejemplos estaban mínimamente desarrollados.
En conjunto puede observarse que AMO les ayudó a
realizar la práctica y que los alumnos fallaron en la parte no
soportada por AMO, es decir, la justificación de que una
estrategia es óptima.
En la evaluación de SEDA los alumnos entregaron el
informe al final de la sesión. Se obtuvieron 3 sobresalientes, 4
notables, 3 aprobados y 1 suspenso. Los alumnos con
sobresaliente eligieron dos estrategias equivalentes y óptimas
con justificación y respaldo empírico buenos. Los alumnos con
notable acertaron con ambas estrategias pero apenas las
justificaron o acertaron con solo una que estuvo correctamente
justificada. Los aprobados propusieron una estrategia
incorrecta junto a otra correcta, mientras que el suspenso
propuso una sola estrategia incorrecta (y confundía el sentido
de cada apartado).
V. CONCLUSIONES Y TRABAJOS FUTUROS
Hemos presentado dos asistentes interactivos para el
aprendizaje de algoritmos voraces. Se han presentado los
niveles educativos de la taxonomía de Bloom a los que están
orientados y las características desarrolladas para soportar
estos niveles. Ambos asistentes son análogos, pero SEDA
incluye algunas facilidades adicionales por haberse diseñado
tras la experiencia de AMO. También hemos presentado los
resultados de dos evaluaciones con usuarios finales realizadas
con ambos asistentes. Los resultados de usabilidad han sido
muy favorables y han permitido identificar bastantes mejoras.
Los resultados de eficacia también han sido positivos.
En la documentación científica sobre enseñanza de la
Informática encontramos numerosos sistemas de apoyo al
ISSN 1932-8540 © IEEE
220
aprendizaje de algoritmos. Sin embargo, apenas hemos
encontrado uno que tenga en cuenta las peculiaridades de los
algoritmos voraces, el sistema PathFinder [12]. Sus objetivos y
funciones difieren bastante de los nuestros, ya que se centran
en la comprensión de algoritmos correctos (en este caso, el
algoritmo de Dijkstra).
Conviene destacar que estos asistentes deben utilizarse de
forma adecuada. Por ejemplo, el profesor debe explicar las
características de los asistentes y el método de indagación
antes de su uso por los alumnos. El método de indagación es
especialmente importante porque conviene orientar al alumno
en su aprendizaje activo.
El uso de estos asistentes también plantea retos nuevos, que
no encontramos en ningún libro de texto. Por ejemplo, una
cuestión interesante es la existencia y descubrimiento de
estrategias equivalentes en estos problemas. Otra cuestión
interesante es el uso de resultados obtenidos empíricamente
como indicio, pero no como justificación de resultados
teóricos. Esta cuestión enlaza con la formación de los alumnos
en la experimentación y el método científico [13].
Durante el curso 2009-2010 se han utilizado ambos
asistentes. También se ha usado otro asistente, llamado
TuMisT [14], para el problema del árbol de recubrimiento de
coste mínimo (que incluye los algoritmos de Prim y Kruskal).
AMO y TuMisT los ha utilizado el profesor en el aula,
mientras que SEDA se ha usado para una sesión de prácticas
de laboratorio. Por otro lado, se están realizando la mayor
parte de las mejoras identificadas en los apartados IV.C y
IV.D. Finalmente, se está modificando SEDA para convertirlo
en un único asistente, llamado GreedEx, que soporte los tres
algoritmos voraces mencionados.
AGRADECIMIENTOS
Este trabajo se ha financiado con el proyecto TIN200804103/TSI del Ministerio de Ciencia e Innovación. Los
autores quieren agradecer el trabajo de Jesús Gila Blázquez y
Miriam Pablo García en el desarrollo respectivo de AMO y
SEDA, así como de Asunción Aldave Izaguirre en la
tabulación de los datos de las evaluaciones.
REFERENCES
[1]
[2]
[3]
[4]
[5]
T. Naps, G. Roessling, V. Almstrum, W. Dann, R. Fleischer, C.
Hundhausen, A. Korhonen, L. Malmi, M. McNally, S. Rodger, y J. Á.
Velázquez Iturbide, “Exploring the role of visualization and engagement
in computer science education”, SIGCSE Bulletin, vol. 35, no. 2, pp.
131-152, junio 2003.
C. Hundhausen, S. Douglas, y J. Stasko, “A meta-study of algorithm
visualization effectiveness”, Journal of Visual Languages and
Computing, vol. 13, no. 3, pp. 259–290, 2002.
L. Fernández Muñoz, y J. Á. Velázquez Iturbide, “Estudio sobre la
visualización de las técnicas de diseño de algoritmos”, en Actas del VII
Congreso Internacional de Interacción Persona-Ordenador,
Interacción 2006, pp. 315-324.
B. Bloom, E. Furst, W. Hill, y D. R. Krathwohl, Taxonomy of
Educational Objectives: Handbook I, The Cognitive Domain. AddisonWesley, 1956.
I. Hernán Losada, J. Á. Velázquez Iturbide, y C. A. Lázaro Carrascosa,
“Programming learning tools based on Bloom’s taxonomy: Proposal and
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
accomplishments”, en Proc. VIII International Symposium of
Computers in Education, SIIE 2006, pp. 325-334.
J. Á. Velázquez Iturbide, A. Pérez Carrasco, y J. Urquiza Fuentes,
“SRec: An animation system of recursion for algorithm courses”, en
Proc. 13rd Annual Conference on Innovation and Technology in
Computer Science Education, ITiCSE 2008, pp. 225-229.
J. Á. Velázquez Iturbide, A. Pérez Carrasco, y J. Urquiza Fuentes, “A
design of automatic visualizations for divide-and-conquer algorithms”,
Electronic 7otes in Theoretical Computer Science, no. 224, pp. 159167, enero 2009.
J. A. Gila Blázquez, “AMO: Asistente interactivo para el aprendizaje del
algoritmo de la mochila”, proyecto de fin de carrera, Universidad Rey
Juan Carlos, Móstoles, Madrid, España, 2008.
R. Sedgewick, Algorithms in Java, Addison-Wesley, 2002.
M. Pablo García, “SEDA: Asistente interactivo para el aprendizaje del
problema de selección de actividades”, proyecto de fin de carrera,
Universidad Rey Juan Carlos, Móstoles, Madrid, España, 2008.
T. H. Cormen, C. E. Leiserson, y R. L. Rivest, Introduction to
Algorithms. The MIT Press, 2ª ed., 2001.
M.G. Sánchez Torrubia, C. Torres Blanc, y M. A. López Martínez,
“PathFinder: A visualization eMathTeacher for actively learning
Dijkstra’s algorithm”, Electronic 7otes in Theoretical Computer
Science, no. 224, pp. 151-158, enero 2009.
P. Denning et al. “Computing as a discipline”, Communications of the
ACM, vol. 32, no. 1, pp. 9-23, enero 1989.
O. Debdi, y J. D. Granada, “Tutor interactivo para el aprendizaje del
algoritmo voraz del árbol de recubrimiento de coste mínimo”, proyecto
de fin de máster, Universidad Rey Juan Carlos, Móstoles, Madrid,
España, 2008.
J. Ángel Velázquez Iturbide es Licenciado en
Informática (1985) y Doctor en Informática (1990)
por la Universidad Politécnica de Madrid, España.
Ha sido profesor desde 1985 en la Facultad de
Informática de la Universidad Politécnica de Madrid.
En 1997 se incorporó a la Universidad Rey Juan
Carlos, donde actualmente es Catedrático de
Universidad y director del Laboratorio de Tecnologías
de la Información en la Educación (LITE). Sus áreas
de investigación son innovación docente y software
educativo para la enseñanza de la programación, visualización del software,
visualización de la información, e interacción persona-ordenador.
El Dr. Velázquez es miembro de IEEE Computer Society, ACM y ACM
SIGCSE. También es secretario de la Asociación para el Desarrollo de la
Informática Educativa (ADIE) y vocal de la Junta Directiva de la Asociación
Interacción Persona-Ordenador (AIPO).
Carlos A. Lázaro Carrascosa es Licenciado en
Informática (2000) por la Universidad Politécnica de
Madrid, España.
Desde 2001 es profesor de la Universidad Rey
Juan Carlos, donde actualmente es Profesor
Colaborador. Sus áreas de investigación son
innovación docente y software educativo para la enseñanza de la
programación, y procesamiento de señal de voz.
El Prof. Lázaro es miembro de la Asociación de Enseñantes Universitarios
de la Informática (AENUI).
Isidoro Hernán Losada es Licenciado en Ciencias
Físicas (1995) por la Universidad Complutense de
Madrid, España.
En 1997 se incorporó al Instituto de Automática
Industrial (CSIC) donde participó en el desarrollo de
varios proyectos de investigación. Desde 2000 es
profesor de la Universidad Rey Juan Carlos, donde
actualmente es Profesor Colaborador. Sus áreas de
investigación son innovación docente y software
educativo para la enseñanza de la programación
(informática educativa).
ISSN 1932-8540 © IEEE
221
V Congreso Iberoamericano de Telemática,
CITA 2009
Xabiel G. Pañeda, Member, IEEE, Álvaro Rendón, Member, IEEE
Editores invitados
Coimbra, mesas redondas y sesiones de pósters, que
confirieron al evento un ambiente muy propicio para el
intercambio científico y la cooperación tecnológica.
Title— Iberoamerican Congress in Telematics (CITA 2009)
Abstract— This editorial is an introduction of the special issue
composed with the best papers in e-learning of CITA2009
(Congreso Iberoamericano de Telemática). This congress was
organized in Gijón/Xixón, Asturies, España, in May of 2009. The
two selected papers are related with different matters of elearning, such as learning objects and system architecture. In this
editorial we introduce CITA 2009 and afterwards we summarize
the papers included in this special issue.
Index Terms—
education.
Educational
technology,
computers
&
I. INTRODUCCIÓN
D
URANTE los días 11 y 12 de Mayo del 2009, se celebró
en el Centro Cultural Antiguo Instituto de Gijón/Xixón
(Principado de Asturias, España) la cuarta edición del
Congreso Iberoamericano de Telemática (CITA 2009),
organizado por el Grupo de Redes y Servicios Telemáticos de
la Universidad de Oviedo, en colaboración con la Fundación
Universidad de Oviedo y con el patrocinio de un importante
grupo de empresas e instituciones.
Como en ocasiones anteriores, CITA 2009 fue un lugar de
encuentro que reunió a investigadores en los diferentes campos
relacionados con la telemática, tanto de la península Ibérica
como de los países de América de habla española y
portuguesa. Se expusieron trabajos de diferente índole y
aplicación, que iban desde temas relacionados con la
seguridad, hasta trabajos relacionados con la provisión de
servicios en zonas con escasez de redes de comunicaciones.
A lo largo del evento se complementaron las sesiones de
ponencias con conferencias plenarias, como la realizada por la
Doctora Marilia Curado, profesora de la Universidade de
Xabiel García Pañeda pertenece al Departamento de Informática,
Universidad de Oviedo, Campus de Viesques s/n, Gijón/Xixón 33203,
Asturies, España ([email protected]).
Álvaro Rendón Gallón pertenece al Departamento de Ingeniería
Telemática, Universidad del Cauca, Popayán, Cauca, Colombia
([email protected]).
II. LOS ARTÍCULOS
Dentro de los numerosos temas tratados en el congreso [1]
cabe destacar el de tele-educación, en el que se desarrollaron 4
sesiones configuradas en un “special track”. De todos los
artículos incluidos en esa área temática, un comité compuesto
por varios miembros del comité de programa y organizador ha
seleccionado dos artículos para ser incluidos en este número
especial de la revista IEEE-RITA. Los artículos son los
siguientes:
− LooKIng4LO, Sistema Informático para la extracción
automática de Objetos de Aprendizaje. Regina Motz,
Claudia Badell, Martín Barrosa, Rodolfo Sum, Gabriel
Díaz, Manuel Castro
−
Hacia una arquitectura para sistemas de e-learning basada
en PoELM. Roberto Pérez Rodríguez, Manuel Caeiro
Rodríguez, Luis Anido Rifón
En el primer artículo se presenta una herramienta capaz de
extraer objetos digitales de aprendizaje de forma automática a
partir de recursos educativos sin caracterizar ni etiquetar. El
principal objetivo de dicha herramienta es el de favorecer la
reutilización de numeroso material educativo existente y que
no puede ser incluido en bibliotecas de recursos por falta de
metainformación.
El segundo artículo presenta una propuesta de arquitectura
para dar soporte a la interoperabilidad de los sistemas de elearning, independientemente de las tecnologías de acceso
empleadas por los usuarios. Este proceso de colaboración
entre plataformas se formaliza utilizando el lenguaje PoEML.
III. PRÓXIMA EDICIÓN
Luego de su exitosa realización en tierras asturianas, CITA
regresa a América, donde tuvieron lugar las ediciones de
Cartagena (Colombia 2001), Mérida (Venezuela 2002),
Montevideo (Uruguay 2003), y Monterrey (México 2006). En
2011 tendrá lugar en Porto Alegre (Brasil), organizado por la
Universidade Federal do Rio Grande do Sul.
ISSN 1932-8540 © IEEE
222
AGRADECIMIENTOS
Queremos agradecer al editor de la revista, Martín Llamas
Nistal, la oportunidad de difundir una parte destacada de las
contribuciones de CITA2009 entre la comunidad ingenieril
iberoamericana. También resaltar el fantástico trabajo de los
miembros de los diferentes comités y de los revisores. Por
último mostrar nuestro agradecimiento a las empresas
(CajaAstur, Telecable) e instituciones (Ayuntamiento de
Gijón, IEEE, OBER, CESEI, Universidad de Oviedo,
Fundación Universidad de Oviedo, Asociación de Ingenieros
de Telecomunicación de Asturias) patrocinadoras del congreso
sin las cuales no hubiera sido posible el evento.
REFERENCIAS
[1]
R. García, J.M Santos, D. Melendi, y M. Caeiro (eds.), Congreso
Iberoamericano de Telemática. Gijón/Xixón, Asturies, España. 2009.
ISSN 1932-8540 © IEEE
Xabiel G. Pañeda (M’99) es Doctor e Ingeniero en
Informática y Profesor Titular de Universidad Interino del Área
de Ingeniería Telemática del Departamento de Informática de
la Universidad de Oviedo (España). Es miembro de diferentes
organizaciones, plataformas y comités de investigación como
el SYMM (Synchronized Multimedia) del W3C. Especialista
en servicios de audio/vídeo para Internet.
Álvaro Rendón Gallón (M’81) es Ingeniero Electrónico con
especialidad en Telecomunicaciones y Magíster en Telemática
por la Universidad del Cauca (Colombia), y Doctor Ingeniero
de Telecomunicación por la Universidad Politécnica de
Madrid (España). Es Profesor Titular del Departamento de
Telemática en la Facultad de Ingeniería Electrónica y
Telecomunicaciones (FIET) de la Universidad del Cauca,
donde además tiene a su cargo la coordinación de los
programas de Maestría y Doctorado en Ingeniería Telemática.
223
LooKIng4LO
Sistema Informático para la
extracción automática de Objetos de Aprendizaje
Caso de Estudio
Regina Motz, Claudia Badell, Martín Barrosa, Rodolfo Sum, Gabriel Díaz, Senior Member, IEEE, y
Manuel Castro, Fellow, IEEE
Title— LooKIng4LO. Information System for automatic
extraction of Learning Objects, a study case.
Abstract— Reducing the production costs associated with
digital materials in the e-Learning area is a imperative need.
One of the followed strategies is to build didactical materials as
modular and reusable components, called digital Learning
Objects (LO). Their most important advantage is their ability for
integrating easily with other more complex LO to build
didactical units or complete courses. In this work we present our
experience using the LookIng4LO tool, for the automatic
extraction of LO and show a general description of the tool. A
part of the experience was done for a course in Industrial
Communications *etworks, a subject in the third course of the
Industrial Technical Engineering career, in U*ED (Universidad
*acional de Educación a Distancia).
Index Terms — e-Learning, Learning Objects, Metadata
extraction and generation, *atural Language processing,
Ontology, SCORM, Semantic annotation.
I. INTRODUCCIÓN
L
OOKING4LO es un prototipo desarrollado en el
marco del Proyecto de Grado de la Facultad de
Ingeniería, UdelaR [1], que recibe como entrada
documentos no estructurados (pdf, texto, HTML y paquetes
SCORM [3]) y extrae información según un área temática y un
conjunto de componentes pedagógicos (definiciones, ejemplos,
ejercicios, etc.), empaquetándola en Objetos Digitales de
Aprendizaje (ODAs) [2]. El área temática se define a través de
una ontología y los componentes pedagógicos son modelados
con reglas para definir patrones de búsqueda. Además, el
Sistema genera metadatos que describen el contenido extraído
y el origen de dicha información. Los ODAS generados son
empaquetados utilizando el estándar SCORM.
Para que la reutilización de los ODAs pueda ser realizada
con criterios pedagógicos, estos deben ser extraídos de forma
que pertenezcan a tipos básicos de elementos pedagógicos,
entre los cuales se encuentran las definiciones, los ejemplos,
ejercicios, teoremas, demostraciones, etc. El estándar de
metadatos LOM [4] proporciona, entre sus atributos, estos
tipos de ODAs pero, sin embargo, encontramos que la exacta
definición de estos elementos es muy dependiente del área
temática del contenido del material.
Para entender el contexto de uso de la herramienta
Looking4LO comenzamos dando una descripción general de la
herramienta y analizando componentes pedagógicos y
metadatos extraíbles. Luego, a partir de la Sección IV,
analizamos la experiencia de su uso y, finalmente, en la
Sección V brindamos algunas conclusiones y líneas de trabajos
futuros.
II. VISIÓN GENERAL DEL SISTEMA LOOKING4LO
El sistema LookIng4LO [1] recibe como entrada un
conjunto de documentos no estructurados sobre los que realiza
la extracción de ODAs. Se basa en una representación
ontológica del área temática por la que interesa anotar la
información, y en la definición de un conjunto de
Componentes Pedagógicos (ejercicio, definición, ejemplo,
etc.) modelados a través de reglas. El resultado obtenido son
ODAs extraídos de los documentos de acuerdo a la
especificación de los Componentes Pedagógicos junto con un
conjunto de
metadatos que son generados de forma
automática.
En la Figura 1 se presenta un diagrama que contiene los
participantes del proceso de generación de ODAs con
metadatos.
R. Motz, C. Badell, M. Barrosa y R. Sum pertenecen a la Facultad de
Ingeniería de la Universidad de la República, Julio Herrera y Reissig 565,
Montevideo, Uruguay (email: [email protected], [email protected],
[email protected] y [email protected]).
G. Díaz y M. Castro pertenecen al Departamento de Ingeniería Eléctrica,
Electrónica y de Control de la UNED, C/Juan del Rosal nº 12, 28040,
Madrid, España (email: [email protected] y [email protected] ).
Fig. 1 – Visión General del Sistema Looking4LO
ISSN 1932-8540 © IEEE
224
Modelo Pedagógico se refiere a una abstracción que sirve
para modelar un curso. En el ámbito de la Pedagogía hay
involucrados conceptos más complejos que los utilizados en
este proyecto. En nuestro caso, se usa para identificar una
estructura formada por elementos que cumplen una función o
rol dentro de un curso, y llamamos Componentes
Pedagógicos a estos elementos. Es decir, el término
Componente Pedagógico se refiere a cualquier material,
texto en esta versión del prototipo, que cumpla una función
didáctica específica, como ser la definición de un concepto,
un ejercicio o problema para resolver, la demostración de un
teorema, etc. Por lo tanto, los Componentes Pedagógicos que
recibe el Sistema indican qué tipo de información se quiere
extraer sobre un tema particular, que está determinado por
otro parámetro, el dominio de interés.
Modelo de Dominio se refiere a un área temática de interés o
conocimiento. Su función consiste en definir cualquier objeto
o entidad que se quiera representar, y se utiliza para modelar
el tema sobre el que se busca generar ODAs. Temáticas de
interés pueden ser matemática, programación de
computadoras, historia, cocina o cualquier otra sobre la que se
quiera generar ODAs.
El Modelo de Dominio define qué tema se quiere buscar,
y los Componentes Pedagógicos qué es lo que se busca sobre
él. En el prototipo, los Componentes Pedagógicos son
modelados mediante un conjunto de reglas, y cada dominio
particular se modela a través de una ontología. Una ontología
es un modelo de datos que representa un dominio y se utiliza
para razonar sobre él. Según la W3C, “Una ontología define
los términos a utilizar para describir y representar un área de
conocimiento. Las ontologías son utilizadas por las personas,
las bases de datos, y las aplicaciones que necesitan compartir
un dominio de información (un dominio es simplemente un
área de temática específica o un área de conocimiento, tales
como medicina, fabricación de herramientas, bienes
inmuebles, reparación automovilística, gestión financiera,
etc.). Las ontologías incluyen definiciones de conceptos
básicos del dominio, y las relaciones entre ellos, que son
útiles para los ordenadores [...]. Codifican el conocimiento
de un dominio y también el conocimiento que extiende los
dominios. En este sentido, hacen el conocimiento
reutilizable”. [8]
Llamamos documento o fuente a cualquier elemento
digital que contenga material desde donde generar ODAs.
Dado que la variedad de fuentes posibles es muy amplia, se
diseñó el Sistema de forma que pueda evolucionar a nuevos
formatos y estrategias de extracción.
La salida de LookIng4LO es un conjunto de ODAs,
donde cada uno de ellos posee metadatos que indican, entre
otros, la temática relativa a la ontología de dominio utilizada,
y la correspondencia con algún componente pedagógico.
Existen muchas definiciones sobre ODAs. Según Wiley
(2000) un ODA es “cualquier recurso digital que pueda ser
reutilizado como soporte para el aprendizaje” y también los
define como “material educativo diseñado y creado en
pequeñas unidades con el propósito de maximizar el número
de situaciones educativas en las que pueda ser reutilizado”.
[6, 7]
Las principales características de un ODA son que se
trata de un objeto digital, que tiene un propósito educativo y
es auto-contenido y reutilizable. En el prototipo, un ODA es
modelado como un elemento que contiene texto, más una
estructura (árbol n-ario) de metadatos que lo describe. Cada
elemento de esta estructura de metadatos, tiene un nombre,
valor y un conjunto de elementos hijos del mismo tipo. Esta
estructura permite manejar metadatos definidos en formato
LOM y extensiones realizadas sobre esta.
En el prototipo, un ODA tiene cuatro conjuntos de
metadatos que clasifican esta información de acuerdo al
origen desde donde es obtenida:
• Fuente: metadatos disponibles a nivel de cada fuente o
recurso. Se refiere a la información asociada al archivo,
como autor, fecha de creación, etc. En el caso de un
paquete SCORM, también se refiere a los metadatos
disponibles en el archivo manifest; entre estos, se
distingue tres niveles: globales a todo el paquete,
asociados a los recursos y los que aplican
específicamente a un archivo contenido en un recurso.
• Generales: son generados automáticamente por el
Sistema y contienen información sobre el contenido del
documento, como el idioma.
• Específicos: generados automáticamente y son
específicos a un tipo de componente pedagógico. Pueden
existir diferentes tipos de metadatos específicos para cada
tipo de componente pedagógicos (ejercicios, ejemplos,
definiciones, etc.). Por ejemplo, nivel de interactividad
puede ser aplicado a un ejercicio pero no a una
definición, tiempo de lectura puede ser relevante para una
definición o ejemplo, pero tal vez no para un ejercicio.
• Externos: se añaden en forma manual por el usuario del
Sistema. Se asocian a todos los ODAs generados durante
la ejecución, y para estos, se debe proporcionar su
nombre y valor.
Esta clasificación de los metadatos permite mantener en
los ODAs toda la información disponible al momento de
realizar la extracción, en contrapartida con integrarla
utilizando alguna estrategia para resolver automáticamente los
conflictos encontrados. Sin embargo, hay una excepción con
los metadatos Fuente; cuando la fuente es un paquete
SCORM se obtienen los mismos integrando los tres niveles de
metadatos que este puede contener (generales del SCORM, a
nivel de recursos, a nivel de cada recurso). El algoritmo
asigna mayor prioridad a los metadatos más “cercanos” al
recurso, complementando estos con el nivel superior. Es
decir, en caso de conflicto, se mantiene el valor del nivel más
bajo, y donde no exista un metadato se lo toma del nivel
inmediato superior si está disponible en él. Por lo tanto, se
realiza una integración desde lo más general a lo más
específico, manteniendo lo específico en caso de conflicto.
En la Figura 2 se muestra un diagrama con la
clasificación de las cuatro agrupaciones de metadatos
definidos previamente cuando la Fuente es un paquete
SCORM.
ISSN 1932-8540 © IEEE
MOTZ et al.: LOOKING4LO: SIST. PARA EXTRACCIÓN AUTOMÁTICA DE OBJETOS DE APRENDIZAJE
225
[9], del año 2007 del Instituto de Computación de la Facultad
de Ingeniería, UdelaR, Montevideo, Uruguay.
El metadato específico nivel de interactividad aplica al
componente pedagógico ejercicio, y asocia un valor entero al
ODA. Este valor depende de si el ejercicio debe enviarse por
email, a un foro, news o no se requiere ninguna de estas
actividades para su resolución. El valor asignado según el
nivel de interactividad se basó en el análisis realizado en
proyecto ODA Asistente Pedagógico [9]. En la Tabla III se
muestra el valor asociado al nivel de interactividad según el
medio de contacto. En caso de no haber un medio de contacto
en el contenido del ejercicio, el valor asignado es cero.
TABLA III
NIVEL DE INTERACTIVIDAD
Fig. 2 – Clasificación de los metadatos de un ODA
En el centro de la Figura 2, se representa el texto de un
documento fuente que pertenece al paquete SCORM, y a su
derecha un “ODA” que contiene un segmento de dicho texto
(recuadro negro), que se corresponde a uno de los
componentes pedagógicos buscados.
El prototipo soporta metadatos multivaluados. Un
metadato es multivaluado cuando para un mismo metadato se
puede tener más de un valor posible. Por ejemplo, el metadato
autor es mutivaluado ya que un documento puede tener más
de un autor.
III. COMPONENTES PEDAGÓGICOS Y METADATOS
EXTRAÍBLES
En la Tabla I y la
Tabla II, se indican los Componentes Pedagógicos,
Metadatos
Específicos
y
Metadatos
Generales
implementados. El prototipo extrae un tipo de metadato
específico para cada uno de los componentes pedagógicos
implementados, y un tipo de metadato general, que aplica a
todos. La elección de estos metadatos fue arbitraria, ya que se
buscó mostrar la utilidad de la clasificación de metadatos
específicos y generales, e implementar su extracción para
demostrar su factibilidad. Extender y/o incorporar nuevos
metadatos generales/específicos implica implementar nuevas
reglas.
TABLA I
COMPONENTES PEDAGÓGICOS Y METADATOS ESPECÍFICOS EXTRAÍBLES
Componente Pedagógico
Definición
Ejemplo
Ejercicio
Metadatos Específicos
tiempo de lectura
tiene imagen
nivel de interactividad
TABLA II
METADATOS GENERALES EXTRAÍBLES
Metadatos Generales
Autor
El metadato específico tiempo de lectura aplica al
componente pedagógico definición, y es una estimación del
tiempo que requiere leer el contenido del ODA. Se calcula
contabilizando la cantidad de palabras del contenido del
ODA, dividido por una constante. La constante por la que se
divide es 200. La elección de este valor se basa en el análisis
realizado en el Proyecto de Grado ODA Asistente Pedagógico
Medio de contacto
Email
News
Foro
Valor de interactividad (1-10)
5
8
9
El metadato específico tiene imagen aplica al componente
pedagógico ejemplo, y asocia un valor booleano, que es
verdadero en caso que el ODA contenga una imagen o figura
como parte de su contenido, falso en caso contrario. Este
último metadato se implementa en forma parcial ya que el
prototipo solo extrae texto, pero se identifica si dentro del
texto original se encuentra una imagen.
Autor es un metadato general, es decir, se busca a nivel de
todo el documento y no solo en el contenido de un tipo de
componente pedagógico particular. Estos metadatos aplican a
todos los ODAs que se extraen. Cuando se identifica el ó los
autores de un documento, se extrae también el correo
electrónico y página web de cada autor en caso de que esta
información esté disponible junto al nombre del autor.
IV. CASO DE ESTUDIO
En esta sección se muestran los resultados obtenidos de la
evaluación sobre el prototipo. Se comenzará por presentar la
configuración del Sistema al realizar las pruebas, luego se
muestran los resultados de la evaluación, y finalmente se
incluye las conclusiones alcanzadas en base a la información
obtenida.
A. Ontología del Dominio
Como se mencionó previamente, se debe proveer al
Sistema con una ontología que modele el área temática sobre
la que se va a extraer información. Se construyó una ontología
sencilla sobre Redes de Comunicaciones que abarca los
principales conceptos del tema.
En la Figura 3 se muestra el diagrama que representa la
ontología de prueba sobre Redes de Comunicaciones.
B. Fuentes
Se seleccionó un conjunto de archivos de prueba de
diferentes formatos, que tratan sobre Redes de
Comunicaciones. Uno de estos archivos es un Trabajo de
doctorado de la UNED [5] que introduce el tema de Redes
Comunicaciones, por lo que contiene “material de buena
calidad” para la extracción, teniendo en cuenta redacción y
contenido. Además se incluyeron ejercicios, exámenes y otros
ISSN 1932-8540 © IEEE
226
documentos, obtenidos de Internet, abarcando los diferentes
formatos que soporta el prototipo.
Previo a la ejecución de las pruebas, se analizó
manualmente la muestra de documentos para determinar en
cada uno, donde se encuentra la información que se
corresponde a una definición, ejercicio o ejemplo. Además, se
identificó cuales de los metadatos que el prototipo puede
extraer, se encontraban en cada documento.
C. Extracción de Componentes Pedagógicos
Como se mencionó en la Sección II, el prototipo identifica
los segmentos de texto donde se trata información relevante
para su extracción. El conjunto de componente pedagógicos
incluidos en la prueba, así como los metadatos que se deben
generar, están descritos en la Sección III.
concepto buscado no se encontraba en la ontología, o no se
definieron reglas que permitieran detectar el componente
pedagógico. Los falsos positivos corresponden a texto que
tiene el mismo patrón que los diseñados para detectar
componentes, pero que en realidad no se trata sobre los
componentes buscados.
En la Tabla IV se presentan los resultados
correspondientes al Componente Pedagógico definición. En la
columna Fuente se listan los nombres de los archivos de
entrada; a continuación el formato del archivo y luego los
resultados esperados y obtenidos.
TABLA IV
RESULTADOS EN LA EXTRACCIÓN DE DEFINICIONES
La columna Cantidad Esperada indica cuantas
definiciones se encontraron de forma manual en el
documento. Cantidad Detectada indica el número de ODAs
efectivamente generados, y la suma con los valores debajo de
las columnas Cantidad no Detectada coincide con la primera.
En los casos en que el Sistema genera un ODA que no
corresponde (falso positivo), este valor se declara en la última
columna.
Las tablas para ejemplos y ejercicios contienen la misma
información. A continuación, en la Tabla V, se presentan los
resultados en la extracción de Ejemplos.
TABLA V
RESULTADOS EN LA EXTRACCIÓN DE EJEMPLOS
Fig. 3 – Ontología de prueba: Redes de Comunicaciones
Los resultados se presentan en tablas, que incluyen los
valores esperados y obtenidos para cada archivo de entrada.
Se utilizó una tabla para cada tipo de componente pedagógico.
Además, se indica la cantidad de falsos positivos, así como la
razón por la que no se detectaron algunos componentes
pedagógicos. Los errores por no detección de componentes
pedagógicos se clasifican por dos razones posibles: el
En la Tabla VI se presentan los resultados en la
extracción de Ejercicios.
ISSN 1932-8540 © IEEE
TABLA VI
RESULTADOS EN LA EXTRACCIÓN DE EJERCICIOS
227
se incluyen varios casos que permiten dar una primera
evaluación sobre esta capacidad.
Para los metadatos específicos, la información que se
registró es diferente, ya que cada metadato contiene
información que es “local” a una ODA, y a su vez, cada tipo
de componente pedagógico puede tener sus metadatos
específicos particulares.
En la Tabla VIII se presentan los resultados obtenidos en
la generación de metadatos específicos.
TABLA VIII
RESULTADOS EN LA GENERACIÓN DE METADATOS ESPECÍFICOS
D.
Extracción de Metadatos Generales y Específicos
A continuación, se presentan los resultados en la
generación de metadatos que forman parte de los ODAs. Esta
información está separada de acuerdo a la clasificación y
alcance de los metadatos. Por un lado, autor, como
representante de los Metadatos Generales que aplican a todos
los ODAs extraídos de un mismo documento; y por otro, los
Metadatos Específicos que están asociados a un tipo de
componente pedagógico. El alcance de estos últimos es local
a cada ODA. Como metadatos específicos se tiene, tiempo de
lectura para las definiciones, tiene imagen para ejemplos y
nivel de interactividad para los ejercicios.
La extracción de la información sobre el/los autores se
hace sobre todo el contenido del documento. En la muestra
utilizada para las pruebas, la mayoría de los documentos no
incluía el autor como parte de su contenido. Esto se representa
con un 0 en la columna Esperados. En los casos en que se
cuenta con el nombre del/los autores del documento, el valor
esperado es el número de ODAs que contienen la información
de sus autores (de todos los tipos de ODAs). La columna
Encontrados indica cuantos de estos ODA contienen el
metadato con la información correcta. En la Tabla VII se
presentan los resultados para la extracción del metadato
general autor.
TABLA VII
RESULTADOS EXTRACCIÓN DE AUTOR
El metadato tiempo de lectura, tiene dos columnas, la
primera muestra el número de metadatos que fueron extraídos
con valor correcto; y la segunda, indica la cantidad de
incorrectos. La suma de ellos, coincide con el total de ODAs
extraídos del tipo definición.
Para el metadato ejemplo, en la primer columna se indica
cuantos ODAs de éste tipo contienen imágenes, y en la
segunda, cuantos tienen el metadato con la información
correcta.
El metadato nivel de interactividad de un ejercicio
depende de si éste debe ser enviado por mail, a un foro, news
o si el alumno simplemente debe realizarlo como práctica. A
todos los ODAs del tipo ejercicio, se les asocia un metadato
con su nivel de interactividad. La columna Esperados indica
la cantidad de ODAs de tipo ejercicio que han sido extraídos,
y la columna Encontrados indica el número de estos ODAs
que tienen el metadato con el valor correcto.
E.
Nótese que el foco en la selección de los archivos de la
muestra está orientado hacia la variedad de formatos de
archivo y componentes pedagógicos, y no tanto, para evaluar
la capacidad de generación de metadatos. De todas maneras,
Paquetes SCORM
En la evaluación del prototipo se utilizaron paquetes
SCORM para verificar el manejo de los metadatos incluidos
en su estructura y, por lo tanto, del manejo de los metadatos
Fuente. En estos paquetes, se incluyeron documentos tal que
su contenido clasificara por distintas reglas especificadas para
cada componente pedagógico. La finalidad de esta elección y
prueba, es corroborar que se:
manipula correctamente la estructura de los paquetes
realiza una correcta extracción de metadatos a partir
del archivo manifiesto
ISSN 1932-8540 © IEEE
228
obtiene los mismos ODAs que si se extrajera la
información a partir de los recursos del SCORM de
forma independiente.
El algoritmo de integración de estos metadatos, asocia a
todos los ODAs extraídos del paquete los metadatos del nivel
1. Si en los siguientes niveles (2 y 3) se encuentra nuevamente
algunos de estos metadatos, se sobrescribe el valor del
metadato del nivel 1 o se incluye también el nuevo para los
que son multivaluados. Esto es igual para el nivel 2 y 3. Si
alguno de los niveles “inferiores” contiene nuevos metadatos,
estos son agregados a los que se vienen acumulando.
V. CONCLUSIONES Y TRABAJOS FUTUROS
A. Conclusiones
Para la evaluación de LooKIng4LO se seleccionó un
conjunto de archivos con formato html, pdf, texto y SCORM,
que tratan sobre Redes de Computadores. Se definió una
ontología de prueba sobre la misma temática y se ejecutaron
las pruebas incluyendo reglas para extraer Componentes
Pedagógicos de los tipos definición, ejemplo y ejercicio, y
metadatos autor (general), tiempo de lectura, imagen y nivel
de interactividad (específicos).
A partir de los resultados, se demostró la capacidad de
procesamiento de los diferentes tipos de formato de
documento.
Con respecto a los paquetes SCORM se logró extraer todos
los metadatos incluidos en su estructura (imsmanifest), y su
integración fue correcta, de acuerdo al algoritmo diseñado
para esto. La descompresión de los archivos del paquete se
realizó sin problemas y la extracción de ODAs desde sus
recursos produjo los mismos resultados para componentes
pedagógicos y metadatos que si se hubieran procesado de
forma independiente.
El conjunto de reglas utilizadas, está diseñado para modelar
oraciones y texto con sintaxis “correcta”. Uno de los casos en
que se detectó un error en la delimitación, se debe a que la
oración previa al fragmento donde se detecta un componente
pedagógico no contiene un punto (delimitación de la oración).
En este caso, la oración anterior también resulta incluida en el
contenido.
Como se mencionó, los errores por no detección de
información se clasificaron como omisión en la ontología o
error en las reglas. En el caso de la ontología, se debe evaluar
qué conceptos agregar y no caer en la tentación de incluir
términos de forma indiscriminada, que no sean específicos del
área modelada, para no obtener correspondencias incorrectas.
La mayor cantidad de errores están asociados a las reglas. En
cada caso, esto se debe a la falta de una regla que lo
contemple o que una regla no es lo suficientemente robusta y
obtiene falsos positivos. La solución a estos errores en
algunos casos es directa y simple; en otros puede involucrar
más pre-procesamiento para obtener mayor información sobre
el contexto permitiendo así tomar “mejores decisiones”. Hay
otros casos, en los que la forma de introducir conceptos tiene
un grado de sutilidad que hace difícil su modelado con reglas.
El alcance del análisis realizado en el proyecto no permitió
profundizar en estos aspectos.
De todas maneras, se puede afirmar que el rendimiento del
prototipo está muy por debajo de la capacidad que se puede
lograr. Las limitaciones que presenta, al momento de esta
evaluación, se deben a que su función es la de probar la
factibilidad de la solución. Es posible mejorar su
configuración y, hasta este momento, no se encontraron
restricciones técnicas o tecnológicas que impidan hacerlo.
B. Trabajos futuros - Soporte a otros formatos de fuentes
El Sistema se diseñó de forma extensible. Actualmente se
quiere extender para otro tipo de formatos de fuentes y, en ese
sentido, se quiere aprovechar la experiencia en repositorios de
temas electrónicos del grupo de la UNED y, en particular, de
su colaboración con la OCW.
OCW (Open CourseWare) [10] es una iniciativa editorial
electrónica a gran escala, basada en Internet y fundada
conjuntamente por la Fundación William and Flora Hewlett,
la Fundación Andrew W. Mellon y el Instituto Tecnológico de
Massachusetts (MIT). Entre sus objetivos destacan el intento
de proporcionar un acceso libre, sencillo y coherente a los
materiales de los cursos del MIT para educadores del sector
público, estudiantes y autodidactas de todo el mundo y crear
un modelo eficiente, basado en estándares, que otras
universidades puedan emular a la hora de publicar sus propios
materiales pedagógicos.
En este último sentido la UNED lleva ya varios años
colaborando con su propio repositorio electrónico OCW [11,
12], en colaboración con el portal UNIVERSIA. Los
materiales depositados en cualquier sitio OCW son de
diferentes tipos: planificación de cursos (programas, temarios,
objetivos pedagógicos, calendarios, etc.), contenidos
(bibliografía, documentos, material audiovisual, material
auxiliar, etc.) y distintas actividades pedagógicas (ejercicios,
tests, proyectos, prácticas de laboratorio, etc.). Son, por lo
tanto, otra buena fuente de datos de prueba para la
herramienta, teniendo en cuenta, además, que pasan una serie
de filtros de calidad previos en la Universidad.
AGRADECIMIENTOS
Los autores agradecen al Programa Iberoamericano de
Ciencia y Tecnología para el desarrollo (CYTED) su soporte
para este trabajo mediante el proyecto CYTED-508AC0341
“SOLITE- SOFTWARE LIBRE EN TELEFORMACIÓN” y
también al Ministerio Español de Ciencia e Innovación su
apoyo mediante el proyecto RedOBER - Proyecto TSI200731091-E Objetos Educativos Reutilizables (para el EEES en
las especialidades de las Tecnologías de la Información y las
Comunicaciones), como también al programa Latin American
and Caribbean Collaborative ICT Research (LACCIR)Proyecto JARDIN.
ISSN 1932-8540 © IEEE
229
REFERENCIAS
Claudia Badell, Martín Barrosa, Rodolfo Sum, Extracción automática
de objetos de aprendizaje y sus metadatos
Proyecto de Grado, Instituto de Computación, Facultad de Ingeniería,
UDELAR, Montevideo Uruguay (2008)
[2] APROA Comunidad – FAQ: Sobre Objetos de Aprendizaje
URL: http://146.83.43.182/aproa/1116/article-68380.html#h2_1
[última visita, noviembre 2008].
[3] SCORM-Sharable Content Object Reference Model
URL: http://adlnet.gov/scorm/index.aspx
[última visita, noviembre 2008]
[4] LOM Learning Object Metadata
URL: http://ltsc.ieee.org/wg12/
[5] UNED – Universidad *acional de Educación a Distancia,
Departamento de Ingeniería Eléctrica Electrónica y de Control
URL: http://www.ieec.uned.es/Asignaturas/Guias/623065.pdf
[6] Baltasar Fernández Manjón, Pablo Moreno Ger, José Luis Sierra
Rodríguez, Iván Martínez Ortiz.
Uso de estándares aplicados a TIC en educación.
URL: http://ares.cnice.mec.es/informes/16/index.htm
[7] Wiley D. A..
Connecting learning objects to instructional design theory: A definition,
a metaphor, and a taxonomy. In D. A. Wiley (Ed.), The Instructional
Use of Learning Objects: Online Version, 2000
URL: http://reusability.org/read/chapters/wiley.doc
[última visita, diciembre 2008]
[8] W3C ontología.
URL: http://www.w3c.es/Traducciones/es/SW/2005/owlfaq
[9] Natalia De Rogatis, Nicolás Millot, Javier Oliva, ODA Asistente
Pedagógico.
Proyecto de Grado, Instituto de Computación, Facultad de Ingeniería,
UDELAR(2006)
[10] Open CourseWare del MIT
URL: http://ocw.mit.edu/OcwWeb/web/about/about/index.htm
[última visita, enero 2009]
[11] Open CourseWare de la UNED-Universia
URL: http://ocw.innova.uned.es/ocwuniversia/
[12] Curso de Redes de Comunicaciones Industriales en la OCW-UNED
URL:http://ocw.innova.uned.es/ocwuniversia/ingenieriaindustrial/redes-de-comunicaciones-industriales
Martín Barrosa es Analista en Computación por la
Universidad de la República, Uruguay (2006). Estudiante
avanzado de la carrera Ingeniería de Sistemas en
Computación por la Universidad de la República,
Uruguay.
Actualmente
se
desempeña
como
Analyst/Developer en el HSBC.
[1]
Regina Motz es Doctor en Computación por la
Technische Universität Darmstadt, Alemania (2004).
Master en Informática por la Universidade Federal de
Pernambuco, Brasil, (1990). Ingeniera de Sistemas en
Computación por la Universidad de la República,
Uruguay (1988). Actualmente se desempeña como
Profesor Agregado Efectivo del Instituto de Computación
de la Facultad de Ingeniería de la Universidad de la
República y como coordinadora del grupo de
investigación Sistemas de Información del mismo instituto. Ha obtenido el
premio Roberto Caldeyro Barcia del Pedeciba 2007 en reconocimiento a su
trayectoria en Informática.
Claudia Badell es estudiante avanzada de la carrera
Ingeniería de Sistemas en Computación por la
Universidad de la República, Uruguay. Actualmente se
desempeña como Ayudante del Instituto de Computación
de la Facultad de Ingeniería de la Universidad de la
República. A su vez, es coordinadora del equipo de
testing en Timba Software Corporation.
Rodolfo Sum es Ingeniero de Sistemas en Computación
por la Universidad de la República, Uruguay (2009).
Gabriel Díaz es Licenciado y Doctor en Ciencias Físicas
por la UAM (Universidad Autónoma de Madrid) desde
1983 y 1988 respectivamente. Ha trabajado durante 15
años para diferentes compañías del mundo de las
Tecnologías de la Información, desde Digital Equipment
Corporation hasta ADSO, su propia compañía, en las que
ha desarrollado diferentes trabajos de consultoría técnica
y organizativa
en Seguridad Informática
y
Comunicaciones. Desde 2006 es Profesor del área de
Ingeniería Telemática en el Departamento de Ingeniería Eléctrica Electrónica
y de Control de la UNED (Universidad Nacional de Educación a Distancia).
Actualmente sus actividades investigadoras están ligadas a la Seguridad
Informática en sistemas de procesos de control, gestión de servicios TI y
varias aproximaciones diferentes a los usos de las TIC para la mejora de la
formación superior en las universidades. Es Senior Member del IEEE y
Vicepresidente del Capítulo Español de la Sociedad de Educación del IEEE,
así como miembro de la ACM y del itSMF.
Manuel Castro. Doctor Ingeniero Industrial por la
Escuela Técnica Superior de Ingenieros Industriales
(ETSII) de la Universidad Politécnica de Madrid (UPM)
e Ingeniero Industrial, especialidad Electricidad,
intensificación Electrónica y Automática, por la misma
Escuela. Ha obtenido el Premio Extraordinario de
Doctorado de la UPM así como el Premio Viesgo 1988 a
la Tesis Doctoral por la aportación a la Investigación
Científica sobre Aplicaciones de la Electricidad en los
Procesos Industriales. Ha obtenido el Premio a los mejores Materiales
Didácticos en Ciencias Experimentales del Consejo Social de la UNED en los
años 1997 y 1999. Ha recibido el premio a la "Innovative Excellence in
Teaching, Learning & Technology" del "Center for the Advancement of
Teaching and Learning" del año 2001. Actualmente es Catedrático de
Universidad del área de Tecnología Electrónica en el Departamento de
Ingeniería Eléctrica, Electrónica y de Control, ETSII de la UNED y Director
del Departamento. Ha sido Vicerrector de Nuevas Tecnologías de la UNED,
así como Subdirector de Investigación, y Subdirector de Gestión Académica
de la ETSII de la UNED y Director del Centro de Servicios Informáticos de la
UNED. Participa en numerosos proyectos de investigación como
investigador, coordinador y director y publica en revistas y congresos, tanto
nacionales e internacionales. Publica igualmente libros y material
investigación multimedia dentro de sus líneas de investigación y docencia, así
como realiza programas de radio, televisión, etc. Ha trabajado cinco años
como Ingeniero de Sistemas en Digital Equipment Corporation. Pertenece al
comité organizador de los congresos internacionales y nacionales IEEE FIE,
CIES-ISES, TAEE y SAAEI, así como es revisor y presidente de mesa. Es
miembro Fellow del IEEE, miembro del Administration Committee
(AdCOM) de la Sociedad de Educación del IEEE y Fundador y PasadoPresidente del Capítulo Español de la Sociedad de Educación del IEEE. Es
Vice-Presidente del Consejo de Dirección de ISES España.
ISSN 1932-8540 © IEEE
230
Hacia una arquitectura para sistemas de elearning basada en PoEML
Roberto Pérez Rodríguez, Manuel Caeiro Rodríguez, Member, IEEE, Luis Anido Rifón, Member,
IEEE
Title— Towards a PoEML-based Architecture for E-learning
Systems.
Abstract—The current panorama of Learning Technologies is
composed of not interoperable technological domains. Thus, there
are web-based systems, m-learning systems, and the recent
concept of t-learning systems. In this paper we present a proposal
of architecture to support the interoperability of e-learning
systems, independently of the access technologies used by
participants. That architecture enables the collaboration between
participants in the same learning process, which is formalized by
using the PoEML Educational Modeling Language.
Index Terms—e-learning, ubiquitous computing, Computer
Supported Collaborative Learning, interoperability
I. INTRODUCCIÓN
D
URANTE los últimos años, las Tecnologías del
Aprendizaje se han convertido en un sector estratégico
tanto para empresas como para universidades. E-learning es
una palabra que engloba numerosos conceptos tales como
aprendizaje a distancia, aprendizaje asistido por ordenador, y
muchos otros. A pesar de los recientes avances en la
estandarización de las Tecnologías del Aprendizaje, los
sistemas de e-learning, tanto propietarios como open-source,
son desarrollados sin el suficiente soporte para la
interoperabilidad. Las consecuencias de este enfoque son que
cada nuevo sistema es desarrollado desde cero, los sistemas no
son compatibles, los Contenidos Educativos no son portables
entre sistemas y, lo que es peor, las Tecnologías del
Aprendizaje no evolucionan al siguiente nivel de desarrollo.
Como en todo ámbito tecnológico que alcanza un cierto
estado de desarrollo han aparecido ciertos estándares de facto
que intentan hacer compatibles las diferentes tecnologías y
unificar esfuerzos. La mayor parte de estas especificaciones se
centran en los contenidos de los sistemas de e-learning
Roberto Pérez Rodríguez está en el Departamento de Ingeniería
Telemática, Universidad de Vigo, 36310 Vigo, España (e-mail:
[email protected])
Manuel Caeiro Rodríguez está en el Departamento de Ingeniería
Telemática, Universidad de Vigo, 36310 Vigo, España (e-mail:
[email protected])
Luis Anido Rifón está en el Departamento de Ingeniería Telemática,
Universidad de Vigo, 36310 Vigo, España (e-mail: [email protected])
(tutoriales, lecciones, ejemplos, exámenes, etc.), definiendo
estándares de clasificación, creación y distribución de dichos
contenidos.
En los últimos años ha aparecido un nuevo enfoque en
cuanto a las especificaciones de diseño centrado en el proceso
educativo (o de aprendizaje atendiendo a la denominación en
inglés de learning process). El proceso educativo se refiere a
la realización y coordinación de las diferentes actividades de
una unidad pedagógica (e.g. seminario, jornada, curso
académico), en los que no es suficiente con describir los
contenidos sino que hay que especificar, por ejemplo, qué
tienen que hacer los alumnos, el orden en el que hay que
realizar los contenidos, etc.
En la actualidad, la arquitectura de los sistemas de elearning es dependiente de la tecnología de acceso. De esta
manera tenemos sistemas inter-departamentales que dependen
de la tecnología de la intranet corporativa, sistemas basados en
Web, sistemas basados en la televisión digital, y sistemas
basados en dispositivos móviles. Cada uno de estos sistemas
presenta habitualmente un diseño monolítico que hace
virtualmente imposible su extensión para soportar una
tecnología de acceso distinta.
XML es el estándar de mayor utilización para la
representación de información de forma independiente de su
presentación. Las aplicaciones, al proveer interfaces basadas
en XML, pueden ofrecer su funcionalidad independientemente
de la tecnología final utilizada por el usuario para acceder a
ellas. De esta manera, los Escenarios Educativos pueden
contener recursos consumibles desde varias tecnologías de
acceso.
En este artículo se presenta una propuesta de arquitectura
para sistemas de e-learning que no depende de la tecnología
de acceso empleada. Para ello se ha optado por una
Arquitectura Basada en Componentes, en la cual cada
componente del sistema tiene una funcionalidad independiente
y realiza una o varias interfaces bien definidas. De esta
manera, el soporte de una nueva tecnología de acceso se logra
añadiendo el componente que realice la nueva funcionalidad,
permaneciendo el resto del sistema sin cambios.
En nuestra propuesta, un motor de ejecución de procesos
educativos es expuesto como un Servicio Web. De esta
manera, la lógica de control de los procesos educativos está
centralizada, siendo la misma independientemente de la
tecnología de acceso empleada por cada participante.
ISSN 1932-8540 © IEEE
PÉREZ RODRÍGUEZ et al.: HACIA UNA ARQUITECTURA PARA SIST. DE E-LEARNING BASADA EN POEML 231
Los módulos de integración siguen un enfoque Orientado a
Aspectos [1], ya que en puntos bien definidos de la ejecución
en la capa de presentación se ejecuta código relativo a
diferentes asuntos o aspectos. De esta manera se encapsulan
las llamadas desde las capas de presentación a los Web
Services de interacción con el motor de ejecución. Estos
asuntos guardan relación con las Perspectivas de PoEML
(Perspective-oriented Educational Modelling Language)
[2][3], el Lenguaje de Modelado Educativo en el cual está
basado este sistema de e-learning.
II. PROPUESTA
Nuestra propuesta de arquitectura está basada en el empleo
del Lenguaje de Modelado Educativo PoEML. Los EMLs
(Educational Modelling Languages) fueron propuestos hace
algunos años con el propósito de dar soporte a la creación de
modelos de unidades educativas con independencia del
enfoque pedagógico. La principal característica de PoEML en
su enfoque basado en la separación de asuntos. En lugar de
intentar dar soporte al modelado de unidades educativas con
un conjunto completo de elementos y relaciones, PoEML
considera los diferentes asuntos implicados en las unidades
educativas y ofrece diferentes conjuntos de elementos y
relaciones para modelar cada asunto.
La propuesta PoEML completa es bastante extensa, ya que
comprende 17 asuntos distintos, agrupados en 13 perspectivas
y 4 aspectos. Las perspectivas y los aspectos son dos tipos de
asuntos ortogonales. A pesar del gran número de perspectivas
y aspectos, una propiedad capital de la propuesta PoEML es
que las perspectivas y los aspectos pueden ser utilizados de
una manera modular. En la práctica, existe sólo una
perspectiva que necesita ser siempre considerada en las
unidades educativas, el resto son opcionales y se pueden
utilizar cuando sea requerido.
El Escenario Educativo es el elemento de construcción
básico para crear modelos de unidades educativas. La Figura 1
muestra la estructura de un Escenario Educativo. Básicamente,
un Escenario Educativo es un elemento que agrega elementos,
especificaciones y expresiones:
• Los elementos representan las entidades contenidas en
el Escenario Educativo. Para el propósito de este
artículo es suficiente con tener en cuenta que un
Escenario Educativo puede incluir: (i) uno o más
objetivos que indican qué tiene que ser realizado de
un modo declarativo; (ii) uno o varios roles que
indican las funciones de los participantes que tienen
que ver con la consecución de los objetivos; (iii) uno
o varios entornos conteniendo los recursos que
pueden ser utilizados por los participantes para
desarrollar su trabajo. Cada uno de esos elementos
puede incluir otros elementos, tales como elementos
de datos, representando propiedades, parámetros o
variables. Adicionalmente, un Escenario Educativo
puede contener otros Escenarios Educativos
agregados jerárquicamente, llamados Subescenarios
Educativos. Es importante destacar que los objetivos
de un Escenario Educativo pueden estar relacionados
con los objetivos de los Subescenarios que lo
componen.
• Las especificaciones representan controles en tiempo
de ejecución que tienen que ser aplicados para
manejar los elementos contenidos en un Escenario
Educativo. En este artículo, las especificaciones
principales son la temporal y la de orden.
• Las
expresiones
implican
descripciones
correspondientes con los aspectos de PoEML.
Representan cuestiones que pueden afectar al
comportamiento de los elementos y las
especificaciones. Por ejemplo, una expresión de
condición determina su resultado de acuerdo con el
valor de ciertos elementos de datos.
Figura 1. Estructura de un Escenario Educativo
Para tener un sistema de e-learning en el estado del arte es
suficiente con considerar 4 de las perspectivas de PoEML:
• La perspectiva estructural define la estructura de una
unidad educativa en Escenarios y Subescenarios
educativos. Esta estructura es análoga al sistema de
directorios en un sistema operativo.
• La perspectiva funcional define una estructura de
objetivos y subobjetivos. Cada Escenario
Educativo debe contener al menos un objetivo. En
la Figura 2 se muestra un ejemplo con relaciones
entre objetivos y subobjetivos.
• La perspectiva de orden define el orden de
realización de los subescenarios contenidos en un
cierto Escenario Educativo.
• La perspectiva temporal permite definir instantes
concretos de tiempo para la realización de un
Escenario Educativo.
Esta estructura permite la descripción de las cuestiones
englobadas en los Escenarios Educativos. Es importante
ISSN 1932-8540 © IEEE
232
señalar que cada una de las cuestiones englobadas en un
Escenario Educativo se incluye como una entidad separada.
De esta manera, se facilita la modificación de Escenarios
Educativos mediante el reemplazo de elementos específicos,
especificaciones o expresiones, facilitando de esta manera la
reutilización. Además, durante el tiempo de ejecución es
necesario crear instancias de los Escenarios Educativos y de
sus elementos. El número de instancias a crear puede ser
determinado estáticamente durante el tiempo de diseño o
dinámicamente durante el tiempo de ejecución de acuerdo con
el resultado proporcionado por expresiones específicas.
Figura 2. Agregación de Escenarios Educativos y objetivos
III. ARQUITECTURA
La Figura 4 muestra un diagrama con la arquitectura del
sistema. En las siguientes subsecciones se detalla dicha
arquitectura.
A. La máquina de procesos educativos: PoEML Engine
El motor de ejecución de procesos educativos es el
componente central del sistema de e-learning [4]. En él se
almacena la información relativa a los Escenarios Educativos,
participantes, objetivos, y resto de elementos, haciendo
evolucionar el estado del sistema dependiendo de los eventos,
tanto externos al motor como internos a él, que se producen.
El motor de ejecución se integra en el sistema de e-learning
a través de una interfaz bien definida basada en Web Services,
garantizando el requisito de la conectividad. Al mismo tiempo,
los componentes de presentación deben estar lo más
desacoplados que sea posible respecto al motor de ejecución,
esto implica utilizar un sencillo conjunto de APIs. La
escalabilidad también es un requisito fundamental, al ser el
motor de ejecución el componente central del sistema de elearning.
Eventos generados por el participante:
• Comenzar un ES
• Finalizar un ES
• Intentar un objetivo
• Darse de alta/darse de baja
Eventos generados por el motor de ejecución:
• Instanciar un ES
• Instanciar un objetivo
• Dar por finalizado un objetivo
• Hacer accesible/no accesible un ES
• Hacer intentable/no intentable un objetivo
Los componentes de presentación también pueden acceder
al motor de ejecución de una manera pasiva simplemente para
recuperar información, tanto sobre los Escenarios Educativos
como sobre los objetivos. Esta recuperación de información
está asociada a la navegación por los Escenarios Educativos:
• Conseguir la información relativa a un Escenario
Educativo
• Conseguir la información de los subescenarios de un
cierto ES
Un Escenario Educativo tiene que ser instanciado para que
un usuario pueda acceder a él. Este caso es similar a la
instanciación en un lenguaje de programación orientado a
objetos, donde un objeto tiene que ser instanciado antes de
poder acceder a sus atributos y métodos. En el caso que nos
ocupa, un Escenario Educativo puede estar también en los
estados Iniciado y Finalizado. La Figura 3 muestra todos los
posibles estados de ejecución en que puede estar un Escenario
Educativo.
Un evento externo al motor de ejecución como el acceso a
un Escenario Educativo puede desencadenar varios eventos
internos al motor de ejecución como la instanciación de sus
Subescenarios Educativos. Al mismo tiempo, se impone la
restricción de que dichos Subescenarios Educativos tengan un
objetivo propuesto. Este comportamiento es un problema bien
conocido, que se resuelve mediante reglas Evento-CondiciónAcción:
• Evento: un participante accede a un Escenario
Educativo
• Condición: que el Subescenario tenga un objetivo
propuesto
• Acción: instanciar el Subescenario
Figura 3. Posibles estados de ejecución de un Escenario Educativo
De una manera similar, el motor de ejecución tiene que
manejar los eventos relativos a los objetivos de los Escenarios
Educativos. El participante puede generar el evento de intentar
objetivo, con los posibles resultados de éxito y fracaso. Este
evento genera en el motor de ejecución los eventos de
ISSN 1932-8540 © IEEE
instanciación de los objetivos que presentan una relación de
completitud con el objetivo intentado.
En resumen, la interacción entre los componentes de
presentación y el motor de ejecución puede ser tanto la
recuperación pasiva de información relativa a los Escenarios
Educativos como la comunicación de eventos generados por el
participante.
Figura 4. Arquitectura del sistema de e-learning
A. La capa de middleware
Para facilitar que los Servicios Web sean accesibles desde
los módulos de presentación se hace uso de las
funcionalidades que provee un motor SOAP. De esta manera
los módulos de presentación tienen una interacción
desacoplada con el motor de ejecución de procesos educativos.
La funcionalidad que provee el motor de ejecución de
procesos educativos se publica en un archivo WSDL. Los
métodos de servicio son tanto para la recuperación pasiva de
información como para la comunicación de eventos generados
por el participante.
B. Los módulos de presentación dependientes de l dominio
tecnológico
Cada Servidor de Presentación se describe como un
componente multicapa:
• La capa de middleware consiste en una
implementación del protocolo SOAP, para acceder
desde cada Servidor de Presentación al motor de
ejecución de procesos educativos.
• La capa de aspectos contiene el código de
integración, encapsulando las invocaciones a los
Web Services del motor de ejecución en aspectos.
• La capa iTV/Web/dispositivo móvil contiene el
código dependiente de cada dominio tecnológico.
IV. CASOS DE APLICACIÓN
A. Moodle
En nuestro estudio de los sistemas de e-learning nos hemos
encontrado con que los sistemas open-source tienen cada vez
una aceptación mayor. Moodle [5] es el Sistema de Gestión
del Aprendizaje (Learning Management System, LMS) más
utilizado, con millones de usuarios (moodlers) a lo largo de
todo el mundo. Su licencia GPL, su estabilidad, y la gran
comunidad de usuarios y desarrolladores, son los principales
motivos de su popularidad.
Moodle sigue un enfoque constructivista. Los estudiantes no
son solamente consumidores de contenidos de aprendizaje,
sino creadores de contenidos también. De esta manera, el
conocimiento es construido por la comunidad. Para dar
soporte al enfoque constructivista, Moodle cuenta con
herramientas colaborativas que ponen en contacto a los
participantes entre sí y con los contenidos.
Hemos evaluado a Moodle descomponiendo el problema
siguiendo el principio de separación de asuntos como sigue:
• Desde un punto de vista estructural, la manera en la
que Moodle estructura los contenidos es muy
rígida, ya que sólo permite diseñar cursos
compuestos de secciones sobre las que se agregan
los recursos educativos. La estructura de
contenidos es una jerarquía: curso, sección,
recurso.
• Desde un punto de vista temporal, Moodle permite
liberar contenidos semanalmente. No permite
definir instantes arbitrarios de tiempo en los que
liberar contenidos.
• Desde un punto de vista de orden de realización,
Moodle no permite definir secuencias ordenadas de
realización de contenidos educativos.
En la actualidad estamos trabajando en el desarrollo de la
capa de aspectos para la integración de Moodle con el motor
ISSN 1932-8540 © IEEE
234
de ejecución de procesos educativos [6]. El enfoque para esto
está basado en la programación orientada a aspectos. El
Desarrollo Software Orientado a Aspectos (Aspect-oriented
Software Development) es un paradigma que permite
modularizar asuntos entrecruzados (crosscutting concerns),
esto es, código que no puede ser capturado en módulos
utilizando el mecanismo de descomposición presente en el
lenguaje de programación empleado. En el caso de Moodle,
las unidades de modularización son scripts PHP, y los nuevos
asuntos entrecruzan multitud de scripts PHP pertenecientes al
código fuente de Moodle. El procedimiento para añadir un
nuevo asunto a Moodle es:
• Listar los puntos la ejecución de Moodle donde ese
asunto tiene que ser tenido en cuenta. Esos puntos
se definen como joinpoints
• Un pointcut se define como un conjunto de
joinpoints
• El último paso es definir el código advice a ejecutar
en cada pointcut. El código advice encapsula las
llamadas a los Web Services del motor de
ejecución de procesos
B. iTV
Consideramos que la experiencia de los participantes en los
sistemas de t-learning sería enriquecida al integrar un motor de
ejecución de procesos educativos no perteneciente al dominio
de la iTV (Interactive Television).
Se utiliza un servidor DVB (Digital Video Broadcasting)
para el streaming, mientras que los Web Services que provee
el motor de ejecución controlan el proceso de aprendizaje. El
participante debe contar con un receptor MHP (Multimedia
Home Protocol).
C. M-learning
Se llama m-learning al aprendizaje a través del uso de
dispositivos móviles. Estos dispositivos móviles son una de las
tecnologías más prometedoras para el soporte del aprendizaje,
ya que el participante puede acceder al sistema en cualquier
tiempo y lugar. Este enfoque se ajusta especialmente bien en
escenarios colaborativos, donde los participantes pueden
colaborar entre sí mediante el uso de un dispositivo móvil.
Cuando se accede a un Escenario Educativo desde un
dispositivo inalámbrico móvil, el sistema tiene que saber cómo
ensamblar los contenidos para posteriormente enviarlos al
dispositivo móvil. Además, la información relativa a un
Escenario Educativo debe ser formateada para ajustarse a
dicho dispositivo.
Con nuestro enfoque, dispondríamos de un módulo de
presentación para m-learning capaz de comunicarse con los
dispositivos móviles utilizando los protocolos de
comunicación empleados en las redes inalámbricas. Este
módulo de presentación consumiría los Web Services que
provee el motor de ejecución de PoEML. Así, el
funcionamiento es muy similar a un sistema basado en Web,
ya que hacemos separación del código dependiente del
dominio tecnológico (web, dispositivos móviles, iTV) del
código independiente del dominio (el motor de ejecución de
procesos educativos).
V. LA EXTENSIÓN DE MOODLE
La extensión que hemos desarrollado se compone de un
nuevo tipo de curso con tres vistas: la vista en tiempo de
ejecución (run-time), la herramienta de autoría, y la vista de
monitorización. En esta sección detallaremos estas tres vistas.
Antes de detallar los diferentes entornos, es importante
describir el concepto de descripción del curso, así como el de
instancia de curso. Una descripción de curso es análoga a una
clase en la Programación Orientada a Objetos: una guía a
partir de la cual los objetos son creados. De esta manera,
múltiples instancias de curso pueden ser creadas a partir de
una descripción de curso: una por estudiante.
En los cursos Moodle actuales, se necesita simplemente un
esquema de base de datos para guardar la descripción de
cursos. En nuestro caso, necesitamos un esquema de base de
datos para las descripciones de cursos y otro para las
instancias de cursos en tiempo de ejecución.
A. El entorno de autoría
El proceso de autoría consiste en una serie de operaciones
atómicas. En el conjunto de operaciones posibles hay algunas
como:
• Añadir/editar/borrar un Escenario
• Añadir/editar/borrar un Objetivo
• Añadir/editar/borrar un recurso/actividad
Los cambios atómicos son validados para asegurar que son
consistentes con el diseño general del curso. Después de haber
verificado su consistencia, el cambio atómico se compromete
contra el esquema de base de datos que contiene las
descripciones de cursos. El nivel de granularidad puede ser
fijado como se desee: una operación atómica puede consistir
en añadir un Objetivo con todos sus campos constituyentes, o
puede ser editar un Objetivo previamente creado y cambiar
sólo un campo. El proceso de autoría consistente en cambios
atómicos presenta algunas ventajas valorables:
• Los cambios atómicos son inmediatamente vistos
por otros co-autores
• No hay necesidad de un chequeo de la consistencia
como el que se necesita al importar un archivo que
contiene una descripción de un curso completo
El chequeo de la consistencia es aún necesario para el
soporte de la interoperabilidad. Las descripciones de cursos
siguen el modelo de datos de PoEML. Por los tanto, las
descripciones de cursos pueden ser exportadas desde su
esquema de base de datos a archivos XML. Así, un archivo
XML que contiene una descripción de curso puede ser
importado en otro LMS compatible con PoEML.
La Figura 5 muestra el proceso de autoría de varios expertos
trabajando en el mismo diseño. Los co-autores realizan
cambios atómicos en el diseño del curso, y esos cambios son
comprometidos contra el esquema de base de datos de las
descripciones de cursos. El diseño del curso puede ser testeado
ISSN 1932-8540 © IEEE
''al vuelo'' creando una nueva instancia de curso y testeándola
en el entorno de tiempo de ejecución. La figura también
muestra que los archivos que contienen descripciones de
cursos pueden ser importados y exportados en la base de datos
del LMS Engine.
actividades nativos de Moodle, tales como cuestionarios, foros
y wikis. Al fondo de la página se presentan los Subescenarios.
En la vista Funcional, el participante puede ver el estado de
los Objetivos y una lista de todos los Entornos necesarios para
completar cada Objetivo. Dependiendo del Objetivo en el cual
esté trabajando el participante, se muestran los Entornos.
La vista de Escenarios en árbol (Figura 7) y la vista de
Objetivos muestran un mapa del estado actual de los
Escenarios y Objetivos para una cierta instancia de curso. Esas
dos vistas pueden resultar de ayuda para ver qué Objetivos han
sido completados y cuáles permanecen pendientes.
Figura 6. Captura de pantalla del entorno de tiempo de ejecución
Figura 5. Nuestro enfoque para la autoría de cursos
B. El entorno de tiempo de ejecución
La Figura 6 muestra una captura de pantalla del entorno de
tiempo de ejecución para un participante en un curso. Consiste
en cuatro vistas de curso: vista Estructural, vista de Escenarios
en árbol, vista de Objetivos, y vista Funcional. Comenzamos la
exposición con la vista Estructural.
Cuando un participante es enrolado en un curso, se le asigna
una instancia de curso. En ese momento, la vista estructural
del curso se presenta en el navegador. Las partes principales
de esa página son la barra de navegación (hilo de Ariadna), los
Objetivos, los Entornos y los Subescenarios.
La barra de navegación o hilo de Ariadna muestra en cada
momento el nivel de agregación en el cual está el participante.
La caja de Objetivos muestra todos los Objetivos para el
Escenario actual. El color de cada Objetivo es una indicación
de su estado. Los posibles estados son: No Propuesto, No
Intentable, Intentable, Pendiente, Completado, y Fallido. Cada
caja de Objetivo puede ser expandida para ver la información
sobre las restricciones de entrada/salida, así como los
parámetros de entrada/salida.
Los recursos y actividades educativos están contenidos en
una caja de Entornos. Un entorno contiene recursos y
Figura 7. Vista en árbol de la jerarquía de Escenarios
C. El entorno de monitorización
La característica de monitorización del curso está disponible
para el rol de profesor. Esta característica se divide en dos
vistas diferentes:
• Monitorización por elemento de curso (dirigida por
elemento)
• Monitorización de todos los elementos por
estudiante (dirigida por estudiante)
ISSN 1932-8540 © IEEE
236
La Figura 8 muestra la monitorización de un objetivo. En la
parte superior de la página, podemos ver los posibles estados
de un Objetivo y el número de estudiantes por estado. Se usa
un histograma para mostrar esa información de una manera
gráfica. En la parte inferior de la página, podemos ver una
tabla detallando el estado de cada Objetivo para cada
estudiante enrolado en el curso.
Las Variables y las Expresiones de Datos pueden ser
también monitorizadas. Las Variables pueden servir para
expresar la nota de un estudiante en un cierto cuestionario. Las
Expresiones de Datos sirven para componer decisiones que
dependen del rendimiento del alumno, por ejemplo, una
decisión que depende de la nota de un alumno en un
cuestionario.
La otra vista de monitorización disponible es la dirigida por
estudiante. Esa vista es apropiada para monitorizar la
progresión de un alumno a través de los itinerarios del curso.
Figura 8. Captura de pantalla del entorno de monitorización.
VI. TRABAJO RELACIONADO
A. CopperCore
CopperCore [7] es la implementación de referencia de un
IMS Learning Design engine y también provee un player
basado en ese engine. El objetivo fue proporcional una fuente
de información para implementar otros players compatibles
con LD. En la práctica ha sido visto como el player de
referencia y herramienta para ejecutar diseños y para validar
otras herramientas de LD tales como editores, herramientas de
autoría, etc.
Los objetivos de CopperCore incluían testear si el diseño de
la API permitía que un thin client fuese construido encima del
engine a un coste reducido; y dar una indicación de la
funcionalidad que se esperaba de los IMS-LD players.
Rendimiento y escalabilidad no son contempladas por
CopperCore, aunque se espera que sea uno de los objetivos de
los IMS-LD players en producción.
A nivel interno CopperCore utiliza una máquina de estados
finita (FSM - Finite State Machine) para evaluar propiedades
y secuenciar condicionalmente el contenido. Por cada UoL
importada se crea una FSM y un árbol de actividades es
adjuntado a cada estado y mostrado al usuario cuando tal
estado es alcanzado.
Los siguientes players utilizan CopperCore:
• SLED [8], Service-based Learning Design system.
Está enfocado en el uso de web services: la
comunicación entre el engine y el player es
realizada usando web services. Herramientas
adicionales y para usuarios finales (e.g. sistemas de
conferencia) fueron construidas orientadas a web
services. SLeD presenta mayor funcionalidad que
el básico CopperCore engine. Por ejemplo, el
CopperCore engine sólo es capaz de indicar que el
diseño de aprendizaje necesita un foro, mientras
que SLeD muestra el foro, ejecutándolo a través
del servicio de conferencia.
• El incluido en el proyecto Reload [9]. Este proyecto
provee una familia de herramientas relacionadas
con las especificaciones IMS, desde el
ampliamente utilizado IMS-CP packager hasta un
IMS-LD editor. Su implementación está basada en
las plataformas Java y JBoss. Su funcionalidad
incluye: importar/borrar de Learning Designs en el
CopperCore engine con una simple interfaz
gráfica, leer automáticamente un Learning Design
y poblar el engine con un usuario activo por cada
rol encontrado dentro del manifiesto (pueden ser
añadidos usuarios a medida también), etc.
B. GRAIL
GRAIL (Gradient-lab RTE for Adaptative IMS-LD in
.LRN) es el entorno de ejecución de IMS-LD implementado en
.LRN. Ha sido concebido para ser utilizado dentro del
contexto de una comunidad .LRN, un conjunto de usuarios
compartiendo recursos tales como documentos, foros,
calendarios, etc. Un curso es simplemente una instancia de una
de esas comunidades. Como suele ser el caso, y IMS-LD no es
una excepción, las especificaciones no incluyen detalles de
cómo debe ser implementado el RTE (Run-Time
Environment). Esto normalmente se traduce en un amplio
conjunto de decisiones que tiene que tomar el equipo de
diseño. Tienen que ver con importantes aspectos de la
usabilidad y efectividad del entorno de ejecución y por lo tanto
tienen que ser cuidadosamente consideradas.
Otros entornos de ejecución de IMS-LD como CopperCore
utilizan un modelo de máquina de estados finitos (FSM) para
evaluar
propiedades
y
secuenciar
el
contenido
condicionalmente. Para cada Unidad de Aprendizaje (UOLUnit Of Learning) importada, una máquina de estados finitos
es creada y un árbol de actividades es creado para cada estado
y mostrado al usuario cuando el estado es alcanzado.
La evaluación de una condición debe conducir a un árbol de
actividades nuevamente calculado, conteniendo sólo aquellos
ISSN 1932-8540 © IEEE
recursos visibles para un usuario y/o un rol. Propiedades y
condiciones pueden estar relacionadas con dependencias
arbitrariamente complejas. Cuando el valor de una propiedad
es cambiado, todas las condiciones referidas a ella necesitan
ser reevaluadas. Tal evaluación puede desencadenar nuevos
cambios de valor en más propiedades. Como consecuencia, el
entorno de ejecución aplica esos pasos iterativamente hasta
que no cambia el valor de ninguna propiedad más, esto es,
alcanzando el nuevo estado. Este proceso tiene el riesgo de
entrar en un bucle infinito (los cambios de valor en las
propiedades no alcanzan un estado estacionario, sino que
oscilan) lo cual denotaría una Unidad de Aprendizaje (UOL)
incorrecta, pero el entorno de ejecución necesita proporcionar
algún mecanismo para evitarlo.
La aproximación tomada en GRAIL es ligeramente
diferente de una máquina de estados. No se definen estados
predefinidos cuando se carga la UoL, en su lugar son
calculados bajo demanda cuando la UoL es ejecutada. El
entorno de ejecución almacena la relación de dependencia
entre propiedades y condiciones. El valor inicial de todas las
condiciones se obtiene cuando se instancia una nueva
ejecución de la UoL. Desde ese punto, cuando una propiedad
cambia de valor solamente se reevalúan las condiciones
relacionadas. Para evitar bucles infinitos el sistema deja de
evaluar condiciones si una propiedad cambia de valor más
veces que un límite dado, el cual debe ser elegido
suficientemente alto.
En build-time, las condiciones son guardadas en la base de
datos tal y como se definen en la descripción de la UoL, con su
código XML. La evaluación de condición significa parsear
este XML reemplazando propiedades por sus valores
correspondientes. Este esquema facilita una hipotética edición
de condiciones cuando un error es detectado.
Las siguientes entidades utilizan .LRN:
• MIT Sloan School of Management .LRN aloja sobre
11000 usuarios y sobre 3000 sesiones
concurrentes. Se estima que .LRN fue desplegado y
mantenido con aproximadamente el 25% del coste
de soluciones basadas en software comercial.
• Harvard Univ. Executive Education Project.
• Vienna Univ. of Economics and Business Admin. Es
una de las instancias de .LRN mayores. Sirve
alrededor de 20000 usuarios, contiene 26000
recursos educativos y soporta de media unas 600
conexiones.
• Universidad de Valencia. Esta universidad requería
una plataforma para soportar 40000 usuarios.
Después de estudiar plataformas como Moodle,
Atutor, WebCT y ILIAS, su elección fue .LRN
debido a su combinación de escalabilidad y
extensibilidad.
modelar las unidades educativas de una manera independiente
de la tecnología logramos que los participantes puedan
colaborar en el mismo proceso de aprendizaje
independientemente de la tecnología de acceso que cada
participante use para conectarse al sistema de e-learning.
El uso de estándares como XML y los Web Services nos
proporciona el necesario desacoplamiento entre la lógica de
control del proceso de aprendizaje y la tecnología empleada
para la presentación final de los contenidos al participante.
Debido a que todo participante en un proceso de
aprendizaje debe ver el mismo estado se hace necesario
centralizar el motor de ejecución de procesos.
La interacción de los servidores de presentación con el
motor de ejecución se realiza a través de una sencilla interfaz
mediante la que se recupera información de una manera pasiva
y mediante la que se comunican eventos generados por el
participante al motor de ejecución de procesos de aprendizaje.
Los módulos de integración de los servidores de
presentación con el motor de ejecución siguen un enfoque
Orientado a Aspectos.
De esta manera, y siguiendo la descomposición en
Perspectivas del lenguaje PoEML, se encapsulan las llamadas
a los Web Services que provee el motor de ejecución de
procesos de aprendizaje.
AGRADECIMIENTOS
Este trabajo ha sido financiado parcialmente por el
programa eContentplus ECP 2007 EDU 417008 (www.aspectproject.org), un programa Comunitario multianual cuyo
objetivo es crear contenidos digitales más fácilmente
accesibles, usables y explotables.
Igualmente, queremos agradecer al Ministerio de Educación
y Ciencia su financiación parcial a este trabajo a través del
proyecto TIN2007-68125-CO02-02 (Servicios Adaptativos
para E-learning basados en estándares).
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
VII. CONCLUSIONES
[8]
El uso de un lenguaje de modelado nos proporciona el
marco conceptual para desarrollar un sistema de e-learning. Al
[9]
R. E. Fillman, T. Elrad, S. Clarke, and M. Aksit, Eds., Aspect-Oriented
Software Development. Boston: Addison-Wesley, 2005.
M. Caeiro, Contribuciones a los lenguajes de modelado educativo.
Universidad de Vigo, 2007.
M. C. Rodríguez, M. J. Marcelino, M. L. Nistal, L. E. Anido-Rifón, and
A.J. Mendes, “Supporting the Modeling of Flexible Educational Units.
PoEML: A Separation of Concerns Approach.” J. UCS, vol. 13, no. 7,
pp. 980-990, 2007.
R. Perez-Rodriguez, M. Caeiro-Rodriguez, and L. Anido-Rifón, “Basic
Perspective Support of a PoEML-conformant Component-based LMS
Engine”, in Proceedings of the X Simposio Internacional de
Informática Educativa, 2008.
(2009, Mar.) Moodle. [Online]. Available: http://moodle.org
R. Perez-Rodriguez, M. Caeiro-Rodriguez, and L. Anido-Rifon,
“Supporting PoEML Educational Processes in Moodle: a Middleware
Approach”, in Proceedings of the V Simposio Pluridisciplinar sobre
Diseño y Evaluación de Contenidos Educativos Reutilizables, 2008.
(2009,
Mar.)
Coppercore.
[Online].
Available:
http://www.coppercore.org
(2009,
Mar.)
Sled.
[Online].
Available:
http://www.elearning.ac.uk/features/sledproject
(2009, Mar.) Reload. [Online]. Available: http://www.reload.ac.uk
ISSN 1932-8540 © IEEE
238
Roberto Pérez Rodríguez es Ingeniero de
Telecomunicación (2008) en la especialidad de
Telemática por la Universidad de Vigo. Actualmente
es estudiante de doctorado en el Departamento de
Ingeniería Telemática de la Universidad de Vigo y
realiza labores docentes como Profesor Invitado en
dicho departamento. Su labor investigadora está
centrada en la utilización de Arquitecturas Orientadas
a Servicios para proveer servicios de e-learning.
Manuel Caeiro Rodríguez es Ingeniero de
Telecomunicación (1999) y Doctor Ingeniero de
Telecomunicación (2007) por la Universidad de
Vigo. Actualmente es Profesor Contratado Doctor en
el Departamento de Ingeniería Telemática de la
Universidad de Vigo realizando tareas docentes
relacionadas con la ingeniería del software y la
arquitectura de ordenadores. En cuanto a la
investigación su interés principal se centra en la
aplicación de las Tecnologías de la Comunicación y
la Información a la educación, en especial en el marco de los lenguajes de
modelado educativo.
Luis
Anido
Rifón
es
Ingeniero de
Telecomunicación cum laude (1997) en las
especialidades de Telemática y Comunicaciones,
y Doctor Ingeniero de Telecomunicación cum
laude (2001) por la Universidad de Vigo.
Actualmente es Profesor Titular de Universidad
en el Departamento de Ingeniería Telemática de
la Universidad de Vigo y ocupa el puesto de
Director del Área de Innovación Educativa de la
Universidad de Vigo. Ha recibido varios premios por el W3C, la Royal
Academy of Sciences y la Colegio Oficial de Ingenieros de
Telecomunicación. Es autor de más de 180 artículos en revistas y congresos.
Es también el director del Programa Gallego de Investigación en TIC,
secretario técnico de AENOR CTN71 SC36 y el director de la delegación
española de ISO/IEC JTC1 SC36.
ISSN 1932-8540 © IEEE
IEEE-RITA (http://webs.uvigo.es/cesei/RITA)
Revisores
Addison Salazar Afanador,
Universidad Politécnica de
Valencia, España
Alberto Jorge Lebre Cardoso,
Universidad de Coimbra, Portugal
Ana Arruarte Lasa, Universidad
del País Vasco, España
Alfredo Ortiz Fernández,
Universidad de Cantabria, España
André Luís Alice Raabe,
Universidade do Vale do Itajaí,
Brasil
Angel García Beltrán, Universidad
Politécnica de Madrid, España
Angel Mora Bonilla, Universidad
de Málaga, España
Angélica de Antonio Jiménez,
Universidad Politécnica de Madrid,
España
Antonio Barrientos Cruz,
España
Antonio Navarro Martín,
Madrid, España
Antonio Sarasa Cabezuelo,
Madrid, España
Basil M. Al-Hadithi, Universidad
Alfonso X El Sabio, España
Basilio Pueo Ortega, Universidad
de Alicante, España
Carmen Fernández Chamizo,
Madrid, España
Cecilio Angulo Bahón,
Catalunya , España
César Alberto Collazos Ordóñez,
Universidad del Cauca, Colombia
Crescencio Bravo Santos,
Universidad de Castilla-La Mancha,
España
Daniel Montesinos i Miracle,
Catalunya, España
David Benito Pertusa, Universidad
Publica de Navarra, España
Faraón Llorens Largo, Universidad
de Alicante, España
Gabriel Díaz Orueta, UNED,
España
Gloria Zaballa Pérez, Universidad
de Deusto, España
Gracia Ester Martín Garzón,
Universidad de Almeria, España
Ismar Frango Silveira, Universidad
de Cruzeiro do Sul, Brasil
Javier Areitio Bertolin,
Universidad de Deusto, España
Javier González Castaño,
Joaquín Roca Dorda, Universidad
Politécnica de Cartagena, España
Luis de la Fuente Valentín,
Jorge Alberto Fonseca e Trindade,
Universidad Carlos III, España
Escola Superior de Tecnología y
Luis Fernando Mantilla Peñalba,
Gestión, Portugal
Universidad de Cantabria, España
Jose Ángel Irastorza Teja,
Universidad de Cantabria, España Luis Gómez Déniz, Universidad de
Las Palmas de Gran Canaria,
José Angel Martí Arias,
España
Universidad de la Habana, Cuba
Luis Zorzano Martínez,
José Javier López Monfort,
Universidad de La Rioja, España
Manuel Benito Gómez,
Valencia, España
Universidad del Pais Vasco,
José Luis Guzmán Sánchez,
España
Universidad de Almeria, España
Manuel Domínguez Dorado,
José Luis Sánchez Romero,
Universidad de Extremadura,
Universidad de Alicante, España
España
José Ramón Fernández Bernárdez,
Manuel Gromaz Campos, Centro
de Supercomputación de Galicia,
Juan Carlos Soto Merino,
España
Universidad del Pais Vasco,
Manuel Pérez Cota, Universidad de
España
Vigo, España
Juan I. Asensio Pérez, Universidad
Margarita Cabrera Bean,
de Valladolid, España
Juan Meléndez, Universidad
Catalunya, España
Pública de Navarra, España
Juan Suardíaz Muro, Universidad Maria Antonia Martínez Carreras,
Universidad de Murcia, España
Politécnica de Cartagena, España
Mario Muñoz Organero,
Juan Vicente Capella Hernández,
Universidad de Carlos III, España
Marta Costa Rosatelli, Universidad
Valencia, España
Católica de Santos, Brasil
Lluís Vicent Safont, Universidad
Mercedes Caridad Sebastián,
Ramón Llul, España
Universidad Carlos III, España
Luis Benigno Corrales Barrios,
Universidad de Camagüey, Cuba
Miguel Angel Gómez Laso,
Universidad Pública de Navarra,
España
Miguel Ángel Redondo Duque,
Universidad de Castilla-La Mancha,
España
Miguel Angel Salido, Universidad
Politécnica de Valencia, España
Oriol Gomis Bellmunt,
Catalunya, España
Rafael Pastor Vargas, UNED,
España
Raúl Antonio Aguilar Vera,
Universidad Autónoma de Yucatán,
México
Robert Piqué López, Universidad
Politécnica de Catalunya, España
Víctor González Barbone,
Universidad de la República,
Uruguay
Victoria Abreu Sernández,
Yod Samuel Martín García,
España
Equipo Técnico: Diego Estévez González,
IEEE-RITA es una publicación lanzada en Noviembre de 2006 por el Capítulo Español de la Sociedad de
Educación del IEEE (CESEI) a través de su Comité Técnico, de Acreditación y Evaluación (CTAE), y
apoyada por el Ministerio Español de Educación y Ciencia a través de la acción complementaria TSI200524068-E. Actualmente es apoyada por el Ministerio Español de Ciencia e Innovación a través de la acción
complementaria TSI2007-30679-E.
IEEE-RITA
(Viene de la Portada)
ARTÍCULOS SELECCIOADOS /ARTIGOS SELECIOADOS CITA 2009
Editores Invitados: Xabiel G. Pañeda y Álvaro Rendón
Presentación CITA 2009 ………..……………..……………............................................
……………..........…………………………………..... Xabiel G. Pañeda y Álvaro Rendón
221
LooKIng4LO Sistema Informático para la extracción automática de Objetos de
Aprendizaje Caso de Estudio ...………………….…………………………………………
……....................................................…….....………….… Regina Motz, Claudia Badell,
Martín Barrosa, Rodolfo Sum, Gabriel Díaz y Manuel Castro
223
Hacia una arquitectura para sistemas de e-learning basada en PoEML.................................
….……………... Roberto Pérez Rodríguez, Manuel Caeiro Rodríguez y Luis Anido Rifón
230
IEEE-RITA é uma publicação da Sociedade de Educação do IEEE, gerida pelo Capitulo
Espanhol e apoiada pelo Ministério Espanhol de Ciência e Inovação através da acção
complementar TSI2007-30679-E, Rede Temática do CESEI.
IEEE-RITA is a publication of the IEEE Education Society, managed by its Spanish
Chapter, and supported by the Spanish Ministry of Science and Innovation through
complementary action TSI 2007-30679-E, Thematic Network of CESEI.
Vol. 4, um. 3, 08/2009
IEEE-RITA es una publicación de la Sociedad de Educación del IEEE, gestionada por su
Capítulo Español y apoyada por el Ministerio Español de Ciencia e Innovación a través de la
acción complementaria TSI2007-30679-E, Red Temática del CESEI.

Revista Iberoamericana de Tecnologías del/da - IEEE-RITA

Transcrição

Documentos relacionados

RE/MAX Portugal

Traduzir-se Traducirse

espanhol - Colégio 24 Horas

RE/MAX Spain

Venda - RE/MAX Chile

PROIBER

Chile - remax.ch

RE/MAX Argentina - RE/MAX Colombia

Colores para toda la casa

RE/MAX Argentina

Diseño de un Entorno Colaborativo Móvil para Apoyo al - IEEE-RITA

Artículos - El profesional de la información

Descargar Panorama de la Infraestructura de Datos

fr - Control Your Pain for Healthcare Professionals