INGENIERIA DE SOFTWARE EDUCATIVO con MODELAJE Orientado por

objeto! UN MEDIO "ARA DESARROLLAR MICROMUNDOS

INTERACTIVOS
Ricardo A# G$ME% CASTRO
A&'aro (# GALVIS "AN)UEVA
O&*a MARI+O DREWS
Re,-en
Las metodologas convencionales de Ingeniera de Software Educativo (ISE) tienen mecanismos robustos para hacer
un anlisis de necesidades y diseo educativo completos pero poco han evolucionado con la tecnologa en lo
relacionado con el diseo computacional! "ara hacer uso efectivo de la informaci#n recolectada en las fases de
anlisis y diseo educativo se propone la inclusi#n del modelo orientado por ob$etos en todas las etapas del ciclo de
desarrollo y as unificar los t%rminos en los &ue se habla en cada etapa estableciendo un modelo del mundo del
problema y de su comportamiento' de este modo se hace referencia a ob$etos presentes en el modelo e(tendiendo as
su funcionalidad! )l llegar a la implementaci#n los resultados obtenidos se transcriben al lengua$e de programaci#n
escogido cambiando la sinta(is en &ue se e(presa el modelo mas no la semntica! Esta propuesta se est
implementando en L*+,-./I0)
*
proyecto en el &ue se circunscribe esta ponencia!
INTRODUCCI$N
*sar la informtica como apoyo a procesos de aprendi1a$e ha sido una in&uietud &ue durante
mucho tiempo ha sido investigada y probada por muchas personas! Su asimilaci#n dentro de
instituciones educativas incluyendo el hogar ha aumentado en los 2ltimos aos con lo &ue la
demanda por software educativo de alta calidad es cada ve1 mayor!
"ara lograr software con las condiciones deseadas dentro de las fases de anlisis y diseo del
mismo se deben incorporar aspectos didcticos y pedag#gicos &ue faciliten y garanticen la
satisfacci#n de necesidades educativas! Se debe involucrar efectivamente a los usuarios para
conseguir identificar necesidades y3o problemas especficos y se puedan establecer mecanismos
de resoluci#n adecuados y apoyar cada una de las fases en s#lidos principios educativos y de
comunicaci#n humana 45! -etodologas vigentes de ingeniera de software educativo (ISE) como
la propuesta por 6alvis 45 atienden muy bien estos re&uerimientos y permiten al e&uipo
encargado de dicha labor asumir con propiedad su funci#n!
"or otra parte la ingeniera de software como disciplina ha evolucionado significativamente en lo
&ue se refiere a modelos conceptuales y herramientas de traba$o 4 5 &ue hacen del proceso de
desarrollo y mantenimiento de software una actividad cada ve1 menos dependiente del arte de
&uienes llevan a la prctica un diseo elaborado! +entro de estos aportes se destacan los de la
orientaci#n por ob$etos &ue cubre todo el ciclo de vida del software 45
El ob$etivo de este traba$o es integrar el modela$e ,!,! con la metodologa de ISE propuesta por
)lvaro 6alvis para enri&uecer el proceso de desarrollo de -ateriales Educativos
0omputari1ados (-E0) altamente interactivos!
0omo punto de partida se identificaron las caractersticas &ue debera poseer un -E0
particularmente un -icromundo Interactivo fruto de evaluar varias aplicaciones e(istentes en el
mercado con este tipo de micormundos! ) partir de all se hi1o adaptaci#n y3o redefinici#n de los
pasos &ue debe seguir una metodologa de ISE en su componente computacional!
MARCO CONCE"TUAL
En esta secci#n se tratan aspectos relacionados con la Ingeniera de Software (IS) e Ingeniera de
Software Educativo (ISE) &ue sern la base para la integraci#n de la metodologa ISE de 6alvis
4op.cit5 con las propuestas del paradigma ,,!
En la metodologa de ISE desarrollada por )lvaro 6alvis los micromundos interactivos $uegan
un papel clave! Es a trav%s de ellos como se crean ambientes l2dicos para aprender y es en ellos
donde se viven e(periencias &ue sirven de base para &ue el aprendi1 genere o apropie
conocimiento dependiendo de la manera (algortmica o heurstica) como se use el micromundo!
Una -etodo&o*.a de ISE
El siguiente diagrama ilustra el flu$o de acci#n en la metodologa de ISE sobre la &ue se desea
hacer incorporaci#n del enfo&ue ,,! 0omo se aprecia el ciclo de vida de una aplicaci#n
educativa puede tener dos maneras de e$ecuci#n en funci#n de los resultados de la etapa de
anlisis7 en el sentido de las manecillas del relo$ se procede a disear desarrollar y probar lo &ue
se re&uiere para atender una necesidad! En el sentido contrario se someta a prueba a&uello &ue se
encontr# puede satisfacer la necesidad!
Ilustracin 1 - Metodologa ISE propuesta por Galvis [2]
La metodologa de ISE en menci#n publicada en 8998 ofrece mecanismos de anlisis diseo
educativo y comunicacional prueba piloto y de campo bastante s#lidos toda ve1 &ue se
fundamentan en principios educativos comunicacionales y de tecnologa educativa de valide1
comprobada! Sin embargo desde la perspectiva computacional no ha evolucionado con lo &ue
cabe enri&uecerla tomando en cuenta los avances tecnol#gicos en el diseo y desarrollo
computacional &ue se han logrado en los 2ltimos aos! Estos avances permiten incluir dentro de
los productos de software nuevos recursos &ue enri&uecen el potencial de acci#n de los mismos y
&ue cabe usar desde el momento de formular su diseo!
La In*enier.a de So/t0are 1 e& paradi*-a OO
El enfo&ue de orientaci#n por ob$etos (,!,!) es un paradigma &ue tambi%n cubre el ciclo de vida
del software y &ue permite tener un mayor acercamiento al mundo &ue se modela y c#mo
funciona este mundo! En algunas metodologas de Ingeniera de Software (IS) se habla del
anlisis diseo y desarrollo como tres procesos independientes cuya me1cla tiene como resultado
final una aplicaci#n &ue satisface : o ; necesidades! El problema &ue se presenta esta disyunci#n
est dado por el modo como se traba$a normalmente en cada uno de estos procesos! El lengua$e
&ue mane$an los alcances y el resultado final de cada uno de ellos puede afectar el resultado final
global! )l tratarlos como entes independientes los mecanismos para acomodar y traducir la
informaci#n producida por cada proceso para &ue pueda ser <efectivamente usada< genera
potenciales fallos a interpretar de determinada manera la informaci#n all contenida!
-ucha informaci#n o documentaci#n de apoyo &ue podra evitar estos problemas no puede ser
usada ya sea por&ue est incompleta o no e(iste o por el contrario e(iste en demasa o no est
<formali1ada< generando <ruido< innecesario &ue en lugar de evitar problemas los acrecienta!
)dems cuando un error es detectado puede &ue sea una falla &ue haya estado latente desde el
proceso de anlisis o diseo y se haya hecho visible en etapas del desarrollo! Es difcil y costoso
solucionarlo por&ue puede re&uerir <echar al cao< lo &ue se ha hecho e incluso puede ser
necesario redisear la aplicaci#n!
El enfo&ue ,!,! busca resarcir las deficiencias &ue se presentan en cada una de las etapas del
ciclo de vida de la IS convencional permitiendo obtener una me$or representaci#n del mundo y
de los re&uerimientos particulares de una aplicaci#n en dicho mundo! Este enfo&ue puede ser
aplicado indistintamente al anlisis diseo o desarrollo de una aplicaci#n! =o es estrictamente
necesario usar el enfo&ue en todas las etapas del ciclo de vida de una aplicaci#n! Si se desea se
puede elaborar un buen anlisis y diseo ,!,! a2n cuando la implementaci#n no necesariamente
siga el mismo es&uema! Sin embargo es una e(celente alternativa usar ,!,! en todo el ciclo de
vida buscando aprovechar al m(imo todas las bondades de este nuevo paradigma 45!
Caracter.tica de& en/o2,e O#O#
0on ,!,! se puede hacer representaci#n del mundo &ue se desea modelar en t%rminos de los
ob$etos &ue posee! 0ada uno de ellos tiene sus propias caractersticas &ue lo identifican y un
comportamiento especfico! Estos aspectos pueden formali1arse con este enfo&ue! 0on base en
las caractersticas y comportamiento del ob$eto se pueden definir invariantes &ue deben
cumplirse permitiendo as verificar &ue el ob$eto funciona como se &uiere!
+urante la definici#n de ob$etos del mundo se pueden usar los mecanismos de herencia y
polimorfismo para aprovechar las caractersticas y comportamiento de algunos ob$etos bsicos
e(tendi%ndolos para conseguir ob$etos con un comportamiento ms especfico! )dems se puede
usar otra importante caracterstica llamada <reutili1aci#n de c#digo< definiendo ob$etos &ue
pueden ser usados en futuros desarrollos!
Ventaja de ,ar e& en/o2,e OO
Las venta$as de usar el enfo&ue ,!,! se traducen en me$oramientos de calidad a lo largo del ciclo
de vida de una aplicaci#n facilitando adems el mantenimiento y la creaci#n de nuevas versiones
&ue e(tiendan el programa!
)l disminuir las barreras entre las etapas de anlisis diseo y desarrollo se garanti1a &ue se est
hablando de las mismas cosas y en los mismos t%rminos desde el comien1o del anlisis hasta el
final de la etapa de implementaci#n! Esto evita inconsistencias y permite verificar &ue las cosas
estn claramente definidas y cumplen con todos los re&uerimientos incluso antes de escribir una
lnea de c#digo del programa! Las caractersticas anteriormente mencionadas (encapsulamiento
herencia reutili1aci#n) permiten crear un software mucho ms robusto!
"or 2ltimo el hecho de modelar el mundo y no 2nicamente los datos necesarios para determinada
aplicaci#n permiten crear diversas aplicaciones sobre la misma informaci#n sin repetir los
procesos de anlisis de los mismos! Esto ofrece la posibilidad de dedicarse a cumplir con los
re&uerimientos de la aplicaci#n basndose en las facilidades &ue ofrecen los ob$etos del mundo
ya modelados!
Se pueden enunciar varios beneficios de la apro(imaci#n orientada por ob$etos 457 reutili1aci#n de
software7 permite describir clases y ob$etos &ue podrn ser usados en otras aplicaciones'
estabilidad7 el diseador piensa en t%rminos de comportamiento de ob$etos no en detalles de ba$o
nivel' diseo rpido y de alta calidad puesto &ue se concentra en satisfacer los re&uerimientos y
no en detalles t%cnicos' integridad' facilidad de programaci#n al usar efectivamente toda la
informaci#n de la fase de diseo poni%ndola en t%rminos de un lengua$e especfico' facilidad de
mantenimiento dado &ue al tener el modelo del mundo es fcil reali1ar mantenimiento en
t%rminos de ob$etos atributos y m%todos de los mismos' independencia en el diseo el diseo de
un software se puede hacer independientemente de plataformas software y hardware!
La ISE enri2,ecida con en/o2,e OO
En el caso particular de la ISE usar ,!,! en todos los procesos computacionales (anlisis diseo
y desarrollo) permite refle$ar fcilmente en los ambientes todo a&uello &ue es importante desde el
punto de vista educativo! Esto forma parte del comportamiento del mundo y dicho
comportamiento puede ser modelado claramente con este enfo&ue!
"ara poder tener un punto de partida s#lido se hi1o la identificaci#n de los atributos &ue cual&uier
micromundo interactivo debera tener (necesario) y de a&uellos &ue seran opcionales (deseables)
revisando diversidad de -E0s &ue son buenos prototipos de software basado en micromundos
interactivos!
E&e-ento de ,n Micro-,ndo Interacti'o
En la siguiente tabla se resumen los elementos &ue valdra la pena incluir al crear un micromundo
interactivo! Esta lista de elementos se hi1o tomando como base un grupo representativo de
programas e(istentes en el mercado &ue incluye micromundos interactivos7 /I- -i castillo de
>antasa ?usy /own -other 6oose >)*=) Sim0ity @ar0raft -ath Aabbit!
Tabla 1 - Eleentos de un icroundo Interactivo
E&e-ento Tipo de e&e-ento
)rgumento e historia =ecesario
Bariables 0ompensatorias =ecesario
Bariables de 0ontrol =ecesario
Bariables de Aesultado =ecesario
-undo 3 Escenarios =ecesario
Aetos (Implcitos 3 e(plcitos) =ecesario
"ersona$es y Aoles =ecesario
,b$etos 3 Cerramientas =ecesario
Donas de 0omunicaci#n =ecesario
-ecanismos de 0omunicaci#n *suarioE)plicaci#n =ecesario
)mbientaci#n 3 0aracteri1aci#n =ecesario
Aecuperaci#n de estados anteriores +eseable
=iveles de +ificultad +eseable
-ane$o de informaci#n del usuario +eseable
-ecanisrmos para )nlisis de desempeo +eseable
)mpliaci#n de las posibilidades del micromundo +eseable
"ersonali1aci#n del ambiente +eseable
Soporte al traba$o en grupo +eseable
METODOLOG3A ISE4OO
La propuesta &ue se desarrolla en este documento busca unir todo lo anteriormente e(puesto E
metodologa ISE con paradigma ,!, E con miras a crear ambientes basados en micromundos
interactivos! El gran reto es disear e implementar icroundos altaente interactivos &ue
tomen muy en cuenta el potencial tecnol#gico y los recursos disponibles actualmente sobre una
slida base educativa ! counicacional!
El enfo&ue base para la conceptuali1aci#n y diseo de micromundos est desarrollado en el libro
de 6alvis 4op.cit" caps! F y G5 y las adiciones propuestas provienen de mecanismos de ingeniera de
software usados actualmente en Ludomtica para el anlisis y diseo de -E0s 45! "ara establecer
la estructura gen%rica sobre la cual se puedan <montar< micromundos l2dicos se va a tener en
cuenta el con$unto de elementos mencionados en 6alvis 4op.cit.5 y se usa el enfo&ue ,!,! para
definir el modelo de datos! La =otaci#n usada en este modela$e modelo es *-L 45!
Siguiendo el ciclo de vida de un -E0 la siguiente descripci#n permte entender cada una de sus
etapas enri&uecidas con el enfo&ue ,, mencionado!
An5&ii
El ob$etivo de esta etapa es determinar el conte(to en el cual se va a crear la aplicaci#n y derivar
de all los re&uerimientos &ue deber atender la soluci#n interactiva como complemento a otras
soluciones basadas en uso de otros medios (personales impresos audioEvisuales e(perienciales)
teniendo claro el rol de cada uno de los medios educativos seleccionados y la viabilidad de
usarlos!
+e acuerdo con 6alvis 4op.cit5 en esta etapa se establece como mnimo la siguiente informaci#n7
#aractersticas de la poblacin ob$etivo
7 edad (fsica y mental) se(o caractersticas fsicas y mentales (si son relevantes)
e(periencias previas e(pectativas actitudes aptitudes intereses o motivadores por aprender!
#onducta de entrada ! capo vital
7 nivel escolar desarrollo mental fsico o psicol#gico entorno familiar y escolar etc!
%roblea o necesidad a atender
"ara establecer la necesidad se puede recurrir a los mecanismos de anlisis de necesidades
educativas en 4H cap! I5! Estos mecanismos usan entrevistas anlisis de resultados acad%micos
etc! para detectar los problemas o posibles necesidades &ue deben ser atendidas! El problema
o necesidad no tiene &ue estar necesariamente relacionado con el sistema educativo formal
pueden ser necesidades sentidas econ#micas sociales normativas etc!
*na ve1 identificado el problema se deben establecer las bases para resolverlo! %rincipios
pedaggicos ! did&cticos aplicables 4
H cap! J5! En esta fase se debe anali1ar c#mo se ha llevado a cabo el proceso de ensean1aE
aprendi1a$e para establecer c#mo debe enfocarse el ambiente &u% factores tomar en cuenta
&u% ob$etivos debe cumplir!
'usti(icacin de uso de los edios interactivos
como alternativa de soluci#n! "ara cada problema o necesidad encontrada se debe establecer
una estrategia de soluci#n contemplando diferentes posibilidades! El apoyo informtico debe
ser tomado en cuenta siempre y cuando no e(ista un mecanismo me$or para resolver el
problema7 soluciones administrativas ver si el problema se soluciona al tomar decisiones de
tipo administrativo' soluciones acad%micas cambios en metodologas de clase' me$oras a los
medios y materiales de ensean1a contemplando el uso de medios informticos! *na ve1 &ue
se han anali1ado todas las alternativas se puede decir por &u% el uso de medios informticos
es una buena soluci#n! La $ustificaci#n se puede basar en la no e(istencia de otro medio me$or
y en la relaci#n costoEbeneficio para la instituci#n pues puede ser &ue e(ista una me$or
soluci#n pero &ue demande mayor tiempo y esfuer1o o un mayor costo econ#mico etc!
Epeci/icaci6n de re2,eri-iento
0omo sntesis de la etapa de anlisis se deben formular los re&uerimientos &ue deber atender el
material interactivo &ue se desea obtener!
La especificaci#n de re&uerimientos debe contener lo siguiente7
)escripcin de la *plicacin
7 0ontiene las caractersticas particulares de la aplicaci#n dentro de determinado dominio7
rea de contenido restricciones etc! Se hace una descripci#n de lo &ue har la aplicaci#n!
)dems se deben de$ar claras las restricciones &ue tendr y una descripci#n de los posibles
escenarios de interacci#n &ue tendr el usuario!
Las restricciones estn relacionadas con aspectos tales como7
"oblaci#n ,b$etivo y sus caractersticas (informaci#n recopilada en la fase de anlisis)!
)reas de contenido y sus caractersticas!
"rincipios pedag#gicos aplicables
-odos de uso de la aplicaci#n7 individual grupal con apoyo de instructor etc!
0onducta de entrada! /odo a&uello con lo &ue el usuario cuenta antes de usar la aplicaci#n7
e(periencias conocimiento habilidades etc!
Los escenarios de interacci#n corresponden a los momento de interacci#n &ue tendr el
usuario en cada uno de los ambientes del mundo! "or e$emplo el registro de datos al iniciar la
aplicaci#n la escogencia de herramientas etc!
)iagraas de Interaccin
7 "ermiten ver secuencias de interacci#n entre el usuario y la aplicaci#n representando lo &ue
se espera del dilogo y dando ms detalle a la descripci#n te(tual de la descripci#n de la
aplicaci#n! Los diagramas de interacci#n son un formalismo &ue permite ver la secuencia de
acciones entre diferentes partes de la aplicaci#n involucrada en llevar a cabo determinada
actividad! Es importante ver la secuencia de acciones para cada escenario de interacci#n! 0on
base en estos diagramas se pueden ver cules pueden ser las necesidades de informaci#n en
cada escenario de interacci#n y se puede ir pensando en cules pueden ser los algoritmos &ue
sern usados!
Los diagramas de interacci#n mencionados en esta etapa tienen la siguiente sinta(is7
K=,-?AE +I)6A)-)L
Ilustracin 2 - )iagraa de Interaccin
El actor en este caso corresponde a cada uno de los diferentes usuarios de la aplicaci#n! Los
ob$etos aplicaci#n y registro corresponden en este caso a las partes de la aplicaci#n involucradas
en el diagrama! =#tese &ue en este momento no se habla de ning2n modelo de datos especfico
simplemente se especifica &u% es lo &ue va a hacer la aplicaci#n!
Las operaciones &ue aparecen en el diagrama son re&uerimientos de informaci#n &ue se
comparten entre cada uno de los diferentes ob$etos! 0on base en estas operaciones se puede
especificar la secuencia para llevar a cabo la acci#n ob$etivo del diagrama! Se debe tener un
diagrama por cada escenario de interacci#n de la aplicaci#n
Die7o
El diseo del -icromundo Interactivo se reali1a a tres niveles diferentes7 educativo
comunicacional y computacional! La metodologa de ISE original es fuertes en cuanto al diseo
educativo y diseo comunicacional de -E0s! En esta propuesta ISEE,, se van a tomar en
cuenta estas fortale1as y se van a usar de manera &ue sean refle$adas en el diseo computacional
de la aplicaci#n y en la implementaci#n de la misma!
)l disear el ambiente en el &ue se desarrollar la acci#n se deben definir claramente los
elementos &ue se determinaron como necesarios en todo micromundo interactivo y a&uellos
deseables &ue convenga para el caso (ver /abla 8)! La identificaci#n de estos elementos en esta
etapa permite crear mayor vnculo con la etapa de desarrollo! -uchas de las decisiones
importantes acerca del micromundo y su comportamiento se toman a&u!
Se va a reali1ar el diseo usando el enfo&ue ,!,! formali1ando muchos de los aspectos
relacionados con la aplicaci#n definiendo desde esta etapa los ob$etos su comportamiento el
prop#sito de la aplicaci#n las restricciones e(istentes y los escenarios de interacci#n!
0omo complemento al diseo educativo de ISE se plantea el uso de una metodologa de
especificaci#n y diseo &ue acer&ue mucho ms los resultados y formulaciones hechas en dicho
diseo educativo hacia la implementaci#n de la aplicaci#n! 0on esto se est garanti1ando un
diseo computacional y posterior implementaci#n con una alta calidad! 0ual&uier a$uste se puede
hacer en etapa de diseo reduciendo costos innecesarios en etapa de desarrollo!
En este documento se usa como base una propuesta planteada en por >igueroa 4op!cit y 5 la cual
servir como soporte al diseo ,!,! y posterior diseo de datos e implementaci#n de la
aplicaci#n! Se va usar *-L 4+5 para la notaci#n del modelo! Se desea as obtener una ar&uitectura
gen%rica para micromundos interactivos &ue pueda e(tenderse para satisfacer necesidades de un
problema en particular! Munto con la ar&uitectura se debe especificar la funcionalidad &ue el
usuario tendr sobre el modelo para saber &u% cosas puede hacer sobre %l!
) continuaci#n se define cada una de las etapas del diseo7 diseo educativo diseo
comunicacional! diseo computacional!
Die7o Ed,cati'o
/omando como punto de partida la necesidad o problema as como la conducta de entrada y
campo vital de la poblaci#n ob$eto se debe establecer lo &ue hay &ue ensear o refor1ar para
subsanar con apoyo del -E0 las necesidades encontradas! 0omo resultado de la fase de diseo
educativo se debe tener lo siguiente7 contenido y su estructura' micromundo' sistema de
motivaci#n' sistema de evaluaci#n! +e acuerdo con 6alvis 4op!cit cap F5 el diseo educativo debe
resolver los siguientes interrogantes7 NOu% aprender con el -E0P NEn &u% micromundo
aprenderloP N0#mo motivar y mantener motivados a los usuariosP N0#mo saber &ue el
aprendi1a$e se est lograndoP Las relaciones entre estos elementos se pueden visuali1ar as7
Ilustracin , - )ise-o educativo de un ME#
Qu aprender con el MEC ?
"ara resolver este interrogante se debe partir del &u% &ue subyace a micromundo7 contenidos a
tratar derivados de las necesidades o problemas tratando de detallar las unidades de contenido
&ue van a tomarse en cuenta en el -E0! Se debe definir la red semntica &ue relaciona los
conceptos &ue interesa desarrollar en la aplicaci#n! 0on base en esta red se puede establecer la
base de datos de contenidos &ue soporta el material! +ebe cuidarse la manera como se presentan
los contenidos en el -E0! Las relaciones de dependencia entre los diferentes temas deben
tomarse en cuenta para no for1ar el paso de un tema a otro y mantener coherencia a lo largo del
material!
Se debe tener clara la diferencia entre lo &ue se sabe antes de usar el -E0 y lo &ue se espera &ue
se sepa al finali1ar el traba$o con %ste7 ,b$etivos contenidos y sus interrelaciones! Siguiendo la
idea de 6alvis 4op.cit cap! F5 se debe establecer esto en t%rminos operacionales estableciendo los
contenidos a tratar y el ob$etivo terminal del -E0 4op.cit cap!8Q5 y luego descomponiendo %ste en
ob$etivos especficos y secuencindolos!
En qu ambiente o micromundo aprenderlo ?
*n -E0 se compone de varios ambientes o micromundos cada uno relacionado con un ob$etivo
en particular! "ara cada micromundo se debe establecer7 )rgumento -undo Escenarios Aetos
"ersona$es y Cerramientas ,b$etos! Siguiendo el modelo ,!,! se deben definir las clases (ver
glosario) &ue identifican cada uno de estos elementos! )lgunas de estas clases sern la base sobre
la cual se puede e(tender el micromundo! )l reali1ar el modela$e del mundo se deben definir las
relaciones e(istentes entre estas clases!
La definici#n de los elementos del micromundo (escenarios ob$etos etc!) se e(presa usando una
tabla como la siguiente7
Tabla 2 - Especi(icacin general de los eleentos del Microundo Interactivo
ELE-E=/, 0)A)0/EARS/I0)S O*S SE "*E+E C)0EA 0,= EL
ELE-E=/, P
=ombre del elemento
,bservaciones
Informaci#n &ue se desea tener en
el elemento
Ou% necesidades de informaci#n
satisface el elemento P

*na tabla como %sta permite hacer una clasificaci#n inicial de todo lo &ue est en el mundo &ue
se est modelando! )dems al tener claras las caractersticas y lo &ue se puede hacer con cada
elemento del mundo se pueden establecer relaciones entre ellos! Estos elementos son posibles
clases de ob$etos' al refinar su definici#n y al establecer las relaciones se puede saber cules de
estos elementos sern clases &ue harn parte del modelo esttico del mundo y cuales son
simplemente atributos comple$os de alguna clase de dicho modelo!
)dems se debe definir &u% cosas puede hacer el usuario en el mundo! En t%rminos de *-L se
refiere a los casos de uso en el mundo! Los casos de uso se identifican al establecer los
re&uerimientos de informaci#n &ue debe satisfacer la aplicaci#n! Los casos de uso pueden
e(tenderse de acuerdo con las necesidades del problema! 0ada caso de uso se especifica usando
diagramas de interacci#n &ue permitan ver los ob$etos &ue estn involucrados as como la
secuencia de mensa$es entre ellos!
Cmo motivar y mantener motivados a los usuarios ?
Seg2n -ocTus 45 Seymour "apert cree &ue una de las contribuciones principales de "iaget ms
all del concepto de estadios de desarrollo es mostrar &ue la gente posee diferentes teoras acerca
del mundo! +e acuerdo con esto los nios aprenden me$or cuando son alentados a apoyarse sobre
su propia intuici#n y a emplear lo &ue ya saben para desarrollar nuevas ideas!
En esta etapa del proceso de diseo se definen las metforas usadas as como cada persona$e &ue
aparece de$ando claro cul es el rol &ue el usuario $uega! las herramientas de interacci#n &ue
podr usar y cul es el reto &ue debe resolver!
En el caso de los micromundos interactivos es vital despertar motivaci#n intrnseca proponiendo
ambientes o situaciones &ue sean interesantes &ue despierten curiosidad &ue inviten al usuario a
indagar a trav%s de la e(perimentaci#n con el micromundo! Cay &ue mantener motivados a los
usuarios para &ue el traba$o &ue se tenga con la aplicaci#n sea efectivo y de provecho! El
micromundo debe ser novedoso y buscar sorprender al usuario darle nuevas oportunidades de
acci#n y plantear nuevos retos! Esto aumenta la curiosidad de los usuarios y los mantiene atentos
al desarrollo del traba$o con la aplicaci#n! 0omplementariamente se deben plantear retos &ue
mantengan alerta a usuario en busca de pistas para resolverlos y con un nivel de comple$idad
apropiado!
El uso de ambientes educativos debe propiciar la generaci#n de motivaci#n intrnseca en los
usuarios para lograr un efecto duradero en el proceso de ensean1a aprendi1a$e! )dems el uso
de fantasas &ue sean interesantes para ellos para llegar a lo &ue "iaget llama intento de asimilar
e(periencia en las estructuras e(istentes en su mente con mnimas necesidades de acomodarlas a
las demandas de una realidad e(terna 45! Es por eso &ue personas como Aichard "attis 45 han
coincidido en la necesidad de crear ambientes educativos &ue aprovechen la motivaci#n &ue los
nios sienten por usar $uegos de vdeo como =intendo antes de for1arlos a usar es&uemas
tradicionales de aprendi1a$e p! e! libros!
La especificaci#n unida a los resultados del diseo educativo puede ser usada como informaci#n
de base para usar herramientas como las encontradas en Aational 4op.cit5 para elaborar el diseo
,!,! de los datos del mundo de la aplicaci#n! Cay &ue refle$ar la motivaci#n en el modelo! Esto
se nota adicionando eventos al modelo as como estableciendo relaciones para &ue las clases del
modelo reaccionen acorde con todo lo &ue pudiera suceder en el modelo! Estas reacciones
lograran captar la atenci#n del usuario e incluso generar mayor curiosidad ante el
comportamiento de la aplicaci#n ante las acciones y decisiones &ue se tomen!
Cmo saber que el aprendizaje se est logrando ?
Las situaciones de evaluaci#n (retos etc!) deben estar relacionadas con los contenidos! La
relevancia y pertinencia de determinado reto o prueba se debe sustentar con base en los
contenidos &ue se han presentado y con la manera como han sido tratados!
Situaciones de evaluacin
El sistema de evaluaci#n est relacionado con todos los retos del mundo! +e acuerdo con esto
debe definirse el nivel de logro para cada reto &ue unido con todas las caractersticas (nivel de
dificultad tipo de aprendi1a$e etc!) debe permitir evaluar &u% ha hecho el usuario en el mundo y
si lo hi1o correctamente o no! Estos indicadores de logro deben llevarse en la historia &ue el
usuario tiene!
Cay &ue tener en cuenta el tipo de cosas &ue se desea aprender7 si el aprendi1a$e es reproductivo
si es de nivel superior o si lo &ue se aprende es afectivo o psicomotor!
En funci#n del momento de evaluaci#n e(isten varios tipos de evaluaci#n para usar7 evaluaci#n
sumativa7 averiguar cunto logr# el aprendi1' evaluaci#n diagn#stica7 aplicada antes de iniciar la
interacci#n con el -E0 para saber el punto de partida' evaluaci#n formativa7 situaciones para
ayudar a descubrir o practicar transferir y afian1ar destre1as conceptos o habilidades!
Los retos &ue se presentarn al usuario se deben establecer de acuerdo con el contenido7
descripci#n representaci#n grfica (si es aplicable) y soluci#n (o mecanismo de verificaci#n para
retos ms comple$os)!
Tabla , - )e(inicin de retos en el ME#
O8JETIVO TI"O DE RETO O8SERVACIONES
)&u se relacionan
los ob$etivos del
-E0
"ara cada ob$etivo se define el
tipo de restos &ue pueden usarse
"ara cada tipo de reto se debe especificar
c#mo es la descripci#n representaci#n tipo
de pistas y modo de obtenerlas (si se van a
dar) y mecanismos de soluci#n
Mane$o de retroin(oracin" re(uer.o ! niveles de logro
+ependen mucho del enfo&ue del micromundo seg2n sea para aprendi1a$e por descubrimiento
(enfo&ue heurstico) o por transmisi#n (enfo&ue algortmico)! En el caso de ambientes heursticos
como es el caso de la mayora de los micromundos interactivos la retroinformaci#n se traduce en
mostrar en el micromundo el efecto de lo &ue hi1o el usuario independientemente de si es
correcto o no para &ue %ste sea &uien analice lo &ue ha pasado y tome decisiones al respecto!
"ara decidir si el usuario ha logrado determinado nivel de aprendi1a$e se deben establecer
criterios claros! "ara esto deben e(tenderse todos los elementos del modelo computacional del
mundo para &ue reaccionen ante determinados eventos! Estos eventos deben modelarse
especificando &u% eventos genera cada elemento del modelo (mundo escenario etc!)! )dems se
debe especificar para cada elemento del modelo ante cules eventos est en capacidad de
reaccionar! Esto se puede lograr definiendo una clase Evento a partir de la cual se pueden
establecer todos los eventos del sistema! Esta clase estara relacionada con todos los elementos
del modelo &ue deseen generar un tipo de evento &ue identifi&ue acciones hechas por el!
Die7o Co-,nicaciona&
En esta fase del proceso de diseo se define la interfa1 (1ona de comunicaci#n usuarioEprograma)
de la aplicaci#n! En este momento se debe complementar ese bos&ue$o definiendo formalmente
los ob$etos &ue posee cada pantalla y cules elementos del mundo son usados3afectados! Se toma
como base la descripci#n macro dada en especificaci#n! Es importante conseguir &ue la interfa1
sea7 amigable fle(ible y agradable de usar' tambi%n debe ser consistente es decir cuidando &ue
los mensa$es y la distribuci#n en pantalla el $uego de colores etc! sigan un mismo patr#n
tambi%n es necesario &ue sea altamente interactiva lo cual conlleva tener mecanismos de
comunicaci#n entre el usuario y la aplicaci#n!
)l definir la interfa1 se debe tener en cuenta7 Ncules dispositivos de entradaEsalida conviene
poner a disposici#n del usuario para traba$ar con el -icromundo P N&u% 1onas de comunicaci#n
entre usuario y programa debe tener el -icromundo P Ncules son las caractersticas de dichas
1onas de comunicaci#n P Nc#mo verificar &ue la interfa1 satisface los re&uisitos mnimos
deseados P! "ara cada pantalla de la interfa1 se deben definir las 1onas de comunicaci#n as como
la distribuci#n de las mismas! "ara hacer esto se deben seguir indicaciones de diseo de
interfaces! En 6alvis 4op.cit cap!G5 se hace una revisi#n de aspectos a tomar en cuenta!
)l disear una interfa1 tambi%n se deben tomar en cuenta restricciones tecnol#gicas
caractersticas de la poblaci#n y aspectos psicol#gicos de la percepci#n 4ibid5!
)s como se estableci# un modelo para el mundo se debe establecer un modelo para la interfa1
&ue est% atento a todo lo &ue ocurre en el mundo pero &ue sea independiente de %l! El es&uema de
interacci#n entre el mundo y la interfa1 se muestra en el siguiente diagrama7
Ilustracin / - Interaccin Inter(a.-Modelo del Mundo
El modelo computacional de la interfa1 consta de7
+efinici#n formal de cada pantalla
,b$etivo
Eventos del modelo del mundo &ue est en capacidad de detectar
+iagrama de la pantalla indicando cules ob$etos tiene y d#nde estn ubicados!
Listado de las caractersticas tanto de la pantalla como de cada ob$eto (colores tamao de
fuentes resoluci#n de imgenes etc!)
Enlaces con otros elementos de la interfa1! En caso de &ue alg2n ob$eto (p! e$! botones)
permitan <via$ar< a otras pantallas!
=otas adicionales! En caso de &ue se re&uiera reali1ar operaciones especiales en la interfa1!
"or e$emplo indicar si hay animaci#n cuando se activa o desactiva la pantalla si hay m2sica
de fondo etc!
+iagrama de flu$o de informaci#n en la Interfa1! te diagrama indica la relaci#n entre las
diferentes pantalla de la interfa1! 0on este diagrama se puede establecer cual es la secuencia
&ue se seguir en la aplicaci#n!
Die7o Co-p,taciona&
)l final de esta etapa se tiene como resultado claramente definidas cada una de las diferentes
clases de ob$etos incluyendo sus atributos (indicando si sern p2blicos Evisibles a todo el mundoE
o privados) el con$unto de m%todos y el invariante de cada clase &ue corresponde al con$unto de
restricciones o de re&uisitos &ue debe siempre cumplir una determinada clase! "or e$emplo se
puede tener definida una clase <relo$< &ue tiene como atributo un intervalo de tiempo! El
invariante de esta clase puede ser tan sencillo como <el intervalo debe ser siempre mayor o igual
a cero<!
+urante las fases de diseo educativo y comunicacional se han definido los diferentes ob$etos
tanto del mundo como de la interfa1! Esta informaci#n se refina en esta fase adecundola a las
posibilidades de la herramienta de desarrollo &ue se vaya a utili1ar! )lgunas clases necesitarn
e(tenderse para ser usadas en el modelo!
)dems se puede dar el caso de agregar nuevas clases y relaciones al modelo para dar mayor
funcionalidad al modelo acorde con los re&uerimientos propios de la aplicaci#n! La herramienta
de desarrollo puede ofrecer mecanismos &ue faciliten la implementaci#n de las interfa1! En caso
de no ser as el modelo del mundo se e(tiende de tal manera &ue pueda comunicarse
efectivamente con el modelo de interfa1 &ue deber ser desarrollado!
Munto al con$unto de clases llamado tambi%n odelo est&tico del undo se debe ilustrar la l#gica
acerca de c#mo se desarrollan cada una de las actividades en el modelo! "ara ello se deben refinar
los casos de uso (algunos de los cuales ya se han obtenido en fases anteriores ilustrando para
cada uno de ellos el proceso &ue se sigue! "ara hacer esto se pueden usar diagramas de
interacci#n &ue pueden ser de dos tipos7 diagramas de secuencia (similares a los usados en la fase
de especificaci#n) o diagramas de colaboraci#n! En estos diagramas ya se puede ver la secuencia
de mensa$es entre los diferentes ob$etos involucrados en cada caso de uso y se pueden modelar
todas las alternativas &ue puedan presentarse en cada caso!
Esta informaci#n puede ayudar a redefinir el modelo antes de iniciar la fase de desarrollo!
)dems permite validar si el modelo es completo y permite satisfacer todos los re&uerimientos de
la aplicaci#n!
La ilustraci#n I muestra los casos de uso generales de una aplicaci#n &ue atiende la funcionalidad
de micromundos interactivos! Estos casos de uso corresponden a a&uellos &ue son satisfechos en
el modelo gen%rico del mundo (ver Macobson 4op.cit5)! Estas son las cosas bsicas &ue puede hacer
el usuario7 puede recorrer todos los escenarios del mundo y en cada uno de ellos resolver retos!
"uede interactuar con persona$es y as obtener pistas para resolver determinado reto! )dems
puede recoger ob$etos &ue encuentra a su paso e incluso usar herramientas para afectar el
escenario!
La ilustraci#n F muestra el modelo de clases de mundo para un micromundo interactivo! Este
modelo puede considerarse como la base sobre la cual se pueden montar todos los elementos
presentes en la aplicaci#n! Este modelo usa notaci#n *-L! En dicho modelo se tiene el mundo y
su con$unto de ambientes! 0ada ambiente o escenario tiene un con$unto de ob$etos herramientas
retos y persona$es! El usuario puede navegar por el mundo libremente cambiando de escenarios
resolviendo retos e interactuando con persona$es!
Ilustracin 0 - )iagraa de casos de uso para un icroundo interactivo
Ilustracin 1 - Modelo 2M3 del Mundo" para un icroundo interactivo
Cay &ue estar atento a cuanto sucede en el modelo del micromundo! "ara esto deben e(tenderse
todos los elementos del mundo para &ue reaccionen ante determinados eventos! Estos eventos
deben modelarse especificando &u% eventos genera cada elemento del modelo (mundo escenario
etc!)! )dems se debe especificar para cada elemento del modelo ante cules eventos est en
capacidad de reaccionar!
"ara ello se puede definir una clase Evento a partir de la cual se pueden establecer todos los
eventos del sistema! Esta clase est relacionada con todos los elementos del modelo &ue deseen
generar un tipo de evento &ue identifi&ue acciones hechas por el!
+entro de los eventos &ue generan las clases del modelo estn7
Tabla / - Eventos en el Modelo
ELEMENTO EVENTOS
-undo
Iniciar )plicaci#n
/erminar )plicaci#n
0ambio de escenario
Escenario
0ambio de Aeto
Aesoluci#n de Aeto
Aecoger ,b$eto
Soltar ,b$eto
*suario
)ctuali1ar de la Cistoria
Escoger ob$eto
)ctivar ob$eto
"ersona$e
Cablar con el usuario
+ar ob$etos al usuario
Cerramienta
)ctivar herramienta
+esactivar herramienta
Estos eventos pueden aumentar de acuerdo con el sistema de motivaci#n y las relaciones
e(istentes entre persona$es herramientas y cosas especficas dentro del argumento del
micromundo! "ara poder <escuchar< eventos en el sistema se debe tener una clase Escuc4a!
El modus operandi de la relaci#n EventoEEscucha es similar a la del modelo observadorE
observado mencionado anteriormente! Se define un clase evento especfica para cada clase del
modelo &ue desee mane$ar eventos! Esta clase se encarga de despachar solamente los eventos
relacionados con una clase en particular!
)dems se debe crear una clase Escucha para cada tipo de eventos del modelo (eventos de
mundo eventos de escenario etc!) 0ada clase Escucha est atenta a recibir solamente los eventos
de determinada clase!
Dearro&&o
En esta fase se implementa la aplicaci#n usando toda la informaci#n obtenida anteriormente! Se
toma la definici#n de clases y se implementa en el lengua$e escogido (Mava +elphi!!!) tomando
en cuenta las restricciones computacionales &ue se tengan! Cay &ue establecer la herramienta de
desarrollo sobre la cual se va a implementar la aplicaci#n! Los criterios para escogerla incluyen'
costo disponibilidad en el mercado portabilidad de la aplicaci#n desarrollada facilidades al
desarrollador (ambientes grficos de desarrollo mecanismos de depuraci#n mane$o de versiones
etc!)!
En el desarrollo se busca &ue el modelo del mundo sea independiente de la interfa1! Esto facilita
el traba$o y permite traba$ar en paralelo!
La interfa1 se implementa usando la especificaci#n del diseo comunicacional! En algunos
ambientes de desarrollo la creaci#n de %sta se facilita con herramientas visuales de desarrollo! En
otros se tiene &ue programar cada uno de los elementos de la interfa1!
"r,eba A LO LARGO 9 AL FINAL de& dearro&&o
La metododologa propuesta permite ir depurando los componentes del modelo generado
haciendo validacu#n con e(pertos de los prototipos durante la etapa de diseo y prueba uno a uno
de los m#dulos desarrollados a medida &ue estos estn funcionales!
Superada la depuraci#n y a$uste se pone a disposici#n una versi#n beta del micromundo
interactivo! Esto conviene hacerlo con una muestra de la poblaci#n' se pretende a trav%s de dicha
prueba piloto verificar &ue efectivamente la aplicaci#n satisface las necesidades y cumple fon la
funcionalidad re&uerida!
CONCLUSIONES
El desarrollo de micromundos interactivos es una necesidad actual &ue debe ser atacada por
desarrolladores de software educativo! El avance tecnol#gico unido con la cultura informtica
cada ve1 mayor a nivel de estudiantes y profesores permite pensar en tener materiales educativos
computari1ados cada ve1 ms sofisticados &ue e(ploten todo el potencial tecnol#gico en pro de
apoyar efectivamente el proceso de ensean1aEaprendi1a$e!
La inclusi#n del modelo ,!,! articulado al ciclo de ISE permite aprovechar todo el potencial de
las metodologas de ISE y de la moderna ISE,,! Esto es importante a la hora de desarrollar
software de calidad! Esta integraci#n de enfo&ues facilita el mantenimiento computacional del
mundo en el &ue se desarrolla la acci#n as como la e(pansi#n de %ste a medida &ue se re&uiera
garanti1ndose as integridad con cada cambio &ue se realice en el modelo del mundo!
El es&uema de interacci#n entre la interfa1 y el modelo del mundo permite traba$ar en paralelo
cada uno de ellos y permite reali1ar cambios sin afectar el proceso de desarrollo! "or otra parte al
traba$ar ,!,! se facilita la reutili1aci#n de c#digo as como la portabilidad del mismo en el caso
de usar lengua$es de programaci#n ,!,! como M)B)!
La metodologa &ue se propone permite montar un micromundo interactivo sobre una estructura
gen%rica ya desarrollada e(tendi%ndola para satisfacer re&uerimientos especficos!
GLOSARIO DE T:RMINOS
*tributo
7 Es cada una de las caractersticas de un ob$eto7 identificador descripci#n!!!
#aso de uso
7 0orresponde a cada cosa &ue puede hacer un usuario dentro del modelo de datos! La identificaci#n de estos
casos de uso se hace con base en los re&uerimientos de la aplicaci#n a desarrollar
#lase
7 +efinici#n de atributos y m%todos para un con$unto de ob$etos!
)epuracin
7 Cace referencia a m%todos para refinar el c#digo del programa &ue se est desarrollando identificando y
eliminando todos los posibles errores &ue %ste tenga!
)iagraa de interaccin
7 Indica las secuencia de acciones &ue deben seguirse para reali1ar una tarea en el modelo computacional! Este
tipo de diagrama puede indicarse de dos maneras7 diagrama de secuencia en el cual se muestra la secuencia
lineal de acciones en determinado momento' diagrama de colaboraci#n muestra la secuencia de acciones de
modo no lineal resaltando las relaciones y3o dependencias entre diferentes clases del modelo!!
Escenario de interaccin
7 0ada uno de los momentos de interacci#n &ue tiene el usuario con la aplicaci#n (registrarse escoger reto etc!)!
Invariante de clase
7 Es todo a&uello &ue debe cumplir siempre cada clase! "or e$emplo si se definiera la <clase "ersona< se tendra
el siguiente invariante7 <una %ersona siepre tiene nobre" apellido ! docuento de identidad. 5o e6isten dos
personas con el iso docuento de identidad<!
'*7*
7 Es un lengua$e de programaci#n ,!,! desarrollado por Sun -icrosystems!
M8todo
7 0orresponde a cada una de las funciones &ue puede llevar a cabo un ob$eto p!e$! crearse destruirse dar su
identificaci#n etc!
Modelo est&tico
7 En la notaci#n *-L el modelo esttico corresponde al diagrama donde se muestran todas las clases definidas
para la aplicaci#n indicando para cada clase sus atributos y m%todos as como las relaciones &ue tiene con las
dems clases!
Modelo din&ico
7 0orresponde al con $unto de casos de uso de la aplicaci#n!
9b$eto
7 En el enfo&ue ,!,! un ob$eto es cual&uier cosa &ue puede ser identificada plenamente en el mundo es decir
&ue tiene unas caractersticas y comportamiento particulares!
%olior(iso
7 Es una caracterstica presente en la programaci#n
%ortabilidad
! 0apacidad &ue tiene una aplicaci#n de e$ecutarse en diferentes plataformas de hardware y software!
%rueba piloto:
"rueba de la aplicaci#n reali1ada con un grupo representativo de la poblaci#n ob$etivo
2M3
7 *nified -odeling Language! Es una manera estndar de modelar los datos de determinada aplicaci#n con una
notaci#n para e(presar los datos (atributos m%todos) las relaciones entre los mismos y el con $unto de
re&uerimientos &ue pueden ser satisfechos en la aplicaci#n!
a*radeci-iento
Este traba$o se reali1# en el proyecto L*+,-./I0) el cual es una alian1a estrat%gica entre la
*niversidad de Los )ndes La >undaci#n Aafael "ombo y el Instituto 0olombiano de ?ienestar
>amiliar! 0uenta con el auspicio de 0,L0IE=0I)SE E/I (contrato H9IE9G) y del I0?>E
subdirecci#n de "rotecci#n (contrato JGHE9G)