Tecnológico de Monterrey: Campus Querétaro

Tecnolgico de Monterrey
Campus Quertaro
Rectora Zona Centro

Direccin de Ingeniera y Arquitectura
Departamento de Sistemas Computacionales
Un Marco de Referencia para la Construccin de un

Motor de Ejecucin de Procesos de Aprendizaje
Complejos Basado en la Integracin de Servicios Web a
Travs de Lenguajes de Modelado Educativo
Tesis III
Autor:
Director:
Eduardo Daniel Jurez Pineda

Jorge A. Torres Jimnez
Quertaro, Mxico, 24 de febrero de 2011.
DASL4LTD Research Group [C-QRO-17/07]

The Distributed and Adaptive Systems Lab
for Learning Technologies Development
Un Marco de Referencia para la Construccin de un

Motor de Ejecucin de Procesos de Aprendizaje
Complejos Basado en la Integracin de Servicios Web a
Travs de Lenguajes de Modelado Educativo
Identificador del entregable:

Autor:
T3
Eduardo Daniel Jurez Pineda
Fecha del entregable:

Fecha de inicio:
Duracin:
Coordinador del entregable:
28 de febrero de 2011
1 de enero de 2010
1 ao 2 meses
Jorge Torres
Clasificacin:
Circulacin Pblica
Quertaro, Mxico, 24 de febrero de 2011.
ndice general
v
ndice general
ix
ndice de figuras
ndice de tablas
xiii
1. Introduccin
1.1. Contexto del problema . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.1. En Busca de la Ejecucin de Procesos de Aprendizaje Complejos
1
3
1.2. Motivacin del trabajo de investigacin . . . . . . . . . . . . . . . . .
1.3. Objetivos del trabajo de investigacin . . . . . . . . . . . . . . . . .
1.4. Contribuciones esperadas . . . . . . . . . . . . . . . . . . . . . . . .
1.5. Metodologa de investigacin . . . . . . . . . . . . . . . . . . . . . .
10
1.6. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . .
12
2. Estado del arte
15
2.1. La evolucin de los Sistemas de E-learning . . . . . . . . . . . . . . .
15
2.2. Procesos de Aprendizaje Complejos . . . . . . . . . . . . . . . . . . .
17
2.3. Lenguajes de Modelado Educativo . . . . . . . . . . . . . . . . . . .
19
2.3.1. Caractersticas de Diseo, Ejecucin y Control de un LME . .
20
2.3.2. IMS Learning Design . . . . . . . . . . . . . . . . . . . . . . .
23
2.3.3. LAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.3.4. LPCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.4. Motores de Ejecucin de Procesos de Aprendizaje . . . . . . . . . . .
34
2.4.1. Motores de Ejecucin de Flujos de Trabajo . . . . . . . . . .
35
2.4.2. El Motor de Ejecucin de IMS LD . . . . . . . . . . . . . . .
41
2.4.3. El Ambiente de Tiempo de Ejecucin de SCORM . . . . . . .
50
2.5. Diversidad Pedaggica y Descripcin del Flujo de Aprendizaje . . . .
56
2.5.1. Evaluacin de los Flujos de Aprendizaje Basada en Patrones

de Control de Flujos de Trabajo (WCP) . . . . . . . . . . . .
57
2.6. Composicin Dinmica y No Anticipada . . . . . . . . . . . . . . . .
62
2.7. Descentralizacin de los Servicios de Aprendizaje . . . . . . . . . . .
63
2.7.1. Servicios de Aprendizaje . . . . . . . . . . . . . . . . . . . . .
64
2.7.2. Arquitectura Orientada a Servicios . . . . . . . . . . . . . . .
64
2.8. Separacin del Proceso de Aprendizaje y Servicio . . . . . . . . . . .
66
2.9. Disponibilidad y Contenido del Servicio de Aprendizaje
. . . . . . .
66
2.10. Soporte Transaccional . . . . . . . . . . . . . . . . . . . . . . . . . .
67
2.10.1. Modelos de Transacciones Avanzados . . . . . . . . . . . . . .
68
2.11. Otros Aspectos a Considerar en el Diseo de Motores de Ejecucin .
72
2.11.1. Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . .
73
2.11.2. Instanciacin . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
2.12. Resmen del captulo . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
3. Planteamiento del problema
83
3.1. Un escenario de aprendizaje . . . . . . . . . . . . . . . . . . . . . . .
84
3.2. Primera etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
3.3. Segunda etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
3.4. Tercera etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
3.5. Cuarta etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
3.6. Problemas para la construccin de motores de ejecucin de procesos

de aprendizaje complejos . . . . . . . . . . . . . . . . . . . . . . . . .
92
vi
3.6.1. O1. Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a travs de un LME . . . . . . . . . . . . . . .
94
3.6.2. O2. Integracin de servicios web . . . . . . . . . . . . . . . . .
94
3.6.3. O3. Sustituir y agregar de manera sencilla y transparente un

servicio web . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
3.6.4. O4. Proveer al proceso de aprendizaje de soporte transaccional
95
3.7. Resmen del captulo . . . . . . . . . . . . . . . . . . . . . . . . . . .

4. Propuesta de solucin
97
99
4.1. C1. Modelo de la arquitectura de software del motor de ejecucin . . 100

4.2. C2. Modelo de informacin del motor de ejecucin . . . . . . . . . . 104
4.3. C3. Modelo de instanciacin de actividades . . . . . . . . . . . . . . 107
4.3.1. Una instancia del modelo de instanciacin de actividades . . . 112
4.4. C4. Modelo de ejecucin de actividades . . . . . . . . . . . . . . . . . 115
4.5. C5. Modelo de transacciones . . . . . . . . . . . . . . . . . . . . . . . 125
4.6. Resmen del captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5. Evaluacin
133
5.1. E1. Ejecucin de un LME . . . . . . . . . . . . . . . . . . . . . . . . 135

5.1.1. Lectura correcta del LME . . . . . . . . . . . . . . . . . . . . 141
5.1.2. Cantidad de instancias generadas de cada actividad . . . . . . 142
5.1.3. Estado del proceso de aprendizaje para cada alumno . . . . . 143
5.2. E2. Navegacin y ejecucin de proceso . . . . . . . . . . . . . . . . . 145
5.2.1. Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.2.2. Separacin paralela . . . . . . . . . . . . . . . . . . . . . . . . 148
5.2.3. Sincronizacin
. . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.2.4. Eleccin Exclusiva . . . . . . . . . . . . . . . . . . . . . . . . 150

5.2.5. Combinacin Sencilla . . . . . . . . . . . . . . . . . . . . . . . 152
5.2.6. Eleccin mltiple . . . . . . . . . . . . . . . . . . . . . . . . . 153
vii
5.2.7. Combinacin estructurada y sincronizada . . . . . . . . . . . 154

5.2.8. Combinacin mltiple . . . . . . . . . . . . . . . . . . . . . . 156
5.2.9. Discriminador estructurado . . . . . . . . . . . . . . . . . . . 156
5.2.10. Ciclo estructurado . . . . . . . . . . . . . . . . . . . . . . . . 158
5.2.11. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
5.3. E3. Instanciacin de actividades . . . . . . . . . . . . . . . . . . . . . 169
5.3.1. Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.3.2. Separacin paralela . . . . . . . . . . . . . . . . . . . . . . . . 172
5.3.3. Sincronizacin
. . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.3.4. Eleccin Exclusiva . . . . . . . . . . . . . . . . . . . . . . . . 174

5.3.5. Combinacin Sencilla . . . . . . . . . . . . . . . . . . . . . . . 176
5.3.6. Eleccin mltiple . . . . . . . . . . . . . . . . . . . . . . . . . 177
5.3.7. Combinacin estructurada y sincronizada . . . . . . . . . . . 178
5.3.8. Combinacin mltiple . . . . . . . . . . . . . . . . . . . . . . 179
5.3.9. Discriminador estructurado . . . . . . . . . . . . . . . . . . . 182
5.3.10. Ciclo estructurado . . . . . . . . . . . . . . . . . . . . . . . . 184
5.3.11. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
5.4. E4. Invocacin de servicios web . . . . . . . . . . . . . . . . . . . . . 187
5.5. E5. Sustitucin de servicios web . . . . . . . . . . . . . . . . . . . . . 188
5.6. E6. Soporte transaccional . . . . . . . . . . . . . . . . . . . . . . . . 190
5.7. Resmen del captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6. Conclusiones
193
6.1. Resumen de objetivos y de su evaluacin . . . . . . . . . . . . . . . . 193

6.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.3. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.4. Lneas de trabajo futuras . . . . . . . . . . . . . . . . . . . . . . . . 193
Referencias Bibliogrficas
195
viii
ndice de figuras
1.1. Relacin entre las problemticas y los objetivos de investigacin . . .
1.2. Relacin entre los problemas, los objetivos y las contribuciones . . .
1.3. Marco de referencia para la investigacin en Sistemas de Informacin
10
1.4. Relacin entre los problemas, objetivos, contribuciones y las evaluaciones 12

2.1. Procesos de Aprendizaje Complejos . . . . . . . . . . . . . . . . . . .
18
2.2. IMS Learning Design . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3. Estructura de IMS LD . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.4. Ejecucin de IMS LD . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.5. LAMS Learning Design . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.6. LPCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
2.7. Arquitectura de Aplicaciones y Servicios Web para la Mejora del

Aprendizaje (WASEL) . . . . . . . . . . . . . . . . . . . . . . . . . .
34
2.8. Caractersticas de los sistemas de flujos de trabajo . . . . . . . . . .
36
2.9. Componentes e interfaces de la arquitectura de flujos de trabajo . . .
37
2.10. Modelo temporal de SCORM RTE . . . . . . . . . . . . . . . . . . .
52
2.11. API de SCORM RTE . . . . . . . . . . . . . . . . . . . . . . . . . .
53
2.12. El modelo Core RBAC. . . . . . . . . . . . . . . . . . . . . . . . . .
75
2.13. El modelo Hierarchical RBAC . . . . . . . . . . . . . . . . . . . . . .
77
2.14. Jerarqua General de Roles . . . . . . . . . . . . . . . . . . . . . . .
77
2.15. Transiciones entre estados para una instancia de proceso . . . . . . .
79
ix
2.16. Transiciones entre estados para una instancia de actividad . . . . . .
80
3.1. Un escenario de aprendizaje . . . . . . . . . . . . . . . . . . . . . . .
84
3.2. Un escenario de aprendizaje diseado en la primera etapa de la evolucin 86

3.3. Un escenario de aprendizaje en un sistema de la segunda etapa . . .
87
3.4. Un escenario de aprendizaje en un sistema de la tercera etapa . . . .
90
3.5. Problemticas abordadas en el objetivo O1
. . . . . . . . . . . . . .
94
. . . . . . . . . . . . . .
95
. . . . . . . . . . . . . .
95
. . . . . . . . . . . . . .
96
4.1. Relacin entre la contribucin C1 y los problemas y objetivos de investigacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.2. Modelo de la arquitectura de software . . . . . . . . . . . . . . . . . 102
4.4. Modelo de informacin del motor de ejecucin . . . . . . . . . . . . . 105
4.7. Modelo de ejecucin de actividades . . . . . . . . . . . . . . . . . . . 117
4.8. Ejecucin de flujos de aprendizaje . . . . . . . . . . . . . . . . . . . . 121
4.9. Ejecucin de flujos de aprendizaje en secuencia . . . . . . . . . . . . 122
4.10. Ejecucin de flujos de aprendizaje en paralelo . . . . . . . . . . . . . 123
4.11. Ejecucin de flujos de aprendizaje opcionales . . . . . . . . . . . . . 124
4.13. Niveles de transacciones en un PAC . . . . . . . . . . . . . . . . . . . 127
4.14. Relacin entre los problemas, los objetivos y las contribuciones . . . 130
x
5.1. Relacin entre la evaluacin E1 y las contribuciones, objetivos y problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

5.2. Escenario de aprendizaje E1 . . . . . . . . . . . . . . . . . . . . . . . 136
5.3. Publicacin del escenario E1 en el motor . . . . . . . . . . . . . . . . 142
5.5. Escenario de aprendizaje E2-Secuencia . . . . . . . . . . . . . . . . . 147
5.6. Escenario de aprendizaje E2-Separacion Paralela . . . . . . . . . . . 160
5.7. Escenario de aprendizaje E2-Sincronizacin . . . . . . . . . . . . . . 161
5.8. Escenario de aprendizaje E2-Eleccin exclusiva . . . . . . . . . . . . 162
5.9. Escenario de aprendizaje E2-Combinacin sencilla . . . . . . . . . . . 163
5.10. Escenario de aprendizaje E2-Eleccin mltiple . . . . . . . . . . . . . 164
5.11. Escenario de aprendizaje E2-Combinacin estructurada y sincronizada 165
5.12. Escenario de aprendizaje E2-Combinacin mltiple . . . . . . . . . . 166
5.13. Escenario de aprendizaje E2-Discriminador estructurado . . . . . . . 167
5.14. Escenario de aprendizaje E2-Ciclo estructurado . . . . . . . . . . . . 168
5.16. Escenario de aprendizaje E3-Secuencia . . . . . . . . . . . . . . . . . 171
5.17. Escenario de aprendizaje E3-Separacin paralela . . . . . . . . . . . 172
5.18. Escenario de aprendizaje E3-Sincronizacin . . . . . . . . . . . . . . 174
5.19. Escenario de aprendizaje E3-Eleccin exclusiva . . . . . . . . . . . . 175
5.20. Escenario de aprendizaje E3-Combinacin sencilla . . . . . . . . . . . 176
5.21. Escenario de aprendizaje E3-Eleccin mltiple . . . . . . . . . . . . . 178
5.22. Escenario de aprendizaje E3-Combinacin estructurada y sincronizada 180
5.23. Escenario de aprendizaje E3-Combinacin mltiple . . . . . . . . . . 181
5.24. Escenario de aprendizaje E3-Discriminador estructurado . . . . . . . 183
5.25. Escenario de aprendizaje E3-Ciclo estructurado . . . . . . . . . . . . 184
xi

xii
ndice de tablas
2.1. Elementos implementados en los LMEs . . . . . . . . . . . . . . . . .
24
2.2. Categoras de los cdigos de error de SCORM RTE . . . . . . . . . .
54
2.3. Elementos del modelo de datos de SCORM RTE . . . . . . . . . . .
56
2.4. Evaluacin de la capacidad expresiva de los LMEs . . . . . . . . . .
60
2.5. Comparacin de los Modelos de Transacciones Avanzados . . . . . .
72
5.1. Lectura correcta del LME . . . . . . . . . . . . . . . . . . . . . . . . 142

5.2. Instancias generadas de cada actividad . . . . . . . . . . . . . . . . . 144
5.3. Estado del flujo de aprendizaje individual . . . . . . . . . . . . . . . 145
5.4. Navegacin de proceso: Secuencia . . . . . . . . . . . . . . . . . . . . 148
5.5. Navegacin de proceso: Separacin paralela - Caso 1 . . . . . . . . . 148
5.8. Navegacin de proceso: Sincronizacin - Caso 1 . . . . . . . . . . . . 150
5.11. Navegacin de proceso: Eleccin exclusiva - Caso 1 . . . . . . . . . . 151
5.14. Navegacin de proceso: Combinacin sencilla - Caso 1 . . . . . . . . 152
xiii

5.17. Navegacin de proceso: Eleccin mltiple - Caso 1
. . . . . . . . . . 153
. . . . . . . . . . 154
. . . . . . . . . . 154
5.20. Navegacin de proceso: Combinacin estructurada y sincronizada Caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5.23. Navegacin de proceso: Discriminador estructurado - Caso 1 . . . . . 157
5.26. E2 Navegacin y ejecucin de proceso . . . . . . . . . . . . . . . . . 158
5.27. Instanciacin de actividades: Secuencia . . . . . . . . . . . . . . . . . 171
5.28. Instanciacin de actividades: Separacin paralela . . . . . . . . . . . 173
5.29. Instanciacin de actividades: Sincronizacin . . . . . . . . . . . . . . 173
5.30. Instanciacin de actividades: Eleccin exclusiva . . . . . . . . . . . . 175
5.31. Instanciacin de actividades: Combinacin sencilla . . . . . . . . . . 177
5.32. Instanciacin de actividades: Eleccin mltiple . . . . . . . . . . . . 179
5.33. Instanciacin de actividades: Combinacin estructurada y sincronizada 179
5.34. Instanciacin de actividades: Combinacin mltiple . . . . . . . . . . 182
5.35. Instanciacin de actividades: Discriminador estructurado . . . . . . . 184
5.36. Instanciacin de actividades: Ciclo estructurado . . . . . . . . . . . . 185
5.37. E3 Instanciacin de actividades . . . . . . . . . . . . . . . . . . . . . 186
5.38. Conjunto de servicios web y sus operaciones para la evaluacin E4 . 188
5.39. Evaluacin E4: Invocacin de servicios web . . . . . . . . . . . . . . . 188
5.40. Evaluacin E5 Sustitucin de servicios web . . . . . . . . . . . . . . . 190
xiv
Captulo 1
Introduccin
E-training increases flexibility by allowing organizations to deliver materials
anywhere and at anytime. It also seems to be fast and efficient. On the other hand,
its expensive to design self-paced online materials, many employees miss the social
interaction provided by a classroom environment, online learners are often more
susceptible to distractions, and clicking through training is no assurance that
employees have actually learned anything.
[Ensher et al., 2002]
1.1.
Contexto del problema
En la ltima dcada, profesionales, investigadores y organizaciones han reconocido la importancia e impacto que tiene la tecnologa en el aprendizaje, y han
desarrollado un amplio conocimiento relacionado al aprendizaje electrnico o elearning, afectando diversos elementos y componentes como infraestructura, herramientas, aplicaciones orientadas a contenido, interaccin humano-computadora,
aspectos pedaggicos, metodologas y modelos, casos de estudio, y proyectos
[Pierre and Paquette, 2007]. Este desarrollo fue particularmente inspirado por las
oportunidades generadas por la Internet, la mayor red de computadoras conectadas
en el mundo.
1
1.1. Contexto del problema
Conforme la Internet ha evolucionado, la variedad y cantidad de dispositivos

conectados y la cantidad de enlaces entre ellos ha aumentado. Esto explica la existencia de ambientes heterogneos, los cuales han generado problemticas de incompatibilidad e integracin. En los ltimos aos, una tendencia que ha hecho frente a
estas problemticas ha sido el paradigma de arquitectura orientada a servicios (SOA,
por sus siglas en ingls) [Erl, 2004] [Turban et al., 2008].
A la par de la evolucin de Internet, los sistemas de e-learning tambin han
evolucionado, ofreciendo con cada etapa de su evolucin, un conjunto mejorado de
caractersticas y flexibilidad en los procesos de aprendizaje. Los sistemas de e-learning
se han desarrollado a travs de cuatro etapas [Torres et al., 2005a], comenzando por
simple contenido web esttico, movindose hacia la estandarizacin de objetos de
aprendizaje, posteriormente dando lugar a la creacin de Lenguajes de Modelado
Educativo (LME) capaces de describir escenarios de aprendizaje, para que finalmente los LMEs sean capaces de describir completamente, ambientes pedaggicos
complejos.
La primera etapa de la evolucin de los sistemas de e-learning se describe por
el desarrollo y despliegue de contenidos web, generalmente simples como archivos
de texto, paginas HTML y recursos multimedia. En esta etapa se busca la estandarizacin de estos contenidos, los cuales, carecen de mecanismos para representar y ejecutar correctamente un escenario de aprendizaje, ya que los mecanismos
se reducen a un itinerario secuencial de contenidos.
En la segunda etapa, el inters se dirige hacia la administracin, ubicacin y
recuperacin de contenidos. Ello logr mejorar la manera de desplegar contenidos,
ya que inici con una tendencia hacia la personalizacin de contenidos de acuerdo
al estudiante. La organizacin IMS Global Learning Consortium (IMS GLC) 1 , un
consorcio mundial que agrupa a ms de 140 organizaciones de tecnologa educativa,
public diversas especificaciones para este fin [IMS, 2001] [IMS, 2003a] [IMS, 2003c]
[IMS, 2004]. Sin embargo, aunque se dio el primer paso en la representacin de escenarios de aprendizaje, surgieron problemticas como dificultad para integrar diversos
recursos y servicios para el aprendizaje, dificultad para sustituir recursos de aprendizaje de manera sencilla y la carencia de soporte al proceso de aprendizaje.
1
http://www.imsglobal.org/
La tercera etapa de los sistemas de e-learning plantea incrementar la flexibilidad

y reusabilidad de los recursos de aprendizaje, lo cual, dio lugar a la creacin de
Lenguajes de Modelado Educativo (LME). Los LMEs [Koper, 2001] representan una
aproximacin importante para integrar diversos aspectos educativos, permitiendo el
diseo y la implementacin de espacios y actividades soportados por las Tecnologas
de Informacin y Comunicacin. Con los LMEs es posible integrar, dentro de un
proceso de aprendizaje, material educativo y personalizado para cada estudiante
e.g. actividades, servicios, recursos, objetivos, evaluaciones, perfiles, promoviendo
la participacin activa del estudiante con su proceso de aprendizaje.
Entre los LMEs ms destados de la tercera etapa se encuentran IMS LD
[Koper and Tattersall, 2005] y LAMS LD [Dalziel, 2003]. De estos LMEs, se han
identificado ms necesidades y cuestiones de diseo, dando lugar a nuevas caractersticas deseables en los LMEs como diversidad pedaggica, descripcin del flujo de
aprendizaje, composicin dinmica y no anticipada, separacin del servicio y proceso
de aprendizaje, disponibilidad de los servicios de aprendizaje y soporte transaccional
[Dodero et al., 2005].
Hasta ahora, los sistemas de e-learning ms avanzados en ambientes de produccin actuales se mantienen en la tercera etapa de la evolucin. Los esfuerzos de la
Ctedra de Investigacin: Sistemas Distribuidos y Adaptativos en Tecnologas Educativas (C-QRO-17/07) del Tecnolgico de Monterrey, entre otros grupos y programas
de investigacin, buscan proponer el primer sistema de cuarta generacin, el cual se
enfoca en representar y ejecutar escenarios de aprendizaje en ambientes pedaggicos complejos y ambientes tecnolgicos distribuidos y heterogneos. El primer acercamiento a esta etapa es el leguaje de modelado LPCEL [Torres et al., 2005a], el
cual es capaz de describir dichos escenarios, sin embargo, an necesita un software
de ejecucin del proceso de aprendizaje.
1.1.1.
En Busca de la Ejecucin de Procesos de Aprendizaje Complejos
La cuarta etapa de la evolucin busca poder representar y ejecutar Procesos de Aprendizaje Complejos (PAC), que faciliten el aprendizaje en ambientes
pedagogicos ricos y personalizados. Un Proceso de Aprendizaje Complejo (PAC)
1.1. Contexto del problema
[Torres et al., 2006] es el resultado de la integracin dinmica y no anticipada de

una mezcla de pedagogas y recursos, basada en la colaboracin de instructores y
estudiantes dentro de un proceso de aprendizaje. Desde un punto de vista constructivista, los PACs reconocen que el aprendizaje es un proceso activo, que se construye
a partir de la experiencia obtenida al entrelazar contenidos, contextos y objetivos
educativos dentro de un proceso de aprendizaje. La complejidad depende principalmente de la dificultad propia de la actividad de aprendizaje, del grado de autonoma
del estudiante, y de la modificacin de las actividades de aprendizaje por parte tanto
del estudiante, como del docente.
Dentro del escenario de aprendizaje de un PAC, existen diversos recursos y servicios para lograr los objetivos de aprendizaje. Entre ellos, destacan los servicios y
recursos que tienen un impacto directo en el aprendizaje, los servicios que permiten
generar espacios para el desarrollo de competencias colectivas, y los servicios y recursos que ayudan a contextualizar y generar el ambiente de aprendizaje. Los servicios
y recursos pueden estar ubicados tanto de manera local, como de forma distribuida.
El lenguaje de modelado LPCEL, considera escenarios de aprendizaje con las

caractersticas de un PAC, incluyendo la integracin de servicios y recursos distribuidos. Sin embargo, como sucede en los Sistemas de Administracin de Workflows, el
lenguaje de modelado requiere de un motor de ejecucin para llevar a cabo el proceso
[Hollingsworth, 1995]. Dicho motor, puede beneficiarse del paradigma SOA, el cual
puede integrar tecnologa de servicios web y es principalmente til en organizaciones
con una amplia variedad de sistemas heterogneos. Los servicios web [Josuttis, 2007]
pueden ser implementados por cualquier tecnologa en cualquier plataforma, y representan funciones auto-contenidas de negocio o aprendizaje, que pueden ser parte
de uno o ms procesos.
Es por ello que para poder llevar a cabo un PAC diseado a travs de un LME,
es necesario un motor de ejecucin capaz de integrar y planificar la ejecucin de
servicios web que apoyen el proceso de aprendizaje.
1.2.
Motivacin del trabajo de investigacin
Desde que era estudiante de bachillerato, he querido hacer algo por la educacin
de mi pas. En la actualidad, a diario convivo con nios y jvenes y me doy cuenta
de los diversos problemas que como sociedad mexicana enfrentamos en el mbito
educativo, que es la base de nuestro desempeo como ciudadanos.
A la par, estoy convencido de que la tecnologa puede contribuir con la mejora
de la educacin, porque a travs de ella, la educacin puede llegar a ms personas,
puede servir de apoyo en los procesos de aprendizaje, e incluso puede contribuir
para mejorar dichos procesos. Sin embargo, aunque el avance es grande, an existen
diversos problemas que no se han abordado o no se han podido solucionar, tanto
desde la perspectiva pedaggica, como desde la perspectiva tecnolgica.
Desde la perspectiva pedaggica, existen cuestiones que van desde el diseo del
aprendizaje, hasta la no inclusin de los aspectos formativos en las herramientas
tecnolgicas. El diseo del aprendizaje generalmente se hace centrado en el alumno
promedio, el cual es un alumno en la mayora de los casos inexistente, ya que en raras
ocasiones un alumno tiene los conocimientos, habilidades y forma de aprender del
alumno para el que fue diseado el curso, y por lo tanto, el aprendizaje difcilmente se
lleva a cabo conforme a su diseo. Con otras tecnologas para el aprendizaje, sucede
que los aspectos formativos han quedado de lado, ya que las herramientas se dedican
nicamente a resolver los problemas de carcter tcnico [Wiley, 2000].
En cuanto a la perspectiva tecnolgica, existen entre otras, un par de tendencias en las tecnologas de la informacin que pueden ser ampliamente aprovechables por la tecnologa educativa: La computacin mvil y el paradigma SOA
[Turban et al., 2008].
La computacin mvil se refiere al modelo computacional diseado para los trabajadores que se trasladan fuera de su lugar de trabajo. Las tecnologas de computacin
mvil tienen un fuerte impacto en nuestras vidas, al permitir el acceso a informacin
y herramientas virtualmente en cualquier lugar, mejorando no slo la capacidad de
comunicacin, sino tambin la realizacin de nuevas actividades.
El paradigma SOA a travs de la tecnologa de servicios web, permite la integracin de sistemas distribuidos y heterogneos, como los sistemas de cmputo mvil
1.2. Motivacin del trabajo de investigacin
y otros sistemas independientes en distintas plataforms, y es especialmente til en

grandes instituciones donde los sistemas autnomos no son capaces de satisfacer
todos los requerimientos de la organizacin.
Recientemente, las organizaciones de tecnologa educativa han comenzado a adentrarse en el paradigma SOA, como prueba de ello se encuentra el documento de
mejores prcticas de adopcin de SOA [IMS, 2009] de IMS GLC. Sin embargo, el
enfoque de IMS GLC se centra en la interaccin entre instituciones educativas para
mejorar los trmites administrativos, ms que en mejorar el aprendizaje de los estudiantes.
Es por ello que la motivacin principal de este trabajo de investigacin est en
los modelos que hay detrs del diseo de una herramienta que pueda aprovechar
las ventajas de las nuevas tendencias en las tecnologas de la informacin, y que
contribuya en la mejora de los procesos de aprendizaje de los estudiantes, logrando
establecer las pautas para los sistemas de e-learning de cuarta generacin.
En concreto, se abordarn los problemas que se mencionan en seguida, los cuales,
han sido identificados a partir de las caractersticas que han exhibido los sistemas de
e-learning a travs de su evolucin:
(P1) Dificultad para ejecutar estructuras de aprendizaje complejas: La mayora de
los sistemas actuales consideran el flujo de aprendizaje como una secuencia lineal de actividades; los sistemas ms avanzados permiten, aunque a un nivel bajo, la ejecucin de actividades paralelas y la eleccin de actividades opcionales.
Sin embargo, estas estructuras estn an lejos de representar la verdadera forma en que un estudiante aprende, la cual puede incluir la seleccin o asignacin
de actividades dentro de un equipo de trabajo o de acuerdo a los intereses del
alumno, la ejecucin cclica de actividades, o la ejecucin de actividades de
compensacin, entre otras.
(P2) Complejo manejo de roles y asignacin de tareas: En un equipo de trabajo
colaborativo, los alumnos e incluso profesores (si son ms de uno), pueden
desempear diversos roles, lo cual les da acceso a diferentes actividades, e.g.,
nicamente el lder del equipo de trabajo puede realizar la entrega final del
proyecto, el alumno administrador de proyecto es el nico que puede modificar
el plan de trabajo, el profesor asistente evaluar las actividades de la mitad
de los estudiantes, entre otras. Los sistemas actuales carecen de este tipo de
controles.
(P3) Dificultad para integrar diversos recursos y servicios para el aprendizaje en
ambientes distribuidos y heterogneos: Los usuarios de los sistemas actuales no
pueden llevar a cabo actividades bajo otras plataformas o usar herramientas
externas, y que el uso, avance y progreso con estas herramientas y recursos
quede registrado en la plataforma.
(P4) Sustitucin de los recursos y servicios de aprendizaje de manera sencilla: Cuando un recurso, servicio o mdulo del sistema tiene un error o existe uno mejor,
hacer un cambio en el curso puede requerir la actualizacin de la plataforma, lo
cual es un procedimiento complicado y que implica la interrupcin del servicio.
O bien, la sustitucin puede generar inconsistencias de informacin.
(P5) Soporte transaccional para el proceso de aprendizaje: La mayora de los sistemas estn diseados para que un alumno acredite o no acredite el curso o
las actividades, sin la opcin de que el alumno pueda llevar a cabo actividades
para compensar y adquirir aprendizaje que no logr previamente.
La descripcin detallada de estos problemas se presenta en el Captulo 3.
1.3.
Objetivos del trabajo de investigacin
El objetivo principal del trabajo de investigacin es desarrollar un marco de referencia para la construccin de un motor de ejecucin de Procesos de Aprendizaje
Complejos, basado en la integracin de servicios web a travs de Lenguajes de Modelado Educativo. El marco de referencia pretende lograr los siguientes subobjetivos:
(O1) Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a travs
de un LME: Las estructuras complejas [Dodero et al., 2005] estn compuestas
por diferentes bloques de construccin como actividades, recursos, roles, dependencias y restricciones (ver seccin 2.2), y se describen a travs de un LME.
Por ello, el motor de ejecucin debe ser capaz de interpretar un LME y ejecutar
las estructuras complejas descritas en l. Este objetivo aborda directamente los
problemas P1 y P2.
1.3. Objetivos del trabajo de investigacin
(O2) Integracin de servicios web: El motor de ejecucin debe ser capaz de integrar y orquestar servicios web que apoyen el proceso de aprendizaje. Dichos
servicios son necesarios en materia de instruccin, por el impacto directo que
tienen en el aprendizaje, porque ayudan a generar espacios para el desarrollo
de competencias, o porque muestran la actividad que los estudiantes realizan
en su entorno de aprendizaje. De su integracin depende la correcta ejecucin
del escenario de aprendizaje. El objetivo tiene una implicacin directa sobre el
problema P3.
(O3) Sustituir y agregar de manera sencilla y transparente un servicio web: Los actuales sistemas de gestin del aprendizaje al requerir un cambio en alguno de sus
mdulos, llevan a cabo un proceso de actualizacin muchas veces complicado
y delicado. Con un correcto diseo e implementacin basado en el paradigma
SOA, la sustitucin de un servicio debe de poder realizarse por el motor de
ejecucin de manera sencilla y transparente, abordando el problema P4.
(O4) Proveer al proceso de aprendizaje de soporte transaccional: El motor de ejecucin debe tener la capacidad de recuperarse despus de un fallo tecnolgico para
no afectar el proceso de aprendizaje, o bien, debe ser capaz de llevar a cabo
actividades de compensacin cuando un estudiante no logre los objetivos de
aprendizaje de una actividad (e.g. reprobar un examen) [Torres et al., 2009c].
Este objetivo envuelve el problema P5 de la investigacin.
La correspondencia entre las problemticas seleccionadas y los objetivos de investigacin, se muestra en la figura 1.1.
Figura 1.1: Relacin entre las problemticas y los objetivos de investigacin
1.4.
Contribuciones esperadas
El producto final de la tesis es un marco de referencia para la construccin de un

motor de ejecucin de PAC. Para ello, se desarrollarn los siguientes subproductos:
(C1) Modelo de la arquitectura de software del motor de ejecucin: Se formalizar
a travs de un diagrama de componentes UML.
(C2) Modelo de informacin del motor de ejecucin: Se formalizar a travs de un
diagrama de clases UML.
(C3) Modelo de instanciacin de actividades: Se formalizar a travs de sentencias
de teora de conjuntos.
(C4) Modelo de ejecucin de actividades: Se formalizar a travs de un diagrama
de secuencia UML.
(C5) Modelo de transacciones: Se formalizar a travs de un diagrama en notacin
BPMN y un lenguaje de ejecucin.
Las relaciones entre las problemticas, los objetivos de investigacin, y las contribuciones se muestran de manera grfica en la figura 1.2.
Figura 1.2: Relacin entre los problemas, los objetivos y las contribuciones
10
1.5. Metodologa de investigacin
1.5.
Metodologa de investigacin
En [Hevner et al., 2004] se presenta un marco de referencia para la investigacin

en la disciplina de los Sistemas de Informacin (ver figura 1.3), la cual est caracterizada por dos paradigmas: La ciencia de la conducta y la ciencia del diseo.
El primer paradigma busca desarrollar y verificar teoras que explican o predicen
el comportamiento humano y organizacional, mientras que el segundo paradigma
busca extender los lmites de las capacidades humanas y organizacionales para crear
artefactos nuevos e innovadores.
Figura 1.3: Marco de referencia para la investigacin en Sistemas de Informacin
Los artefactos de tecnologas de informacin estn definidos como constructores

(vocabulario y smbolos), modelos (abstracciones y representaciones), mtodos (algoritmos y prcticas), e instanciaciones (prototipos de sistemas e implementaciones).
Dichos artefactos pueden ser evaluados en trminos de funcionalidad, completitud,
consistencia, certeza, desempeo, fiabilidad, usabilidad, acoplamiento con la organizacin y otros atributos de calidad relevantes.
11
Para este proyecto de tesis, el prototipo del motor de ejecucin ser validado
en una primera etapa a travs de una metodologa cuantitativa en funcin de los
siguientes mtodos:
(E1) Ejecucin de un LME: Esta evaluacin se realizar a travs de pruebas funcionales en la ejecucin de un script de un LME. La finalidad de estas pruebas
es descubrir fallas e identificar defectos en la lectura y ejecucin de un script
de un LME. Esta evaluacin mide la completitud y correctitud en la lectura
de un LME, en la cantidad de instancias generadas de las actividades, y en el
estado del proceso de aprendizaje para cada alumno.
(E2) Navegacin y ejecucin de proceso: Esta evaluacin se realizar a travs de
pruebas funcionales en la navegacin y ejecucin en diversos escenarios de
aprendizaje. La finalidad de estas pruebas es demostrar que los modelos que se
proponen para el diseo de un motor de ejecucin, tienen la capacidad para ejecutar actividades en secuencia, paralelo y otros patrones de control de flujos de
trabajo [Torres et al., 2009b]. La validacin se har con base en dichos patrones
de control de flujos de trabajo, representados en escenarios de aprendizaje.
(E3) Instanciacin de actividades: Esta evaluacin tiene como objetivo verificar que
el modelo de instanciacin tiene la capacidad de generar las instancias de actividades necesarias para soportar de manera completa y correcta, patrones de
control de flujos de trabajo. La validacin de esta evaluacin se har a travs
de escenarios de aprendizaje que representen los diversos patrones de flujos de
trabajo.
(E4) Invocacin de servicios web: Esta evaluacin tiene como objetivo verificar que el
motor es capaz de invocar servicios web distribuidos en una red computacional.
La verificacin se har a travs de pruebas funcionales.
(E5) Sustitucin de servicios web: El objetivo de esta evaluacin es validar la capacidad de los modelos propuestos de eliminar y agregar servicios web del proceso
de aprendizaje. Esta evaluacun se har a travs de pruebas funcionales.
(E6) Soporte transaccional: El objetivo de esta evaluacin es validar que el modelo
de transacciones propuesto es factible para un ambiente pedaggico apoyado
en la tecnologa. El modelo de transacciones debe tener la capacidad para
12
1.6. Estructura del documento
recuperar el proceso de aprendizaje despus de un fallo tecnolgico, o bien

cuando un estudiante no logra los objetivos pedaggicos de una actividad.
En la figura 1.4 se muestran las relaciones entre los objetivos, las contribuciones
esperadas y sus respectivas evaluaciones.
Figura 1.4: Relacin entre los problemas, objetivos, contribuciones y las evaluaciones
1.6.
Estructura del documento
En esta seccin se detalla la estructura del documento describiendo el objetivo

fundamental de cada captulo.
Captulo 1: Introduccin al trabajo, presentacin objetivos, contribuciones esperadas y descripcin de la metodologa de trabajo.
Captulo 2: Estado del arte en materia de LMEs, motores de ejecucin y sus
caractersticas.
Captulo 3: Planteamiento del problema abordado y descripcin detallada de
los objetivos perseguidos.
13
Captulo 4: Presentacin de la propuesta de solucin a los problemas a travs

de cinco contribuciones.
Captulo 5: Evaluacin de las contribuciones y objetivos de investigacin.
Captulo 6: Descripcin de las conclusiones obtenidas, principales contribuciones del trabajo y lneas de investigacin futuras.
14
1.6. Estructura del documento
Captulo 2
Estado del arte

En el primer captulo se dio una breve introduccin sobre el estado actual de las
tecnologas electrnicas para el aprendizaje y se definieron los objetivos, las aportaciones esperadas y la metodologa de la presente tesis. Retomando la breve explicacin del captulo anterior sobre la evolucin de los sistemas de e-learning, en este
captulo se comienza con la ampliacin de la evolucin de los sistemas de e-learning,
para proseguir con la explicacin de los procesos de aprendizaje complejos (PAC),
uno de los temas de principal inters. Posteriormente se hace una revisin de las
caractersticas de los lenguajes de modelado educativo (LME), abordando tres de las
propuestas ms amplias hasta el momento, IMS LD, LAMS y LPCEL.
Ms adelante en el captulo, se abordarn temas especficos sobre los motores
de ejecucin de los sistemas de e-learning, abordando tanto la teora general de los
motores de flujos de trabajo, como aspectos especficos relacionados con las caractersticas de los lenguages de modelado educativo desde el punto de vista de la
ejecucin. Para concluir con el captulo, se ahondar en dos temas vitales para un
motor de ejecucin: el control de acceso y la instanciacin de procesos y actividades.
2.1.
La evolucin de los Sistemas de E-learning
Los sistemas de aprendizaje electrnico o e-learning han sido trascendentales en el

avance de los modelos educativos actuales. Estos sistemas han evolucionado a travs
15
16
2.1. La evolucin de los Sistemas de E-learning
de varias etapas [Torres et al., 2005a], cada una con un progreso significativo para
el diseo y despliegue de contenidos pedaggicos, incrementando la funcionalidad,
la informacin semntica y la flexibilidad para soportar ambientes pedaggicos ms
complejos:
Primera Etapa: Esta etapa se describe por el desarrollo y despliegue de contenidos
web, generalmente aplicaciones simples (e.g. archivos de texto, pginas HTML,
recursos multimedia). El inters en esta etapa est en la estandarizacin de
objetos de aprendizaje que han de ser usados en el proceso de aprendizaje. Los
objetos de aprendizaje son contenidos de instruccin simples que pueden ser
desplegados para la enseanza (e.g. lecciones, artculos, tareas), y reutilizados
en diferentes contextos de aprendizaje [Wiley, 2002]. Estos objetos carecen de
mecanismos para construir un proceso de aprendizaje, ya que los mecanismos
se reducen a un itinerario secuencial de contenidos.
Segunda Etapa: En esta etapa el inters se dirige hacia la administracin, ubicacin y recuperacin de contenidos. La manera de desplegar contenidos se
mejora y personaliza de acuerdo al estudiante, como se proporciona en la especificacin IMS Learning Information Package Specification [IMS, 2001]. Tambin se desarrollan tecnologas para la evaluacin como la especificacin IMS
Question & Test Interoperability Specification [IMS, 2004]. Incipientemente,
existe una forma para el intercambio de recursos entre aplicaciones a travs
de IMS Content Packaging [IMS, 2003a]. En el dominio pedaggico, existe la
posibilidad de disear procesos de aprendizaje fundados en estructuras bsicas
predefinidas con un estilo jerrquico secuencial, a travs de la especificacin
IMS Simple Sequencing Specification [IMS, 2003c].
Tercera Etapa: La bsqueda de mayor flexibilidad y reusabilidad se plantea
aqu, es por ello que se introducen arquitecturas de software para la gestin
de aplicaciones interoperables para el aprendizaje. Un ejemplo significativo de estas arquitecturas es el modelo de referencia de objetos de contenido compartido: Sharable Content Object Reference Model (SCORM)
[Advanced Distributed Learning (ADL), 2009c]. Tambin se observan esfuerzos para generar tecnologas con mayor flexibilidad didctica como la propuesta Integrated E-Learning de la Open University of the Netherlands
[Jochems et al., 2004], que muestra una visin de los sistemas de e-learning
17
para soportar procesos de aprendizaje con diversidad pedaggica. Este inters

tambin es abordado por los patrones de e-learning centrados en la persona:
Person Centered E-Learning (PCeL) [Derntl and Motschnig-Pitrik, 2004].
Desde una perspectiva pedaggica, es posible personalizar contenidos e interacciones de estudiantes con su proceso de aprendizaje, basado en escenarios,
actividades, roles y perfiles, a travs de los Lenguajes de Modelado Educativo
(LME) como IMS Learning Design [IMS, 2003b].
Cuarta Etapa: El inters en esta etapa se centra en los procesos de aprendizaje
complejos (PAC), que facilitan el aprendizaje en ambientes pedaggicos personalizados. En la siguiente seccin se abordar este tema a detalle.
2.2.
Procesos de Aprendizaje Complejos
En la seccin anterior, se hace referencia a los procesos de aprendizaje complejos como el principal inters en la cuarta etapa de la evolucin de los sistemas de
e-learning. Un proceso de aprendizaje complejo (PAC) [Dodero et al., 2005] es el resultado de la integracin dinmica y no anticipada de una mezcla de pedagogas y
recursos, basada en la colaboracin entre instructores y estudiantes dentro de un
proceso de aprendizaje. Un PAC toma en cuenta los objetivos de instruccin y sus
resultados, los instrumentos de evaluacin, la estructura de los contenidos, las estrategias de instruccin, los recursos y servicios, los prerrequisitos de instruccin y
el perfil del estudiante (ver figura 2.1). Desde un punto de vista constructivista, un
PAC reconoce que el aprendizaje es un proceso activo, construido sobre las experiencias que se obtienen al combinar contenidos, contextos y objetivos de educacin,
dentro de un proceso de aprendizaje.
La complejidad de un PAC depende de 3 factores:
1. La complejidad de la tarea de aprendizaje por s misma, que es influenciada por
el carcter multidisciplinario del tema de aprendizaje, la duracin del proceso
de aprendizaje y la diversidad de los enfoques pedaggicos que se apliquen.
2. El grado de autonoma que tiene el estudiante al seleccionar sus objetivos de
aprendizaje, tpicos y resultados esperados.
18
2.2. Procesos de Aprendizaje Complejos
Figura 2.1: Procesos de Aprendizaje Complejos

3. El diseo y control del proceso despus de que los objetivos de aprendizaje
se han fijado, lo cual es una responsabilidad compartida entre profesores y
estudiantes, y consiste en planear y seleccionar las actividades y los productos
a desarrollar.
El flujo de aprendizaje de un PAC consiste en la composicin de estructuras

complejas, que estn compuestas por diferentes bloques de construccin como actividades, recursos, roles, dependencias, restricciones, entre otros. Estos elementos
interactan de forma compleja y colaborativa para alcanzar los objetivos de aprendizaje. Adems, la composicin de dichas estructuras no puede ser modificada o
programada en tiempo de diseo, sino de manera dinmica y no anticipada. En algunos casos, la forma inicial de un PAC debe ser adaptada y rediseada segn cambie
la interaccin entre estudiantes e instructores. Esto usualmente se hace en tiempo de
ejecucin, sin perder el estado alcanzado en el proceso de aprendizaje.
19
Estos aspectos no son los nicos que contribuyen en la complejidad de un procesos de aprendizaje, ya que un PAC asume que los recursos para el aprendizaje no slo
aparecen como texto, audio, lecturas, animaciones o documentos; sino que adicionalmente invocan recursos y servicios que pueden ser integrados en las actividades de
aprendizaje que el estudiante ejecuta en diferentes espacios de aprendizaje, ya sean
stos formales o informales. Los PAC permiten a los estudiantes tomar el control sobre algunas de sus actividades de aprendizaje, es decir, los mismos estudiantes pueden
crear y elegir sus actividades de aprendizaje. Aunado a esto, un PAC incorpora diferentes tcnicas de evaluacin como los exmenes tradicionales, evaluacin basada en
portafolio, evaluacin basada en productos, autoevaluacin, entre otros. Estos principios usualmente son identificados como pedagoga constructivista [Vrasidas, 2000]
y aprendizaje para toda la vida (life-long learning) [Knapper and Cropley, 2000].
El diseo de un PAC generalmente resulta en redes complejas de aprendizaje, por
ejemplo, cuando un grupo de esudiantes trabaja conjuntamente en el desarrollo de
proyectos o en la solucin de problemas. Las actividades en la red son ejecutadas por
diversos roles que entrelazan sus esfuerzos para alcanzar los objetivos de aprendizaje.
Una vez analizado el inters de la cuarta etapa de la evolucin de los sistemas de
e-learning desde un punto de vista instruccional, en el resto del captulo se proceder
a describir las cuestiones tcnicas para lograr esta cuarta etapa de la evolucin. En
la siguiente seccin, se comienza por presentar a los lenguajes de modelado educativo (LMEs), que sirven para describir escenarios aprendizaje de manera formal y
ejecutable por una computadora, es por ello su gran importancia dentro del contexto
del e-learning.
2.3.
Lenguajes de Modelado Educativo
Los lenguajes de modelado educativo (LMEs) proveen un lenguaje que puede ser
utilizado por los instructores para formalizar su proceso de enseanza, de tal forma que este proceso pueda ser interpretado por computadoras. Es por ello que son
considerados como la piedra angular del e-learning [Martinez-Ortiz et al., 2007]. As,
los LMEs [Koper, 2001, Rawlings et al., 2002] representan una aproximacin importante para integrar diversos aspectos educativos, permitiendo el diseo y la imple-
20
2.3. Lenguajes de Modelado Educativo
mentacin de espacios y actividades soportados por las Tecnologas de Informacin

y Comunicacin (TICs).
Con los LMEs es posible integrar, dentro de un proceso de aprendizaje, material
educativo y personalizado para cada estudiante e.g. actividades, servicios, recursos,
objetivos, evaluaciones, perfiles promoviendo la participacin activa del estudiante
con su proceso de aprendizaje. Adems, estos lenguajes estn basados en la creacin
de escenarios de aprendizaje dentro de una unidad de aprendizaje.
Una unidad de aprendizaje (UA) [Koper, 2001] es la unidad ms pequea que
provee, a los estudiantes o aprendices, de eventos de aprendizaje satisfaciendo uno
o ms objetivos de aprendizaje. Es por ello que una UA no puede ser dividida sin
perder su semntica y efectividad para conseguir los objetivos de aprendsaje. La UA
define el modelo de enseanza-aprendizaje y el ambiente donde la actividad se lleva
a cabo. Una UA puede ser un curso, un taller, una prctica, un programa de estudio
completo, entre otros.
Los diferentes elementos implicados en la experiencia de aprendizaje e.g. roles,
objetivos, resultados, actividades, recursos y servicios son modelados dentro de
las UAs junto con los mecanismos de organizacin y coordinacin de la experiencia
de aprendizaje e.g. estructuras de actividades, asignacin de las estructuras de
actividades a roles y reglas que determinen el despliegue del material. Al orden
temporal en que las diversas actividades de aprendizaje se desarrollan dentro de una
UA se le llama flujo de aprendizaje [Koper and Tattersall, 2005].
Una vez visto el panorama general de los LMEs, en seguida se abordarn las
caractersticas de diseo, ejecucin y control de un LME, y posteriormente se presentarn tres de los EMLs de ms amplio espectro: IMS LD, LAMS y LPCEL.
2.3.1.
Caractersticas de Diseo, Ejecucin y Control de un LME
De acuerdo con [Koper, 2001] los LMEs deben reunir los siguientes requerimientos:
Formalizacin: Los LMEs deben ser capaces de describir modelos pedaggicos formalmente, de manera que puedan ser ledos por una mquina y el procesamiento automtico sea posible.
21
Flexibilidad pedaggica: Los LMEs deben ser capaces de describir unidades de

estudio basadas en diferentes teoras y modelos de instruccin y aprendizaje.
Objetos de aprendizaje explcitamente caracterizados: Los LMEs deben ser
capaces de expresar el significado semntico de diversos objetos de aprendizaje
dentro del contexto de una UA.
Completitud: Los LMEs deben describir una unidad de estudio completamente,
incluyendo todos los objetos de aprendizaje caracterizados, la relacin entre
los objetos de aprendizaje, y las actividades y flujos de trabajo de todos los
estudiantes y personal docente con relacin a los objetos de aprendizaje.
Reproducibilidad: Los LMEs deben describir las UA de tal forma que su ejecucin
repetida sea posible.
Personalizacin: Los LMEs deben ser capaces de describir aspectos de personalizacin, de tal manera que las actividades de aprendizaje y el material de
aprendizaje, puedan ser adaptados de acuerdo a las preferencias de los estudiantes.
Neutralidad al medio: Donde sea posible, la notacin de unidades de estudio debe
ser neutral al medio, del tal forma que puedan ser usadas en diversos formatos
de publicacin como web, en papel, libros electrnicos, dispositivos mbiles,
entre otros.
Interoperabilidad y sostenibilidad: Los estndares de descripcin y las tcnicas
de interpretacin deben estar separados. As, las inversiones en el desarrollo de
la educacin han de resistir a los cambios tecnolgicos y a los problemas de
conversin.
Compatibilidad: Los LMEs deben corresponder a los estndares y especificaciones
disponibles.
Reusabilidad: Los LMEs deben hacer posible la identificacin, aislamiento, descontextualizacin e intercambio de objetos de aprendizaje para que puedan ser
reutilizados en otros contextos.
Ciclo de vida: Los LMEs deben hacer posible la produccin, mutacin, preservacin, distribucin y archivo de las UA y de todos los objetos de aprendizaje
que ellas contienen.
22
Debido a los niveles de complejidad y al vasto nmero de tcnicas didcticas,

en [Dodero et al., 2005] se definen nuevas caractersticas que se presentan a continuacin, para que los LMEs de la cuarta etapa puedan dar soporte a los PACs:
Diversidad pedaggica: Los LMEs deben ser capaces de guiar la composicin,
ejecucin y control de un proceso de aprendizaje que incluya diversas tcnicas
pedaggicas y niveles de complejidad.
Descripcin del flujo de aprendizaje: Los LMEs necesitan tener la expresividad suficiente para especificar estructuras de flujos de aprendizaje complejas y
dinmicas, lo cual incluye actividades, dependencias, reglas, contenidos, roles,
escenarios y participantes.
Composicin dinmica y no anticipada: En algunos casos, la especificacin inicial de un proceso de aprendizaje debe ser redefinida y modificada segn el tipo
de colaboracin y negociacin entre los estudiantes y los instructores, esto generalmente se lleva a cabo en tiempo de ejecucin, sin que ello afecte el estado
alcanzado en el proceso de aprendizaje.
Descentralizacin de los servicios de aprendizaje: Las UAs deben ser vistas
como un conjunto de servicios de aprendizaje que pueden ser usados en un
proceso de aprendizaje. Algunos de los servicios pueden ser recuperados y desplegados de manera local, mientras que otros pueden ser ejecutados de forma
descentralizada, es decir, distribuida.
Separacin del proceso de aprendizaje y servicio: Los LMEs deben contener
informacin detallada para habilitar el acceso dinmico y en tiempo de ejecucin a los servicios requeridos, es decir, los LMEs deben de soportar la interoperabilidad semntica.
Disponibilidad y contenido del servicio de aprendizaje: Una instancia de un
proceso de aprendizaje diseada a travs de un LME, debe proveer de descripciones adecuadas de los recursos y servicios necesarios para mantener la
disponibilidad del proceso de aprendizaje, y que ella no dependa de autocontenidos. Esto con el objetivo de que el proceso de aprendizaje no pierda la
oportunidad de evolucionar, sustituir e integrar otros recursos y servicios.
23
Soporte transaccional: Los LMEs deben describir el soporte transaccional de operacin para ejecutar un proceso de aprendizaje con la posibilidad de implementar actividades de larga duracin.
Una comparacin de los elementos implementados en diversos LMEs se presenta
en la tabla 2.1. En la parte superior se muestran los diferentes LMEs, mientras que
a un costado se muestran los elementos a considerarse. En las intersecciones entre
el LME y el elemento puede aparecer el smbolo +, que significa que el elemento
est implementado considerando un estndar o especificacin; el smbolo -, quiere
decir que el elemento no est considerado; el smbolo que significa que est
implementado pero no de acuerdo a una especificacin o estndar; o el smbolo ++,
que significa que el elemento est implementado y extiende o mejora la especificacin
o estndar.
Como puede observarse, la mayora de los LMEs no soportan los aspectos
pedaggicos como las estructuras cognitivas de contenido, objetivos, prerrequisitos y
evaluacin, as como para los procesos de aprendizaje y servicios. En este contexto,
tres de los LMEs de mayor amplitud por sus caractersticas son IMS Learning Design
(IMS LD), The Learning Activity Management System - Learning Design (LAMS
LD) y The Learning Process Execution and Composition Language (LPCEL).
La especificacin IMS LD [Koper and Tattersall, 2005] incluye un lenguaje para
describir experiencias de aprendizaje como UAs, y provee un marco de referencia
para la especificacin de diseos de procesos de aprendizaje, que posteriormente
tienen que ser desplegados en un motor de ejecucin basado en computadora. El
enfoque de LAMS LD [Dalziel, 2003] integra el diseo y ejecucin de las actividades
de aprendizaje en el mismo lenguaje de diseo, el ambiente de diseo y el motor
de ejecucin. Por su parte, LPCEL [Torres et al., 2006] provee de un marco de referencia incluyendo las primitivas apropiadas del lenguaje, para describir diseos de
aprendizaje conscientes de la ejecucin, pero an carece de una implementacin. En
los siguientes apartados, se describen ampliamente cada uno de estos lenguajes.
2.3.2.
IMS Learning Design
El lenguaje IMS Learning Design (IMS LD) [Koper and Tattersall, 2005] se
basa en la metfora de una obra de teatro para modelar el proceso de enseanza-
24
!"#$%"%&'%()*$%"%&'+
)
!"#$%$#$
()*#"*#
()*#"*#+,#-./#.-"
()*#"*#+()1*2#23"+,#-./#.-"
456"/#23"7
8-"-"9.272#"7
:;<"/#"%+="7.>#7
?77"77@"*#
4%0=&>&?)5=@1%++
?/#232#A+,"9."*/"
?/#232#A+8$-$>>">2B$#2)*
4<#2)*$>+?/#232#A+8$-$>>">2B$#2)*+
()*%2#2)*7
!"77$1"7
=)>"7
C-).<7
:%=A>1%+
!)*2#)-2*1
,"$-/D
()@@.*2/$#2)*
:;#"-*$>+E))>7
4#D"-+8-)<2"#$-A+E))>7
,-. /%01234 4334 534 5647) 8%(9) 45,*4) !3:;4- 463:) *<34)
!
&
'
&
'
&
&
&
&
'
'
&
&&
&&
&
&&
&
&
&
&
'
'
'
&
&
&
&
'
&
&
&
&
&
&
'
'
&
&
&&
'
'
&
&
&
'
&
&
&
&
'
&&
'
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
'
&
&
'
&
&
'
Tabla 2.1: Elementos implementados en los LMEs
aprendizaje. Como se ilustra en la figura 2.2, la parte del mtodo (method ) es donde
se describe la coordinacin de alto nivel entre los actores. Un obra (play), al igual que
en una obra de teatro, consiste en una serie de actos (act), aunque tambin pueden
existir obras de un slo acto. Los actos se ejecutan en secuencia, es decir, el siguiente
acto comienza a ejecutarse cuando el acto actual ha terminado, y la obra termina
cuando el ltimo acto ha terminado de ejecutarse. La transicin de un acto a otro
sirve como punto de sincronizacin para los mltiples participantes en un proceso de
aprendizaje, asegurando que todos los participantes comenzarn el siguiente acto al
mismo tiempo.
Un acto se compone por actividades (activity), estructuras de actividades (activity structure), y partes de rol (role-part). En cada acto, la parte de rol asocia a un
25
!"#$%&
designed towards>
'()*+,
1+3,4)4+3
use
1..*
5.+6/.$(.('(3)9
.(/23435$+67(1)48(
-2(2(;:494)(
84(=$-2+-(2)0
-./0
-2+-(2)0
*
9()$-2+-(2)0
1..*
84(=$-2+-(2)0$52+:-
/1)
-(29+3
9()$-2+-(2)0$52+:-
1..*
2+.($-/2)
*
2+.(
*
.(/23(2
performs>
3+)4<41/)4+3
using>
/1)484)0
1..*
1..*
creates>
<triggers
(3842+3'(3)
*
+:)1+'(
*
9)/<<
/1)484)0$9)2:1):2(
.(/23435$+67(1)
9(2841(
Figura 2.2: IMS Learning Design

rol con una actividad. Las actividades pueden ser actividades de aprendizaje (learning activity), actividades de soporte (support activity) o estructuras de actividades
(activity structure).
Una actividad es la unidad bsica de aprendizaje y hace referencia a un material fsico de aprendizaje, generalmente una liga hacia contenidos que incluyen texto
plano, hipertexto, grficos, medios audiovisuales, entre otros. Este vnculo se logra a
travs de la etiqueta environment (ambiente), con el propsito de lograr la reusabilidad del recurso.
El flujo de aprendizaje [Chen et al., 2005, Torres et al., 2006] de una unidad de
aprendizaje (UA) generalmente se representa por la estructura anidada de actividades de aprendizaje, como se muestra en la figura 2.3. Una UA se organiza como un
rbol de actividades en el que el elemento mtodo de ms alto nivel, pone juntos a
varios escenarios de aprendizaje que se ejecutan de forma independiente y concurrente. Dentro de una obra, un acto controla la sincronizacin del escenario. Mientras
26
que un escenario, puede incluir un nmero de actos que son ejecutados de manera
secuencial. Cada acto puede contener diversas partes de rol, las cuales son concurrentes e independientes, pero sncronas. Las actividades de aprendizaje de cualquier
estructura de actividades dentro de una parte de rol, deben ser ejecutadas tambin
de manera secuencial.
Method
IMS-LD Structure
Top-Level
Play1
concurrence
and independence
sequence
Act
<Role-Part>
Act
concurrence,
independence and
synchronization
<Role-Part>
Playn
Sub-Level
Subsub-Level
2
SA1
L-A1
Role
L-A2
L-An
Learning Activity-Level
simple sequence
Figura 2.3: Estructura de IMS LD
Por otro lado, en lo que se refiere al trabajo colaborativo, IMS LD implementa

la colaboracin entre roles como la representacin sincronizada de un nmero de
carriles de actividades, los cuales son descritos de forma independiente como trabajo
individual para cada rol que participa en la colaboracin. En este modelo, slo es
posible asignar estructuras de actividades completas a roles especficos, los cuales no
pueden ser cambiados o dinmicamente asociados a otras actividades. En la figura
2.4 se presenta la ejecucin de una instancia de una UA a lo largo del tiempo.
27
sequence
1
<Role-Part>
sequence
L-A
L-A
L-A
Role 1
<Role-Part>
L-A
L-A
Role 2
<Role-Part>
L-A
L-A
L-A
Role 1
<Role-Part>
L-A
10
Role 2
<Role-Part>
L-A
11
L-A
12
Role 2
Figura 2.4: Ejecucin de IMS LD

En la prctica, para poder trabajar con la especificacin IMS LD, es necesario el
uso de herramientas para tiempo de diseo y herramientas para tiempo de ejecucin
[Griths et al., 2005]:
Herramientas para tiempo de diseo: Son
generalmente
herramientas
de
autora de IMS LD, tambin conocidas como editores. Se emplean

para disear las UA, usualmente a travs de grficos e iconografas,
que al manipularse generan de manera automtica una instancia de
lenguaje IMS LD. Algunos ejemplos son Reload [Milligan et al., 2005],
aLFanet
LD
Editor
[van Rosmalen and Boticario, 2005]
ASK-LDT
[Sampson and Karampiperis, 2006].

Herramientas para tiempo de ejecucin: Una vez que la UA ha sido diseada,
para poder ser ejecutada son necesarias las herramientas para tiempo de ejecucin. La especificacin IMS LD requiere de dos herramientas indispensables:
28
El motor de ejecucin y el ambiente en tiempo de ejecucin (player ). El motor

de ejecucin es la herramienta que procesa e interpreta la UA, un ejemplo de
ello es el motor CopperCore [Martens and Vogten, 2005]. El player o ambiente en tiempo de ejecucin es la herramienta donde se entrega y desplega la
unidad de aprendizaje a los alumnos y profesores, un ejemplo de ello es Edubox
[Tattersall et al., 2005a].
Como parte de un proyecto de investigacin en la Universidad Massey de Nueva
Zelanda, Kim Hagen, Diana Hibbert y Kinshuk crearon Voyager, crearon un prototipo basado en web de un sistema de gestin de aprendizaje (LMS, por sus siglas
en ingls), que cumpla con la especificacin IMS LD. Los beneficios percibidos de
dicho sistema fueron la flexibilidad del modelo IMS LD para diferentes enfoques
pedaggicos y a diferentes niveles de uso. Sin embargo, los educadores que crearon
el prototipo de IMS LD encontraron difcil de entender en un principio la metfora de la obra de teatro. Aunado a esto, a los educadores tambin se les hizo difcil
disear un escenario de aprendizaje con mltiples flujos de trabajo e interacciones
opcionales. Tambin fue difcil modelar actividades que no son realizadas con una
secuencia en particular, por ejemplo, los estudiantes que llevan a cabo una actividad
de evaluacin antes o despus de asistir a una clase (otra actividad). Para los estudiantes, la metfora del teatro introdujo un nuevo modelo que ellos deban aprender
antes de conocer el contenido del curso, lo cual represent un incremento en su carga
cognitiva [Hagen et al., 2006].
Despus de esta revisin de la especificacin IMS LD, a continuacin se abordar
el sistema LAMS, que es un software inspirado en IMS LD pero con una orientacin
ms prctica sobre algunos aspectos que apenas se abordan en IMS LD, como el
diseo del aprendizaje basado en actividades individuales y colaborativas.
2.3.3.
LAMS
El sistema Learning Activity Management System (LAMS) [Dalziel, 2003] es un

software capaz de disear, administrar y desplegar escenarios de aprendizaje empleando tecnologas basadas en Internet. Para ello, LAMS integra los ambientes para la
administracin de usuarios, el ambiente de tiempo de ejecucin para la entrega de
secuencias al estudiante, el ambiente de tiempo de ejecucin del profesor para el mo-
29
nitoreo de las secuencias de los estudiantes y, la herramienta de autora y adaptacin

de secuencias del profesor.
En LAMS, el diseo del aprendizaje se centra en el diseo de una secuencia de
actividades para el aprendizaje. En dicha secuencia, los estudiantes deben llevar a
cabo las actividades de manera individual o en pequeos grupos para lograr los objetivos de aprendizaje. Cada actividad incluye las herramientas y recursos necesarios
para ser llevada a cabo, algunos ejemplos se describen a continuacin:
Pregunta y respuesta, lo cual tambin comprende respuestas de los estudiantes
compartidas con el grupo incluso de manera annima.
Encuestas con los resultados compartidos con todo el grupo.
Foro de discusin asncrono.
Chat sncrono.
Tablero de anuncios, con simple contenido de texto o instrucciones.
Presentacin e intercambio de recursos como URLs, pginas web y archivos.
Bloc de notas.
Diario.
Envo de tareas.
Preguntas de opcin mltiple y de verdadero o falso, con opcin para desplegar
retroalimentacin, promedio de la clase y puntaje ms alto.
Varias combinaciones de herramientas.
Adems de lo anterior, una herramienta de agrupacin permite que cualquier
herramienta se ejecute para toda la clase o en modo de pequeos grupos. La flexibilidad del lenguaje de diseo de aprendizaje de LAMS (LAMS LD), permite que ms
herramientas colaborativas puedan ser desarrolladas para ampliar el impacto de la
plataforma LAMS.
LAMS originalmente fue inspirado en IMS LD. Sin embargo, LAMS no fue diseado para ser una implementacin de referencia de la especificacin IMS LD, pero
30
se espera que a medida de que IMS LD evolucione y aborde sus actuales retos de implementacin, LAMS pueda soportar dicha especificacin. A pesar de que LAMS no
propone un LME y es limitado en el uso de estndares y especificaciones, el modelo
LAMS LD que se presenta en la figura 2.5, sugiere una orientacin prctica sobre
algunos aspectos que apenas se abordan en los LMEs actuales. Por mencionar un
ejemplo, LAMS mantiene un inters especial en el diseo de aprendizaje basado en
actividades individuales y colaborativas, adems tambin se hace un esfuerzo en desarrollar herramientas que faciliten el desempeo de dichas actividades. Finalmente,
LAMS incorpora cierta flexibilidad al disear estructuras de actividades aparte de
simples secuencias de actividades, como por ejemplo, actividades en paralelo, actividades opcionales y mecanismos de sincronizacin.
!"#$%!&
!"#$%!'()*+*,&'-+,*
parentLearningDesign
2>3-'*:)3;5+*,
@(*?34:)3;5+*,
parentActivity
1..*
"./+0+/1
grouping
grouping
:)3;5+*,
:)3;5
23456'7"./+0+/1
85/+3*-"./+0+/1
9()(66'6"./+0+/1
A3/+.'B3()?
$+456'"./+0+/1
$'<;'*.'"./+0+/1
=336"./+0+/1
CD"
I3);4
E3;)*(6FA3/'B33G
$;B4+/I+6'-
H3/'D@(*G
$.)+B'
$>()'?@'-3;).'
$;)0'1
#;6/+56'85/+3*
2>(/
createGrouping
:(/'"./+0+/1
:)3;5+*,"./+0+/1
$1*.>:(/'"./+0+/1
$.>'?;6':(/'"./+0+/1
9')4+--+3*:(/'"./+0+/1
Figura 2.5: LAMS Learning Design

Hasta este punto, se han revisado dos de las propuestas actuales ms interesantes
en el marco del e-learning. Sin embargo, estas propuestas se encuentran todava
31
dentro de la tercera etapa de la evolucin del e-learning, ya que ninguna de ellas tiene
un soporte completo de los PACs. En seguida se revisar el lenguaje LPCEL, que
aunque todava no cuenta con una implementacin de referencia, hace una propuesta
interesante para soportar formalmente los PACs dentro de una arquitectura orientada
a servicios.
2.3.4.
LPCEL
El lenguaje Learning Process Composition and Execution Language (LPCEL)

[Dodero et al., 2005, Torres et al., 2006] es un lenguaje formal que proporciona una
marco de referencia de contencin de elementos capaces de describir cualquier diseo
de un PAC. LPCEL se usa para especificar estructuras complejas y dinmicas, lo
que incluye roles, grupos, dependencias, reestricciones, escenarios, contenidos, servicios, evaluaciones y otros recursos, los cuales interactan para lograr un conjunto de
objetivos de aprendizaje. Adems, LPCEL permite el rediseo del proceso de aprendizaje de manera dinmica y no anticipada. LPCEL puede ser usado para describir
la ejecucin de un proceso de aprendizaje y al mismo tiempo, orquestar los servicios
y recursos necesarios para llevar a cabo de manera exitosa dicho proceso. LPCEL
puede integrar aplicaciones externas y servicios dentro del proceso de aprendizaje,
de tal forma que LPCEL se convierte en el ncleo de una Arquitectura Orientada a
Servicios (SOA, por sus siglas en ingls), la cual es pensada para integrar, componer
y ejecutar un PAC.
Una visin general del concepto de LPCEL se muestra en la figura 2.6. Este
modelo tiene 4 grupos principales de elementos:
Informacin general del proceso de aprendizaje, la cual comprende prerrequisitos, objetivos de aprendizaje, productos y caractersticas generales.
La estructura del proceso de aprendizaje, que se compone de actividades complejas, actividades bsicas y roles.
El detalle de las actividades que tomarn parte en el proceso de aprendizaje, lo cual comprende actividades de aprendizaje, actividades de evaluacin y
actividades de contexto.
32
Los recursos y servicios que pueden ser buscados, accesados, invocados o creados para cada actividad.
;*+'*+),*Q)'0.06DG
!"#$!%&'()*)+),*
;*+'*+),*%$</6.+)='
>?@'6+)='Q)'0.06DG
!'.0*)*5%>?@'6+)='
MOOP
NOOM
9,3'
NOOP
-'.+/0'
9':/)7)+'
NOOP
#,123'4%!'.0*)*5%"0,6'77
8)1
>?@'6+)='&'2'*<'*6)'7
>/+6,1'
877)5*1'*+
;<8)1
MOOP
;<9':/)7)+'
#,*+'*+Q'0.06DG
#,12,*'*+%#!"
$4'6/+'>*
877)5*1'*+
#,*+'*+7B+0/6+/0'
"'07,*877)51'*+
NOOP
"'01>2'0.+
L7'0
>2'0.+),*
#,123'4%#,12,*'*+
B':/'*6'
".0.33'3
<,ED)3'
#D,)6'
F,)*
A.7)6%#,12,*'*+
BC)+6D
B23)+
ED)3'
86+),*
#,12'*7.+'#8
-3,C
J'01)*.+'
&'3.G
877)5
;*=,H'
#0'.+'
I.+'C.G
#,12'*7.+'A8
#,12,*'*+%86+)=)+G
877'771'*+%86+)=)+G
!'.0*)*5%86+)=)+G
/7'
MOOP
#,*+'4+%86+)=)+G
NOOP
B'0=)6'%A/7
9'7,/06'7
MOOP
MOOP
866'77%K'+D,<
M
!)*HR+,
E'?%B'0=)6'%#3)'*+
!'.0*)*5%B'0=)6'
E'?%B'0=)6'%&'()*)+),*
9'1,+'%866'7
MOOP
;*2/+%".5'
!'.0*)*5%>?@'+6
!,6.3%866'77
MOOP
9'7/3+%".5'
MOOP
MOOP
)*+'0(.6'
JG2'7
B'0=)6'
+G2'7
;*+'0(.6'
9"#%A.7'<
?)*5)*5
MOOP
3)*H%?.7'<
MOOP
)*+'0(.6'
A)*<)*5
Figura 2.6: LPCEL

El elemento <lpcel-definition>permite la definicin de diversos elementos <complexlearningprocess>para representar un PAC. Cada uno de estos elementos se conforma por uno o ms elementos de componente de PAC
(<component-clp>) para disear las estructuras de aprendizaje complejas.
Un elemento de componente complejo (<complexcomponent>) incluye uno o
varios componentes bsicos (<basic-component>) y/o componentes complejos
(<complex-component>). Adems, para definir el flujo de aprendizaje, el lenguaje hace referencia a una coleccin de elementos como paralelizacin (<parallel>),
unin (<join>), hasta (<until>), el ciclo por cada (<foreach>) y el propio componente complejo; dichos elementos incluyen sus relaciones y un nmero de criterios
para indicar sus condiciones de inicio y terminacin.
Por su parte, los componentes de actividad (<component-activity>)
contienen una coleccin de elementos para ejecutar actividades como ac-
33
tividades de aprendizaje (<learningactivity>), actividades de evaluacin

(<assessmentactivity>) y actividades de contexto (<contextactivity>).
Cada actividad puede hacer referencia a diferentes especificaciones de recursos
(<resource>) a ser usados en la actividad. Un recurso puede invocar recursos locales (<local-access>) o remotos (<remote-access>), como contenidos
SCORM o aplicaciones remotas, como por ejemplo, repositorios de proyectos, laboratorios virtuales, simuladores, herramientas colaborativas, herramientas de diseo,
entre otros servicios.
A diferencia de otros LMEs, LPCEL tiene una consideracin de los roles ms all
de estudiante y docente. Para dar soporte a los PACs, sugiere que un estudiante
en un momento dado de su proceso de aprendizaje puede tomar un rol ms especfico,
por ejemplo, en un proyecto colaborativo un estudiante puede ser lder de proyecto,
mientras que otro puede tomar el rol de programador y otro el rol de investigador
de campo, esto sin que dejen de ser estudiantes, existiendo as una asociacin de
roles. Para dar soporte a ello, LPCEL cuenta con los elementos de rol (<role>) y
permisos (<permission>), los cuales son asignados a los componentes de actividad
y a los componentes complejos.
Como en el caso de IMS LD, para trabajar en un ambiente de e-learning basado
en LPCEL, es necesario el uso de herramientas complementarias, tanto para tiempo
de diseo como para tiempo de ejecucin. En [Torres et al., 2009c] se propone la
Arquitectura de Aplicaciones y Servicios Web para la Mejora del Aprendizaje (en
ingls WASEL: Web Applications and Services Enhanced Learning Architecture) (ver
la figura 2.7). Dicha arquitectura se basa en los sistemas de gestin de flujos de
trabajo [Hollingsworth, 1995] y el paradigma SOA [Erl, 2008].
La arquitectura WASEL se compone principalmente de los siguientes elementos:
Editor de procesos de aprendizaje: Esta herramienta de tiempo de diseo, sirve
para disear el proceso de aprendizaje a travs de una iconografa. De esta
forma el editor genera automticamente la instancia de LPCEL de un PAC,
que sirve como lenguaje script o guin para que se ejecute posteriormente en
el motor de ejecucin.
Motor de ejecucin de procesos de aprendizaje: Esta herramienta de tiempo
de ejecucin es el inters principal de la presente tesis, y es la encargada de
34
2.4. Motores de Ejecucin de Procesos de Aprendizaje
Figura 2.7: Arquitectura de Aplicaciones y Servicios Web para la Mejora del Aprendizaje (WASEL)
procesar y ejecutar la instancia de LPCEL. En las siguientes secciones se abordarn ampliamente los temas relacionados con las caractersticas del motor.
Bus de servicios de aprendizaje: Es la infraestructura de servicios que se utilizarn para soportar el proceso de aprendizaje.
Protocolos de comunicacin: Son las formas estndar en que se comunicarn los
diferentes servicios y aplicaciones entre s y con el motor. Entre ellos se incluyen
los lenguajes WSDL [W3C, 2007] y WADL [Hadley, 2009].
Con lo anterior concluye la revisin de los LMEs. El resto del captulo se enfocar
en los aspectos generales y especficos de los motores de ejecucin de procesos de
aprendizaje.
2.4.
Motores de Ejecucin de Procesos de Aprendizaje
En la seccin anterior se presentaron las caractersticas de diseo, ejecucin y control de los LMEs y se hizo una revisin de los lenguajes IMS LD, LAMS y LPCEL.
Como se vio anteriormente, los LMEs sirven para describir escenarios de aprendizaje. Sin embargo, al igual que en los sistemas de gestin de flujos de trabajo, es
35
necesario de un software que lleve a cabo el procesamiento y ejecucin del escenario

de aprendizaje descrito en una instancia de un LME. Dicho software es el motor de
ejecucin.
En la actualidad, no existen motores de ejecucin que soporten PACs, por ello el
objetivo de esta tesis de desarrollar un marco de referencia para la construccin de
dicho motor. Por lo tanto, en esta seccin se analizarn los tres puntos de partida que
se tienen: Los motores de ejecucin de flujos de trabajo, el motor de ejecucin de IMS
LD, y a manera de referencia, el ambiente de ejecucin de SCORM. Posteriormente en
las secciones siguientes, se abordarn los aspectos particulares de las caractersticas
de los LMEs de cuarta generacin que debe soportar el motor.
2.4.1.
Motores de Ejecucin de Flujos de Trabajo
Los motores de ejecucin de flujos de trabajo tienen su fundamento en los Sistemas de Administracin de Flujos de Trabajo (en ingls WFMS: Workflow Management Systems). Los WFMS, a grandes razgos, son sistemas computarizados utilizados para soportar y coordinar procesos de negocio en diversos dominios de aplicacin
como finanzas, manufactura, telecomunicaciones, entre otros. La Workflow Management Coalition (WMC), una organizacin internacional de vendedores, usuarios y
grupos de investigacin de flujos de trabajo, establece en [Hollingsworth, 1995] un
modelo de referencia de flujos de trabajo que se presenta a continuacin.
El modelo de referencia de flujos de trabajo define un flujo de trabajo como
la facilitacin computarizada o automtica de un proceso de negocio, entero o en
parte, en donde documentos, informacin y tareas se pasan de un participante a
otro de manera organizada a travs de reglas y procedimientos. Un flujo de trabajo
separa las diversas actividades de un proceso de negocio en un conjunto de tareas
definidas especficamente, y en un conjunto de dependencias entre las tareas. Las
tareas generalmente las llevan a cabo varios usuarios en concordancia con las reglas
de la organizacin relevantes al proceso representado por el flujo de trabajo.
A un WFMS, el modelo de referencia lo define como un sistema que define completamente, gestiona y ejecuta flujos de trabajo, a travs de la ejecucin de software
cuyo orden de ejecucin es manejado por una representacin computacional de la lgica del flujo de trabajo. Un WFMS es responsable de la planeacin y sincronizacin
36
de las diversas tareas en un flujo de trabajo, en concordancia con el conjunto de dependencias entre las tareas. Tambin es responsable de enviar cada tarea a la entidad
de procesamiento especfica, como un navegador web o un servidor de base de datos.
A los recursos de datos que utiliza una tarea se les llama tems de trabajo.
Una vez que han sido definidos los conceptos bsicos de los WFMS, a continuacin
se mostrarn las principales caractersticas y componentes de la arquitectura de los
WFMS.
As, de la figura 2.8, se puede observar que los WFMS se caracterizan por soportar
tres reas funcionales:
Figura 2.8: Caractersticas de los sistemas de flujos de trabajo
Funciones de tiempo de diseo relacionadas con la definicin y modelado del

flujo de trabajo y sus actividades.
Funciones de tiempo de ejecucin relacionadas con la administracin del flujo
de trabajo en un ambiente operacional, y con la secuencia de las diversas actividades que se manejan como parte de cada proceso.
37
Las interacciones en tiempo de ejecucin con usuarios humanos y otras aplicaciones y herramientas de tecnologas de la informacin, para el procesamiento
de los diversos pasos de cada actividad.
Ya con las reas funcionales definidas, en seguida se presentan los componentes

arquitectnicos de los WFMS (ver figura 2.9):
Figura 2.9: Componentes e interfaces de la arquitectura de flujos de trabajo
Servicios de desarrollo del flujo de trabajo: En ingls Workflow Enactment

Services, de acuerdo a [Hollingsworth, 1995], son servicios de software que
consisten en uno o ms motores de ejecucin de flujos de trabajo, para crear,
administrar y ejecutar instancias de flujos de trabajo. Las aplicaciones pueden
tener una interface para este servicio a travs de la interface de programacin
de aplicaciones de flujos de trabajo (WAPI, por sus siglas en ingls). Estos
servicios son prcticamente el ambiente de tiempo de ejecucin del WFMS.
Para interactuar con recursos externos, los servicios de desarrollo se pueden
comunicar a travs de las interface del cliente del flujo de trabajo, y a travs
de la interface de aplicacin invocada, las cuales se presentan en los siguientes
puntos. Tambin, ms adelante se abordarn a detalle las caractersticas de los
servicios de desarrollo del flujo de trabajo por ser de principal atencin en el
tema de la tesis.
38
Definicin del proceso: Es el tiempo de diseo del flujo de trabajo, donde se definen, describen y modelan el flujo de trabajo y sus actividades. Tpicamente
esta tarea se realiza con ayuda de herramientas como editores grficos.
Funciones del cliente del flujo de trabajo: La interaccin de los servicios de
desarrollo del flujo de trabajo con los recursos externos necesarios para las
actividades, puede llevarse a cabo a travs de la interface con las funciones del
cliente del flujo de trabajo. El motor de ejecucin interacta con esta interface, la cual a travs de un manejador de listas de trabajo, es responsable de
organizar el trabajo de parte de un recurso del usuario.
Funciones de aplicacin invocadas: Tambin es posible la interaccin de los servicios de desarrollo del flujo de trabajo con los recursos externos a travs de la
interface con las funciones de aplicacin invocadas, la cual, habilita al motor
para activar directamente una herramienta en especfico para llevar a cabo cierta actividad, generalmente basada en una aplicacin de servidor sin interface
de usuario.
Interoperabilidad del flujo de trabajo: Se han identificado cuatro niveles de capacidad para interactuar entre diversos y heterogneos WFMS, los cuales se
presentan brevemente a continuacin: (1) Procesos conectados discretamente
o encadenados; (2) procesos jerrquicos o subprocesos anidados; (3) proceos
conectados indiscretamente o punto a punto y; procesos sincronizados paralelamente.
Administracin de sistemas: El ltimo componente es una interface estndar
para la administracin y monitoreo, la cual permitir a la aplicacin administrativa de un vendedor trabajar en conjunto con el motor de ejecucin de otro
vendedor. Con esto se logra que varios servicios de flujos de trabajo compartan
funciones comunes de administracin y monitoreo.
Hasta ahora, se ha dado un panorama general sobre los WFMS, y como se mencion anteriormente, los servicios de desarrollo del flujo de trabajo consisten en uno
o ms motores de ejecucin de flujos de trabajo. A continuacin, se presentan ampliamente las caractersticas de los motores de ejecucin de flujos de trabajo.
39
Un motor de ejecucin de flujos de trabajo se define en [Hollingsworth, 1995] como

un servicio de software o motor que provee el ambiente de tiempo de ejecucin para
una instancia de un flujo de trabajo. Por lo tanto, el motor es el responsable del
control del ambiente de tiempo de ejecucin dentro de un servicio de desarrollo de
flujo de trabajo. Generalmente, los motores proporcionan facilidades para realizar:
1. La interpretacin del proceso definido.
2. El control de las instancias de los procesos incluyendo su creacin, activacin,
suspensin y terminacin.
3. La navegacin entre las actividades de un proceso como operaciones secuenciales o paralelas.
4. Permitir el acceso y salida de los participantes en el proceso.
5. La identificacin de tems de trabajo que requieren atencin del usuario y una
interface para soportar las interacciones con los usuarios.
6. El mantenimiento de los datos de control del flujo de trabajo.
7. Una interface para invocar aplicaciones y servicios externos, as como la relacin
que hay con los datos del flujo de trabajo.
8. Las acciones de supervisin y control con propsitos de administracin y auditora.
En lo que se refiere a las tres primeras actividades, para que un motor pueda interpretar un proceso definido en repetidas ocasiones, i.e. que el proceso sea
reutilizable, y que sus actividades puedan utilizarse en distintos puntos del proceso
y puedan repetirse, adems de poder implementarse en un ambiente con mltiples
usuarios, es necesaria la instanciacin del proceso y de sus actividades. Esta cuestin
se abordar a detalle en la seccin 2.11.2.
Sobre el acceso y salida de los participantes en el proceso, el modelo de referencia
de flujos de trabajo no especifica un marco de referencia en particular. Sin embargo,
en [Ferraiolo et al., 2007a] se plantea un mecanismo de control de acceso basado en
roles, con fundamento en el estndar RBAC [ANSI, 2004]. En la seccin 2.11.1, se
presentan estas cuestiones ampliamente.
40
Adems, para el soporte de estas actividades, el motor de flujos de trabajo necesita de dos componentes ms: Las llamadas a las interfaces de programacin de
aplicaciones (del ingls API ) y datos.
Al conjunto de llamadas a las interfaces de programacin de aplicaciones de un
motor de ejecucin, es llamado Intercambio e Interface de Programacin de Aplicaciones de Flujos de Trabajo (en ingls WAPI: Workflow Application Programming
Interface and Interchange). El WAPI comprende tanto funciones de llamadas al API,
como funciones de intercambio de datos. La mayora de las funciones de llamadas al
API se componen de un conjunto de parmetros definidos y cdigos de resultados.
Tambin donde es apropiado, se definen formatos de intercambio de datos, como por
ejemplo para intercambiar definiciones de proceso.
Las funciones de llamadas al API comprenden los siguientes grupos:
Establecimiento de sesiones.
Operaciones para la definicin de flujos de trabajo y sus objetos.
Funciones de control del proceso.
Funciones de supervisin del control del proceso.
Funciones para procesar el estado del proceso.
Funciones para administrar las actividades.
Operaciones de gestin de datos.
Funciones para manejar las listas de trabajo y los tems de trabajo.
Operaciones de administracin de usuarios.
Operaciones de administracin de roles.
Funciones para gestionar las auditoras.
Operaciones para el control de recursos.
Por otra parte, las funciones de intercambio de datos se espera que abarquen:
41
La transferencia de la definicin de procesos.

La transferencia de datos relevantes del flujo de trabajo.
Los datos relevantes del flujo de trabajo, son slo un tipo de dato de los WFMS.
Los WFMS contienen tres tipos de datos que se explican a continuacin, siendo los
datos, el ltimo de los componentes que se vern sobre el modelo de referencia de
los flujos de trabajo:
Datos de control del flujo de trabajo: Son los datos internos del motor de ejecucin usados para identificar el estado de un proceso o actividad individualmente. Estos datos no son accesibles por otra entidad ni son intercambiables.
Datos relevantes del flujo de trabajo: Son los datos usados por el WFMS para
determinar la transicin de estados de una instancia de proceso. Estos datos son
potencialmente accesibles para las operaciones de las aplicaciones de flujos de
trabajo, y pueden ser transferidos entre actividades por el motor de ejecucin.
Datos de aplicaciones de flujos de trabajo: Son los datos especficos de las
aplicaciones y no son accesibles por el WFMS.
Finalmente, existe un aspecto ms que tiene que ver con la ejecucin correcta y
confiable de las actividades que no se aborda en el modelo de referencia, dicho aspecto
es el soporte transaccional. Muchas de las actividades de un motor de ejecucin de
flujos de trabajo, usualmente se implementan a travs de un Modelo de Transacciones
Avanzado (MTA) para asegurar su ejecucin de manera correcta y fiable. Este aspecto
se extiende en la seccin 2.10.
En esta seccin se presentaron las caractersticas principales de los WFMS y
de los motores de ejecucin de flujos de trabajo, que son unos de los puntos de
partida principales sobre el diseo de un motor de cuarta generacin de PACs. A
continuacin, se presentarn los aspectos relacionados con el motor de ejecucin de
IMS LD y ms adelante, el ambiente de ejecucin de SCORM.
2.4.2.
El Motor de Ejecucin de IMS LD
El motor de ejecucin de IMS LD es la herramienta que procesa e interpreta la

UA, y la entrega para ser desplegada en el player o ambiente en tiempo de ejecucin.
42
Antes de abordar los aspectos concretos del motor de IMS LD, es necesario tener en
cuenta los siguientes conceptos [Tattersall et al., 2005b]:
Inscripcin a un curso: Es cuando los estudiantes se inscriben para participar en
un curso de aprendizaje electrnico (en ingls e-learning). En Mxico, a los
cursos de aprendizaje electrnico tambin se les suele llamar cursos virtuales o
cursos en lnea, sin embargo, es ms descriptivo el trmino curso de aprendizaje
electrnico.
Entrega de un curso: Es el proceso en el cual los estudiantes se involucran en un
proceso de aprendizaje soportado por sistemas de e-learning.
Poltica de entrega de un curso: Tiene que ver con la manera en que el diseo
del aprendizaje se le entrega a los participantes de un curso, principalmente en
el cmo se entrega y cundo se entrega, a un conjunto de estudiantes.
Proveedor de aprendizaje: Es la entidad encargada de la entrega de un curso y
de la poltica de entrega. Esta entidad puede ser una universidad, un instituto,
un profesor, entre otros.
Desde la primera etapa de la evolucin de los sistemas de e-learning y ms fuertemente en la tercera (ver seccin 2.1), se ha buscado la reusabilidad. Como un sistema
de la tercera etapa, el motor de IMS LD soporta la reusabilidad de las UA. Para ello,
existen cuatro requerimientos de reproducibilidad que los proveedores de aprendizaje
en sus polticas de entrega de cursos deben cumplir [Tattersall et al., 2005b]:
1. Debe ser posible que el mismo curso pueda ser entregado a diversos conjuntos
de estudiantes sin que ello ocasione que su estructura y contenidos se dupliquen.
2. Se debe procurar que las entregas de los cursos sean manejadas de una manera
eficiente, y de ser posible, en parte o completamente automatizadas.
3. Debe de haber un control de versiones efectivo para todos los cursos.
4. Pequeas actualizaciones a los cursos en ejecucin deben ser posibles sin perturbar el desarrollo de sus procesos de aprendizaje.
43
Ahora que se tienen claros los requerimientos y conceptos anteriores, se continuar

con los aspectos concretos del motor de IMS LD.
En [Vogten et al., 2005] se propone una arquitectura para la implementacin de
un motor de ejecucin de un LME, partiendo de un enfoque basado en las Mquinas
de Estado Finito (MEF). Una MEF [Sipser, 1997] consiste en un conjunto de estados,
un estado inicial, un alfabeto de entrada y una funcin de transicin. Las MEFs
ofrecen un enfoque lgico y metodolgico hacia el procesamiento secuencial de las
entradas, lo cual evita la propensin a errores de programacin condicional. Adems
son un concepto probado en cuanto a que permiten implementaciones eficientes y
efectivas. Las MEFs del motor de IMS LD se describen de la siguiente manera:
Conjunto de estados: Son los valores de las propiedades de las actividades. Un
estado representa la posicin de un usuario con respecto a su progreso en la
UA.
Estado inicial: Se define con el valor inicial de todas las propiedades para un
usuario. Estos valores iniciales los define la instancia de IMS LD, o bien, pueden
ser el resultado de ejecutar otras UA en etapas anteriores.
Alfabeto de entrada: Se compone por todos los constructores de IMS LD.
Funcin de transicin: Relaciona un smbolo del alfabeto de entrada i.e. un
constructor de IMS LD y el estado actual hacia el siguiente estado. Cuando
ocurre esta transicin, se le llama evento.
Al respecto, a continuacin se le prestar principal atencin al conjunto de estados. El mecanismo de estados para el motor de IMS LD, define una MEF para cada
usuario. Como se acaba de mencionar, el conjunto de estados de una MEF de IMS
LD, se compone de los valores de las propiedades de las actividades. Cada propiedad
representa datos que sern almacenados, y por ello cada una tiene una definicin con
uno o ms valores que se presentan a continuacin:
Tipo: Delimita los posibles valores y provee de semntica implcita en la interpretacin de los datos, de la misma manera que ocurre con los tipos de variable
en la mayora de los lenguajes de programamcin.
44
Valor por defecto: Es el valor que se utiliza al determinar el estado inicial de una
MEF.
Alcance: Puede ser local, lo cual significa que se limita al contexto de la ejecucin
actual, o puede ser global, lo cual implica que no tiene una relacin directa con
la ejecucin actual sino que abarca a todas las instancias de la UA.
Dueo: Define a quin o a qu pertenece la propiedad.
La combinacin de los valores de alcance y dueo de la propiedad, determina
cundo y cmo las propiedades son instanciadas. Una propiedad es instanciada cuando una nueva instancia de propiedad es creada. A una nueva instancia se le asigna
el valor inicial de la propiedad valor por defecto y su definicin correspondiente.
En las MEFs de IMS LD, se consideran dos tipos de propiedades:
Propiedades definidas por el usuario: Son el resultado de la interaccin entre
los usuarios y el sistema y son declaradas explcitamente en IMS LD. Para
este tipo de propiedades cuando no se define la propiedad valor por defecto, se
asigna el valor null (nulo).
Propiedades definidas por el sistema: Son las propiedades que no se declaran
explcitamente pero se asume que existen, como por ejemplo el estatus de completado de una actividad realizada por un usuario. Para este tipo de propiedades
cuando no se define la propiedad valor por defecto, el motor asigna el valor inicial cuando crea la propiedad. Adems, es responsabilidad del motor determinar
el valor del alcance y dueo de cada propiedad de este tipo.
Una vez explicados los conceptos anteriores, se proceder con explicar el proceso
de ejecucin de la UA en el motor. Ya que se tiene el escenario de aprendizaje definido
en una UA de IMS LD, el motor analiza la sintaxis de la UA y de ser correcta, crea
todas las propiedas y las almacena en una base de datos.
A las instancias especficas de una UA, se les llama ejecuciones (en ingls runs).
Una ejecucin se define en [Tattersall et al., 2005b] como la combinacin de una
UA particular con una comunidad de usuarios asignada. La ejecucin se introduce
como un trmino pedaggicamente neutral para unir a un grupo de usuarios con una
45
UA a travs de una publicacin. Cada ejecucin tiene uno o ms usuarios asignados,

formando as la comunidad de usuarios que participar en la UA. Los usuarios pueden
inscribirse a una UA en particular y son asignados a una o ms ejecuciones de la UA.
Una ejecucin tiene exactamente una publicacin asociada, la cual a la vez tiene
una UA asociada. Una publicacin permite el pre-procesamiento de los contenidos
de una UA de tal forma que puedan ser procesados fcilmente por el motor durante
la ejecucin de la UA. Por cada publicacin, una o ms ejecuciones pueden existir,
permitiendo la ejecucin en paralelo de la misma UA.
El encargado de publicar la UA es el motor de publicacin. Dicho motor primero
debe validar la UA y posteriormente compilarla para transformarla en un lenguage intermedio. En este ltimo proceso, se deben establecer todas las propiedades definidas
por el sistema.
La validacin de la UA comprende los siguientes aspectos:
Completitud: Se valida que todos los recursos referenciados localmente estn incluidos dentro del paquete de la UA. Esta validacin puede realizarse de manera
sencilla con tecnologa XML.
Validacin del manifiesto de la UA: Se valida el manifiesto XML (en ingls
XML Manifest) de la UA con el esquema de IMS LD (en ingls IMS LD
schema). Esta validacin tambin puede realizarse de manera sencilla con tecnologa XML.
Validaciones de semntica: Este tipo de validaciones tienen que ver con el significado, sentido e interpretacin de la UA. Las validaciones de semntica incluyen:
(1) determinar si la UA contiene referencias cruzadas; (2) validacin de los valores de los atributos de la UA; (3) verificar que no existan ciclos infinitos cuando
se emplea recursin. Tambin se pueden hacer validaciones sobre el significado
pedaggico de la UA, pero requieren de la intervencin de un experto humano.
Si la validacin resulta exitosa, se convoca al analizador sintctico de IMS LD, el
cual convierte la instancia de IMS LD en un lenguaje intermedio, el cual debe de estar
en un formato XML fcil de interpretar en la fase de ejecucin. Este formato se usa
durante la etapa de personalizacin de la UA. Otro resultado del anlisis sintctico es
46
el almacenamiento de todas las reglas que se deben aplicar durante la ejecucin de la

UA. Estas reglas se recuperan mediante el despachador de eventos para determinar
las acciones que se deben tomar cuando un evento ocurre. Finalmente, para terminar
con el proceso de publicacin se crean todas las definiciones de las propiedades.
Para ejecutar una UA es necesario que previamente se hayan definido los roles en
la UA, y posteriormente es responsabilidad del motor asignar los usuarios individuales
a los roles abstractos definidos en la UA. Es decir, la informacin sobre los roles es
asociada a la publicacin y almacenada a travs de las propiedades globales de la UA,
mientras que la informacin de los usuarios individuales es asociada a la ejecucin y
almacenada en las propiedades locales de la UA. Con ello, la participacin en un rol
es general para todas las instancias de la UA, mientras que la participacin en una
ejecucin es especfica de la ejecucin. La forma en que se hace la asignacin no es
parte de la funcionalidad del motor de ejecucin, sin embargo, proveer las interfaces
para que dicha asignacin se haga y que una asignacin no genere un estado no
permitido por la UA, s es responsabilidad del motor.
En los prrafos anteriores, se ha hablado bastante sobre el conjunto de estados
de las MEFs de IMS LD, y en parte del estado inicial. El alfabeto de entrada se
ha definido en la seccin 2.3.2. Con lo cual, se han abordado la mayora de las
caracetersticas de una MEF de IMS LD. No obstante, hace falta hablar sobre la
ltima de las caractersticas, la funcin de transicin.
Como se mencion anteriormente en la descripcin de una MEF, la funcin de
transicin relaciona un smbolo del alfabeto de entrada y el estado actual, hacia
el siguiente estado. Cuando ocurre esta transicin, se le llama evento, y se define
en [Vogten et al., 2005] como cualquier cosa que cambia el estado de una MEF.
Existen 2 tipos de eventos:
Eventos de propiedad: Ocurren cuando cambia el valor de una propiedad.
Eventos de tiempo: Ocurren despus de una cierta duracin de tiempo. En este
tipo de eventos existe el riesgo de un ciclo de recursin infinito. De aqu la
importancia del proceso de validacin semntica antes mencionado.
El manejador de eventos del motor de ejecucin de IMS LD es el componente
encargado de reaccionar ante los eventos, los cuales pueden o no desencadenar ms
47
eventos. Cuando es el caso de que desencadenan ms eventos, ocurre una cadena de

eventos. Los eventos subsecuentes, no necesariamente desencadenan un cambio de
propiedad, ya que pueden existir eventos que generen notificaciones o mensajes de
correo electrnico, sin que ello implique un cambio de propiedad.
Tambin puede ocurrir la situacin en que varias MEFs cambien de estado como
resultado de un evento, a travs de las propiedades globales. Esta situacin asegura la
propagacin y sincronizacin de diferentes roles y grupos que trabajan en conjunto.
Para que este mecanismo funcione adecuadamente, los cambios en ms de una MEF,
deben ser considerados como una accin atmica (ver seccin 2.10).
Hasta ahora, se han examinado las caractersticas generales de un motor de ejecucin de IMS LD. A continuacin, se presentarn algunas aspectos de una implementacin de referencia de dicho motor. El sistema en cuestin es el motor CopperCore [Martens and Vogten, 2005].
El motor CopperCore, cuenta con las siguientes caractersticas:
Una rutina de validacin para el archivo de manifiesto de IMS LD. Dicha rutina
incluye tanto la validacin tcnica, como la validacin semntica.
Una interface administrativa para gestionar publicaciones, ejecuciones, roles y
usuarios.
Interpretacin de IMS LD y entrega de contenido personalizado de acuerdo a
las reglas definidas en IMS LD. Esto se logra por medio del almacenamiento
del progreso del usuario y de su configuracin.
Independiente de la plataforma por haber sido implementado con tecnologas
Java y J2EE.
CopperCore para procesar exitosamente una instancia del lenguaje IMS LD, divide su funcionalidad en dos partes:
CourseManager : Es la parte de encargada de todas las tareas administrativas
para que LDEngine pueda funcionar. Tales como la administracin de usuarios,
roles, ejecuciones y publicaciones.
48
LDEngine: Es el corazn del sistema, y se encarga de la entrega en tiempo de

ejecucin del contenido personalizado definido en la instancia de IMS LD.
Como se mencion anteriormente, el CourseManager se encarga de la gestin de

publicaciones de UAs. Para que CopperCore lleve a cabo una publicacin, se hace la
llamada al API publishUOL (publicar UA). Dicha funcin ejecuta primero la rutina
de validacin, y posteriormente divide el diseo del aprendizaje en varias partes
como actividades, ambiente, objetos de aprendizaje, roles, entre otros, para hacer
ms sencilla su manipulacin. Despus se analizan los roles declarados en el diseo
del aprendizaje, para poder asignar los usuarios a los roles, y finalmente, se copia
todo el contenido en un directorio del servidor web para que pueda ser recuperado
durante el despliegue.
El motor CopperCore para poder hacer una entrega personalizada de una UA,
crea un expediente para cada usuario a travs de la llamada al API createUser
(crear usuario). El nico parmetro necesario en dicha llamada es el identificador del
usuario (id), ya que el resto de la informacin del usuario debe ser definida en la
instancia de IMS LD como propiedades globales personales, y deben ser almacenadas
en el expediente del usuario. Una vez que un usuario ha sido definido, no puede ser
eliminado.
Una vez creados los usuarios, se asignan a una ejecucin con la llamada al API
addUserToRun (agregar usuario a ejecucin), y se eliminan de una ejecucin con la
llamada removeUserFromRun (quitar usuario de una ejecucin). Las ejecuciones de

una publicacin son creadas con la llamada al API createRun (crear ejecucin).
En una ejecucin, para poder asignar los usuarios a los roles se utiliza el mtodo addUserToRole (agregar usuario al rol), y para eliminarlo del rol el mtodo
removeUserFromRole (quitar usuario del rol). Cabe mencionar que los roles en IMS
LD, son el principal mecanismo de personalizacin, y son esenciales para crear diferentes caminos de aprendizaje. En IMS LD se define una jerarqua de roles, con
lo cual un sub-rol hereda todas las propiedades de su ancestro. Adems, tambin
es posible que un usuario est asignado a mltiples roles, sin embargo, slo uno de
estos roles puede estar activo en un momento determinado. La llamada al API para
seleccionar el rol activo es setActiveRole (establecer el rol activo).
49
Con lo anterior, se ha visto la funcionalidad del componente CourseManager

de CopperCore. A continuacin se har una revisin del componente LDEngine de
CopperCore, el cual se encarga de la entrega en tiempo de ejecucin de la UA.
Como se mostr en la seccin 2.3.2, IMS LD define una jerarqua de actividades
para ser desempeadas por un rol en la seccin method (mtodo). Para cada actividad
existen recursos, objetos de aprendizaje y servicios de aprendizaje, agrupados en
un ambiente, el cual tambin es una jerarqua. El componente LDEngine define
diversos conceptos y llamadas al API para recuperar la informacin contenida en
esas jerarquas.
El rbol de actividades es una representacin XML de la seccin method de IMS
LD personalizada para el rol activo de un usuario. El rbol puede ser recuperado a
travs de la llamada al API getActivityTree (obtener rbol de actividades). El
rbol de actividades contiene slo los nodos disponibles para el usuario al momento
de la llamada al API, lo cual es una diferencia significativa con respecto a la diseo
original de la UA que contiene todos los nodos potenciales para todos los usuarios.
Este filtrado de nodos es slo un resultado de la personalizacin. El otro o aspecto
de la personalizacin se encuentra en los atributos de los nodos.
Cada nodo contiene los siguientes atributos:
completed : (completado). Valores posibles: true, false, unlimited (verdadero, falso, no limitado). Indica si un usuario ha completado el nodo o no.
Si el valor es no limitado, el nodo se considera completado.
environment: (ambiente). Es una lista separada por espacios que contiene los identificadores de los ambientes de la actividad representada por el nodo.
identifier : (identificador). Es el identificador del objeto representado por el nodo.
isvisible: (es visible?). Indica si el nodo es visible para un usuario o no.
role: (rol). El nombre del rol base para generar el rbol de actividades.
structure-type: (tipo de estructura). Valores posibles: sequence, selection (secuencia, seleccin). Indica el tipo de estructura de las actividades. Es decir, si
se ejecutan secuencialmente o si se pueden escoger ciertas actividades.
50
time-limit: (lmite de tiempo). Indica si la completitud de un nodo depende de un

evento de tiempo.
user-choice: (eleccin del usuario). El usuario debe indicar cundo es completada
la actividad.
Por su parte, el rbol del ambiente es una representacin XML del ambiente y
de los objetos y servicios de aprendizaje correspondientes a una o ms actividades.
Y es recuperado a travs del mtodo del API getEnvironmentTree (obtener rbol
del ambiente).
Todos los nodos tanto en el rbol de actividades como en el rbol de ambiente
pueden tener contenido. El contenido puede ser recuperado a travs de la llamada al
API getContent (obtener contenido). El contenido se recupera como XML personalizado parecido al contenido original del diseo del aprendizaje. Todo el contenido
puede incluir un ttulo y metadatos, si stos fueron definidos en la UA. La llamada
al API getContent no regresa el contenido actual de los tems, sino que cada tem
contiene una URL hacia la ubicacin del recurso que representa el contenido.
Con esto ha concluido con la revisin del motor de ejecucin de IMS LD. Durante
este apartado se abordaron los requerimientos para lograr la reusabilidad de las UA,
la arquitectura del motor de ejecucin de IMS LD basada en MEFs, se presentaron
los conceptos e implicaciones en la ejecucin y publicacin de una UA, as como su
proceso de validacin, y por ltimo se present el motor de IMS LD CopperCore
con sus dos componentes principales: CourseManager y LDEngine. A continuacin
se presentar brevemente el ambiente de tiempo de ejecucin SCORM.
2.4.3.
El Ambiente de Tiempo de Ejecucin de SCORM
En los apartados anteriores, se presentaron y analizaron los motores de ejecucin

de flujos de trabajo y el motor de ejecucin de IMS LD, como puntos principales de
partida hacia la construccin de un motor de ejecucin de PACs. En este apartado
se presenta el ambiente de ejecucin de SCORM. Dicha presentacin no se hace
como referencia hacia un motor de ejecucin, sino nicamente hacia el ambiente de
tiempo de ejecucin que incorpora tres caractersticas tiles para el diseo del motor
51
de ejecucin de PACs: Un modelo temporal de tiempo de ejecucin, un API bien

documentado, y un modelo de datos de tiempo de ejecucin.
SCORM es el acrnimo de Sharable Content Object Reference Model, que en
espaol se refiere al modelo de referencia de objetos de contenido intercambiables.
SCORM fue desarrollado por ADL (Advanced Distributed Learning), y comprende
una coleccin de estndares y especificaciones adoptadas de mltiples fuentes para
proveer interoperabilidad, accesibilidad y reusabilidad de contenidos web para el
aprendizaje. SCORM comprende tres modelos:
SCORM CAM: Es el moledo para agregar contenidos (Content Aggregation Model,
por sus siglas en ingls) [Advanced Distributed Learning (ADL), 2009c].
SCORM RTE: Es el ambiente de tiempo de ejecucin (Run-Time Environment,
por sus siglas en ingls) [Advanced Distributed Learning (ADL), 2009a].
SCORM SN: Es
tenidos
el
modelo
(Sequencing
and
de
secuenciacin
Navigation,
por
y
sus
navegacin
siglas
de
en
coningls)
[Advanced Distributed Learning (ADL), 2009b].

De ellos, el ambiente de tiempo de ejecucin SCORM RTE es el de principal
atencin en este apartado. A continuacin se abordarn los tres componentes del
ambiente de tiempo de ejecucin de nuestro inters: El modelo temporal de tiempo
de ejecucin, el API y el modelo de datos.
El modelo temporal de SCORM RTE se muestra grficamente en la figura 2.10.
Dicho modelo toma como referencia el estndar de tecnologa para el aprendizaje
de la IEEE Data Model for Content to Learning Management System Communication
[IEEE, 2005], y define los siguientes conceptos:
Intento de estudiante: (En ingls Learner Attempt). Comprende un esfuerzo rastreado del estudiante para satisfacer los requerimientos de una actividad de
aprendizaje que usa un objeto de contenido. Un intento puede extenderse hacia ms de una sesin del estudiante y puede ser suspendido entre sesiones del
estudiante.
52
Figura 2.10: Modelo temporal de SCORM RTE

Sesin del estudiante: (En ingls Learner Session). Se trata de un periodo de
tiempo sin interrupciones durante el cual un estudiante se encuentra accesando
un objeto de contenido.
Sesin de comunicacin: Es la conexin activa entre un objeto de contenido y un
API.
Sesin de usuario: (En ingls Login Session). Comprende el periodo de tiempo
desde que un estudiante comienza una sesin con el sistema, y hasta que el
estudiante termina la sesin con el sistema.
Como se mencion en el listado anterior, la sesin de comunicacin es la conexin

activa entre un objeto de contenido y un API. El API (interface de programacin
de aplicaciones) es el mecanismo de comunicacin entre objetos de contenido y los
sistemas de gestin de aprendizaje (LMS, por sus siglas en ingls). A travs del API
se informa al LMS del estado conceptual de comunicacin entre un LMS y un objeto
de contenido, dicho estado de comunicacin puede ser inicializado, terminado y/o
en condicin de error. De esta forma, el API se usa para recuperar y almacenar
datos como calificaciones, lmites de tiempo, y otros, entre el LMS y los objetos de
contenido. El API de SCORM RTE se muestra de manera grfica en la figura 2.11.
53
Figura 2.11: API de SCORM RTE

Los mtodos del API de SCORM RTE se dividen en tres categoras de acuerdo
a su propsito. Las categoras son mtodos de sesin, mtodos de transferencia de
datos y mtodos de soporte. A continuacin se presenta brevemente la funcionalidad
de los mtodos de sesin del API de SCORM RTE:
Initialize: (Inicializar). Inicia la sesin de comunicacin.
Terminate: (Terminar). Termina la sesin de comunicacin.
Por su parte los mtodos de transferencia de datos cuentan con la siguiente
funcionalidad:
GetValue: (Obtener valor). Pide un valor particular de informacin al LMS.
SetValue: (Establecer valor). Pide la transferencia hacia el LMS de un valor de
informacin.
Commit: (Cometer). Pide que todos los datos manipulados en la sesin de comunicacin sean almacenados de manera persistente.
54
Y por ltimo se encuentran los mtodos de soporte, los cuales se encargan principalmente de obtener y describir los errores en tiempo de ejecucin:
GetLastError : (Obtener el ltimo error). Pide el cdigo de error del estado actual
de la instancia del API.
GetErrorString : (Obtener mensaje de error). Recupera la descripcin textual del
estado del error actual.
GetDiagnostic: (Obtener diagnstico). Pide informacin de diagnstico sobre la
instancia del API.
Los errores en SCORM RTE, tienen la clasificacin mostrada en la tabla 2.2.
Categora del cdigo de error
No hay error
Errores generales
Errores de sintaxis
Errores del servicio de tiempo de ejecucin
Errores del modelo de datos
Errores definidos por la implementacin
Rango del cdigo de error

0
100 - 199
200 - 299
300 - 399
400 - 499
1000 - 65535
Tabla 2.2: Categoras de los cdigos de error de SCORM RTE

Adems de un mecanismo de comunicacin, es necesario un modelo de datos
comn para rastrear la experiencia de aprendizaje del estudiante con los objetos de
contenido, como por ejemplo el resultado de un examen. Los elementos del modelo
de datos de SCORM RTE, se presenta de manera tabular en la tabla 2.3.
Elemento del modelo
de datos
Accin de lmite de tiempo
Vnculo en notacin de
punto
cmi.time_limit_action
Calificacin
cmi.score
Comentarios del estudiante

Comentarios del LMS
cmi.comments_from_learner
cmi.comments_from_lms
Descripcin
Indica lo que debe hacer el objeto de contenido cuando se ha pasado el tiempo mximo
permitido
Identifica la calificacin de un estudiante para
un objeto de contenido
Contiene texto del estudiante
Contiene comentarios y anotaciones que
tienen la intencin de estar disponibles para
el estudiante
55
Crdito
cmi.credit
Datos de lanzamiento
cmi.launch_data
Datos suspendidos
cmi.suspend_data
Entrada
cmi.entry
Escala de calificacin de
aprobado
Estatus de completitud
cmi.scaled_passing_score
Estatus de xito
cmi.success_status
Identificador del
diante
Interacciones
estu-
cmi.completion_status
cmi.learner_id
cmi.interactions
Localizacin
cmi.location
Medida de progreso
cmi.progress_measure
Modo
cmi.mode
Nombre del estudiante

Objetivos
cmi.learner_name
cmi.objectives
Preferencia del estudiante

Salida
cmi.learner_preference
Tiempo mximo permitido
cmi.max_time_allowed
Tiempo de sesin
cmi.session_time
Tiempo Total
cmi.total_time
cmi.exit
Indica si el estudiante ser acreditado por su

desempeo en el objeto de contenido actual
Provee de datos especficos a un objeto de contenido, los cuales el objeto de contenido puede
usar para inicializarse
Provee informacin que puede ser creada por
un objeto de contenido como resultado de un
estudiante accesando o interactuando con el
objeto de contenido
Contiene informacin que evala si un estudiante ha accesado el objeto de contenido previamente
Identifica la escala de calificacin de aprobado
para un objeto de contenido
Indica si el estudiante ha completado el objeto
de contenido
Indica si el estudiante ha dominado el objeto
de contenido
Identifica al estudiante de parte de la instancia que inici el objeto de contenido
Define informacin pertinente a una interaccin con el propsito de medir o evaluar
Representa la localizacin de un objeto de
contenido
Identifica una medida de progreso que el estudiante ha realizado para completar el objeto
de contenido
Identifica los modos en que un objeto de contenido puede ser presentado al estudiante
Representa el nombre del estudiante
Especifica los objetivos de aprendizaje o desempeo asociados con un objeto de contenido
Especifica las preferencias del estudiante asociadas con su uso del objeto de contenido
Indica cmo o por qu el estudiante ha dejado
el objeto de contenido
Indica la cantidad de tiempo acumulada que
tiene permitido el estudiante en el uso de un
objeto de contenido durante su intento de estudiante
Identifica la cantidad de tiempo que ha transcurrido en la sesin actual del estudiante
para un objeto de contenido
Identifica la suma de tiempo de todas las sesiones del estudiante acumuladas en el actual
intento del estudiante previo a la sesin del
estudiante actual
56
2.5. Diversidad Pedaggica y Descripcin del Flujo de Aprendizaje
Umbral de completitud
cmi.completion_threshold
Identifica un valor con el cual medir el progreso que el estudiante ha hecho para completar
un objeto de contenido y que puede ser comparado para determinar si el objeto de contenido se puede considerar como completado
Tabla 2.3: Elementos del modelo de datos de SCORM RTE
Con esta revisin de SCORM RTE, se concluye la presentacin de los puntos de

partida de referencia que se tienen para disear un motor de ejecucin de PACs, que
como se mostr, SCORM RTE aporta un modelo temporal de tiempo de ejecucin,
un API, y un modelo de datos. En las secciones siguientes, se abordarn los aspectos
particulares de las caractersticas de los LMEs de cuarta generacin que debe soportar
el motor de ejecucin de PACs.
2.5.
Diversidad Pedaggica y Descripcin del Flujo de

Aprendizaje
En la seccin anterior se abordaron los puntos de partida para el diseo de la

arquitectura de un motor de ejecucin PACs. A partir de esta seccin, se abordarn
los puntos de llegada o las capacidades que el motor debe tener para poder soportar
PACs.
En la seccin 2.3.1, se describieron las caractersticas que debe tener un LME para
poder soportar un PAC. A continuacin se abordarn nuevamente estas caractersticas, pero ahora no desde el punto de vista del lenguaje, sino desde la perspectiva
del diseo de la implementacin en el motor de ejecucin.
En esta seccin se abordarn las primeras dos caractersticas, que son diversidad
pedaggica y descripcin del flujo de aprendizaje, ya que desde el punto de vista del
diseo de la implementacin, ambas caractersticas estn directamente relacionadas.
Esta relacin se debe a que, para que pueda existir diversidad pedaggica, es necesario
que el LME y su ambiente en tiempo de ejecucin, tengan la expresividad suficiente
57
para poder describir flujos de aprendizaje complejos. Es decir, flujos de aprendizaje

que vayan ms all de simples secuencias lineales de actividades.
El flujo de aprendizaje, como se explic en la seccin 2.3, consiste en el orden
temporal en el que las diversas actividades de aprendizaje se desarrollan dentro
de una UA [Koper and Tattersall, 2005]. Los LMEs como IMS LD, LAMS y LPCEL tienen diferente capacidad expresiva para representar flujos de aprendizaje. En
[Torres et al., 2009d] y [Torres et al., 2009b], se hace una evaluacin de la expresividad de dichos lenguajes basada en los patrones de control de flujos de trabajo. Esta
evaluacin es trascendente para el presente trabajo de investigacin, ya que de la
misma forma que se evalan los LMEs, se evaluar la capacidad de navegacin en el
proceso de aprendizaje del motor de ejecucin.
2.5.1.
Evaluacin de los Flujos de Aprendizaje Basada en Patrones

de Control de Flujos de Trabajo (WCP)
Los patrones de control de flujos de trabajo [Russell et al., 2006] (WCP, por sus
siglas en ingls), son un mecanismo para evaluar la capacidad expresiva de los WFMS,
con el objetivo de delinear y describir de forma imperativa, los requerimientos fundamentales que surgen de manera recurrente durante el modelado de procesos. Hasta
la fecha, 43 patrones han sido identificados, y se clasifican en:
Control de flujo bsico: Capturan los aspectos elementales de control de procesos.
Ramificacin y sincronizacin avanzada: Describen conceptos ms complejos
sobre ramificacin y sincronizacin.
Instancias mltiples: Describen situaciones donde hay mltiples hilos de ejecucin
activos relacionados a una misma actividad.
Basados en estado: Reflejan situaciones en las que las soluciones se alcanzan ms
fcilmente en lenguajes que soportan la nocin de estado. En este contexto,
se considera que un estado de una instancia de proceso incluye una amplia
coleccin de datos asociadas con el estado de varias actividades, as como datos
relevantes al proceso.
58
Cancelacin y finalizacin: Consideran variantes en un proceso a travs del concepto de cancelacin de actividades, donde la instancia de la tarea activa es
descartada.
Iteracin: Capturan comportamientos repetitivos en un flujo de trabajo.
Terminacin: Describen las circunstancias sobre las cuales un flujo de trabajo se
considera completado.
Desencadenamiento y descargo: Consideran las seales externas que son requeridas para comenzar ciertas tareas.
En
las
evaluaciones
antes
mencionadas
de
[Torres et al., 2009d]
[Torres et al., 2009b], de los 43 patrones, la evaluacin se centr en 10 WCP,

por su capacidad de representar los flujos de aprendizaje ms comunes.
De la categora de control de flujo bsico se incluyeron todos los WCP y se
describen a continuacin:
Secuencia: Una tarea en un proceso se habilita despus de la terminacin de la
tarea precedente en el mismo proceso.
Separacin paralela: La divergencia de una rama en dos o ms ramas paralelas,
cada una de las cuales se ejecuta concurrentemente.
Sincronizacin: La convergencia de dos o ms ramas en una rama sencilla subsecuente, de tal forma que el hilo de control pase a la rama subsecuente cuando
todas las ramas entrantes hayan sido habilitadas.
Eleccin Exclusiva: La divergencia de una rama en dos o ms ramas de tal forma
que cuando la rama entrante es habilitada, el hilo de control inmediatamente
pasa a precisamente una de las ramas de salida basado en un mecanismo de
seleccin que puede elegir a una de las ramas de salida.
Combinacin Sencilla: La convergencia de dos o ms ramas en una rama sencilla
subsecuente de tal forma que cada vez que una rama entrante es habilitada, el
hilo de control pasa a la rama subsecuente.
59
Por otra parte, de la categora de ramificacin y sincronizacin avanzada, en la

evaluacin se incluyeron los patrones que se describen a continuacin:
Eleccin mltiple: La divergencia de una rama en dos o ms ramas de tal forma
que cuando la rama entrante es habilitada, el hilo de control inmediatamente
pasa a una o ms de las ramas de salida en base a un mecanismo que selecciona
una o ms ramas de salida.
Combinacin estructurada y sincronizada: La convergencia de dos o ms ramas (que divergieron antes en el proceso en un punto nico e identificable) en
una sencilla rama subsecuente, de tal forma que el hilo de control pase a la rama subsecuente cuando cada rama entrante activa sea habilitada. Este patrn
ocurre en un contexto estructurado, i.e. debe de haber una eleccin mltiple
sencilla antes en el modelo del proceso con la que la combinacin estructurada
y sincronizada est asociada, y todas las ramas salientes de la eleccin mltiple
deben combinarse.
Combinacin mltiple: La convergencia de dos o ms ramas en una rama sencilla
subsecuente de tal forma que cada vez que una rama entrante es habilitada se
pasa el hilo de control a la rama subsecuente.
Discriminador estructurado: La convergencia de dos o ms ramas en una rama
sencilla subsecuente siguiendo una correspondencia divergente antes en el modelo del proceso, de tal forma que el hilo de control pase a la rama subsecuente
cuando la primera rama entrante sea habilitada. El habilitamiento de ramas
entrantes subsecuentes no resulta en pase del hilo de control. El constructor del
discriminador estructurado se reinicia cuando todas las ramas entrantes han
sido habilitadas. El discriminador estrucutrado ocurre en un contexto estructurado, i.e. debe haber slo una separacin paralela antes en el proceso con
la que el discriminador estrucutrado est asociado y en l deben combinarse
todas las ramas del discriminador estructurado. Estas ramas deben seguir el
flujo de la separacin paralela al discriminador estructurado sin separaciones o
combinaciones, o stos deben estar en forma estructurada (i.e., separaciones y
combinaciones balanceados).
Finalmente, de la categora de iteracin en la evaluacin se incluy el patrn de
ciclo estructurado:
60
Ciclo estructurado: La habilidad de ejecutar una tarea o subproceso repetidamente. El ciclo tiene una condicin de pre-prueba o de post-prueba asociada
con l, y es evaluada al principio o al final del ciclo para determinar si debe
continuar. La estructura del ciclo tiene slo un punto de entrada y slo un
punto de salida.
Los resultados de la evaluacin se muestran en la tabla 2.4. En la parte superior
de la tabla se muestran los LMEs IMS LD, LAMS y LPCEL, mientras que del
lado izquierdo los WPC a considerarse. En las intersecciones entre el LME y el
patrn puede aparecer el smbolo +, que significa que el patrn est completamente
soportado; el smbolo quiere decir que el patrn est soportado parcialmente a
travs de una solucin alternativa; y el smbolo -, significa que el patrn no puede
ser expresado por el lenguaje.
!"#$%&"'()"*+#"&(,-++.#*
/01234
3501
3,)63
7-89:()"*+#"&(;&"'
!!!"#!$%&'%()%
!!!+#!,-.-//%/!$0/12
!!!4#!$5()6.7(18-217(
!!!:#!;<)/'=1>%!?671)%
!!!@#!$1A0/%!B%.C%
!!!I#!$2.')2'.%G!J1=).1A1(-27.
9
9
9
9
*
*
/+.#-+9"*
!!!"K#!$2.')2'.%G!L770
5<=-*:.<(7#-*:>9*?(-*<(
1@*:>#"*9A-+9"*
!!!D#!B'/21E?671)%
!!!F#!$2.')2'.%G!$5()6.7(181(C!B%.C%
!!!H#!B'/21EB%.C%
Tabla 2.4: Evaluacin de la capacidad expresiva de los LMEs

Como puede observarse, IMS LD slo tiene soporte completo para el patrn de
secuencia. El patrn de separacin paralela puede describirse al definir ms de un
61
elemento <play>(obra) (ver figura 2.2), pero esto ocasionara una prdida de sentido del script, ya que una obra se traduce a un proceso de enseanza-aprendizaje
y en consecuencia, habra muchos procesos de aprendizaje donde pedaggicamente
slo debe haber uno. Adems no hay manera de sincronizar obras. IMS LD cuenta
con la opcin de elegir un nmero de actividades, pero ello no implica que los patrones de eleccin exclusiva, eleccin mltiple, sincronizacin, combinacin simple,
combinacin mltiple y discriminador estructurado estn soportados, ya que las actividades son ejecutadas secuencialmente de forma rgida como se muestra en la figura
2.4.
En el modelo de informacin de LAMS (ver figura 2.5), tambin hay
un soporte completo para el patrn de secuencia a travs del elemento
<SequenceActivity>(actividad secuencial). Los patrones de separacin paralela,
sincronizacin y combinacin simple, tambin estn soportados, pero estn limitados a un conjunto de actividades ya definidas. Estos patrones tienen soporte
a travs de los elementos <SynchGateActivity>(compuerta de sincronizacin
de actividades), <ScheduleGateActivity>(compuerta de planeacin de actividades), <PermissionGateActivity>(compuerta de permisos de actividades) y
<ParallelActivity>(actividad en paralelo).
En el caso de LPCEL (ver figura 2.6), el soporte a estos 10 WCP es completo y se
logra a travs de las colecciones de elementos <Complex-Component>(componente
complejo)
<Basic-Component>(componente
bsico),
las
relaciones
entre ellos, incluyendo los criterios para indicar las condiciones de inicio
La
coleccin
tos
terminacin
de
de
los
elementos
<Sequence>(secuencia),
<Switch>(cambio),
componentes
de
PACs
(<Component-CLP>).
<Complex-Component>comprende
<Parallel>(paralelo),
<While>(mientras),
los
elemen-
<Choice>(eleccin),
<doWhile>(hacer
mientras),
<Join>(unin), <Split>(separacin) y <CompensateCA>(compensacin). La

coleccin de <Basic-Component>comprende los elementos <Action>(accin),
<Flow>(flujo), <Delay>(retraso), <Invoke>(invocar), <Gateway>(compuerta),
<Terminate>(terminar), <Assig>(asignar), <Create>(crear) y <CompensateBA>(compensacin).
Con la presentacin de esta evaluacin se pretende mostrar el impacto del lenguaje de modelado en la facultad del motor para ejecutar flujos de aprendizaje y navegar
62
2.6. Composicin Dinmica y No Anticipada
a travs de los procesos de aprendizaje. Como principio, un motor de ejecucin debe

tener la capacidad de ejecutar y navegar el proceso definido en su lenguaje de modelado. De esta forma, la evaluacin de navegacin del proceso de aprendizaje del
motor de ejecucin, puede realizarse en base a los WCP.
En la siguiente seccin, se abordar la caracterstica de composicin dinmica y
no anticipada, la cual es la base para ejecutar adaptaciones no anticipadas en tiempo
de ejecucin de los procesos de aprendizaje.
2.6.
Composicin Dinmica y No Anticipada
En la seccin anterior se abord la diversidad pedaggica y descripcin del flujo

de aprendizaje, y se presentaron los patrones de control de flujos de trabajo para
evaluar estas caractersticas. En esta seccin se hablar sobre la capacidad del motor
de composicin dinmica y no anticipada, la cual es la base para poder modificar el
diseo del aprendizaje del lenguaje de modelado, para poder realizar adaptaciones
no anticipadas en tiempo de ejecucin.
Como se mencion en la seccin 2.3.1, en algunos casos, la especificacin inicial
de un proceso de aprendizaje debe ser redefinida y modificada segn el tipo de
colaboracin y negociacin entre los estudiantes y los instructores. La composicin
dinmica y no anticipada, se refiere a la capacidad de poder modificar en tiempo
de ejecucin el diseo del aprendizaje, sin que ello afecte el estado alcanzado en el
proceso.
Cuando se disea una UA, el objetivo es plasmar el desarrollo del conocimiento, habilidades y competencias empleando diversos paradigmas de instruccin
[Koper, 2003, Rosmalen et al., 2003]. Sin embargo, si se definen todas las actividades
y asignaciones de usuarios en tiempo de diseo, el resultado es un esquema rgido que
no puede ser adaptado de acuerdo a los eventos que ocurren al ejecutar las secuencias de aprendizaje. Por el contrario, si todas las actividades se definen en tiempo
de ejecucin, el resultado ser un esquema ms flexible, pero sin ningn diseo del
aprendizaje.
En este sentido los diseadores instruccionales encuentran dificultad, debido al
hecho de que cada estudiante es en parte responsable de construir su aprendiza-
63
je. Los LMEs como IMS LD y LAMS estn pensados para describir escenarios de
aprendizaje que pueden ser diseados completamente antes de su despliegue, a diferencia de LPCEL, que permite el rediseo del proceso de aprendizaje de manera
dinmica y no anticipada, una vez que el escenario de aprendizaje se est ejecutando
[Torres et al., 2005a].
Por ello, el motor de ejecucin debe ser capaz de soportar de manera dinmica
la modificacin del proceso de aprendizaje [Torres et al., 2005b].
En la siguientes secciones se abordarn las caractersticas relacionadas con los
servicios que soportan el aprendizaje y el paradigma SOA.
2.7.
Descentralizacin de los Servicios de Aprendizaje
En la seccin anterior se abord la capacidad del motor de modificar de manera

dinmica y no anticipada, el proceso de aprendizaje. En esta seccin se tratar la descentralizacin de los servicios de aprendizaje, la cual tiene que ver con el paradigma
de arquitectura orientada a servicios (SOA, por sus siglas en ingls).
La descentralizacin de los servicios de aprendizaje, como se mencion en la
seccin 2.3.1, se refiere a que los servicios de aprendizaje puedan ser recuperados y
desplegados tanto de manera local como de manera distribuida.
En la actualidad, lo que ocurre con las UAs de IMS LD, LAMS, y sistemas de
la segunda etapa de la evolucin de los sistemas de e-learning como BlackBoard
1
y Moodle2 , es que sus UAs estn restringidas a los recursos digitales que son
empaquetados en ellas. Lo cual, no permite la integracin de recursos y aplicaciones

externas.
Para dar esta capacidad de integracin a las UAs, es necesario que sean consideradas como un conjunto de servicios de aprendizaje [Torres et al., 2005b].
1
2
http://www.blackboard.com/
http://www.moodle.org
64
2.7. Descentralizacin de los Servicios de Aprendizaje
2.7.1.
Servicios de Aprendizaje
Dentro del ambiente de un PAC, existen una gran variedad de recursos y servicios
que los estudiantes pueden acceder para lograr sus objetivos de aprendizaje. stos
se clasifican en:
Servicios y recursos de aprendizaje: Tienen un impacto directo en el aprendizaje, e.g. laboratorios virtuales, tutoriales, simuladores, contenidos educativos,
sistemas de evaluacin, sistemas de bsqueda, ambientes de programacin y
diseos, entre otros.
Servicios y recursos de comunidad: Permiten generar espacios para el desarrollo de competencias colectivas, e.g. herramientas de colaboracin, foros, listas
de distribucin, herramientas de coordinacin, agendas compartidas, repositorios para trabajo en equipo, gestin de documentos, entre otros.
Servicios y recursos de contexto: Muestran la actividad que los estudiantes estn desarrollando en su ambiente de aprendizaje, e.g. servicios de tutora, servicios de biblioteca digital, servicios universitarios, entre otros.
Algunos de estos servicios pueden ser recuperados y desplegados localmente,
mientras que otros pueden ser ejecutados de manera distribuida, basados en un
paradigma SOA, permitiendo la integracin con nuevos recursos y servicios al ambiente de aprendizaje. A continuacin, se abordar el paradigma SOA.
2.7.2.
Arquitectura Orientada a Servicios
El paradigma de arquitectura orientada a servicios (SOA) [Erl, 2004, Erl, 2008] es

un enfoque que ayuda a grandes sistemas a mantenerse escalables y flexibles mientras
siguen creciendo. SOA acepta que la nica forma de mantener la flexibilidad en
grandes sistemas distribuidos es soportando la heterogeneidad, descentralizacin y
la tolerancia a fallos [Josuttis, 2007].
El enfoque SOA consiste de tres elementos principales:
65
Servicios: Representan una funcionalidad de negocios o de soporte al aprendizaje

de manera auto contenida, la cual puede ser parte de uno o ms procesos, y
adems, puede ser implementada en cualquier tecnologa o plataforma.
Una infraestructura especfica: Permite combinar los servicios de manera sencilla y flexible. En el contexto de los negocios se le llama Enterprise Service
Bus (ESB) o bus de servicios empresariales [Chappell, 2004]. En el contexto
de la tecnologa educativa y la arquitectura WASEL (ver seccin 2.3.4) a la
infraestructura se le llama Learning Service Bus (LSB) o bus de servicios de
aprendizaje [Torres et al., 2010a].
Polticas y procesos: Sirven para lidiar con las cuestiones de los grandes sistemas
distribuidos al ser heterogneos, encontrarse en mantenimiento y tener diversos
dueos.
Una vez descritos los elementos principales del paradigma SOA, es necesario
hacer mencin sobre la forma de controlar los procesos bajo este paradigma, ya que
los sistemas distribuidos cuentan con diferentes dueos. Existen dos enfoques de
control de procesos [Josuttis, 2007]:
Orquestacin: en este enfoque, se emplea un controlador central que coordina todas
las actividades del proceso. Este controlador central, tambin llamado motor
de procesos, tiene la habilidad de monitorear los servicios.
Coreografa: en este enfoque, ninguna entidad tiene el control total del proceso e
incluso puede darse el caso de que nadie conozca el proceso completo. Como
no existe un control central, los sistemas pueden escalarse ms fcilmente. Sin
embargo, con este enfoque es muy difl saber el estado en que se encuentra el
proceso.
Dados los enfoques de control de procesos, el motor de ejecucin de PACs para
poder descentralizar los servicios de aprendizaje, debe estar dentro de un ambiente
SOA y debe ser la entidad controladora del proceso con un enfoque de orquestacin.
Esto debido a que en un proceso de aprendizaje, es necesario tener control sobre el
proceso y conocer el estado en el que se encuentra.
En la siguiente seccin, se abordar la caracterstica de separacin del proceso de
aprendizaje y servicio.
66
2.8. Separacin del Proceso de Aprendizaje y Servicio
2.8.
Separacin del Proceso de Aprendizaje y Servicio
En la seccin anterior se habl sobre la descentralizacin de los servicios de aprendizaje, caracterstica que desde el punto de vista del diseo del motor de ejecucin,
tiene que ver con la orquestacin de servicios web en un ambiente SOA. La caracterstica de la que se hablar en esta seccin, separacin del proceso de aprendizaje
y servicio, tambin tiene que ver con el paradigma SOA, concretamente con la capacidad de orquestacin del motor.
La separacin del proceso de aprendizaje y servicio, como se mencion en la
seccin 2.3.1, se refiere a que los LMEs deben de contener informacin detallada
para habilitar el acceso dinmico y en tiempo de ejecucin a los servicios requeridos,
es decir, los LMEs deben de soportar la interoperabilidad semntica.
Esta caracterstica, desde la perspectiva del motor, se soporta a travs de la sustitucin transparente de servicios web. Durante la ejecucin de un proceso de aprendizaje, si alguno de los servicios asociados no se encuentra disponible, debe ser posible
sustituir el servicio por otro con una funcionalidad semejante. La sustitucin puede
realizarse de manera manual, o bien el motor debe buscar de manera automtica en
el bus de servicios de aprendizaje, uno o varios servicios que realicen una funcin
con un sentido pedgogico similar al del servicio anterior, a travs de la informacin
semntica de la actividad de aprendizaje. Si esto puede realizarse, entonces se ha
separado de manera adecuada el proceso del servicio de aprendizaje. El lenguaje LPCEL, s considera informacin semntica detalla en las actividades de aprendizaje,
para que el motor de ejecucin pueda hacer dicha sustitucin [Torres et al., 2005b].
En la siguiente seccin, se abordar la caracterstica de disponibilidad y contenido
del servicio de aprendizaje.
2.9.
Disponibilidad y Contenido del Servicio de Aprendizaje
Anteriormente se habl de las caractersticas de descentralizacin, disponiblidad

y contenido de servicios de aprendizaje, que en parte son soportadas por el motor
siguiendo un paradigma SOA. En esta seccin, se abordar una caracterstica ligada
67
a las dos que se acaban de mencionar: disponibilidad y contenido del servicio de

aprendizaje.
Como se mencion en la seccin 2.3.1, la caracteristica de disponibilidad y contenido del servicio de aprendizaje, tiene que ver con la capacidad del motor de integrar nuevos servicios de manera distribuida y que no necesariamente estn contenidos
dentro del paquete de la UA. Esto es, aunque una especificacin de un proceso de
aprendizaje contenga todos los recursos dentro de un paquete y garantice su disponibilidad, es necesario que una UA contenga descripciones adecuadas de los recursos y
servicios necesarios para seguir manteniendo la disponibilidad del proceso de aprendizaje an con servicios distribuidos, haciendo as, que la UA no sea dependiente de
autocontenidos. Esto con el objetivo de que el proceso de aprendizaje no pierda la
oportunidad de evolucionar, sustituir e integrar otros recursos y servicios.
LPCEL permite describir recursos y servicios de aprendizaje, tanto locales como
externos, para que puedan ser sustituidos por otros, que quizs sean menos poderos
o apropiados, pero estarn disponibles. En cuanto al motor de ejecucin, ste debe
tener la capacidad de ejecutar recursos y servicios de manera local, y tambin debe
ser capaz de integrar servicios externos en tiempo de ejecucin [Torres et al., 2005b].
Pero qu pasa con el motor al momento de no encontrar un servicio? O al
momento de que el alumno demuestra no haber adquirido el aprendizaje diseado? La
siguiente seccin abordar dichas interrogantes por medio del soporte transaccional.
2.10.
Soporte Transaccional
Hasta este punto, se han descrito casi todas las caractersticas del motor de
ejecucin, haciendo falta nicamente la caracterstica de soporte transaccional. El
soporte transaccional, tiene que ver con asegurar la correcta ejecucin del proceso
de aprendizaje, tanto desde un punto de vista tcnolgico, como desde un punto de
vista pedaggico.
Una transaccin [Gray, 1981] es una unidad computacional consistente y confiable, la cual se ejecuta a partir de un estado inicial consistente y finaliza su ejecucin
en un estado final consistente. Es decir, una transaccin es una coleccin de acciones
que llevan a cabo una transformacin consistente de los estados de un sistema. Para
68
2.10. Soporte Transaccional
lograr esto, las transacciones deben de poseer las llamadas propiedades ACID (por
sus siglas en ingls) [Gray and Reuter, 1993], que se presentan a continuacin:
Atomicidad: Una transaccin se ejecuta completamente (en ingls commits) o el
efecto final es como si no se hubiera ejecutado (aborta). Es decir una transaccin
se comete o se aborta, pero no puede haber un estado intermedio entre estos
dos.
Consistencia: El cdigo de una transaccin debe garantizar que si se aplica a un
estado consistente de datos, el resultado ser tambin un estado consistente de
datos.
Aislamiento: La ejecucin concurrente de transacciones que acceden datos en
comn, debe equivaler a la ejecucin en serie de las mismas transacciones.
Durabilidad: Los efectos de la transaccin cometida deben ser preservados an en
el caso de fallas.
Como se mencion en la seccin 2.4.1, para que el motor garantice la ejecucin
correcta y fiable de un flujo de aprendizaje, es necesario que el motor provea soporte transaccional a travs de un Modelo de Transacciones Avanzado (MTA). Los
MTAs [Elmagarmid, 1992] relajan una o ms de las propiedades ACID para soportar
actividades de larga duracin (como lo es el proceso de aprendizaje de una UA) de
manera correcta y fiable. En el siguiente apartado, se presentan algunos de los MTAs
existentes.
2.10.1.
Modelos de Transacciones Avanzados
Actualmente existen diversos MTAs que pueden ser apropiados para un motor de
ejecucin de PACs. Cada MTA tiene un propsito especfico y relaja una o ms de
las propiedades ACID para lograr su propsito. A continuacin se presentan algunos
de los MTAs:
Transacciones anidadas: Este modelo fue propuesto por [Moss, 1981]. La idea
bsica detrs de este modelo es que nuevas transacciones (subtransacciones)
pueden ser creadas dentro de otra transaccin, produciendo una estructura de
69
rbol de transacciones. A la raz del rbol se le llama transaccin de alto nivel

y preserva todas las propiedades ACID. Las subtransacciones son atmicas y
aisladas con respecto a otras subtransacciones en el rbol que no son ancestras
ni descendientes. Si una subtransaccin aborta, su transaccin padre es notificada y puede escoger abortar o realizar una accin de contingencia. Cuando
una subtransaccin comete, el estado no es final, y depende de que todos sus
ancestros cometan. Si una transaccin aborta, todos sus descendientes abortan incluso si ya han cometido. Las transacciones anidadas soportan mayor
paralelismo y tolerancia a fallos. Las subtransacciones pueden ser ejecutadas
en paralelo, lo cual incrementa la concurrencia dentro de una transaccin.
SAGAS: Propuesto por [Garca-Molina and Salem, 1987], SAGAS fue diseado
para lidiar con transacciones de larga duracin, mediante la relajacin de la
propiedad de aislamiento. Una saga es una secuencia de subtransacciones. Cada subtransaccin tiene asociada una transaccin de compensacin, la cual
deshace los efectos de su subtransaccin. Los efectos de una subtransaccin se
hacen visibles despus de haber sido cometida. La saga puede completarse satisfactoriamente, o en caso de aborto cada subtransaccin cometida se deshace
aplicando la transaccin de compensacin correspondiente en orden reverso.
Una saga se comete si todas sus subtransacciones tambin se cometen.
Transacciones anidadas abiertas: Este
modelo
propuesto
en
[Weikum and Schek, 1992], relaja la propiedad de aislamiento del modelo de transacciones anidadas para mejorar el desempeo. Las transacciones
anidadas abiertas externalizan sus resultados tan pronto como se realizan.
Las subtransacciones anidadas abiertas son persistentes. Si una transaccin
aborta, sus subtransacciones anidadas abiertas no son automticamente
compensadas. La nica forma de deshacer una transaccin anidada abierta es
que el programador explcitamente invoque una transaccin de compensacin.
La propiedad de persistencia de una subtransaccin anidada abierta, hace este
modelo adecuado para actividades de larga duracin.
Transacciones flexibles: En este modelo se relajan las propiedades de atomicidad
y aislamiento a travs de compensacin. La estructura de las transacciones es
una transaccin anidada de dos niveles. El nivel ms alto, llamado transaccin global, puede ser ejecutado en diferentes sitios. Las subtransacciones son
70
2.10. Soporte Transaccional
ejecutadas en un slo sitio. Este modelo permite que el usuario especifique

un conjunto de subtransacciones equivalentes (alternativas), las cuales brindan flexibilidad para alcanzar un objetivo en particular. Cuando se completa
una subtransaccin alternativa se logra una tarea deseada. Una funcin de
preferencia o especificacin de dependencias, puede ser asociada a las subtransacciones alternativas para especificar un orden particular de ejecucin. Se
identifican tres tipos de subtransacciones en el modelo: (1) Compensables: Se
pueden deshacer despus de haber sido cometidas a travs de una transaccin
de compensacin; (2) Rejuzgables: Se garantiza su cometido despus de un
nmero finito de intentos y; (3) Pivote: No pueden ser conpensadas o rejuzgadas [Elmagarmid et al., 1990, Mehrotra et al., 1992, Zhang et al., 1994].
Contratos: En
ingls
ConTracts
[Reuter and Schneider, 1992,
Reuter and Schneider, 1997], fue propuesto para controlar cmputos de

larga duracin en aplicaciones no estndares como flujos de trabajo y diseo
asistido por computadora. Este modelo relaja la propiedad de aislamiento para
externalizar resultados parciales antes de que el contrato finalice. Un contrato
es una ejecucin tolerante a fallos de una secuancia de acciones o pasos que
siguen una descripcin de un flujo (script). Cada paso es una transaccin con
las propiedades ACID. Por cada paso existe un paso de compensacin que se
usa para deshacer los efectos de un paso en caso de que el contrato se cancele.
Transacciones-S: Este modelo se propuso para soportar la cooperacin entre organizaciones, y puede ser aplicado en cualquier ambiente donde la autonoma
de las organizaciones debe ser preservada [Eliassen and Veijalainen, 1988]. El
modelo se basa en la generacin dinmica de transacciones anidadas. Las
transaciones-s no preservan la propiedad de aislamiento. Una subtransaccin-s
se comete y externaliza sus resultados tan pronto como termina. Una transaccin decide sus resultados con base en los resultados de sus subtransacciones. Si
la transaccin falla, la falla se propaga en todas sus subtransacciones cometidas
a travs de transacciones de compensacin.
El modelo de transacciones DOM: Soporta actividades de larga duracin y la
ejecucin de actividades desencadenadas por el sistema. La propiedad de aislamiento no se preserva. El modelo se basa en el modelo de transacciones
anidadas. Las transacciones pueden ser definidas por el usuario o ser el resulta-
71
do de un desencadenamiento de acciones por el sistema. Los desencadenamientos se llevan a cabo al final de la transaccin padre, pero antes de que cometa,
o bien puede ser una transaccin paralelizable con dependencias en relacin a
la transaccin padre. Las transacciones paralelizables slo pueden ver el ltimo estado cometido, es decir, no pueden ver las modificaciones siguientes. El
modelo tambin considera transacciones de compensacin y transacciones de
contingencia (transacciones alternativas) [Buchmann et al., 1992].
Transacciones multi-colores: El objetivo de este modelo es incrementar. la concurrencia de transacciones anidadas para permitir que los resultados parciales de las subtransacciones sean permanentes en el caso de fallas. Las
subtransacciones de una accin de serializacin no preservan la propiedad
de atomicidad. Si una subtransaccin comete y su transaccin padre aborta ms tarde, los efectos de la subtransaccin no se deshacen. Los colores en
una transaccin definen los tipos de candados que se asignan estticamente
a las transacciones y las transacciones se serializan de acuerdo a los colores
[Shrivastava and Wheater, 1990].
Una vez descritos los MTAs, en la tabla 2.5 [Torres et al., 2009a] se presenta una
comparacin de ellos, la cual muestra su propsito, la propiedad ACID que relajan,
y una breve descripcin.
Cuando a un WFMS se le implementa un MTA, se le conoce como flujo de
trabajo transaccional. En dicho dicho sistema, las actividades de proceso se mapean
a componentes de transacciones de una transaccin avanzada, y las dependencias de
flujo de control se definen como dependencias entre los pasos transaccionales. Una
capa adicional de control en trminos de dependencias se le agregar al MTA para
proveer de funcionalidad a las transacciones en ejecucin en un ambiente distribuido.
Cabe destacar que las caractersticas transaccionales de un MTA forman slo una
pequea parte de una aplicacin de flujos de trabajo. Los requerimientos de un
WFMS exceden o difieren significativamente de los requerimientos de un MTA en
trminos de modelado, coordinacin y tiempo de ejecucin. Por lo tanto, es muy til
incorporar semntica de transacciones como recuperacin, atomicidad e isolacin
relajada, para asegurar la correcta ejecucin de un flujo de trabajo. No obstante, ver
un WFMS como un MTA, o usar un MTA para modelar un flujo de trabajo sera
inapropiado [Worah and Sheth, 1997].
72
2.11. Otros Aspectos a Considerar en el Diseo de Motores de Ejecucin
Tabla 2.5: Comparacin de los Modelos de Transacciones Avanzados

Con esto se concluye la revisin del soporte de las caractersticas de los LMEs
que debe soportar un motor de ejecucin. Para cerrar con los temas del captulo,
a continuacin se exponen otros temas importantes a considerar en el diseo de un
motor de ejecucin de PACs, como lo es el control de acceso, y la instanciacin de
actividades.
2.11.
Otros Aspectos a Considerar en el Diseo de Motores de Ejecucin
En la seccin anterior, se abordaron las caractersticas de los LMEs que un motor de ejecucin de escenarios de aprendizaje debe soportar. Sin embargo, existen
otros dos requerimientos que es necesario considerar en el diseo del programa que
73
va a ejecutar un escenario descrito a travs de un LME: el control de acceso y la

instanciacin de actividades.
El control de acceso o autorizacin, tiene que ver con la manera en que los usuarios
tienen acceso a recursos en un sistema computacional [Ferraiolo et al., 2007b]. En lo
que concierne al tema de la presente tesis, se revisar el modelo de Control de Acceso
Basado en Roles (RBAC, por sus siglas en ingls), por la aceptacin y xito que ha
tenido en sistemas empresariales y WFMS.
Por otra parte, la instanciacin de actividades tiene que ver con la manera en
que las actividades pueden reutilizarse y repetirse en distintos puntos de un proceso.
A continuacin se presentan cada uno de estos aspectos a detalle.
2.11.1.
Control de acceso
Dadas las caractersticas multiusuario en escenarios de aprendizaje complejos (ver

seccin 2.2), y la caracterstica de descentralizacin de los servicios de aprendizaje
de los EMLs de cuarta generacin (ver seccin 2.7), se hace presente la necesidad
de controlar el acceso a los recursos de aprendizaje en un motor de ejecucin de
PACs. Para ello, se toma como referencia y punto de partida, el modelo de Control
de Acceso Basado en Roles (RBAC).
RBAC surgi de la motivacin de crear un nuevo modelo de control de acceso para
satisfacer de mejor manera que en modelos previos, las necesidades de autorizacin de
usuarios comerciales y a un menor costo, sobretodo en redes de gran tamao con un
alto grado de complejidad en la administracin de seguridad [Ferraiolo et al., 2007b].
Algunos de los modelos previos a RBAC que adems sirvieron como base para su desarrollo son los presentados en [Lampson, 1969], donde se introduce de manera formal
la nocin de sesin y objeto; en [Bell and LaPadula, 1973] se formalizan en un modelo
matemtico las reglas militares de control de acceso con mltiples niveles de seguridad; en [Dobson and McDermid, 1989] se introduce el trmino de roles funcionales;
en [Baldwin, 1990] se establecen jerarquas de dominios de proteccin y se organizan en subconjuntos de permisos de dominios de proteccin; en [Thomsen, 1991] se
reconoce el uso de roles para soportar el principio de mnimo privilegio restricto, en
donde un rol slo debe contar con los permisos mnimos para poder llevar a cabo su
74
tarea; y en [Brewer and Nash, 1989] se presenta una teora bsica para implementar
de manera dinmica cambios en los permisos de acceso.
Desde una perspectiva de negocios, RBAC tiene el potencial del ofrecer mayor
productividad administrativa en funciones de gestin de la autorizacin. Estas funciones incluyen asignar permisos de acceso a recursos para nuevos usuarios y nuevos
recursos, revisar y negar accesos que ya no son necesarios con respecto al cambio
del puesto de trabajo de un usuario o cuando un usuario deja la organizacin, entre
otras [Ferraiolo et al., 2007b].
Desde la perspectiva de los WFMS, por las caracterstiacs de estos sistemas de
soportar la definicin de procesos de negocio y el cumplimiento del control sobre
esos procesos (ver seccin 2.4.1), el modelo RBAC ha tenido una buena aceptacin
por su capacidad para soportar polticas de seguridad empresariales y la facilidad
para gestionar accesos. Se ha encontrado que especificar los requeriemientos de control de acceso en flujos de trabajo en trminos de roles, es preferible a especificarlos en trminos de individuos [Ferraiolo et al., 2007a]. Adems, la autorizacin
basada en roles es particularmente benfica en los WFMS para facilitar el balanceo dinmico de cargas cuando varios individuos pueden desempear una tarea
[Georgakopoulos et al., 1995].
Desde una perspectiva de seguridad, el modelo RBAC considera dos principios
bsicos:
Mnimo Privilegio Estricto. Se refiere a que a un usuario no se le d ms privilegio que el necesario para llevar a cabo su trabajo [Ferraiolo et al., 2007c].
Para lograr esto se requiere identificar el trabajo que un usuario puede realizar
en un momento dado, as como los privilegios que debe tener para realizarlo y
finalmente asignarle al usuario esos permisos. El modelo RBAC lo permite al
asignar permisos a roles individualmente, pudiendo componer roles restrictos
a estos permisos.
Separacin de Tarea. SoD, de sus siglas en ingls, este principio requiere que para
un conjunto particular de transacciones, un individuo por s slo no pueda ejecutar todo el conjunto de transacciones [Ferraiolo et al., 2007c]. Este principio
tiene como objetivo evitar fraudes. Una forma sencilla de entenderlo es pensando en un cheque que requiere la firma de dos individuos, de tal forma que no
75
es posible que un slo individuo realice una tarea crtica para la organizacin.
SoD puede adems ser esttica o dinmica, la primera se cumple al hacer una
asignacin de usuarios a roles y de permisos a roles. La segunda se realiza en
tiempo de ejecucin de forma que es ms flexible que la metodologa esttica.
El modelo RBAC descrito en [Ferraiolo et al., 2007c] fue formalizado en 1992 por
David Ferraiolo y Rick Kuhn, y posteriormente fue adoptado como estndar por el
American National Standards Institute en 2004 [ANSI, 2004]. RBAC est organizado
en cuatro niveles de capacidades funcionales incrementales llamadas Core RBAC,
Hierarchical RBAC, Static Constrained RBAC y Dynamic Constrained RBAC. A
continuacin, se presentan los modelos Core RBAC y Hierarchical RBAC por ser
los modelos de principal inters en el diseo del motor de PACs.
Los principales elementos del modelo Core RBAC son seis: Usuarios, Roles, Operaciones, Objetos, Permisos y Sesiones. En trminos generales el modelo RBAC establece que a usuarios individuales se le pueden asignar roles, a los cuales a su vez
se les asignan permisos, que sirven para activar tareas. A travs de este mecanismo
es como los usuarios adquieren el privilegio de ejecutar tareas. Las Sesiones mapean
un subconjunto de roles activados en un momento dado para un usuario. La figura
2.12, muestra de manera grfica las relaciones entre estos componentes.
Figura 2.12: El modelo Core RBAC.

La especificacin RBAC plano se define formalmente de la siguiente manera:
76
U SU ARIOS, ROLES, OP S y OBS (usuarios, roles, operaciones, y objetos,

respectivamente.
U A U SU ARIOS ROLES, mapeo muchos a muchos entre usuarios y roles
(relacin de asignacin usuario a rol).
usuarios_asignados : (r : ROLES) 2U SU ARIOS , el mapeo de un rol r

en un conjunto de usuarios. Formalmente: usuarios_asignados(r) = {u
U SU ARIOS | (u, r)
U A}.
P RM S = 2(OP SOBS) , el conjunto de permisos.

P A P RM S ROLES, mapeo muchos a muchos entre permisos y roles
(relacin de asignacin de roles a permisos).
permisos_asignados(r : ROLES) 2P RM S , el mapeo de un rol r en un

conjunto de permisos. Formalmente: permisos_asignados(r) = {p
(p, r)
P A}.
P RM S |
SESION ES, el conjunto de sesiones.

sesion_usuario(s : SESION ES) U SU ARIOS, el mapeo de una sesin s
en el usuario asociado a la sesin.
sesion_roles(s : SESION ES) 2ROLES , el mapeo de una sesin s en

un conjunto de roles. Formalmente: sesion_roles(si ) {r
(sesion_usuario(si ), r)
U A}
ROLES |
El modelo Core RBAC se extiende para considerar jerarquas de roles en el

modelo Hierarchical RBAC, como se muestra en la figura 2.13, donde un rol puede
heredar los permisos de su rol padre. Las jerarquas de roles son una manera de
estructurar los roles para reflejar las lneas de autoridad y responsabilidad en una
organizacin.
La herencia de privilegios ocurre en los roles de forma que un rol r1 puede heredar
el rol r2 si los permisos en r2 tambin son permisos de r1. Adicionalmente, r1 puede
definir nuevos permisos no definidos en r2. Un rbol de jerarqua de roles puede
apreciarse en la figura 2.14. Las jerarquas de roles pueden ocurrir en dos formas:
Jerarqua General de Roles o Jerarqua de Roles Limitada. La primera permite niveles
77
Figura 2.13: El modelo Hierarchical RBAC

de jerarqua mltiples, mientras que la segunda impone restricciones en el nmero
de roles descendientes.
Figura 2.14: Jerarqua General de Roles

Con lo anterior termina la presentacin del modelo RBAC. En el ambiente educativo se han propuesto arquitecturas que incorporan el modelo RBAC como la presentada en [Neely et al., 2004]. Sin embargo estas arquitecturas se enfocan ms en la
cooperacin interinstitucional, dejando de lado el hecho de que dentro de un ambiente de aprendizaje colaborativo existen diversos roles dentro de un grupo de trabajo,
para los cuales cada alumno que desempea un rol tiene sus propios objetivos de
78
aprendizaje, que en conjunto contribuyen a lograr los objetivos de aprendizaje grupales. De ah la importancia de estudiar e incorporar el modelo RBAC en los sistemas
de e-learning. Como parte de un proyecto de la Ctedra de Investigacin Sistemas
Distribuidos y Adaptativos en Tecnologa Educativa, del Tecnolgico de Monterrey,
en [Torres et al., 2010b] se presenta una extensin al modelo RBAC para controlar
el acceso a recursos educativos en un ambiente orientado a servicios.
A continuacin se presenta el tema de instanciacin de actividades, el cual tiene
que ver con la manera en que las actividades pueden reutilizarse y repetirse en
distintos puntos de un proceso.
2.11.2.
Instanciacin
Como se mencion anteriormente en la seccin 2.4.1, para que un motor pueda interpretar en repetidas ocasiones un proceso definido, i.e. que el proceso sea
reutilizable, y que sus actividades puedan utilizarse en distintos puntos del proceso y puedan repetirse, adems de poder implementarse en un ambiente de mltiples
usuarios, es necesaria la instanciacin del proceso y de sus actividades. Para ello, es
necesario hablar sobre los estados de un proceso, que al igual que en los sistemas
operativos [Stallings, 2004], es necesario un modelo de estados de proceso para poder
caracterizar la conducta de un proceso y que los flujos de trabajo puedan instanciarse
y ejecutarse correctamente.
En [Hollingsworth, 1995] se considera al motor de ejecucin como una mquina
de transicin de estados [Sipser, 1997], donde los procesos individuales o las instancias de las actividades cambian de estado en respuesta a eventos externos (e.g. una
actividad se completa), o a decisiones de control especficas tomadas por el motor
(e.g. la navegacin a la siguiente actividad dentro de un proceso). En una instancia
de proceso se consideran seis estados bsicos que se pueden observar junto con sus
transiciones en la figura 2.15.
A continuacin, se presentan cado uno de estos seis estados bsicos:
Iniciado: En ingls initiated, es cuando la instancia del proceso ha sido creada
incluyendo datos relevantes sobre el estado del proceso y el flujo de control,
pero an no se cumplen las condiciones para que inicie su ejecucin.
79
Figura 2.15: Transiciones entre estados para una instancia de proceso

Ejecutndose: En ingls running, ocurre cuando la instancia de proceso inici su
ejecucin y cualquiera de sus actividades ha comenzado.
Activo: En ingls active, es cuando una o ms de las actividades del proceso han iniciado, por ejemplo cuando un tem de trabajo ha sido asignado a una instancia
de actividad.
Suspendido: En ingls suspended, ocurre cuando la instancia del proceso est inactiva y no se pueden comenzar actividades hasta que el proceso haya regresado
al estado ejecutndose, a travs del comando resumir.
Completado: En ingls completed, es cuando la instancia de proceso ha cumplido
con las condiciones de completitud.
Terminado: En ingls terminated, es cuando la instancia de proceso ha sido detenida antes de que sea completada de manera normal.
Con la presentacin de estos estados y sus transiciones, se hace posible la instanciacin del proceso. Sin embargo para que la ejecucin de la instancia sea correcta, es
necesario tambin instanciar las actividades que se ejecutan en los distintos puntos
del proceso.
Para la instanciacin de actividades en WFMS, existen un par de situaciones
que es necesario considerar. Las actividades pueden ser no-interrumpibles, esto es,
una vez que un servicio del flujo de trabajo ha iniciado una actividad en particular
dentro de una instancia de proceso, no debe ser posible suspender o terminar esa
actividad. Esto significa que las funciones de suspensin y reinicio no pueden ser
80
completadas hasta que todas las actividades activas hayan sido completadas y la
instancia de proceso haya regresado al estado ejecutndose. La otra situacin es
cuando es necesario marcar un conjunto de actividades como una unidad atmica,
las cuales son ejecutadas completamente, o la instancia de proceso debe regresar a
un punto de reinicio. En la figura 2.16 se pueden observar los cuatro estados bsicos
de una instancia de actividad y las transiciones entre ellos.
Figura 2.16: Transiciones entre estados para una instancia de actividad

A continuacin, se describen los estados bsicos de las instancias de actividad:
Inactiva: En ingls inactive, es cuando la actividad dentro de una instancia de
proceso ha sido creada pero no ha sido activada porque las condiciones de
inicio no se cumplen, ni tiene tems de trabajo por procesarse.
Activa: En ingls active, es cuando un tem de trabajo ha sido creado y asignado a
la instancia de actividad para su procesamiento.
Suspendida: En ingls suspended, es cuando la instancia de la actividad se encuentra inactiva y no se le asignar un tem de trabajo hasta que la actividad regrese
al estado de ejecucin inactiva.
Completada: En ingls completed, es cuando la ejecucin de la instancia de actividad se ha completado.
La instanciacin en el caso de del motor de ejecucin CopperCore de IMS LD
(ver seccin 2.4.2), a nivel de proceso para cada ejecucin de un curso, se le asigna
exactamente una UA, pero una UA puede tener cero o ms ejecuciones asignadas a
ella. Los estados de una ejecucin pueden ser los siguientes [Tattersall et al., 2005b]:
81
Esperando: Cuando una ejecucin es creada se le asigna este estado, lo cual significa
que los usuarios an no han sido asignados a la ejecucin antes de que la entrega
del curso comience.
Activa: Este estado se asigna cuando la ejecucin de un curso inicia su entrega, es
decir, cuando la ejecucin comienza.
Parada: Es el estado en el que entra una ejecucin cuando todos los usuarios han
terminado. Durante este estado, los usuarios pueden an tener acceso al diseo del apredizaje y los contenidos correspondientes en la UA, pero ya no se
permiten ms interacciones.
Archivada: En este estado, la UA ya no se encuentra disponible para los estudiantes
y el equipo docente, sin embargo toda la informacin se guarda en un archivo
para futuras referencias.
En cuanto a la forma de instanciar actividades en el motor de IMS LD y otros
sistemas de e-learning, se ha publicado poco. Esto debido a que los sistemas de elearning actuales, por un lado han buscado la reutilizacin de un curso completo y
la reutilizacin de recursos, pero en s no han fijado su atencin en la reutilizacin de
actividades; por otro lado tambin tiene que ver el escaso manejo de roles lo cual le
resta complejidad a la instanciacin, adems de la forma en que los sistemas despliegan los contenidos de los cursos basada en contenidos en lugar de estar orientados
en el despliegue de actividades.
Con los temas del control de acceso y la instanciacin de procesos y actividades,
se cierran los temas del estado del arte. A continuacin se presenta un resmen de
esta revisin bibliogrfica.
2.12.
Resmen del captulo
En este captulo se present una revisin bibliogrfica sobre los sistemas de elearning, desde las herramientas que existen para el diseo de escenarios de aprendizaje, hasta las herramientas que existen para la ejecucin de los escenarios de
aprendizaje, mismas que han evolucionado a travs de tres etapas y lo que se con-
82
2.12. Resmen del captulo
sidera la nueva generacin de sistemas de aprendizaje electrnico, los cuales buscan

ser capaces de ejecutar procesos de aprendizaje complejos en ambientes distribuidos.
Desde la perspectiva del diseo de los escenarios de aprendizaje, existen en la
actualidad tres propuestas de amplio espectro, las cuales son IMS LD, LAMS y
LPCEL, siendo LPCEL la ms rica en cuanto a sus caractersticas para soportar
procesos de aprendizaje complejos.
Desde la perspectiva de la ejecucin de los escenarios de aprendizaje, en el captulo
se estudiaron los motores de ejecucin de flujos de trabajo, el motor de ejecucin
CopperCore de IMS LD, y el ambiente de ejecucin de SCORM. Posteriormente, se
abordaron ampliamente cada una de las caractersticas deseadas en los LME para
ejecutar procesos de aprendizaje complejos.
Por ltimo se ahond en los temas de control de acceso e instanciacin de procesos
y actividades, temas de gran inters en cuanto a su relevancia en el diseo de motoros
de ejecucin de procesos.
En el siguiente captulo, se presentan a profundidad cada una de las problemticas
que se han identificado en los sistemas de e-learning a travs del tiempo, con respecto
a la ejecucin de PACs.
Captulo 3
Planteamiento del problema

En el captulo anterior se present una revisin bibliogrfica sobre el estado actual
de los sistemas de e-learning, comenzando por su evolucin, despus se presentaron
los LMEs, y posteriormente una serie de aspectos relacionados con las caractersticas de ejecucin de dichos sistemas. A lo largo de cada una de las secciones, se
mostraron tambin diversas cuestiones que deben ser consideradas al momento de la
implementacin.
En este captulo se presentan de manera detallada, el surgimiento de cada una
de las problemticas identificadas y seleccionadas, para posteriormente plantear los
objetivos de investigacin, y en el siguiente captulo proponer una solucin a los
problemas que logre los objetivos.
Lo anterior se realizar a travs de la descripcin de un breve escenario de aprendizaje, y un ejemplo de su ejecucin en las diversas etapas de la evolucin de los
sistemas de e-learning.
A continuacin, se presenta un escenario de aprendizaje modelado con la notacin
estndar BPMN (Business Process Modeling Notation) [OMG, 2009]. BPMN es una
notacin grfica diseada para modelar procesos de negocio con el objetivo de que
dichos procesos puedan ser entendidos tanto por la gente de negocios, como por los
desarrolladores tcnicos, y a la vez permita cerrar la brecha entre el diseo y la
implementacin de un proceso.
83
84
3.1. Un escenario de aprendizaje
La eleccin de esta notacin para modelar escenarios de aprendizaje se debe por

un lado, a que en el terreno de la educacin no existe una notacin grfica estndar
para modelar escenarios de aprendizaje, y por otro, a que si se ve el aprendizaje como
un proceso, esta notacin es una herramienta ideal para representarlo y visualizarlo
de manera sencilla y estndar.
3.1.
Un escenario de aprendizaje
El siguiente escenario de aprendizaje es un estracto adaptado tomado del curso

de la Universidad Virtual del Tecnolgico de Monterrey, Liderazgo para el Desarrollo
Sostenible en su versin enero-mayo 2010. El escenario de aprendizaje se muestra de
manera grfica en la figura 3.1.
Figura 3.1: Un escenario de aprendizaje
85
El escenario de aprendizaje se compone por 4 actividades:

1. Leer artculo sobre el estado del planeta: El alumno debe leer el captulo
1 de State of the world 2001 [Flavin, 2001]. Esta actividad emplea un objeto
externo, que es el propio captulo que el alumno debe leer.
2. Leer artculo sobre indicadores ambientales: El alumno debe leer la seccin
Summary for decision makers en [Sarukhn and Whyte, 2005]. Esta actividad
emplea un objeto externo, que es la seccin del libro que el alumno debe leer.
3. Participar en el juego Ecocity: El
juego
Ecocity,
disponible
alumno
en
Internet
debe
en
http://www7.dw-world.de/ecocity/ecocity.html.
jugar
el
la
direccin
Esta
actividad
emplea una aplicacin externa, el juego Ecocity.

4. Examen mdulo 1: El alumno debe realizar el examen correspondiente al mdulo uno del curso. El examen es un recurso interno.
En este escenario, el proceso de aprendizaje de un alumno comienza con lo que en
BPMN se le conoce como una decisin compleja. El alumno puede decidir si realiza
la actividad 1, la actividad 2, o ambas. Posteriormente el alumno debe llevar a cabo
la actividad 3. Una vez concluida la actividad 3, el alumno proceder con el examen
del mdulo para terminar con su proceso de aprendizaje.
Ahora, para poder entender la complejidad de un sistema de e-learning de cuarta
generacin, es necesario conocer la forma en que el escenario de aprendizaje anterior
se disea y ejecuta a travs de cada una de las etapas de la evolucin de los sistemas de
e-learning. A continuacin se presentar dicha forma, y en cada etapa se identificarn
diversas problemticas relacionadas con la ejecucin del escenario de aprendizaje.
3.2.
Primera etapa
Como se mencion en la seccin 2.1, la primera etapa de la evolucin de los

sistemas de e-learning se enfoca en la estandarizacin de objetos de aprendizaje, los
cuales son contenidos de instruccin simples. Por lo tanto el escenario de aprendizaje
presentado anteriormente, en un sistema de e-learning de primera etapa, quedara
86
3.3. Segunda etapa
modelado en trminos de sus objetos de aprendizaje como se muestra en la figura

3.2.
Figura 3.2: Un escenario de aprendizaje diseado en la primera etapa de la evolucin

En un sistema tpico de la primera etapa, una pgina web simple con contenido
esttico, presentara ligas hacia cada uno de los objetos de aprendizaje. Este tipo
de pginas, representaron el origen de los sistemas de e-learning, donde a travs de
su evolucin, se fueron identificando las problemticas que conciernen la presente
tesis. Durante esta etapa no se identifican problemas de ejecucin de los sistemas de
e-learning, ya que no existe como tal un proceso de aprendizaje en ejecucin en el
contexto de un sistema.
A continuacin, se presenta el mismo escenario de aprendizaje en la segunda
etapa de la evolucin.
3.3.
Segunda etapa
La segunda etapa de la evolucin de los sistemas de e-learning, como se mencion en la seccin 2.1, se caracteriz por su enfoque en la administracin, ubicacin
y recuperacin de contenidos, los cuales gracias a los avances en esta etapa, podan
desplegarse y personalizarse de acuerdo al estudiante. En esta etapa surgieron los
primeros Sistemas de Gestin de Aprendizaje (LMS, por sus siglas en ingls), los
cuales permitieron los primeros diseos de procesos de aprendizaje en ambientes
87
electrnicos. No obstante, estos procesos de aprendizaje tenan nicamente expresividad para modelar estructuras bsicas con un estilo jerrquico secuencial.
Para mostrar el escenario de aprendizaje modelado en la segunda etapa, se tomar
como LMS de ejemplo Blackboard 1 . En un sistema de este tipo, la herramienta para
el diseo del proceso de aprendizaje es un editor en lnea del propio sistema al cual
se accede a travs de un panel de control. El editor para el proceso de aprendizaje
permite agregar recursos de manera local, los cuales pueden ser editados en HTML
[W3C, 1999]. Adems, el editor de procesos de aprendizaje permite establecer ciertos
controles de acceso para el momento de acceder los recursos.
El sistema Blackboard, adems cuenta con una serie de herramientas propias
con diversos propsitos instruccionales e.g. exmenes, foro de discusin, anuncios,
calificaciones, entre otros los cuales permiten enriquecer el entorno de aprendizaje.
El proceso de aprendizaje al ejecutarse en Blackboard, puede visualizarse de manera
parecida a como se muestra en la figura 3.3.
Figura 3.3: Un escenario de aprendizaje en un sistema de la segunda etapa

Al ejecutar el escenario de aprendizaje en el LMS de segunda etapa, surgen una
serie aspectos que es necesario considerar.
1
http://www.blackboard.com/
88
3.3. Segunda etapa
El primero de estos aspectos ocurre cuando el diseador instruccional o profesor,

desea hacer uso de algn recurso externo como por ejemplo artculos acadmicos que
se encuentran en algn sitio web o el juego Ecocity. En el caso de los artculos, stos
tendran que ser subidos dentro de los recursos del LMS, lo que pudiera incurrir
en problemas de derechos de autor, o bien podran accederse mediante un enlace al
recurso externo. Sin embargo, bajo el segundo esquema el profesor no tendra manera
de registrar el uso del recurso, que con los artculos el problema no es tan grande, sin
embargo para otro tipo de actividades como el juego Ecocity el problema si puede
ser mayor. En el caso de este curso, el profesor decidi crear una actividad ms,
para que el alumno pudiera registrar su progreso en el juego Ecocity, ms esto no
garantiza que el alumno realmenta progres conforme a lo que report. Debido a
las situaciones anteriores, aqu se identifica el problema de la dificultad para integrar
diversos recursos y servicios para el aprendizaje.
Por otra parte, se identifica otro aspecto al momento de que un curso se encuentra en ejecucin, y el administrador del sistema o el profesor requieren de una
actualizacin del LMS o de alguno de sus mdulos. Cuando ocurre esto, es necesario
interrumpir el servicio del LMS para poder llevar a cabo la actualizacin, la cual
implica un proceso con riesgos y propenso a fallos, el cual puede generar inconsistencias en la informacin. Por ello, aqu se identifica el problema de la sustitucin de
servicios de aprendizaje de manera sencilla.
Por ltimo en esta etapa, se indentifica un problema ms: La falta de soporte
al proceso de aprendizaje. Los LMS actuales se han enfocado en brindar soluciones
tcnicas a problemas pedaggicos, sin embargo, su contribucin no ha sido tan grande
en cuanto al desarrollo de soluciones pedaggicas. Este problema surge de la falta de
medios que tiene un alumno, para lograr el aprendizaje que no pudo adquirir durante
el desarrollo de las actividades programadas por el docente. En otras palabras, si un
alumno reprueba un examen, ya no le es posible lograr los objetivos de aprendizaje
del curso, a menos que lo repita en otra ocasin.
En resumen, con los sistemas de segunda etapa, se identifican cuatro problemticas en la ejecucin de procesos de aprendizaje, an latentes:
1. Dificultad para integrar diversos recursos y servicios para el aprendizaje.
2. Sustitucin de servicios de aprendizaje de manera sencilla.
89
3. Soporte al proceso de aprendizaje

En seguida se presenta el mismo escenario de aprendizaje en la tercera etapa de
la evolucin de los sistemas de e-learning.
3.4.
Tercera etapa
Como se mencion en la seccin 2.1, la tercera etapa de la evolucin de los

sistemas de e-learning se caracteriz por la bsqueda de mayor flexibilidad y reusabilidad, dando lugar al surgimiento de Lenguajes de Modelado Educativo (LME). De
estos lenguajes, destaca IMS Learning Design (IMS LD), el cual se ha consolidado
como el LME estndar.
Las herramientas para trabajar con la especificacin IMS LD (ver seccin 2.3.2),
generalmente hacen uso de una herramienta en tiempo de diseo para modelar el
escenario de aprendizaje, y una herramienta en tiempo de ejecucin para ejecutar
el proceso de aprendizaje. Sin embargo, como se presenta en la seccin 2.5.1, IMS
LD no tiene la expresividad necesaria para disear escenarios de aprendizaje con
estructuras complejas de aprenizaje. Por lo tanto, el diseo y ejecucin del escenario
de aprendizaje en IMS LD ms cercano al escenario de aprendizaje que se ha tomado
como ejemplo, es el que se muestra en la figura 3.4.
Como se puede observar, el escenario de aprendizaje adaptado a un sistema de
tercera etapa, se compone por una secuencia de las siguientes 4 actividades:
1. Revisar artculos y material de apoyo: Esta actividad sustituy la estrucutura de la decisin compleja del escenario anterior y las actividades que la
estructura contena, para agruparlas dentro de una sola y nueva actividad que
hace referencia a los dos recursos de aprendizaje. Esto se debe a que es la nica
manera de que el escenario no perdiera la flexibilidad para darle al alumno el
sentido pedaggico con el que originalmente fue creado el escenario. Sustituir
la decisin compleja con una sola actividad es la nica forma en la que IMS LD
puede permitir cierto paralelismo a la hora de acceder los recursos, sin embargo
la responsabilidad de la decisin compleja queda a cargo del alumno, y no a
cargo del ambiente de ejecucin.
90
3.4. Tercera etapa
Figura 3.4: Un escenario de aprendizaje en un sistema de la tercera etapa

2. Participar en el juego Ecocity: Esta actividad no sufre modificaciones con
respecto al escenario original. Sin embargo, debido a que IMS LD y su motor de ejecucin no tienen forma de integrar el uso del recurso de aprendizaje,
es necesario crear una actividad ms para poder registrar la participacin en
el juego.
3. Registrar participacin de Ecocity: Esta es una nueva actividad creada en
este escenario de aprendizaje para poder registrar la participacin en el juego
Ecocity. El registro puede hacerse a travs de un examen preguntando cuestiones relacionadas con la participacin en el juego.
4. Examen mdulo 1: Esta actividad no sufre modificaciones con respecto al escenario de aprendizaje original.
De la descripcin anterior del escenario de aprendizaje, se puede ver que los
problemas identificados en la segunda etapa siguen latentes en la tercera etapa, y
adems surgen nuevas cuestiones que en seguida se presentan.
En la temtica de las estructuras de aprendizaje, en esta etapa surge el problema
de la dificultad para ejecutar estructuras de aprendizaje complejas, como puede apreciarse claramente al tener que modificar dichas estructuras del escenario de aprendizaje original. En la tercera etapa de la evolucin, la mayora de los sistemas con-
91
sideran el flujo de aprendizaje como una secuencia lineal de actividades, y an los

sistemas ms avanzados, aunque a un nivel bajo, slo permiten la ejecucin de actividades paralelas y la eleccin de actividades opcionales. Sin embargo, estas estructuras
estn lejos de representar la verdadera forma en que un estudiante aprende, la cual
puede incluir la seleccin o asignacin de actividades dentro de un equipo de trabajo
o de acuerdo a los intereses del alumno, la ejecucin cclica de actividades, o la ejecucin de actividades de compensacin, entre otras. Esta cuestin, aunque desde el
punto de vista pedaggico estaba presente desde las etapas anteriores, no se considera un problema de ejecucin hasta esta etapa, debido a que en las etapas anteriores
no se ejecutaban estructuras de aprendizaje, sino nicamente se controlaba el acceso
a recursos.
Por ltimo, de la segunda etapa persisten de manera similar los problemas de la
dificultad para integrar diversos recursos y servicios para el aprendizaje, la sustitucin
de los recursos y servicios de aprendizaje de manera sencilla, y el problema de soporte
al proceso de aprendizaje.
Sumarizando, en la tercera etapa de la evolucin de los sistemas de e-learning, se
identifican cinco problemticas en la ejecucin de procesos de aprendizaje:
1. Dificultad para ejecutar estructuras de aprendizaje complejas.
2. Dificultad para integrar diversos recursos y servicios para el aprendizaje.
3. Sustitucin de servicios de aprendizaje de manera sencilla.
4. Soporte al proceso de aprendizaje.
A continuacin, se presenta el mismo escenario de aprendizaje en la cuarta etapa
de la evolucin de los sistemas de e-learning.
3.5.
Cuarta etapa
En la cuarta etapa de la evolucin se pretende que los sistemas de e-learning

sean capaces de ejecutar procesos de aprendizaje complejos (PAC) (ver seccin 2.2),
con ayuda del paradigma de la arquitectura orientada a servicios (SOA) (ver seccin
2.7.2). Desde esta perspectiva, se pueden encontrar diferentes servicios que apoyen
92
3.6. Problemas para la construccin de motores de ejecucin de procesos de aprendizaje complejos
el proceso de aprendizaje, como los que se presentaron en la seccin 2.7.1. Dicho

proceso de aprendizaje deber ser ejecutado por un motor que integre y orqueste los
diversos servicios.
En la actualidad, el lenguaje LPCEL es el que cuenta con la expresividad suficiente para disear PACs, como se mostr en la seccin 2.5.1. LPCEL adems, tiene
la capacidad para describir la integracin con diversos recursos de aprendizaje, incluyendo servicios web. Por lo tanto, el escenario de aprendizaje que se tom como
ejemplo, puede modelarse tal cual en LPCEL.
El reto, es poder disear y construir un motor capaz de ejecutar escenarios de
aprendizaje de PACs, para lo cual, aparte de darle solucin a los problemas presentados en la tercera etapa de la evolucin, es necesario que tambin resuelva el
problema del complejo manejo de roles y asignacin de tareas. Este problema que
aunque de cierta forma se presenta en las etapas anteriores al momento de trabajar
con roles dentro de un equipo de trabajo, adquiere una complejidad especial en esta
etapa al momento de que la ejecucin del proceso de aprendizaje, se enfrenta con un
ambiente de servicios distribuido.
El problema identificado en etapas anteriores como soporte al proceso de aprendizaje, en esta etapa eleva su complejidad, ya que por las caractersticas propias de
un entorno distribuido, es necesario que el soporte al proceso de aprendizaje tenga
un carcter transaccional para tener la capacidad de ejecutar actividades de larga
duracin de manera confiable (ver seccin 2.10). Por ello, este problema se identifica
ahora como soporte transaccional para el proceso de aprendizaje.
En la siguiente seccin, se presentan cada uno de los problemas identificados a
lo largo de la evolucin de los sistemas de e-learning, y que tienen una relevancia
importante para la construccion de un motor de ejecucin de procesos de aprendizaje
complejos.
3.6.
Problemas para la construccin de motores de ejecucin de procesos de aprendizaje complejos
Como se pudo observar en las secciones anteriores, se han identificado diversos

problemas en cada una de las etapas de la evolucin de los sistemas de e-learning
93
que an persisten, y se pretende sean resueltos y brinden mejores caractersticas en

los sistemas de cuarta etapa.
A continuacin, se enumeran y describen cada uno de los problemas:
(P1) Dificultad para ejecutar estructuras de aprendizaje complejas: La mayora de
los sistemas actuales consideran el flujo de aprendizaje como una secuencia lineal de actividades; los sistemas ms avanzados permiten, aunque a un nivel bajo, la ejecucin de actividades paralelas y la eleccin de actividades opcionales.
Sin embargo, estas estructuras estn an lejos de representar la verdadera forma en que un estudiante aprende, la cual puede incluir la seleccin o asignacin
de actividades dentro de un equipo de trabajo o de acuerdo a los intereses del
alumno, la ejecucin cclica de actividades, o la ejecucin de actividades de
compensacin, entre otras.
(P2) Complejo manejo de roles y asignacin de tareas: En un equipo de trabajo
colaborativo, los alumnos e incluso profesores (si son ms de uno), pueden
desempear diversos roles, lo cual les da acceso a diferentes actividades, e.g.,
nicamente el lder del equipo de trabajo puede realizar la entrega final del
proyecto, el alumno administrador de proyecto es el nico que puede modificar
el plan de trabajo, el profesor asistente evaluar las actividades de la mitad
de los estudiantes, entre otras. Los sistemas actuales carecen de este tipo de
controles.
(P3) Dificultad para integrar diversos recursos y servicios para el aprendizaje en
ambientes distribuidos y heterogneos: Los usuarios de los sistemas actuales no
pueden llevar a cabo actividades bajo otras plataformas o usar herramientas
externas, y que el uso, avance y progreso con estas herramientas y recursos
quede registrado en la plataforma.
(P4) Sustitucin de los recursos y servicios de aprendizaje de manera sencilla: Cuando un recurso, servicio o mdulo del sistema tiene un error o existe uno mejor,
hacer un cambio en el curso puede requerir la actualizacin de la plataforma, lo
cual es un procedimiento complicado y que implica la interrupcin del servicio.
O bien, la sustitucin puede generar inconsistencias de informacin.
(P5) Soporte transaccional para el proceso de aprendizaje: La mayora de los sistemas est diseados para que un alumno acredite o no acredite el curso o las
94
actividades, sin la opcin de que el alumno pueda llevar a cabo actividades

para compensar y adquirir aprendizaje que no logr previamente.
A partir de estos problemas, en este trabajo de investigacin se pretende elaborar
un marco de referencia para la construccin de un motor de ejecucin de PACs, con
la capacidad para integrar servicios web. El marco de referencia pretende lograr los
objetivos que se presentan a continuacin.
3.6.1.
O1. Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a travs de un LME
El primer objetivo que se establece, pretende resolver los problemas P1 Dificultad

para ejecutar estructuras de aprendizaje complejas y P2 Complejo manejo de roles
y asignacin de tareas. El objetivo se define como O1 Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a travs de un LME. De manera grfica,
en la figura 3.5 se muestra su relacin con los problemas P1 y P2.
Figura 3.5: Problemticas abordadas en el objetivo O1
3.6.2.
O2. Integracin de servicios web
El segundo objetivo que se establece, pretende resolver el problema P3 Dificultad

para integrar diversos recursos y servicios para el aprendizaje en ambientes distribuidos y heterogneos. El objetivo se define como O2 Integracin de servicios web. De
manera grfica, en la figura 3.6 se muestra su relacin con el problema P3.
95
3.6.3.
O3. Sustituir y agregar de manera sencilla y transparente un

servicio web
El tercer objetivo que se establece, pretende resolver el problema P4 Sustitucin

de los recursos y servicios de aprendizaje de manera sencilla. El objetivo se define
como O3 Sustituir y agregar de manera sencilla y transparente un servicio web. De
manera grfica, en la figura 3.7 se muestra su relacin con el problema P4.
3.6.4.
O4. Proveer al proceso de aprendizaje de soporte transaccional
El cuarto y ltimo objetivo que se establece, pretende resolver el problema P5

Soporte transaccional para el proceso de aprendizaje. El objetivo se define como O4
Proveer al proceso de aprendizaje de soporte transaccional. De manera grfica, en la
figura 3.8 se muestra su relacin con el problema P5.
96

En el siguiente captulo, se presentan las contribuciones que pretenden dar una
solucin a cada uno de los problemas identificados para lograr los objetivos establecidos.
97
3.7.
Resmen del captulo
En este captulo se present el planteamiento del problema de la tesis, a travs

de la identificacin de cinco aspectos relacionados con la ejecucin de procesos de
aprendizaje, a lo largo de la evolucin de los sistemas de e-learning. Para ello se
utiliz como ejemplo la ejecucin en las cuatro etapas, de un escenario de aprendizaje
adaptado del curso Liderazgo para el Desarrollo Sostenible en su versin enero-mayo
2010, de la Universidad Virtual del Tecnolgico de Monterrey.
Con el escenario de aprendizaje se identific en la segunda etapa la dificultad para
integrar diversos recursos y servicios para el aprendizaje, la cuestin de sustitucin
de servicios de aprendizaje de manera sencilla y la falta de soporte al proceso de
aprendizaje.
En la tercera etapa, persisten los problemas de la etapa anterior, e incluso algunos
adquieren una complejidad mayor. Los problemas identificados en esta etapa son
la dificultad para ejecutar estructuras de aprendizaje complejas, la dificultad para
integrar diversos recursos y servicios para el aprendizaje, el aspecto de la sustitucin
de servicios de aprendizaje de manera sencilla, y el soporte al proceso de aprendizaje.
Finalmente, en la cuarta etapa se identifica el problema del complejo manejo de
roles y asignacin de tareas. Adems la cuestin del soporte al proceso de aprendizaje se vuelve ms compleja al requerir que el soporte tenga caractersticas transaccionales.
Los problemas que se abordarn en el resto del documento, para construir el
marco de referencia para el diseo del motor de ejecucin de procesos de aprendizaje
de cuarta etapa son:
P1 Dificultad para ejecutar estructuras de aprendizaje complejas.
P2 Complejo manejo de roles y asignacin de tareas.
P3 Dificultad para integrar diversos recursos y servicios para el aprendizaje en
ambientes distribuidos y heterogneos.
P4 Sustitucin de los recursos y servicios de aprendizaje de manera sencilla.
P5 Soporte transaccional para el proceso de aprendizaje.
98
A partir de estos problemas se planetaron los siguientes objetivos de investigacin:

O1 Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a
travs de un LME.
O2 Integracin de servicios web.
O3 Sustituir y agregar de manera sencilla y transparente un servicio web.
O4 Proveer al proceso de aprendizaje de soporte transaccional.
En el siguiente captulo se abordarn las contribuciones que pretenden dar solucin a los problemas identificados a lo largo de este captulo.
Captulo 4
Propuesta de solucin
En el captulo anterior, se present el planteamiento del problema de la tesis
donde se identificaron seis aspectos relacionados con la ejecucin de procesos de
aprendizaje. En el presente captulo se presenta una propuesta de solucin a las
problemticas anteriormente identificadas, a travs de cinco contribuciones que tienen
como objetivo, proveer un marco de referencia para el diseo y la construccin de un
motor de ejecucin de procesos de aprendizaje complejos.
Por su capacidad para describir PACs (ver seccin 2.2) y derivado del anlisis de
la seccin 2.3, el LME que el motor de ejecucin interpretar ser LPCEL. Por lo
tanto, como se describe en la seccin 2.3.4, el motor ser el componente central de
la arquitectura WASEL.
Partiendo de la revisin de los motores de ejecucin de flujos de trabajo y de procesos de aprendizaje (ver seccin 2.4), se han planteado las siguientes contribuciones:
(C1) Modelo de la arquitectura de software del motor de ejecucin.
(C2) Modelo de informacin del motor de ejecucin.
(C3) Modelo de instanciacin de actividades.
(C4) Modelo de ejecucin de actividades.
(C5) Modelo de transacciones.
99
100
4.1. C1. Modelo de la arquitectura de software del motor de ejecucin
El enfoque de la propuesta de solucin se diferencia de otros enfoques SOA en el

ambiente educativo por tener un impacto directo en los procesos pedaggicos. A la
fecha, los enfoques SOA en el ambiente educativo han centrado sus esfuerzos en procesos administrativos de cooperacin interinstitucional, dejando de lado los procesos
de aprendizaje. Un caso de ello, es la reciente publicacin del IMS Global Learning
Consortium, sobre las prcticas recomendadas para la adopcin de SOA para systemas empresariales en la educacin (Adoption of Service Oriented Architecture for
Enterprise Systems in Education: Recommended Practices en ingls) [IMS, 2009].
A continuacin, se presentan a detalle cada una de las contribuciones que forman
parte de la propuesta de solucin.
4.1.
C1. Modelo de la arquitectura de software del motor

de ejecucin
La primera contribucin se define como C1 Modelo de la arquitectura de software del motor de ejecucin, y responde a la visin general del motor de ejecucin
y la forma en que los componentes de ste, interactan con los participantes, sus
componentes internos, y otros sistemas en el proceso de aprendizaje. Esta contribucin aborda junto con otras contribuciones, los objetivos O1 Ejecutar un proceso de
aprendizaje con estructuras complejas, descrito a travs de un LME, O2 Integracin
de servicios web y O3 Sustituir y agregar de manera sencilla y transparente un servicio web; para brindar una solucin a los problemas P1 Dificultad para ejecutar
estructuras de aprendizaje complejas, P2 Complejo manejo de roles y asignacin de
tareas, P3 Dificultad para integrar diversos recursos y servicios para el aprendizaje
en ambientes distribuidos y heterogneos y P4 Sustitucin de los recursos y servicios
de aprendizaje de manera sencilla. En la figura 4.1, se muestran estas relaciones de
manera grfica.
La contribucin C1 se formaliza a travs de un diagrama de componentes UML
que se puede observar en la figura 4.2.
El modelo de arquitectura propuesto, toma como arquitectura de referencia la
presentada en [Hollingsworth, 1995] (ver seccin 2.4.1) para motores de ejecucin
de flujos de trabajo, y a la vez incorpora elementos de la arquitectura del motor
101
Figura 4.1: Relacin entre la contribucin C1 y los problemas y objetivos de investigacin

CopperCore (ver seccin 2.4.2). A nivel de subcomponentes, el motor de ejecucin
considera los siguientes:
backend: Es el componente donde se lleva a cabo la administracin del motor de
ejecucin. Se compone por los subcomponentes users, login y roles.
users: Este componente se encarga de la gestin de los usuarios del motor de ejecucin.
login: En este componente se lleva a cabo la autentificacin de los usarios, y es el
punto de entrada al motor.
roles: El componente roles es el encargado de asignar los roles a los usuarios del
motor. Los roles del motor pueden ser administrador del sistema, diseador
instruccional, docente, y alumno. Estos roles son nicamente para el acceso al
motor, y difieren de los roles que un alumno puede desempear dentro de un
curso. El administrador del sistema es el nico que tiene acceso al backend. El
diseador instruccional es el nico que tiene acceso al componente publication.
El profesor es el nico que tiene acceso a management, y junto con el alumno ambos tienen acceso a execution que es donde se ejecuta el escenario de
aprendizaje.
102
4.1. C1. Modelo de la arquitectura de software del motor de ejecucin
Figura 4.2: Modelo de la arquitectura de software

frontend: Es el componente donde se crean, administran y ejecutan los escenarios
de aprendizaje. Comprende los subcomponentes login, publication, management
y execution.
publication: Este componente se encarga de la publicacin de cursos (ver seccin
2.4.2), elaborados por un diseador instruccional. Es a travs de este componente que un diseador instruccional le da al motor el escenario de aprendizaje
descrito en un LME, en este caso LPCEL, y entonces el motor se encarga de
leerlo, validarlo y publicarlo para que posteriormente pueda ser ejecutado.
management: En este componente es donde se administran las ejecuciones de los
cursos. Es decir, una vez que un curso ha sido publicado a travs del componente
publication, para que el curso pueda llevarse a cabo es necesario crear una
ejecucin del curso a travs de la creacin de una instancia de la publicacion,
a la cual se le llama ejecucin. La publicacin puede instanciarse tantas veces
como se quiera ejecutar el curso. Una vez que ha sido creada una ejecucin
del curso, se pueden inscribir a la ejecucin usuarios del motor con los roles de
alumno y profesor. Dado que el escenario de aprendizaje est diseado con el
lenguaje LPCEL, el cual permite definir roles para los alumnos y profesores, en
el componente management se pueden asignar los roles definidos en el escenario
de aprendizaje a los alumnos y profesores, dando la posibilidad incluso de
establecer jerarquas de roles. Por ltimo en este componente, el profesor decide
103
cuando cerrar las inscripciones, para iniciar la ejecucin del curso y que el
motor genere las instancias necesarias para cada actividad, a travs del modelo
de instanciacin que se presenta ms adelante en la seccin 4.3.
execution: El componente execution es donde se lleva a cabo el PAC. En este
componente se describe y ejecuta el flujo de aprendizaje de cada participante,
incluyendo cada una de sus actividades, las cuales pueden hacer uso de recursos
y servicios web, que el motor debe integrar y ejecutar.
Por otra parte, para complementar la presentacin de la arquitectura de software,
a nivel de interfaces se consideran las siguientes:
login: La interface login sirve para comunicar al motor de ejecucn los datos de
autentificacin del usuario, y as permitir o negar el acceso al motor.
user: Esta interface permite la entrada de datos de usuarios para la gestin de los
mismos en el motor de ejecucin.
role: En esta interface entran datos para la gestin de los roles en el motor de
ejecucin.
lpcel def: Esta es la interface de definicin del proceso de aprendizaje, el cual se
describe a travs de un escenario de aprendizaje definido en un archivo del
lenguaje LPCEL.
enrollment: Desde esta interface, se inscriben alumnos y profesores a la ejecucin
del proceso de aprendizaje, y se crean equipos de trabajo para la ejecucin del
curso.
activities: A travs de esta interface se comunican los componentes management y
execution, para ejecutar las actividades del flujo de aprendizaje.
web service: En esta interface es donde ocurre la integracin con servicios web que
se emplean en la ejecucin de las actividades del escenario de aprendizaje.
Con lo anterior, concluye la presentacin general de la arquitectura de software
del motor de ejecucin. a continuacin se presenta el modelo de informacin del
motor de ejecucin.
104
4.2. C2. Modelo de informacin del motor de ejecucin
4.2.
C2. Modelo de informacin del motor de ejecucin
En el apartado anterior, se present el modelo de la arquitectura de software del

motor de ejecucin de PACs, el cual muestra a nivel de componentes la estructura
interna del motor. En este sentido, para que cada uno de los componentes del motor
se pueden comunicar entre s, y juntos sean capaces de ejecutar PACs, es necesario
que compartan un modelo de informacin.
La segunda contribucin se define como C2 Modelo de informacin del motor de
ejecucin. Esta contribucin aborda junto con otras contribuciones, los objetivos O1
Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a travs de un
LME, O2 Integracin de servicios web y O3 Sustituir y agregar de manera sencilla y
transparente un servicio web; para brindar una solucin a los problemas P1 Dificultad
para ejecutar estructuras de aprendizaje complejas, P2 Complejo manejo de roles y
asignacin de tareas, P3 Dificultad para integrar diversos recursos y servicios para el
aprendizaje en ambientes distribuidos y heterogneos y P4 Sustitucin de los recursos
y servicios de aprendizaje de manera sencilla. En la figura 4.3, se muestran estas
relaciones de manera grfica.

El modelo de informacin del motor de ejecucin se formaliza a travs de un
diagrama de clases UML que se puede observar en la figura 4.4. El modelo de in-
105
formacin propuesto toma como puntos de partida el modelo de informacin del

lenguaje LPCEL (ver seccin 2.3.4), el motor de ejecucin de IMS LD (ver seccin
2.4.2), el modelo de control de acceso basado en roles (ver seccin 2.11.1), cuestiones
de instanciacin de procesos y actividades (ver seccin 2.11.2), y la teora de sistemas
de flujos de trabajo (ver seccin 2.4.1).
Figura 4.4: Modelo de informacin del motor de ejecucin

Las clases que se proponen en el modelo de informacin tienen diversos propsitos:
Descripcin del escenario de aprendizaje
Instanciacin de procesos
Instanciacin de actividades
Control de acceso y asignacin de permisos a usuarios
Ejecucin del flujo de aprendizaje
Para la descripcin del escenario de aprendizaje se consideran las clases
CLP_publication, Feature, Requisite, Aim, Execution_role, Assignment,
Activity, Resource, Link, RPC, CLP_component y todas sus clases heredadas.
La clase CLP_publication, contiene la descripcin general del escenario de aprendizaje. Las clases Feature, Requisite y Aim, contienen informacin especfica sobre las caractersticas, requisitos y objetivos del proceso de aprendizaje. Las clases
106
4.2. C2. Modelo de informacin del motor de ejecucin
Activity, Resource, CLP_component y sus clases heredadas describen el flujo de
aprendizaje del escenario de aprendizaje, junto con los recursos requeridos. La clase
Resource describe los recursos almacenados de manera local, mientras que las clases
heredadas Link y RPC describen los recursos remotos; la clase Link describe aquellos
recursos que se accesan a travs de un enlace web, mientras que la clase RPC describe
los recursos que se accesan a travs de llamadas a procedimientos remotos. Y las
clases Execution_role y Assignment, contienen informacin sobre los roles de los
participantes que deben ejecutar partes especficas del flujo de aprendizaje. Todas
las instancias de estas clases se generan a partir de cuando el motor de ejecucin lee
el escenario de aprendizaje de un LME, lo procesa, y entonces genera cada una de
las instancias a partir del diseo del escenario de aprendizaje.
Para la instanciacin de procesos de aprendizaje, se consideran las clases
Publicacin_PAC y CLP_execution. La clase CLP_publication guarda el LME,
y cada vez que se va a iniciar una nueva ejecucin de la publicacin, se genera una
instancia de la clase CLP_execution. Los objetos de la clase CLP_execution son
las propias instancias del proceso de aprendizaje, y entre los atributos de la clase se
encuentra el estado de la ejecucin, el cual puede tomar los siguientes valores:
Inscripciones: Indica que los usuarios pueden inscribirse al curso.
Cerrado: Los usuarios ya no pueden inscribirse al curso, y que la ejecucin est
lista para comenzar.
Cursando: El proceso de aprendizaje se est ejecutando.
Terminado: Todos los usuarios han terminado la ejecucin de su proceso de aprendizaje.
En cuanto a la instanciacin de actividades, las clases diseadas para este propsito son CLP_component, Basic_component, Activity, Activity_instance,
Team_instance,
Individual_instance,
Team,
User,
Execution_role,
Hierarchy y Assignment. Un Basic_component tiene asociada una activi-
dad Activity, la cual puede instanciarse mltiples veces dependiendo del rol que
debe llevarla a cabo y tambin depende de si es una actividad individual o una
actividad en equipo. Esta generacin de instancias se detalla ms adelante en el
modelo de instanciacin de actividades, que se presenta en la seccin 4.3.
107
En lo que respecta al control de acceso y asignacin de permisos a usuarios, lo

primero es destacar que se consideran dos tipos de roles para los usuarios: los roles
del motor y los roles de ejecucin. Los roles del motor de ejecucin, como se mencion
en el modelo de la arquitectura de software, pueden ser administrador del sistema,
diseador instruccional, docente, y alumno. El administrador del sistema es el nico
que tiene acceso a la administracin del motor, es decir, es el nico que puede crear
nuevos usuarios y asignarles roles del motor. El diseador instruccional es quien
disea los escenarios de aprendizaje en un LME, y posteriormente los publica en el
motor. El profesor es quien crea las ejecuciones de las publicaciones y tiene acceso a la
administracin de la ejecucin, es decir, puede inscribir alumnos al curso, conformar
equipos y hacer modificaciones en el flujo de aprendizaje. El alumno es quien lleva a
cabo los procesos de aprendizaje, una vez que se ha inscrito en una ejecucin de un
curso. Cuando un profesor o alumno estn inscritos en una ejecucin, entonces estos
usuarios pueden adquirir adems un rol de ejecucin.
Los roles de ejecucin son dinmicos y especficos para cada ejecucin. Se establecen en tiempo de diseo del escenario de aprendizaje, y se asignan cuando la
ejecucin del curso est en el estado inscripciones.
Finalmente, todas las clases expuestas hasta ahora que conforman el modelo de
informacin del motor de ejecucin, son necesarias para la ejecucin del flujo de
aprendizaje. La ejecucin del flujo de aprendizaje se presenta en la seccin 4.4 a
travs del modelo de ejecucin de actividades.
A continuacin se presenta el modelo de instanciacin de actividades.
4.3.
C3. Modelo de instanciacin de actividades
Hasta ahora se han presentado el modelo de la arquitectura de software y el

modelo de informacin del motor de ejecucin. La siguiente contribucin que se
define como C3 Modelo de instanciacin de actividades, tiene que ver con la generacin automtica de las instancias necesarias de cada actividad dentro del proceso
de aprendizaje, para que posteriormente el proceso de aprendizaje se pueda ejecutar.
Esta contribucin aborda junto con otras contribuciones, el objetivo de investigacin O1 Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a
108
4.3. C3. Modelo de instanciacin de actividades
travs de un LME; para brindar una solucin al problema P2 Complejo manejo de

roles y asignacin de tareas. En la figura 4.5, se muestran estas relaciones de manera
grfica.

El modelo de instanciacin que se propone, toma como referencia los WFMS (ver
seccin 2.11.2) y el modelo RBAC (ver seccin 2.11.1). Sin embargo, es importante
hacer la siguiente distincin entre los flujos de trabajo y los flujos de aprendizaje:
En los flujos de trabajo de sistemas empresariales, es comn que un usuario
una vez que realiza su tarea o actividad, no vuelva a saber del estado del flujo
de trabajo, ya que su reponsabilidad se limita al proceso del cual es dueo.
Mientras que los directivos responsables del proceso completo son a quienes les
concierne el estado completo del flujo de trabajo, sin embargo, son pocas las
tareas operativas que ellos ejecutan. Con frecuencia los usuarios se limitan a
realizar un slo tipo de actividad, en slo una parte del proceso.
En cambio, en un flujo de aprendizaje, el usuario es dueo y responsable de
todo su proceso de aprendizaje, y tiene la responsabilidad de llevar a cabo cada
una de las actividades de aprendizaje. En muy raras ocasiones, el usuario llega
a repetir actividades, y con frecuencia realiza diversos tipos de actividades a lo
largo de todo su proceso de aprendizaje.
109
Por lo tanto, es necesario un modelo de instanciacin de actividades que incluya

los beneficios de los WFMS para monitorear y manipular el estado del proceso,
y que tome en cuenta el nivel de ejecucin de actividades basado en roles para
complementar el sentido pedaggico de las actividades en PACs. Al mismo tiempo,
el modelo debe de tomar en cuenta los requerimientos pedaggicos propios de los
procesos de aprendizaje sealados en el prrafo anterior.
A continuacin, se presenta el modelo de instanciacin de actividades por medio
de notacin de teora de conjuntos. Se comienza por definir los conjuntos de las
entidades relacionadas con las actividades que se van a instanciar. Dichas entidades
son los usuarios, los roles que puede desempear cada usuario, y los equipos en los
que puede participar cada usuario.
U S = {us1 , us2 , . . . , usn },
donde US es el conjunto denominado Usuarios, que representa a los sujetos que
tienen acceso al motor de ejecucin. Los elementos de US se definen por la siguiente
tupla:
us = tupla(n, us, c),
donde n es el nombre real del sujeto, us es el nombre de usuario, es decir, la
identificacin del sujeto dentro del motor de ejecucin, y c es la contrasea o clave
de acceso del sujeto.
R = {r1 , r2 , . . . , rn },
donde R es el conjunto de denominado Roles, que representa las responsabilidades
de un usuario dentro de una ejecucin de un PAC. Los elementos de R se definen en
tiempo de diseo por la siguiente tupla:
r = tupla(t),
donde t se refiere al ttulo del rol.
E = {e1 , e2 , . . . , en },
donde E es el conjunto denominado Equipos, que representa los equipos que
participan en una ejecucin de un PAC. Se definen en tiempo de ejecucin del PAC
por la tupla:
110
e = tupla(t, e),
donde t se refiere al ttulo o nombre del equipo, y e se refiere a una instancia de
ejecucin de un PAC, es decir, a una instancia de un curso.
JR R R,
donde JR es el conjunto denominado Jerarqua de roles, el cual es un subconjunto de relaciones muchos a muchos de rol a rol, las cuales sirven para determinar
diferentes niveles de responsabilidades dentro de un PAC. Las relaciones se definen
en el diseo del PAC.
RU R U S,
donde RU es el conjunto denominado Roles de usuarios, el cual es un subconjunto
de asignaciones de Roles R a Usuarios U, las cuales se establecen en tiempo de
ejecucin.
RE R E,
donde RE es el conjunto denominado Roles de equipo, el cual es un subconjunto
de asignaciones de Roles R en Equipos E, las cuales se establecen en tiempo de
ejecucin.
En seguida se presentan los conjuntos relacionados con las descripciones de las
actividades, en donde se debe de tomar en cuenta tanto las actividades individuales,
como las actividades en equipo.
A = {a1 , a2 , . . . , an },
donde A es el conjunto denominado Actividades, que representa descripciones de
actividades. Se definen en tiempo de diseo por la tupla:
a = tupla(t, d, i, r),
a2A
p(i) : i = {0, 1},
donde t se refiere al ttulo o nombre de la actividad, d a la descripcin de la

actividad, i se refiere a si la actividad debe ejecutarse de manera individual o en
equipo, y r se refiere al rol que debe ejecutar la actividad.
AI A
a2A
p(i) : i = 1,
111
donde AI es el conjunto denominado Actividades individuales, que es subconjunto

de Actividades A, donde i indica que la actividad que debe ejecutarse de manera
individual.
AE A
a2A
p(i) : i = 0,
donde AE es el conjunto denominado Actividades en equipo, que es subconjunto

de Actividades A, donde i indica que una actividad que puede ejecutarse en equipo.
Por lo tanto,
AI AE A
Por ltimo, se generan los conjuntos de las instancias de las actividades.
II RU AI |
ru2RU
p(t)
ai2AI
p(r) : t = r,
donde II es el conjunto denominado Instancias de actividades individuales, que es

el conjunto de actividades que se ejecutan de manera individual por cada usuario que
tiene asignado un rol en especfico que coincide con la descripcin de la actividad, i.e.,
una instancia de actividad slo puede ser ejecutada por un determinado usuario con
un rol especificado por la actividad; si la actividad genera un valor de evaluacin, el
valor es nicamente para el usuario que ejecut la actividad; si la actividad requiere
de la generacin de un producto, el usuario lo produce por s mismo.
IE RE AE |
re2RE
p(t)
ae2AE
p(r) : t = r,
donde IE es el conjunto denominado Instancias de actividades en equipo, que es el

conjunto de actividades que se ejecutan en equipo por un usuario que tiene asignado
un rol en especfico que coincide con la descripcin de la actividad, i.e., cualquier
usuario con un rol especfico dentro de un equipo, puede ejecutar la actividad; si la
actividad genera un valor de evaluacin, el valor es para todos los usuarios del equipo;
si la actividad requiere de la generacin de un producto, ste puede ser generado por
varios usuarios con el rol especificado dentro del mismo equipo.
I = II IE,
donde I es el conjunto denominado Instancias, que es el conjunto de todas las
instancias de actividades, conformado por las Instancias de actividades individuales
II y las Instancias de actividades en equipo IE.
112
i2I
p(e) : e = {in, a, s, c f },
donde cada instancia i, tiene la propiedad estado e, la cual indica el estado de

ejecucin de la instancia (ver seccin 2.11.2). Los estados de ejecucin de la instancia
pueden ser in, que indica que la instancia se encuentra inactiva; a, que indica que la
instancia est activa; s, que indica que la instancia se encuentra suspendida; c, que
indica que la instancia ha sido completada con xito; o f, que indica que la instancia
ha sido completada pero con fracaso, ya sea por una cuestin tecnolgica o porque
no se lograron los objetivos de aprendizaje.
Con lo anterior, termina la definicin del modelo de instanciacin de actividades.
Las principales contribuciones de este modelo son las siguientes:
El modelo genera las instancias necesarias de cada actividad, lo que asegura la
completitud del flujo de aprendizaje para cada participante.
El modelo slo genera las instancias de actividades que se necesitan, es decir,
no se generan instancias de actividades que no son de inters para ciertos
participantes. Por ejemplo, un usuario con determinado rol, no tiene dentro de
sus actividades, una actividad especfica para un rol que no tiene asignado.
Existen dos tipos de instancias de actividades, las instancias de actividades
individuales y las instancias de actividades en equipo. Esto le permite al alumno conocer y mantener el control de su proceso de aprendizaje, adems de
participar colaborativamente con otros alumnos en tareas comunes.
La forma en que se realiza la instanciacin en este modelo, permite al docente
conocer el estado del flujo de aprendizaje de cada alumno y del grupo en
general.
A continuacin para clarificar el modelo, se presenta un ejemplo del modelo de
instanciacin aplicado en un escenario de aprendizaje.
4.3.1.
Una instancia del modelo de instanciacin de actividades
En la Universidad Virtual del Tecnolgico de Monterrey, Mxico, dentro del programa de Maestra en Administracin de Tecnologas de la Informacin, hay un curso
113
de Mejora Continua de Servicios de Tecnologas de Informacin 1 . El curso diseado

por la Mtra. Teresa de Jess Lucio Nieto, dedica el Mdulo 5 al tema Gestin de
problemas, y se est ejecutando en su versin agosto-diciembre 2010. Un extracto
del mdulo consta de las siguientes actividades:
1. Realiza la lectura crtica (modalidad individual).
2. Anlisis del caso de estudio (modalidad colaborativa).
3. Examen de lectura (modalidad individual).
A partir de lo anterior se obtienen los siguientes elementos:
a1 (Realiza la lectura crtica, Libro IT IL Service Operation Cap. 4(. . .), 1, alumno),
a2 (Anlisis del caso de estudio, Analiza el caso de estudio(. . .), 0, miembro de equipo),
a3 (Examen de lectura, Consiste en 10 preguntas(. . .), 1, alumno).
Los elementos anteriores conforman los siguientes conjuntos:
A = {a1 , a2 , a3 },
AI = {a1 , a3 },
AE = {a2 },
de donde
AI AE A
Para llevar a cabo las actividades anteriores se han definido los siguientes roles:
r1 (alumno),
r2 (miembro de equipo).
Los cuales conforman el conjunto de roles
R = {r1 , r2 },
con la siguiente jerarqua:
JR = {(r1 , r2 )}.
1
http://www.ruv.itesm.mx/portal/promocion/oe/m/mti/plan/homedoc.htm#TI5018
114
En tiempo de ejecucin, se inscriben los siguientes usuarios al curso:

us1 (EduardoJurez, A00339777, ),
us2 (BenjamnV alds, A00882900, ),
us3 (M iguelHidalgo, A16091810, ),
us4 (GustavoM adero, A20111910, ),
us5 (V enustianoCarranza, A05021917, ),
us6 (LzaroCrdenas, A18031938, ).
Los cuales conforman el conjunto de usuarios
U S = {us1 , us2 , us3 , us4 , us5 , us6 }.
De acuerdo al nmero de usuarios inscritos, el docente decide crear dos equipos:
e1 (equipo1, ago
dic2010),
e2 (equipo2, ago
dic2010).
Los cuales conforman el conjunto de equipos

E = {e1 , e2 }.
Posteriormente, el profesor decide asignar los siguientes roles a los usuarios inscritos:
RU = {(r2 , us1 ), (r2 , us2 ), (r2 , us3 ), (r2 , us4 ), (r2 , us5 ), (r2 , us6 )},
y por jerarqua, la asignacin final queda de la siguiente forma:
RU = {(r2 , us1 ), (r2 , us2 ), (r2 , us3 ), (r2 , us4 ), (r2 , us5 ), (r2 , us6 ),
(r1 , us1 ), (r1 , us2 ), (r1 , us3 ), (r1 , us4 ), (r1 , us5 ), (r1 , us6 )}.
Despus, el docente asigna el siguiente rol a los equipos:
RE = {(r2 , e1 ), (r2 , e2 )}.
Entonces, al iniciar la ejecucin del curso, el sistema genera las siguientes instancias de actividades:
II = {((r1 , us1 ), a1 ), ((r1 , us2 ), a1 ), ((r1 , us3 ), a1 ), ((r1 , us4 ), a1 ), ((r1 , us5 ), a1 ),
115
((r1 , us6 ), a1 ), ((r1 , us1 ), a3 ), ((r1 , us2 ), a3 ), ((r1 , us3 ), a3 ), ((r1 , us4 ), a3 ),
((r1 , us5 ), a3 ), ((r1 , us6 ), a3 )},
| II |= 12,
IE = {((r2 , e1 ), a2 ), ((r2 , e2 ), a2 )},
| IE |= 2,
| I |= 14.
En total se habrn generado 14 instancias de actividades, de las cuales, 12 son
instancias de actividades individuales y 2 son instancias de actividades en equipo.
Con lo anterior termina la presentacin del modelo de instanciacin de actividades. A continuacin se presenta el Modelo de ejecucin de actividades.
4.4.
C4. Modelo de ejecucin de actividades
Hasta ahora, se han presentado el modelo de la arquitectura de software, el modelo

de informacin del motor de ejecucin de PACs, y el modelo de instanciacin de
actividades, los cuales muestran la estructura de componentes y clases necesarias
para el funcionamiento del motor, as como las instancias que se generan de cada
actividad para que posteriormente el escenario de aprendizaje pueda ser ejecutado.
En esta seccin se presenta la contribucin C4 Modelo de ejecucin de actividades del
motor de ejecucin de PACs, el cual se formaliza a travs de diagramas de secuencia
UML.
Esta contribucin aborda junto con otras contribuciones, el objetivo de investigacin O1 Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a
travs de un LME; para brindar una solucin al problema P1 Dificultad para ejecutar
estructuras de aprendizaje complejas. En la figura 4.6, se muestran estas relaciones
de manera grfica.
En la figura 4.7, se muestra la secuencia en la que un alumno inscrito en una
ejecucin de un PAC, requiere ejecutar su flujo de actividades de aprendizaje. En
primer lugar el alumno obtiene el identificador de la ejecucin, para a partir de ah
obtener el primer componente del flujo de aprendizaje, y posteriormente obtener el
116
4.4. C4. Modelo de ejecucin de actividades

flujo de actividades de aprendizaje completo, el cual se ir construyendo a partir de
obtener las instancias de las actividades que el alumno debe llevar a cabo. El primer
componente debe ser siempre un componente complejo, es decir, una estructura de
actividades. Esto debido a que si fuera un componente bsico, la ejecucin del curso
constara slo de una actividad.
La construccin del flujo de aprendizaje se hace a partir de la funcin recursiva
getNextActivityInstance, la cual se encarga de obtener la siguiente instancia
de actividad, o en su caso, el siguiente componente del flujo de aprendizaje. El

diagrama de secuencia de la funcin getNextActivityInstance se presenta en la
figura 4.8. La funcin getNextActivityInstance comienza por obtener el tipo de
componente, y dependiendo de si el componente es un complejo o bsico, se llevan
a cabo diferentes acciones. Si el componente es un componente bsico, simplemente
se obtiene la instancia de la actividad contenida en el componente bsico. Para el
caso de los componentes complejos, pueden seguirse diversos rumbos de acciones
dependiendo del tipo de componente complejo.
En la figura 4.9 se muestra el diagrama de secuencia para la ejecucin de actividades que se llevan a cabo de manera secuencial, es decir, una actividad seguida
de otra en un orden especfico y riguroso. Para auxiliar en el control de la ejecucin
de las estrucutras de actividades, se crea una instancia de la clase Controlflow, la
cual dentro de sus atributos almacena la cantidad de componentes (i.e. actividades y
estructuras de actividaes) que tiene el componente en cuestin, y tambin almacena
117
Figura 4.7: Modelo de ejecucin de actividades
la cantidad de componentes que han ejecutado sus actividades de manera exitosa.

De esta forma, el objeto de la clase Controlflow se utiliza para controlar el flujo
de aprendizaje como se ver ms adelante. La funcin getNextActivityInstance,
a su vez cuenta con una variable success para indicar si el componente (bsico o
complejo) se ha ejecutado con xito. Esta variable tiene un valor inicial de verdadero,
y cambia su valor a falso si la actividad no se ha completado.
Una vez creado el objeto de Controlflow, se obtienen todos los subcomponentes
del componente en cuestin y se ejecuta una serie de acciones para cada subcomponente, dependiendo del tipo de subcomponente. Si el subcomponente es un componente complejo y la variable success es verdadera, entonces quiere decir que la
secuencia se ha estado ejecutando con xito y que se debe obtener la siguiente instancia de actividad, a travs nuevamente de la funcin getNextActivityInstance, la
cual dependiendo de su resultado, puede modificar el valor de la variable success a
falso, o mantener el valor de esta variable en verdadero. En el caso de que el valor
de success se mantenga en verdadero, se aade un xito al contador de xitos de
Controlflow.
118
Para el caso en el que el subcomponente es un componente bsico y la variable

success es verdadera, entonces se obtiene la instancia de la actividad relacionada
con el componente bsico, y se obtiene su estado. Si el estado de la instancia no es de

xito, entonces el valor de la variable xito cambia a falso. Si el estado de la instancia
es de xito, entonces se agrega un xito al contador de xitos de Controlflow.
Posteriormente se obtiene el siguiente subcomponente de manera recursiva a travs
de la funcin getNextActivityInstance.
Para las condiciones en las cuales se obtiene un subcomponente y el valor de
la variable de xito es falso, no se lleva a cabo accin alguna, lo cual repercute
directamente en parar el flujo de todas las actividades de aprendizaje siguientes.
Esto es correcto y adecuado, ya que el participante en el proceso de aprendizaje
no debe poder ejecutar ms actividades dentro de una secuencia una vez que se
encuentra con una actividad que no ha completado.
Para que la ejecucin de una secuencia sea considerada exitosa, el contador de
xitos de Controlflow, debe ser igual a la cantidad de subcomponentes del componente en cuestin.
Por otra parte, para ejecutar flujos de aprendizaje en paralelo y opcionales, el
modelo de ejecucin es parecido, pero con diferencias substanciales en las condiciones
de flujo.
Los flujos de aprendizaje de actividades en paralelo, son aquellos en los que no
es relevante el orden en que se ejecutan las actividades, es decir, puede llevarse a
cabo primero una actividad, o la otra, o ambas pueden estarse ejecutando al mismo
tiempo. Lo importante es destacar que para que el flujo en paralelo se considere
exitoso, todas las actividades paralelas deben de haberse ejecutado.
En la figura 4.10, se presenta el modelo de ejecucin de actividades en paralelo.
Al igual que en la ejecucin de actividades en secuencia, el primer paso es crear
un objeto de la clase Controlflow, y despus obtener el tipo de subcomponente.
A diferencia de la ejecucin de secuencias, las condiciones dentro del ciclo de subcomponentes, nicamente dependen del tipo de subcomponente y no del valor de la
variable success.
Si el subcomponente es un componente complejo se obtiene la siguiente instancia de actividad a travs de la funcin getNextActivityInstance, y si el valor
119
de success no cambia, se suma uno al contador de xitos de Controlflow. Si el

subcomponente es un componente bsico, se obtiene la instancia de la actividad relacionada con el componente, as como su estado. Si el estado de la instancia no es de
xito, entonces el valor de la variable xito cambia a falso. Si el estado de la instancia
es de xito, se agrega un xito al contador de xitos de Controlflow.
La diferencia ms destacable de la ejecucin de actividades en paralelo con respecto a la ejecucin de actividades en secuencia, es que en las actividades en paralelo,
se muestran todos los componentes que se ejecutan en paralelo, no importando que
alguno de ellos no haya sido completado con xito.
Como se mencion anteriormente, el flujo en paralelo se considera exitoso slo si
todos los subcomponentes se ejecutaron con xito.
Por otra parte, para el caso de la ejecucin de actividades opcionales, el modelo
de ejecucin es semejante a la ejecucin de actividades paralelas con una pequea
variacin en las condicin de xito, lo cual provoca una serie de acciones posteriores
al ciclo de subcomponentes.
Las estructuras de aprendizaje con actividades opcionales, se refieren a un escenario de aprendizaje en el que se tienen que ejecutar n actividades de un conjunto de
N actividades. Por ejemplo, para poder continuar con las actividades de aprendizaje,
es necesario llevar a cabo 2 de 4 actividades propuestas.
El modelo de ejecucin de flujos de aprendizaje de actividades opcionales se presenta en la figura 4.11. Como puede observarse, las acciones a seguir son las mismas
que en la ejecucin de actividades paralelas, hasta llegar al punto donde termina el
ciclo de subcomponentes. A partir de ah lo siguiente es obtener la cantidad de xitos
actuales a travs del objeto de Controlflow, y tambin se debe obtener la cantidad
de actividades que deben completarse para que se considere que el componente ha
sido ejecutado con xito, esto a travs de la funcin getJoinCondition de la clase
Choice. Si el nmero de xitos es mayor o igual a la cantidad de actividades que
deben completarse, entonces se considera que la estructura ha sido ejecutada con

xito.
Con lo anterior, termina la presentacin del modelo de ejecucin de actividades.
En el siguiente apartado se presenta el modelo de transacciones del motor, el cual
120
tiene que ver con las situaciones en que se lleva a cabo una actividad, pero no es
completada con xito.
121
Figura 4.8: Ejecucin de flujos de aprendizaje
122
Figura 4.9: Ejecucin de flujos de aprendizaje en secuencia
123
Figura 4.10: Ejecucin de flujos de aprendizaje en paralelo
124
Figura 4.11: Ejecucin de flujos de aprendizaje opcionales
125
4.5.
C5. Modelo de transacciones
En la seccin anterior se present el modelo de ejecucin de actividades, el cual

expresa la forma en que estructuras de actividades son ejecutadas por el motor. En
esta seccin se presenta la contribucin C5 Modelo de transacciones para motores de
ejecucin de PACs. El modelo de transacciones complementa al modelo de ejecucin
para manejar situaciones en que a pesar de que se ejecuta una actividad, el resultado
de su ejecucin no es suficiente para lograr los objetivos de aprendizaje del alumno.
Esta contribucin aborda, los objetivos de investigacin O3 Sustituir y agregar de
manera sencilla y transparente un servicio web, y O4 Proveer al proceso de aprendizaje de soporte transaccional, descrito a travs de un LME; para brindar una solucin
a los problemas P4 Sustitucin de los recursos y servicios de aprendizaje de manera
sencilla, y P5 Soporte transaccional para el proceso de aprendizaje. En la figura 4.12,
se muestran estas relaciones de manera grfica.

Para presentar esta contribucin, es necesario retomar lo presentado en la seccin
2.10, donde se presentaron algunos de los MTAs, as como una comparacin entre
ellos. El estudio de diversos MTAs es importante en el terreno del diseo del aprendizaje, no slo para soportar actividades de larga duracin, sino tambin para proveer
de soporte pedaggico al proceso de aprendizaje. Ello debido a que cada actividad
126
4.5. C5. Modelo de transacciones
y proceso de aprendizaje es diferente, y pueden requerir de una ejecucin bajo un

MTA diferente.
Considerando las caractersticas del ambiente de aprendizaje, es necesario remarcar la diferencia entre una actividad de un flujo de aprendizaje y una actividad de
un flujo de trabajo. Cuando una actividad de un flujo de trabajo es ejecutada y la
transaccin falla, se debe a un problema de software o hardware, e.g., recurso no
disponible, formato de entrada incorrecto, falla interna de la aplicacin, entre otros
[Hagen and Alonso, 2000]. En cambio, en las actividades de un flujo de aprendizaje,
cuando una transaccin falla, puede deberse tambin a que el estudiante no logr los
objetivos de aprendizaje, an cuando el estudiante complet la actividad de manera
correcta, e.g., el alumno no obtuvo la calificacin mnima para aprobar un examen,
hicieron falta productos en la presentacin de un proyecto, entre otros. Debido a
esto, los motores de ejecucin de PACs, deben de proveer una forma de manejar
actividades de compensacin en los flujos de aprendizaje para lograr los objetivos de
aprendizaje.
Adems, el soporte transaccional de un motor de ejecucin de PACs debe soportar
diversos MTAs, de tal forma que las diferentes actividades de aprendizaje puedan
ejecutarse bajo el MTA ms adecuado. La propuesta es manejar tres niveles de
transacciones en un motor de ejecucin (ver figura 4.13):
Proceso: En este nivel se utiliza un MTA general para todo el PAC. Especficamente
en la descripcin de un escenario de aprendizaje descrito en el lenguaje LPCEL,
este nivel se describe en el elemento <Complex-Learning-Process>(proceso
de aprendizaje complejo). A nivel de ejecucin, la eleccin del MTA se lleva a
cabo a travs de la clase CLP_execution. Un MTA enfocado en actividades
de larga duracin es adecuado para este nivel.
Actividad o subproceso: Este es el nivel de transacciones ms crtico en trminos
del aprendizaje. Si se escoge el MTA ms adecuado para cada actividad o conjunto de actividades de aprendizaje, se lograr una contribucin importante en
el estudiante para que logre sus objetivos de aprendizaje, al proveer al flujo
de aprendizaje de estructura y comportamiento adecuados. Diferentes MTAs
pueden ser usados en diferentes actividades y estructuras, e.g., el MTA Contratos puede ser usado en el elemento <Complex_component>(componente
127
Figura 4.13: Niveles de transacciones en un PAC

complejo), junto con las estructuras <Sequence>(secuencia) y <Loop>(ciclo),
bajo un paradigma de instruccin conductista; o bien puede usarse el MTA
Transacciones-s en el elemento <Complex_component>, junto con la estructura <Choice>(opcin), bajo un paradigma de instruccin constructivista.
Recurso: Este nivel ocurre en los objetos de la clase <Resource>(recurso). El
asunto principal aqu es si el recurso se trata de un servicio con estados o
un servicio sin estados. Con servicios sin estado un modelo de transacciones
simple con todas las propiedades ACID puede ser utilizado, mientras que con
los servicios con estados, el modelo de transacciones depender del tipo de
recurso.
A continuacin, se presenta el modelo de transacciones por medio de un algoritmo
expresado en lenguaje pseudocdigo.
128
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
4.5. C5. Modelo de transacciones
EscenarioAprendizaje E
Inicia TransaccionProceso P(E)
EstructuraDeActividades = E.ObtenSiguientesActividades
ParaCada (Estructura
EstructuraDeActividades) Hacer
Inicia TransaccionActividad A(Estructura)
Opcion (Estructura)
Caso Secuencia:
Mientras (Actividad = Estructura.ObtenSiguienteActividad
) Hacer
Recursos = Actividad.ObtenRecursos
ParaCada (Recurso
Recursos) Hacer
TransaccionRecurso(Recurso)
Fin ParaCada
Si (Actividad.Ejecuta != Verdadero) Entonces
A.EjecutaAccionDeFracaso(Actividad)
Fin Si
Fin Mientras
Caso Paralelo:
ParaCada (Actividad
Estructura.ObtenActividades) Hacer
ParaCada (Recurso
Recursos) Hacer
Fin Para
Si (Actividad.Ejecuta != Verdadero) Entonces
A.EjecutaAccionDeFracaso(Actividad)
Fin Si
Fin ParaCada
Caso Opcional:
ParaCada (Actividad
Estructura.ObtenActividades) Hacer
ParaCada (Recurso
Recursos) Hacer
Fin ParaCada
Fin ParaCada
Si (Estructura.ActividadesExitosas < Estructura.
ActividadesNecesarias) Entonces
P.EjecutaAccionDeFracaso(Estructura)
Fin Si
129
37
38
39
40
41
42
Fin Opcion
Si (A.Cometer != Verdadero) Entonces
P.EjecutaAccionDeFracaso(Estructura)
Fin Si
Fin CicloPorCada
Fin TransaccionProceso P
43
44
45
46
47
48
49
50
Funcion TransaccionRecurso(Recurso)
Inicia TransaccionRecurso R(Recurso)
R.ObtenRecurso
Si (R.Cometer != Verdadero) Entonces
R.Rollback
Fin Si
Fin Funcion
En otras palabras, suponga que Alicia y Beto estn inscritos en un curso. El

curso completo puede ser visto como una transaccin con muchas subtransacciones
(actividades de aprendizaje), y debido a que el curso dura una cantidad de tiempo
considerable y es una actividad de larga duracin con resultados parciales, el MTA
Transacciones anidadas abiertas sera adecuado como modelo de transacciones del
nivel de proceso.
Pero entonces, qu pasa cuando el profesor quiere que sus estudiantes desarrollen ciertas habilidades que pueden ser obtenidas de mejor manera a travs de un
enfoque conductista, donde una secuencia de tareas debe ser totalmente completada en un orden determinado? El MTA Contratos en el nivel de actividad debe ser
utilizado para esta situacin. Posteriormente cuando es tiempo de desarrollar una
actividad colaborativa bajo un enfoque constructivista, donde Alicia y Beto necesitan trabajar juntos con entregables parciales para lograr un objetivo, entonces el
MTA Transacciones-s sera ms adecuado.
Finalmente, cada tarea tiene recursos asociados a ella, algunos pueden ser simples
servicios sin estado que pueden ser manejados por el modelo de transacciones del
nivel de actividad, mientras que otros pueden ser manejados en el nivel recurso
por un modelo transaccional tradicional con todas las propiedades ACID, o bien, si
son necesarias interacciones complejas con servicios con estados, un MTA puede ser
utilizado dependiendo del tipo de recurso.
130
Con lo anterior, termina la presentacin del modelo de transacciones del motor

de ejecucin, y con ello concluyen las contribuciones de la presente tesis, las cuales
se evaluarn a lo largo del siguiente captulo.
4.6.
Resmen del captulo
A lo largo de este captulo, se presentaron las cinco contribuciones de la tesis,

mismas que pretenden lograr los objetivos de investigacin planteados en el captulo
anterior y dar una solucin a los problemas identificados, tal como se muestra en la
figura 4.14.
Figura 4.14: Relacin entre los problemas, los objetivos y las contribuciones
La contribucin C1 Modelo de la arquitectura de software del motor de ejecucin,
responde a la visin general del motor de ejecucin y la forma en que los componentes
de ste interactan con los participantes, sus componentes internos, y otros sistemas
en el proceso de aprendizaje.
La contribucin C2 Modelo de informacin del motor de ejecucin se formaliza
a travs de un diagrama de clases UML, el cual tiene la capacidad para almacenar
descripciones de escenarios de aprendizaje, instancias de procesos, instancias de actividades, mecanismos de control de acceso y el estado de la ejecucin de flujos de
aprendizaje.
La contribucin C3 Modelo de instanciacin de actividades, presenta una forma
de generar de manera automtica las instancias necesarias de cada actividad dentro
131
del proceso de aprendizaje, lo cual asegura la completitud del flujo de aprendizaje

para cada participante. El modelo toma en cuenta tanto actividades individuales
como actividades en equipo, lo cual permite al alumno conocer y mantener el control
de su proceso de aprendizaje, adems de participar colaborativamente con otros
alumnos en tareas comunes. Adems, por la forma en que se realiza la instanciacin
en este modelo, le permite al docente conocer el estado del flujo de aprendizaje de
cada alumno y del grupo en general.
La contribucin C4 Modelo de ejecucin de actividades se formaliza a travs de
diagramas de secuencia UML, los cuales muestran la forma en que se ejecuta el flujo
de actividades de aprendizaje para un participante en un proceso de aprendizaje. El
modelo contempla, entre otras, la ejecucin de estructuras de actividades en secuencia, paralelo y opcionales.
La contribucin C5 Modelo de transacciones, presenta una forma de visualizar un
proceso de aprendizaje como un modelo transaccional, con tres niveles de transacciones. El primer nivel contempla todo el proceso de aprenizaje. Mientras que el
segundo nivel se refiere a estructuras de actividades. Por ltimo, el tercer nivel acta
en la capa de los recursos para el aprendizaje. De esta forma se asegura la correcta
ejecucin de un escenario de aprendizaje.
A continuacin en el siguiente captulo, se presenta la evaluacin de cada una de
las contribuciones presentadas hasta el momento.
132
Captulo 5
Evaluacin
En el captulo anterior se present la propuesta de solucin a los problemas
identificados en el captulo 3 a travs de cinco contribuciones, las cuales buscan lograr
los objetivos planteados en el captulo 1. En este captulo, se presenta la evaluacin
de las contribuciones para asegurar que se logran los objetivos planteados.
Durante el primer captulo, se establecieron los siguientes objetivos de investigacin:
(O1) Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a travs
de un LME.
(O2) Integracin de servicios web.
(O3) Sustituir y agregar de manera sencilla y transparente un servicio web.
(O4) Proveer al proceso de aprendizaje de soporte transaccional.
Para cumplir dichos objetivos, en el captulo 4, se presentaron las cinco contribuciones de la tesis que forman el marco de referencia para la construccin de un
motor de ejecucin de PACs. Las contribuciones presentadas se enlistan nuevamente
a continuacin:
C1 Modelo de la arquitectura de software del motor de ejecucin.
C2 Modelo de informacin del motor de ejecucin.
133
134
C3 Modelo de instanciacin de actividades.

C4 Modelo de ejecucin de actividades.
C5 Modelo de transacciones.
Para verificar que las contribuciones logran los objetivos planteados, se consideran
las siguientes evaluaciones:
(E1) Ejecucin de un LME: Esta evaluacin se realizar a travs de pruebas funcionales en la ejecucin de un script de un LME. Esta evaluacin mide la
completitud y correctitud en la lectura de un LME, en la cantidad de instancias generadas de las actividades, y en el estado del proceso de aprendizaje
para cada alumno.
(E2) Navegacin y ejecucin de proceso: Esta evaluacin se realizar a travs de
pruebas funcionales en la navegacin y ejecucin en diversos escenarios de
aprendizaje. La finalidad de estas pruebas es demostrar que los modelos que
se proponen para el diseo de un motor de ejecucin, tienen la capacidad para
ejecutar estructuras de actividades en diversos patrones de control de flujos de
trabajo.
(E3) Instanciacin de actividades: Esta evaluacin tiene como objetivo verificar que
el modelo de instanciacin tiene la capacidad de generar las instancias de actividades necesarias para soportar de manera completa y correcta, patrones de
control de flujos de trabajo.
(E4) Invocacin de servicios web: Esta evaluacin tiene como objetivo verificar que
el modelo de la arquitectura de software y el modelo de informacin son capaces
de invocar servicios web distribuidos en una red computacional. La verificacin
se har a travs de pruebas funcionales.
(E5) Sustitucin de servicios web: El objetivo de esta evaluacin es validar la capacidad de los modelos propuestos de eliminar y agregar servicios web del proceso
de aprendizaje. Esta evaluacun se har a travs de pruebas funcionales.
(E6) Soporte transaccional: El objetivo de esta evaluacin es validar la factibilidad
del modelo de transacciones propuesto para un ambiente pedaggico apoyado
en la tecnologa.
135
En las siguientes secciones, se detallan cada una de las evaluaciones.
5.1.
E1. Ejecucin de un LME
La primera evaluacin denominada E1 Ejecucin de un LME, consiste en la lectura y ejecucin por parte del motor, de un escenario de aprendizaje descrito a travs
de un LME, en este caso LPCEL. La evaluacin se realizar a travs de pruebas funcionales en la ejecucin de un script de un LME.
Esta evaluacin valida las contribuciones C1 Modelo de la arquitectura de software del motor de ejecucin, C2 Modelo de informacin del motor de ejecucin, y
C3 Modelo de instanciacin de actividades. La validacin de dichas contribuciones se
hace con base en el objetivo de investigacin O1 Ejecutar un proceso de aprendizaje
con estructuras complejas, descrito a travs de un LME; para brindar una solucin
a los problemas P1 Dificultad para ejecutar estructuras de aprendizaje complejas, y
P2 Complejo manejo de roles y asignacin de tareas. En la figura 5.1, se muestran
estas relaciones de manera grfica.
Figura 5.1: Relacin entre la evaluacin E1 y las contribuciones, objetivos y problemas
136
5.1. E1. Ejecucin de un LME
La evaluacin E1 mide la completitud y correctitud en la lectura de un LME.

Los elementos a validar con estas pruebas son:
Lectura correcta del LME: Comprende la descripcin general del escenario de
aprendizaje, los roles generados, y la descripcin del flujo de aprendizaje.
Cantidad de instancias generadas de cada actividad: Para cada actividad,
deben generarse n cantidad de instancias, dependiendo del rol del alumno y si
la actividad es individual o colaborativa.
Estado del proceso de aprendizaje para cada alumno: Despus de que ciertos alumnos ejecutan determinada cantidad de actividades, el estado de cada
alumno debe ser nico para cada uno de acuerdo a su estado en el flujo de
aprendizaje, dependiendo de las actividades que cada uno ejecut.
Para esta evaluacin, se considera el escenario de aprendizaje E1: Mdulo 2Diseo de una estrategia tecnolgica. Dicho escenario se presenta en la figura 5.2. Este
escenario es un extracto de la materia Administracin de la Innovacin y Procesos de
Negocio en su versin enero-marzo 2011, de la Universidad Virtual del Tecnolgico de
Monterrey, diseado por el Dr. Macedonio Alans Gonzlez en el sistema Blackboard.
Figura 5.2: Escenario de aprendizaje E1

En el lenguaje LPCEL, el escenario se describe de la siguiente forma:
51
52
53
<?xml version="1.0" encoding="UTF-8"?>

<LPCEL xsi:noNamespaceSchemaLocation="lpcel.xsd" xmlns:xsi="http:
//www.w3.org/2001/XMLSchema-instance">
<Feature>Este curso busca un enfoque prctico, el anlisis de
situaciones reales, y la aplicacin de dichos conceptos, con
137
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
la finalidad de enfrentar de una manera ms efectiva los retos

que las organizaciones tienen hoy en da.</Feature>
<Aims>
<Aim id="AIM_1">
<Learning-Objective id="LRNO_1">
<Title>Estructurar estrategias tecnolgicas</Title>
<Description>Estructurar estrategias tecnolgicas que permitan
la supervivencia y competitividad de la empresa a travs
de una administracin efectiva y una estrategia empresarial
tecnolgica.</Description>
</Learning-Objective>
</Aim>
<Aim id="AIM_2">
<Title>Determinar estrategias tecnolgicas</Title>
<Description>Determinar la mejor estrategia tecnolgica que
permita apoyar y potenciar las capacidades de las personas,
cultura y estructura administrativa.</Description>
</Aim>
<Aim id="AIM_3">
<Title>Identifcar procesos</Title>
<Description>Identificar el proceso para disear, implementar
y analizar las implicaciones de las innovaciones
tecnolgicas en las organizaciones, como una herramienta
para aumentar la competitividad de las mismas. </
Description>
</Aim>
<Aim id="AIM_4">
<Title>Generar proyectos</Title>
<Description>Generar proyectos y planes tecnolgicos retadores
y acordes a los avances que se presenten en el rea de la
innovacin tecnolgica. </Description>
</Aim>
</Aims>
138
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
<Roles>
<Role id="ROL_1">
<Title>Alumno</Title>
<RoleHierarchy>
<Role id="ROL_2">
<Title>Miembro de equipo</Title>
</Role>
</RoleHierarchy>
</Role>
<Role id="ROL_3">
<Title>Profesor</Title>
<Description>El profesor titular del curso</Description>
<Cardinality>1</Cardinality>
</Role>
</Roles>
<Complex-Learning-Process>
<Component-CLP idAim="AIM_2" id="ID_1" >
<Title>Mdulo 2: Diseo de una estrategia tecnolgica</Title>
<Complex-Component>
<Sequence>
<Component-CLP id="ID_2">
<Basic-Component>
<Action>
<Component-Activity id="ID_3">
<Learning-Activity>
<Title>Identifica las ideas relevantes del mdulo 2</
Title>
<Status></Status>
<Resources id="R_1">
<Learning-Object>
<Access-Method>
<Local-Access>Recursos de apoyo/Mdulo 2/
Presentacion2.pdf</Local-Access>
</Access-Method>
</Learning-Object>
</Resources>
</Learning-Activity>
</Component-Activity>
</Action>
139
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
</Basic-Component>
</Component-CLP>
<Basic-Component>
<Action>
<Learning-Activity>
<Title>Realiza las lecturas de la semana</Title>
<Status></Status>
<Learning-Object>
<Access-Method>
<Local-Access>Captulo2.pdf</Local-Access>
</Access-Method>
</Learning-Object>
</Resources>
</Learning-Activity>
</Action>
</Basic-Component>
</Component-CLP>
<Basic-Component>
<Action>
<Component-Activity id="ID_7" individual="false">
<Assessment-Activity>
<Title>Entrega fase 1 del proyecto</Title>
<Status></Status>
<Grade></Grade>
<Learning-Service>
<Access-Method>
<Remote-access>
<Link-based>http://apps03.ruv.itesm.mx:8080/
operaciones/sistareas/alumnos/</Link-based>
</Remote-access>
</Access-Method>
</Learning-Service>
</Resources>
140
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
</Assessment-Activity>
</Action>
</Basic-Component>
</Component-CLP>
<Basic-Component>
<Action>
<Assessment-Activity>
<Title>Realizar la coevaluacin del proyecto fase 1</
Title>
<Status></Status>
<Grade></Grade>
<Learning-Service>
<Access-Method>
<Remote-access>
<Link-based>enlacepro.ruv.itesm.mx</Link-based>
</Remote-access>
</Access-Method>
</Learning-Service>
</Resources>
</Assessment-Activity>
</Action>
</Basic-Component>
</Component-CLP>
</Sequence>
</Complex-Component>
</Component-CLP>
</Complex-Learning-Process>
<Operations>
<Operation id="OP_1">
<Title>Ejecutar</Title>
</Operation>
</Operations>
<Assignments>
141
192
193
194
195
196
197
<Assignment executeOnComponentCLP="ID_2"
permOperation="OP_1"/>
</Assignments>
</LPCEL>
5.1.1.
roleAssignment="ROL_1"
Lectura correcta del LME
Para validar la lectura correcta del LME en el motor de ejecucin, es necesario

publicar el script de LPCEL arriba presentado en el motor. Esto lo hace el diseador
instruccional a travs de la interface lpcel def (ver figura 4.2). Posteriormente es
necesario crear la ejecucin de la publicacin. Para ello, un usuario profesor selecciona la publicacin y crea la ejecucin del escenario. Entonces el motor vaca la
informacin del script en el modelo de informacin (ver figura 4.4) y genera las instancias necesarias para cada actividad. En la figura 5.3 se muestra una captura de
pantalla del motor de ejecucin con la informacin general de la ejecucin.
Como puede observarse, la descripcin general del escenario de aprendizaje ha
sido recuperada de manera correcta, al mostrarse en pantalla, cada uno de los elementos descritos en el script de LPCEL como las caractersticas, requisitos y objetivos.
En cuanto a la generacin de roles, se puede ver que el motor genera el rol Alumno,
el rol Miembro de equipo que hereda al rol Alumno, y el rol Profesor. Estos roles
fueron ledos del script de LPCEL de forma exitosa.
Por ltimo, la descripcin del flujo de aprendizaje tambin se hace de forma correcta. El script del LME describe la secuencia de las cuatro actividades presentadas
en la figura 5.2, mismas que son desplegadas por el motor como una secuencia de
actividades en el mismo orden en que se definieron en el escenario de aprendizaje
original.
142
Figura 5.3: Publicacin del escenario E1 en el motor

En resumen, los resultados de las pruebas de lectura pueden observarse en la
tabla 5.1. A continuacin se presentan los resultados de las instancias generadas de
cada actividad.
Escenario
E1
Descripcin general del

escenario de aprendizaje
Caractersticas, requisitos, objetivos (Correcto)
Roles generados
3 de 3
Descripcin del flujo de

aprendizaje
Secuencia de 4 actividades (Correcto)
Tabla 5.1: Lectura correcta del LME
5.1.2.
Cantidad de instancias generadas de cada actividad
Para cada actividad deben generarse n cantidad de instancias, dependiendo del

rol del alumno y si la actividad es individual o colaborativa. Para actividades que
son individuales, debe generarse una instancia de la actividad para cada participante
143
que tenga el rol indicado por la actividad. Para actividades en equipo, nicamente
debe generarse una instancia de la actividad para el equipo completo.
Para validar la cantidad de instancias generadas, es necesario inscribir participantes en la ejecucin, asignarles roles, y crear los equipos de trabajo para la ejecucin. Posteriormente, es necesario cerrar las inscripciones al curso, para que el motor
genere las instancias necesarias de cada actividad. Para los efectos de esta evaluacin, se crearn los equipos 1 y 2, y se inscribirn los participantes que se muestran
a continuacin en formato NOMBRE :[EQUIPO-]ROL:
Usuario1: Alumno, Equipo1 - Miembro de equipo
Usuario9: Profesor
En la tabla 5.2, se muestran los resultados de la cantidad de instancias generadas
para cada actividad. En la tabla las actividades se identifican de la siguiente forma:
(A1) Identifica las ideas relevantes del mdulo 2, (A2) Realiza las lecturas de la
semana, (A3) Entrega fase 1 del proyecto, (A4) Realizar la coevaluacin del proyecto
fase 1.
5.1.3.
Estado del proceso de aprendizaje para cada alumno
Despus de que los alumnos ejecutan actividades y avanzan en su flujo de aprendizaje, el estado del flujo de aprendizaje de cada alumno cambia de acuerdo a su
144
Actividad
A1
A2
A3
A4
Instancias
Individual o colaborativa Esperadas Generadas
Individual
8
8
Individual
8
8
Colaborativa
2
2
Individual
8
8
Total de instancias generadas: 26 de 26
Resultado
Correcto
Correcto
Correcto
Correcto
Correcto
Tabla 5.2: Instancias generadas de cada actividad

avance, sin afectar el flujo de aprendizaje de los dems, excepto en las actividades
colaborativas, las cuales s tienen un impacto directo en el flujo del aprendizaje de
los compaeros de equipo.
Para realizar esta evaluacin, se considera el siguiente avance para cada alumno.
Considere el nmero 1 como un indicador de que el alumno ejecut la actividad, y el
nmero 0 como un indicador de que la actividad no ha sido ejecutada por el alumno.
Usuario1: A1(1), A2(1), A3(0), A4(0)
Usuario2: A1(1), A2(1), A3(1), A4(0)
Usuario3: A1(1), A2(1), A3(0), A4(1)
Usuario4: A1(1), A2(0), A3(0), A4(0)
Usuario5: A1(1), A2(0), A3(0), A4(0)
Usuario6: A1(1), A2(1), A3(0), A4(0)
Usuario7: A1(0), A2(0), A3(0), A4(0)
Usuario8: A1(1), A2(1), A3(0), A4(0)
A continuacin en la tabla 5.3 se muestra el estado en el flujo de aprendizaje de
cada alumno. En la tabla se marcan con una C las actividades completadas por
cada alumno, con una D las actividades disponibles para realizar, y las actividades
que no tienen ninguna marca son aquellas no disponibles para el alumno por no tener
realizadas las actividades anteriores.
145
Usuario1
Usuario2
Usuario3
Usuario4
Usuario5
Usuario6
Usuario7
Usuario8
A1
C
C
C
C
C
C
D
C
A2
C
C
C
D
D
C
A3
C
C
C
C
A4
D
D
C
Tabla 5.3: Estado del flujo de aprendizaje individual

Con lo anterior se demuestra la capacidad del motor de mantener el estado del
flujo de aprendizaje personalizado por cada usuario, y hacer la entrega de contenidos
y actividades de acuerdo al avance del alumno, lo cual es una diferencia significativa
con respecto a otros LMS. En Moodle o Blackboard por ejemplo, nicamente se
tienen dos tipos de control sobre los contenidos y actividades. El primero es por
tiempo, i.e. un contenido se publica a partir de determinada fecha y hora y por
determinado tiempo; y el segundo por la publicacin o eliminacin del contenido por
parte del equipo docente. Sin embargo, en estos sistemas no existe un control para
el flujo de aprendizaje individual como tal.
En el caso del motor CopperCore de IMS LD, ste tiene la capacidad de mantener
el estado del flujo de aprendizaje para cada participante, sin embargo esta capacidad
es nicamente para las actividades individuales.
Hasta este punto, terminan las evaluacin E1 Ejecucin de un LME. La siguiente
evaluacin es sobre capacidad para navegar y ejecutar de procesos con estructuras
complejas de aprendizaje.
5.2.
E2. Navegacin y ejecucin de proceso
La segunda evaluacin denominada E2 Navegacin y ejecucin de proceso, complementa la evaluacin E1 para evaluar si se cumpli el objetivo de investigacin O1
Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a travs de
un LME. De manera especfica, esta evaluacin se enfoca en evaluar la ejecucin de
un proceso de aprendizaje con estructuras complejas a travs de pruebas funcionales
146
5.2. E2. Navegacin y ejecucin de proceso
en diversos escenarios de aprendizaje. La finalidad de estas pruebas es demostrar

que los modelos que se proponen para el diseo de un motor de ejecucin, tienen la
capacidad para ejecutar estructuras de actividades en diversos patrones de control
de flujos de trabajo.
Esta evaluacin valida las contribuciones C2 Modelo de informacin del motor de
ejecucin, C3 Modelo de instanciacin de actividades, y C4 Modelo de ejecucin de
actividades; para brindar una solucin a los problemas P1 Dificultad para ejecutar
estructuras de aprendizaje complejas, y P2 Complejo manejo de roles y asignacin
de tareas. En la figura 5.4, se muestran las relaciones entre esta evaluacin, las
contribuciones, objetivos y problemas de manera grfica.

La validacin de estas pruebas se hace con base en los patrones de control de
flujos de trabajo presentados en la seccin 2.5.1. Para ello, se tomar un escenario
de aprendizaje para cada patrn. A continuacin, se presenta la evaluacin de cada
uno de los patrones de flujos de trabajo.
5.2.1.
Secuencia
Para evaluar la navegacin en el proceso de aprendizaje de una secuencia, se toma

el mismo escenario de aprendizaje que se present en la evaluacin E1 (ver seccin
147
5.1), el cual puede observarse en notacin BPMN en la figura 5.5, donde A1, A2, A3
y A4, representan las actividades del flujo de aprendizaje.
Figura 5.5: Escenario de aprendizaje E2-Secuencia

A continuacin en la tabla 5.4, se muestra cada uno de los estados de la navegacin
del proceso de la secuencia de aprendizaje, para el usuario Usuario1. En la tabla,
la letra C indica que el alumno complet la actividad, la letra D indica que
la actividad est disponible para poder realizarse, y las actividades que no tienen
ninguna letra son aquellas no disponibles para el alumno por cuestiones del flujo de
control.
Como puede observarse, el patrn secuencia se ejecuta de manera correcta y se
puede navegar en el proceso de manera exitosa. A continuacin se presenta el patrn
separacin paralela.
148
Usuario1
Estado inicial
Completa A1
Completa A2
Completa A3
Completa A4
A1
D
C
C
C
C
A2
A3
A4
D
C
C
C
D
C
C
D
C
Tabla 5.4: Navegacin de proceso: Secuencia
5.2.2.
Separacin paralela
En la evaluacin de la navegacin en el proceso de aprendizaje de una separacin paralela, se tomar el escenario de aprendizaje que se muestra en la figura
5.6 en notacin BPMN, donde A1, A2 y A3, representan las actividades del flujo de
aprendizaje.
A continuacin en las tablas 5.5, 5.6 y 5.7, se muestra cada uno de los estados
de la navegacin del proceso de la separacin paralela en tres diferentes casos, para
el usuario Usuario1. El primer caso ocurre cuando Usuario1 decide ejecutar despus
de la actividad A1, la actividad A2 y posteriormente A3. El segundo caso ocurre
cuando Usuario1 decide ejecutar despus de la actividad A1, la actividad A3 y posteriormente la A2. El tercer caso ocurre cuando Usuario1 decide ejecutar la despus
de la actividad A1, la actividad A2 y simultneamente un miembro de su equipo
ejecuta la actividad A3.
Usuario1
Estado inicial
Completa A1
Completa A2
Completa A3
A1
D
C
C
C
A2
A3
D
C
C
D
D
C
Tabla 5.5: Navegacin de proceso: Separacin paralela - Caso 1

Usuario1
Estado inicial
Completa A1
Completa A3
Completa A2
A1
D
C
C
C
A2
A3
D
D
C
D
C
C
149
Usuario1
Estado inicial
Completa A1
Completa A2 y A3
A1
D
C
C
A2
A3
D
C
D
C

En la tabla, la letra C indica que el alumno complet la actividad, la letra D
indica que la actividad est disponible para poder realizarse, y las actividades que
no tienen ninguna letra son aquellas no disponibles para el alumno por cuestiones
del flujo de control.
Como puede observarse, el patrn separacin paralela se ejecuta de manera correcta y se puede navegar en el proceso de manera exitosa. A continuacin se presenta
el patrn sincronizacin.
5.2.3.
Sincronizacin
Para la evaluacin de la navegacin en el proceso de aprendizaje del patrn

sincronizacin, se utiliza el escenario de aprendizaje que se muestra en la figura 5.7
en notacin BPMN, donde A2, A3 y A4, representan las actividades del flujo de
aprendizaje.
de la navegacin del proceso del patrn sincronizacin en tres diferentes casos, para
el usuario Usuario1. El primer caso ocurre cuando Usuario1 decide ejecutar primero
la actividad A2, posteriormente la actividad A3, para entonces poder llevar a cabo la
actividad A4. El segundo caso ocurre cuando Usuario1 decide primero la actividad
A3, posteriormente la A2, para despus poder ejecutar A4. El tercer caso ocurre
cuando Usuario1 ejecuta la actividad A2 y simultneamente un miembro de su
equipo ejecuta la actividad A3, entonces Usuario1 puede ejecutar A4.
En la tabla, la letra C indica que el alumno complet la actividad, la letra D
150
Usuario1
Estado inicial
Completa A2
Completa A3
Completa A4
A2
D
C
C
C
A3
D
D
C
C
A4
D
C
Tabla 5.8: Navegacin de proceso: Sincronizacin - Caso 1

Usuario1
Estado inicial
Completa A3
Completa A2
Completa A4
A2
D
D
C
C
A3
D
C
C
C
A4
D
C

Como puede observarse, el patrn sincronizacin se ejecuta de manera correcta
y se puede navegar en el proceso de manera exitosa. A continuacin se presenta el
patrn eleccin exclusiva.
5.2.4.
Eleccin Exclusiva
Para la evaluacin de la navegacin en el proceso de aprendizaje en una eleccin

exclusiva, se utiliza el escenario de aprendizaje que se muestra en la figura 5.8 en
notacin BPMN, donde A1, A2, A3 y A4, representan las actividades del flujo de
aprendizaje.
de la navegacin del proceso cuando se intenta navegar a travs del patrn eleccin
exclusiva en tres diferentes casos para el usuario Usuario1, todos los casos parten de
que la primera actividad ejecutada fue A1. El primer caso ocurre cuando Usuario1
decide ejecutar la actividad A2. El segundo caso ocurre cuando Usuario1 decide
ejecutar la actividad A3. El tercer caso ocurre cuando Usuario1 decide ejecutar la
actividad A4.
En las tablas, la letra C indica que el alumno complet la actividad, la letra D
151
Usuario1
Estado inicial
Completa A2 y A3
Completa A4
A2
D
C
C
A3
D
C
C
A4
D
C

Usuario1
Estado inicial
Completa A1
Completa A2
A1
D
C
C
A2
A3
A4
D
C
D
D
Se esperaba: No disponible
D
D
Tabla 5.11: Navegacin de proceso: Eleccin exclusiva - Caso 1
Como puede observarse, el patrn de eleccin exclusiva se ejecuta y se puede

navegar en el proceso, slo de manera parcial. Esto debido a que una vez que el
participante realiza una actividad, el motor deja disponibles el resto de las actividades
alternativas, en lugar de inhabilitarlas. Desde el punto de vista pedaggico, para el
caso de las actividades de aprendizaje, esta situacin no tiene un impacto negativo en
el aprendizaje del alumno si se trata de actividades de aprendizaje, puesto que aunque
el alumno haya decidido realizar una actividad, los recursos de aprendizaje de las
actividades alternativas seguirn disponibles para que el alumno pueda consultarlos y
hacer uso de ellos, reforzando el aprendizaje. El nico impacto negativo sera para el
profesor si las actividades en el flujo de aprendizaje fueran actividades de evaluacin,
y de acuerdo al diseo de su curso, el alumno slo deba ejecutar especficamente una
de las actividades de evaluacin.
El patrn de eleccin exclusiva se puede lograr mejorando el modelo de ejecucin
de actividades, para que en el caso de una situacin de eleccin exclusiva, una vez que
el participante haya escogido la actividad que va a desempear, el motor inhabilite
el resto de las instancias de actividad en las ramas de flujo de aprendizaje que no
fueron activadas.
A continuacin se presenta el patrn de combinacin sencilla.
152
Usuario1
Estado inicial
Completa A1
Completa A3
A1
D
C
C
A2
A3
A4
D
D
D
C
D
D

Usuario1
Estado inicial
Completa A1
Completa A3
A1
D
C
C
A2
A3
A4
D
D
D
D
D
C
5.2.5.
Combinacin Sencilla
En una combinacin sencilla, para evaluar la navegacin en el proceso de aprendizaje se utiliza el escenario de aprendizaje que se muestra en la figura 5.9 en notacin
BPMN, donde A2, A3, A4 y A5, representan las actividades del flujo de aprendizaje.
de la navegacin del proceso del patrn combinacin sencilla en tres diferentes casos
para el usuario Usuario1. El primer caso ocurre cuando Usuario1 decide ejecutar la
actividad A2. El segundo caso ocurre cuando Usuario1 decide ejecutar la actividad
A3. El tercer caso ocurre cuando Usuario1 decide ejecutar la actividad A4.
Usuario1
Estado inicial
Completa A2
Completa A5
A2
D
C
C
A3
D
D
D
A4
D
D
D
A5
D
C
Tabla 5.14: Navegacin de proceso: Combinacin sencilla - Caso 1

153
Usuario1
Estado inicial
Completa A3
Completa A5
A2
D
D
D
A3
D
C
C
A4
D
D
D
A5
D
C

Usuario1
Estado inicial
Completa A4
Completa A5
A2
D
D
D
A3
D
D
D
A4
D
C
C
A5
D
C

Como puede observarse, el patrn de combinacin sencilla se ejecuta de manera
correcta y se puede navegar en el proceso de manera exitosa. A continuacin se
presenta el patrn eleccin mltiple.
5.2.6.
Eleccin mltiple

mltiple, se utiliza el escenario de aprendizaje que se muestra en la figura 5.10 en
aprendizaje.
de la navegacin del proceso del patrn eleccin mltiple en tres diferentes casos para
el usuario Usuario1, todos los casos parten de que la primera actividad ejecutada
fue A1. El primer caso ocurre cuando Usuario1 decide ejecutar la actividad A2. El
segundo caso ocurre cuando Usuario1 decide ejecutar las actividades A2 y A3. El
tercer caso ocurre cuando Usuario1 decide ejecutar las actividades A2, A3 y A4.
Usuario1
Estado inicial
Completa A1
Completa A2
A1
D
C
C
A2
A3
A4
D
C
D
D
D
D
Tabla 5.17: Navegacin de proceso: Eleccin mltiple - Caso 1
154
Usuario1
Estado inicial
Completa A1
Completa A2 y A3
A1
D
C
C
A2
A3
A4
D
C
D
C
D
D

Usuario1
Estado inicial
Completa A1
Completa A2, A3 y A4
A1
D
C
C
A2
A3
A4
D
C
D
C
D
C

Como puede observarse, el patrn de eleccin mltiple se ejecuta de manera
correcta y se puede navegar en el proceso de manera exitosa. A continuacin se
presenta el patrn combinacin estructurada y sincronizada.
5.2.7.
Combinacin estructurada y sincronizada
En una combinacin estructurada y sincronizada, para evaluar la navegacin en

el proceso de aprendizaje se utiliza el escenario de aprendizaje que se muestra en la
figura 5.11 en notacin BPMN, donde A2, A3, A4 y A5, representan las actividades
del flujo de aprendizaje. La combinacin y sincronizacin de las actividades depende
de la condicin establecida en tiempo de diseo por el diseador instruccional. La
condicin de sincronizacin se establece con base en n actividades que deben completarse para poder continuar con la siguiente actividad en el flujo de aprendizaje.
de la navegacin del proceso del patrn combinacin estructurada y sincronizada en
tres diferentes casos para el usuario Usuario1. El primer caso tiene como condicin
de sincronizacin completar una actividad; en este contexto Usuario1 decide ejecutar
la actividad A2. El segundo caso tiene como condicin de sincronizacin completar
155
dos actividades; en este contexto Usuario1 decide ejecutar la actividad A2 y posteriormente la actividad A3. El tercer caso tiene como condicin de sincronizacin
completar tres actividades; en este contexto Usuario1 decide ejecutar la actividad
A2, posteriormente la actividad A3, y despus la actividad A4.
Usuario1
Estado inicial
Completa A2
Completa A5
A2
D
C
C
A3
D
D
D
A4
D
D
D
A5
D
C
Tabla 5.20: Navegacin de proceso: Combinacin estructurada y sincronizada - Caso

1
Usuario1
Estado inicial
Completa A2
Completa A3
Completa A5
A2
D
C
C
C
A3
D
D
C
C
A4
D
D
D
D
A5
D
C

2
Usuario1
Estado inicial
Completa A2
Completa A3
Completa A4
Completa A5
A2
D
C
C
C
C
A3
D
D
C
C
C
A4
D
D
D
C
C
A5
D
C

3
Como puede observarse, el patrn de combinacin estructurada y sincronizada se
ejecuta de manera correcta y se puede navegar en el proceso de manera exitosa. A
continuacin se presenta el patrn combinacin mltiple.
156
5.2.8.
Combinacin mltiple

mltiple, se utiliza el escenario de aprendizaje que se muestra en la figura 5.10 en
aprendizaje.
El patrn de combinacin mltiple no se puede ejecutar con el modelo de ejecucin de actividades actual. Desde un punto de vista pedaggico, este patrn es
raro que se disee en un proceso de aprendizaje, esto debido a que al hacer una
combinacin mltiple de diferentes actividades, el control del flujo se multiplica en la
rama principal una vez que se hace la combinacin, y difcilmente el o los estudiantes
estaran ejecutando el flujo de aprendizaje ms de una vez; en este caso para recobrar
el sentido pedaggico, el escenario de aprendizaje necesitara de un mecanismo de
sincronizacin para eliminar los mltiples flujos de control. Desde la perspectiva del
diseo del escenario de aprendizaje, el mismo escenario podra lograrse sin perder los
objetivo pedaggicos, si en cada rama despus de las actividades A1, A2 y A3, se
agrega la actividad A4 y posteriormente se hace una combinacin estructurada de
todas ramas.
El patrn de combinacin mltiple podra lograrse mejorando el modelo de ejecucin de actividades. A continuacin se presentan las pruebas funcionales del patrn
discriminador estructurado.
5.2.9.
Discriminador estructurado
Para evaluar la navegacin en el patrn discriminador estructurado, en un proceso

de aprendizaje se utiliza el escenario de aprendizaje que se muestra en la figura 5.13
en notacin BPMN, donde A2, A3, A4 y A5, representan las actividades del flujo de
aprendizaje.
de la navegacin del proceso del patrn discriminador estruturado en tres diferentes
casos para el usuario Usuario1. En el primer caso Usuario1 decide ejecutar la actividad A2, posteriormente la actividad A5, y despus las actividades A3 y A4. En el
segundo caso Usuario1 decide ejecutar la actividad A2, posteriormente la actividad
157
A3, despus A5, y por ltimo A4. En el tercer caso Usuario1 decide ejecutar las
actividades A2, A3, y A4, y posteriormente la actividad A5.
Usuario1
Estado inicial
Completa A2
Completa A5
Completa A3
Completa A4
A2
D
C
C
C
C
A3
D
D
D
C
C
A4
D
D
D
D
C
A5
D
C
C
C
Tabla 5.23: Navegacin de proceso: Discriminador estructurado - Caso 1
Usuario1
Estado inicial
Completa A2
Completa A3
Completa A5
Completa A4
A2
D
C
C
C
C
A3
D
D
C
C
C
A4
D
D
D
D
C
A5
D
D
C
C
Usuario1
Estado inicial
Completa A2
Completa A3
Completa A4
Completa A5
A2
D
C
C
C
C
A3
D
D
C
C
C
A4
D
D
D
C
C
A5
D
D
D
C

Como puede observarse, el patrn discrimandor estructurado se ejecuta de manera correcta y se puede navegar en el proceso de manera exitosa. A continuacin se
presenta el patrn ciclo estructurado.
158
5.2.10.
Ciclo estructurado
Para la evaluacin de la navegacin en el proceso de aprendizaje con un patrn de

ciclo estructurado, se utiliza el escenario de aprendizaje que se muestra en la figura
5.14 en notacin BPMN, donde A1, A2, y A3, representan las actividades del flujo
de aprendizaje.
El patrn de ciclo estructurado no fue considerado en el modelo de ejecucin de
actividades actual. Sin embargo, el patrn podra ejecutarse mejorando el modelo de
ejecucin de actividades. A continuacin se presentan los resultados condensados de
las pruebas funcionales de navegacin de proceso.
5.2.11.
Resultados
Hasta este punto, se presentaron las pruebas funcionales de navegacin de proceso, para cada uno de los patrones de control de flujos de trabajo presentados en
la seccin 2.5.1. En la tabla 5.26, se muestran los resultados condensados de dichas
pruebas. Para cada patrn se indica con el smbolo +, si el patrn es soportado por
el modelo de ejecucin de actividades del motor de ejecucin; con el smbolo si el
patrn es parcialmente soportado; y con el smbolo - si el patrn no est soportado.
Patrn de control de flujo de trabajo
Secuencia
Separacin paralela
Sincronizacin
Eleccin exclusiva
Combinacin Sencilla
Eleccin mltiple
Combinacin mltiple
Ciclo estructurado
Capacidad de ejecucin
+
+
+
+
+
+
+
-
Tabla 5.26: E2 Navegacin y ejecucin de proceso

En conclusin, el motor es capaz de ejecutar la mayora de las estructuras complejas de aprendizaje, cumpliendo de esta forma con el objetivo de investigacin O1.
El modelo de ejecucin de actividades, si bien an no soporta la expresividad del
159
lenguaje LPCEL al cien por ciento, es claramente ms expresivo y con mayor capacidad que los lenguajes IMS LD y LAMS, y sus respectivos ambientes de ejecucin.
Lo cual tiene un impacto positivo para poder ejecutar PACs.
En la siguiente seccin, se presenta la evaluacin E3 Instanciacin de actividades.
160
Figura 5.6: Escenario de aprendizaje E2-Separacion Paralela
161
Figura 5.7: Escenario de aprendizaje E2-Sincronizacin
162
Figura 5.8: Escenario de aprendizaje E2-Eleccin exclusiva
163
Figura 5.9: Escenario de aprendizaje E2-Combinacin sencilla
164
Figura 5.10: Escenario de aprendizaje E2-Eleccin mltiple
165
Figura 5.11: Escenario de aprendizaje E2-Combinacin estructurada y sincronizada
166
Figura 5.12: Escenario de aprendizaje E2-Combinacin mltiple
167
Figura 5.13: Escenario de aprendizaje E2-Discriminador estructurado
168
Figura 5.14: Escenario de aprendizaje E2-Ciclo estructurado
169
5.3.
E3. Instanciacin de actividades
La tercera evaluacin denominada E3 Instanciacin de actividades, complementa

las evaluaciones E1 y E2 para evaluar si se cumpli el objetivo de investigacin O1
Ejecutar un proceso de aprendizaje con estructuras complejas, descrito a travs de
un LME. De manera especfica, esta evaluacin se enfoca en verificar que el modelo
de instanciacin tiene la capacidad de generar las instancias de actividades necesarias
para soportar de manera completa y correcta, patrones de control de flujos de trabajo.
Esta evaluacin valida la contribucin C3 Modelo de instanciacin de actividades,
para brindar una solucin a los problemas P1 Dificultad para ejecutar estructuras
de aprendizaje complejas, y P2 Complejo manejo de roles y asignacin de tareas. En
la figura 5.15, se muestran las relaciones entre esta evaluacin, las contribuciones,
objetivos y problemas de manera grfica.

La evaluacin E3 se har a travs de pruebas de factibilidad tomando los mismos
escenarios que la evaluacin E2 Navegacin y ejecucin de proceso, para cada patrn
170
5.3. E3. Instanciacin de actividades
de control de flujos de trabajo. Para esta evaluacin es necesario tambin considerar

la cantidad de participantes en el proceso de aprendizaje, por lo que se consideran
los mismos participantes inscritos que en la evaluacin E1 Ejecucin de un LME.
Recapitulando, se tienen para cada escenario de aprendizaje los siguientes roles para
cada partipante:
Usuario9: Profesor
A continuacin, se presenta la evaluacin de la instanciacin para cada uno de
los patrones de flujos de trabajo.
5.3.1.
Secuencia
Para evaluar la instanciacin de actividades de una secuencia de actividades de

aprendizaje, se usa el escenario que se muestra en la figura 5.16, el cual es similar al
escenario presentado en la evaluacin E2 para el patrn secuencia. De este escenario
de aprendizaje, se tiene que A1, A2, A3 y A4, representan las actividades del flujo
de aprendizaje, de las cuales A1, A2 y A4 son actividades individuales, y A3 es una
actividad en equipo.
A continuacin en la tabla 5.27, se muestran los resultados de la prueba de
factibilidad para el patrn secuencia. En la tabla por cada actividad se muestra el
171
Figura 5.16: Escenario de aprendizaje E3-Secuencia
tipo de actividad, las instancias esperadas de la actividad, la instancias generadas, y

en la ltima fila, la cantidad total de instancias de actividad esperadas, generadas,
y si existe factibilidad de ejecucin del patrn en lo que se refiere al nmero de
instancias.
Actividad
Tipo de actividad
A1
A2
A3
A4
Total
Individual
Individual
Equipo
Individual
Factibilidad de ejecucin: S
Instancias
esperadas
8
8
2
8
26
Instancias
generadas
8
8
2
8
26
Tabla 5.27: Instanciacin de actividades: Secuencia

Como puede observarse, el modelo de instanciacin tiene la capacidad de generar
las instancias necesarias para ejecutar un escenario de aprendizaje con el patrn
secuencia. A continuacin, se presentan las pruebas de factibilidad para el patrn
separacin paralela.
172
5.3.2.
Separacin paralela
Para evaluar la instanciacin de actividades de una separacin paralela, se usa el

escenario que se muestra en la figura 5.17, el cual es similar al escenario presentado en
la evaluacin E2 para el patrn separacin paralela. De este escenario de aprendizaje,
se tiene que A1, A2, y A3, representan las actividades del flujo de aprendizaje, de
las cuales A1 y A2 son actividades individuales, y A3 es una actividad en equipo.
Figura 5.17: Escenario de aprendizaje E3-Separacin paralela

factibilidad para el patrn separacin paralela. En la tabla por cada actividad se
muestra el tipo de actividad, las instancias esperadas de la actividad, la instancias
generadas, y en la ltima fila, la cantidad total de instancias de actividad esperadas,
generadas, y si existe factibilidad de ejecucin del patrn en lo que se refiere al
nmero de instancias.
173
Actividad
Tipo de actividad
A1
A2
A3
Total
Individual
Individual
Equipo
Instancias
esperadas
8
8
2
18
Instancias
generadas
8
8
2
18
Tabla 5.28: Instanciacin de actividades: Separacin paralela

separacin paralela. A continuacin, se presentan las pruebas de factibilidad para el
patrn sincronizacin.
5.3.3.
Sincronizacin
Para evaluar la instanciacin de actividades de una sincronizacin, se usa el escenario que se muestra en la figura 5.18, el cual es similar al escenario presentado en
la evaluacin E2 para el patrn sincronizacin. De este escenario de aprendizaje, se
tiene que A2, A3, y A4, representan las actividades del flujo de aprendizaje, de las
cuales A2 y A4 son actividades individuales, y A3 es una actividad en equipo.
factibilidad para el patrn sincronizacin. En la tabla por cada actividad se muestra
el tipo de actividad, las instancias esperadas de la actividad, la instancias generadas,
y en la ltima fila, la cantidad total de instancias de actividad esperadas, generadas,
instancias.
Actividad
Tipo de actividad
A2
A3
A4
Total
Individual
Equipo
Individual
Instancias
esperadas
8
2
8
18
Instancias
generadas
8
2
8
18
Tabla 5.29: Instanciacin de actividades: Sincronizacin
174
Figura 5.18: Escenario de aprendizaje E3-Sincronizacin

sincronizacin. A continuacin, se presentan las pruebas de factibilidad para el patrn
eleccin exclusiva.
5.3.4.
Eleccin Exclusiva
Para evaluar la instanciacin de actividades de una eleccin exclusiva, se usa el

la evaluacin E2 para el patrn eleccin exclusiva. De este escenario de aprendizaje,
se tiene que A1, A2, A3 y A4 representan las actividades del flujo de aprendizaje,
las cuales son actividades individuales.
factibilidad para el patrn eleccin exclusiva. En la tabla por cada actividad se
175
Figura 5.19: Escenario de aprendizaje E3-Eleccin exclusiva

Actividad
Tipo de actividad
A1
A2
A3
A4
Total
Individual
Individual
Individual
Individual
Instancias
esperadas
8
8
8
8
32
Instancias
generadas
8
8
8
8
32
Tabla 5.30: Instanciacin de actividades: Eleccin exclusiva

eleccin exclusiva. A continuacin, se presentan las pruebas de factibilidad para el
patrn combinacin sencilla.
176
5.3.5.
Combinacin Sencilla
Para evaluar la instanciacin de actividades de una combinacin sencilla, se usa

el escenario que se muestra en la figura 5.20, el cual es similar al escenario presentado en la evaluacin E2 para el patrn combinacin sencilla. De este escenario de
aprendizaje, se tiene que A2, A3, A4 y A5, representan las actividades del flujo de
aprendizaje, de las cuales A2, A3 y A4 son actividades individuales, y A5 es una
actividad en equipo.
Figura 5.20: Escenario de aprendizaje E3-Combinacin sencilla

factibilidad para el patrn combinacin sencilla. En la tabla por cada actividad se
177

Actividad
Tipo de actividad
A2
A3
A4
A5
Total
Individual
Individual
Individual
Equipo
Instancias
esperadas
8
8
8
2
26
Instancias
generadas
8
8
8
2
26
Tabla 5.31: Instanciacin de actividades: Combinacin sencilla

combinacin sencilla. A continuacin, se presentan las pruebas de factibilidad para
el patrn eleccin mltiple.
5.3.6.
Eleccin mltiple
Para evaluar la instanciacin de actividades de una eleccin mltiple, se usa el

la evaluacin E2 para el patrn eleccin mltiple. De este escenario de aprendizaje,
se tiene que A1, A2, A3 y A4 representan las actividades del flujo de aprendizaje,
las cuales son actividades individuales.
A continuacin en la tabla 5.32, se muestran los resultados de la prueba de factibilidad para el patrn eleccin mltiple. En la tabla por cada actividad se muestra el
tipo de actividad, las instancias esperadas de la actividad, la instancias generadas, y
en la ltima fila, la cantidad total de instancias de actividad esperadas, generadas,
instancias.
eleccin mltiple. A continuacin, se presentan las pruebas de factibilidad para el
patrn combinacin estructurada y sincronizada.
178
Figura 5.21: Escenario de aprendizaje E3-Eleccin mltiple
5.3.7.
Para evaluar la instanciacin de actividades de una combinacin estructurada y

sincronizada, se usa el escenario que se muestra en la figura 5.22, el cual es similar
al escenario presentado en la evaluacin E2 para el patrn combinacin estructurada
y sincronizada. De este escenario de aprendizaje, se tiene que A2, A3, A4 y A5,
representan las actividades del flujo de aprendizaje, de las cuales A2, A3 y A4 son
actividades individuales, y A5 es una actividad en equipo.
factibilidad para el patrn combinacin estructurada y sincronizada. En la tabla
por cada actividad se muestra el tipo de actividad, las instancias esperadas de la
actividad, la instancias generadas, y en la ltima fila, la cantidad total de instancias
de actividad esperadas, generadas, y si existe factibilidad de ejecucin del patrn en
lo que se refiere al nmero de instancias.
179
Actividad
Tipo de actividad
A1
A2
A3
A4
Total
Individual
Individual
Individual
Individual
Instancias
esperadas
8
8
8
8
32
Instancias
generadas
8
8
8
8
32
Tabla 5.32: Instanciacin de actividades: Eleccin mltiple

Actividad
Tipo de actividad
A2
A3
A4
A5
Total
Individual
Individual
Individual
Equipo
Instancias
esperadas
8
8
8
2
26
Instancias
generadas
8
8
8
2
26
Tabla 5.33: Instanciacin de actividades: Combinacin estructurada y sincronizada

combinacin estructurada y sincronizada. A continuacin, se presentan las pruebas
de factibilidad para el patrn combinacin mltiple.
5.3.8.
Combinacin mltiple
Para evaluar la instanciacin de actividades de una combinacin mltiple, se

usa el escenario que se muestra en la figura 5.23, el cual es similar al escenario
presentado en la evaluacin E2 para el patrn combinacin mltiple. De este escenario
de aprendizaje, se tiene que A1, A2, A3 y A4, representan las actividades del flujo
de aprendizaje, las cuales son actividades en equipo.
Por la complejidad de este patrn, se tiene la siguiente asignacin de roles para
este caso en particular:
Usuario1: Alumno, Equipo1 - Interfaz grfica
Usuario2: Alumno, Equipo1 - Jefe documentacin
180
Figura 5.22: Escenario de aprendizaje E3-Combinacin estructurada y sincronizada

Usuario3: Alumno, Equipo1 - Contacto con el cliente
Usuario5: Alumno, Equipo2 - Interfaz grfica
Usuario6: Alumno, Equipo2 - Jefe documentacin
Usuario7: Alumno, Equipo2 - Contacto con el cliente
Usuario9: Profesor
181
Figura 5.23: Escenario de aprendizaje E3-Combinacin mltiple

factibilidad para el patrn combinacin mltiple. En la tabla por cada actividad se
Como puede observarse, el modelo de instanciacin no tiene la capacidad de
generar las instancias necesarias para ejecutar un escenario de aprendizaje con el
patrn combinacin mltiple. Esto debido a que en la ejecucin del patrn cada vez
que una cada rama entrante llega a la actividad de combinacin, esta actividad se
182
Actividad
Tipo de actividad
A1
A2
A3
A4
Total
Equipo
Equipo
Equipo
Equipo
Factibilidad de ejecucin: No
Instancias
esperadas
2
2
2
6
12
Instancias
generadas
2
2
2
2
8
Tabla 5.34: Instanciacin de actividades: Combinacin mltiple

activa, por lo que la actividad debe instanciarse ms veces de las que se pueden
generar a travs del modelo definido. Adems cabe destacar, como se mencion en la
evaluacin E2 Navegacin y ejecucin de proceso, desde un punto de vista pedaggico,
este patrn es raro que se presente en un proceso de aprendizaje, esto debido a que
al hacer una combinacin mltiple de diferentes actividades, el control del flujo se
multiplica en la rama principal una vez que se hace la combinacin, y difcilmente
el o los estudiantes estaran ejecutando el flujo de aprendizaje ms de una vez; en
este caso para recobrar el sentido pedaggico, el escenario de aprendizaje necesitara
de un mecanismo de sincronizacin para eliminar los mltiples flujos de control.
Desde la perspectiva del diseo del escenario de aprendizaje, el mismo escenario
podra lograrse sin perder los objetivo pedaggicos, si en cada rama despus de las
actividades A1, A2 y A3, se agrega la actividad A4 y posteriormente se hace una
combinacin estructurada de todas ramas.
A continuacin, se presentan las pruebas de factibilidad para el patrn discriminador estructurado.
5.3.9.
Para evaluar la instanciacin de actividades en el patrn discriminador estructurado, se usa el escenario que se muestra en la figura 5.24, el cual es similar al
escenario presentado en la evaluacin E2 para el patrn discriminador estructurado. De este escenario de aprendizaje, se tiene que A2, A3, A4 y A5, representan
las actividades del flujo de aprendizaje, de las cuales A2, A3 y A4 son actividades
individuales, y A5 es una actividad en equipo.
183
Figura 5.24: Escenario de aprendizaje E3-Discriminador estructurado

factibilidad para el patrn combinacin estructurada y sincronizada. En la tabla
por cada actividad se muestra el tipo de actividad, las instancias esperadas de la
actividad, la instancias generadas, y en la ltima fila, la cantidad total de instancias
de actividad esperadas, generadas, y si existe factibilidad de ejecucin del patrn en
lo que se refiere al nmero de instancias.
discriminador estructurado. A continuacin, se presentan las pruebas de factibilidad
para el patrn ciclo estructurado.
184
Actividad
Tipo de actividad
A2
A3
A4
A5
Total
Individual
Individual
Individual
Equipo
Instancias
esperadas
8
8
8
2
26
Instancias
generadas
8
8
8
2
26
Tabla 5.35: Instanciacin de actividades: Discriminador estructurado
5.3.10.
Ciclo estructurado
Para evaluar la instanciacin de actividades en el patrn ciclo estructurado, se

usa el escenario que se muestra en la figura 5.25, el cual es similar al escenario
presentado en la evaluacin E2 para el patrn ciclo estructurado. De este escenario
de aprendizaje, se tiene que A1, A2, y A3, representan las actividades del flujo de
aprendizaje, las cuales son actividades en equipo.
Figura 5.25: Escenario de aprendizaje E3-Ciclo estructurado
185
Por la complejidad de este patrn, se tiene la siguiente asignacin de roles para

este caso en particular:
Usuario1: Alumno, Equipo1 - Aseguramiento de calidad
Usuario3: Alumno, Equipo1 - Programacin
Usuario9: Profesor
factibilidad para el patrn ciclo estructurado. En la tabla por cada actividad se
Actividad
Tipo de actividad
A1
A2
Equipo
Equipo
A3
Equipo
Total
Factibilidad de ejecucin: No
Instancias
esperadas
2
Depende del
nmero de
ciclos
Depende del
nmero de
ciclos
Variable
Instancias
generadas
2
2
Tabla 5.36: Instanciacin de actividades: Ciclo estructurado
186
Como puede observarse, el modelo de instanciacin no tiene la capacidad de

generar las instancias necesarias para ejecutar un escenario de aprendizaje con el
patrn ciclo estructurado. Para que el modelo adquiera dicha capacidad, es necesario
tomar en cuenta las condiciones que propician el ciclo de actividades, las cuales puede
establecerse en tiempo de diseo con base en los datos del diseo del aprendizaje, o
bien en tiempo de ejecucin con base en las decisiones de los participantes.
A continuacin, se presenta el condensado de resultados de las pruebas de factibilidad para la instanciacin de actividades.
5.3.11.
Resultados
Hasta este punto, se presentaron las pruebas de factibilidad de instanciacin de

actividades, para cada uno de los patrones de control de flujos de trabajo presentados
en la seccin 2.5.1. En la tabla 5.37, se muestran los resultados condensados de dichas
pruebas. Para cada patrn se indica con el smbolo +, si el patrn es soportado por
el modelo de instanciacin de actividades del motor de ejecucin, y con el smbolo
- si el patrn no est soportado por el modelo.
Patrn de control de flujo de trabajo
Secuencia
Separacin paralela
Sincronizacin
Eleccin exclusiva
Combinacin Sencilla
Eleccin mltiple
Combinacin mltiple
Ciclo estructurado
Factibilidad de ejecucin
+
+
+
+
+
+
+
+
-
Tabla 5.37: E3 Instanciacin de actividades

En conclusin, el modelo de instanciacin tiene la capacidad para generar instancias de actividades para poder ejecutar la mayora de las estructuras complejas de
aprendizaje, cumpliendo de esta forma con el objetivo de investigacin O1.
En la siguiente seccin, se presenta la evaluacin E4 Invocacin de servicios web.
187
5.4.
E4. Invocacin de servicios web
La cuarta evaluacin denominada E4 Invocacin de servicios web, tiene como objetivo evaluar las contribuciones C1 Modelo de la arquitectura de software del motor
de ejecucin, y C2 Modelo de informacin del motor de ejecucin, en cuanto a su capacidad para invocar servicios web distribuidos en una red computacional, y de esta
forma asegurar que se alcanza el objetivo de investigacin O2 Integracin de servicios web; y as brindar una solucin al problema P3 Dificultad para integrar diversos
recursos y servicios para el aprendizaje en ambientes distribuidos y heterogneos. En
la figura 5.26, se muestran las relaciones entre esta evaluacin, las contribuciones,
objetivos y problemas de manera grfica.

La verificacin de esta evaluacin se har a travs de pruebas funcionales. Para
estas pruebas, se utilizaron los servicios web con las operaciones que se presentan en
la tabla 5.38. Estos servicios se encuentran ubicados en un servidor remoto conectado
a la red Internet.
A continuacin en la tabla 5.39, se presentan los resultados de la evaluacin E4.
Como puede observarse, la ejecucin de diversas operaciones de los servicios web
se invocaron de manera correcta dentro dle motor de ejecucin. Lo cual valida la
188
5.5. E5. Sustitucin de servicios web
Servicio
Periodic Table
Periodic Table
Country
ConvertWeights
URI
http://www.webservicex.net/periodictable.asmx?WSDL
http://www.webservicex.net/periodictable.asmx?WSDL
http://www.webservicex.net/country.asmx?WSDL
http://www.webservicex.net/ConvertWeight.asmx?WSDL
Operacin
GetAtomicWeight
GetAtomicNumber
GetCurrencyByCountry
ConvertWeight
Tabla 5.38: Conjunto de servicios web y sus operaciones para la evaluacin E4

Servicio
Periodic Table
Periodic Table
Periodic Table
Periodic Table
Country
Country
ConvertWeights
Operacin
GetAtomicWeight
GetAtomicWeight
GetAtomicNumber
GetAtomicNumber
ConvertWeight
Parmetros
Resultado
ElementName=Oxygen 15.9994
ElementName=Helium 4.0026
ElementName=Oxygen
8
ElementName=Helium
2
Country=Mexico
Peso
Country=Guatemala
Quetzal
Weight=63
4472.2222
FromUnit=Kilograms
ToUnit=Poundals
Invocacin correcta
S
S
S
S
S
S
S
Tabla 5.39: Evaluacin E4: Invocacin de servicios web

capacidad de la arquitectura de software y del modelo de informacin del motor para
invocar servicios web ubicados de manera distribuida en una red computacional.
A continuacin, en el siguiente apartado se presenta la evaluacin E5 Sustitucin
de servicios web, como un complemento de esta evaluacin para hacer dinmica la
integracin de servicios web.
5.5.
E5. Sustitucin de servicios web
La quinta evaluacin denominada E5 Sustitucin de servicios web, tiene como

objetivo evaluar las contribuciones C1 Modelo de la arquitectura de software del
motor de ejecucin, y C2 Modelo de informacin del motor de ejecucin, en cuanto a su capacidad para eliminar, agregar y modificar servicios web del proceso de
aprendizaje, y de esta forma lograr la flexibilidad que requiere un PAC para hacer
dinmica la integracin de servicios web, y as asegurar que se alcanza el objetivo de
investigacin O3 Sustituir y agregar de manera sencilla y transparente un servicio
web; y as brindar una solucin al problema P4 Sustitucin de los recursos y servicios
de aprendizaje de manera sencilla. En la figura 5.27, se muestran las relaciones entre
esta evaluacin, las contribuciones, objetivos y problemas de manera grfica.
189

La verificacin de esta evaluacin se har a travs de pruebas funcionales. Para
estas pruebas, se utilizaron los mismos servicios web y operaciones que se presentaron en la tabla 5.38, sustituyendo en cada caso el actual por el siguiente. Para
su ejecucin, inicialmente se tena registrado el servicio web Periodic Table con
la operacin GetAtomicWeight. Posteriormente, utilizando la funcin del motor
ModifyResource, se modific la ubicacin del servicio, la operacin, y la interfaz
grfica de entrada del serivicio, con los valores que se presentan en la tabla 5.40, y
posteriormente se invoc el nuevo servicio.
Como puede observarse en la tabla 5.40, las pruebas funcionales se ejecutaron
de manera exitosa. En cada ejecucin se consumi el servicio sustituido y la nueva
operacin del servicio a travs de la nueva interface. Por lo tanto, se comprueba
que a travs del modelo de informacin y del modelo de la arquitectura de software,
pueden sustituirse de manera sencilla y transparente los servicios web empleados en
el proceso de aprendizaje.
A continuacin se presenta la evaluacin del modelo de transacciones.
190
5.6. E6. Soporte transaccional

Estado
Inicio
Servicio
Periodic Table
Operacin
GetAtomicWeight
Sustitucin 1
Periodic Table
GetAtomicNumber
Sustitucin 2
Country
Sustitucin 3
ConvertWeights
ConvertWeight
Interface
<form method=POST>
ElementName:
<input
type=text
name=ElementName/>
<input
type=submit
class=button value=Invoke
name=Invoke/></form>
<form method=POST>
ElementName:
<input
type=text
name=ElementName/>
<input
type=submit
<form method=POST>
Country:
<input
type=text
name=Country/>
<input
type=submit
<form method=POST>
Weight:
<input
type=text
name=Weight/>
FromUnit:
<input
type=text
name=FromUnit/>
ToUnit:
<input
type=text
name=ToUnit/>
<input
type=submit
Invocacin
S
Tabla 5.40: Evaluacin E5 Sustitucin de servicios web
5.6.
E6. Soporte transaccional
La sexta evaluacin denominada E6 Soporte transaccional, tiene como objetivo

evaluar la contribucin C5 Modelo de transacciones, en cuanto a que el modelo es
factible para un ambiente pedaggico apoyado en la tecnologa, y as asegurar que se
alcanza el objetivo de investigacin O4 Proveer al proceso de aprendizaje de soporte
transaccional; brindando una solucin al problema P5 Soporte transaccional para
el proceso de aprendizaje. En la figura 5.28, se muestran las relaciones entre esta
evaluacin, las contribuciones, objetivos y problemas de manera grfica.
La verificacin de esta evaluacin se har a travs de pruebas de factibilidad en
las que el modelo demuestra su capacidad para recuperar el proceso de aprendizaje
191

despus de un fallo tecnolgico, o bien cuando un estudiante no logra los objetivos
pedaggicos de una actividad.
192
5.7.
Resmen del captulo
Captulo 6
Conclusiones
6.1.
Resumen de objetivos y de su evaluacin
6.2.
Conclusiones
6.3.
Contribuciones
La contribucin fundamental de la tesis es un marco de referencia para la construccin de un motor de ejecucin de procesos de aprendizaje complejos basado en
la integracin de servicios web a travs de lenguajes de modelado educativo. Dicho
marco de referencia se compone en concreto, de las siguientes contribuciones:
Por ltimo, cabe destacar que durante urante el desarrollo de esta tesis, se originaron trabajos de investigacin relacionados que pueden clasificarse de la siguiente
forma:
6.4.
Lneas de trabajo futuras
193
194
6.4. Lneas de trabajo futuras
[Advanced Distributed Learning (ADL), 2009a] Advanced
(ADL).
Distributed
Learning
R
Sharable content object reference model (scorm)
2004 4th edition
run-time environment (rte) version 1.1. Technical report, Advanced Distributed

Learning (ADL), 2009.
[Advanced Distributed Learning (ADL), 2009b] Advanced
Distributed
Learning
R 2004 4th edition se(ADL). Sharable content object reference model (scorm)
quencing and navigation (sn) version 1.1. Technical report, Advanced Distributed
Learning (ADL), 2009.
[Advanced Distributed Learning (ADL), 2009c] Advanced
Distributed
Learning
R content aggregation
(ADL). Sharable content object reference model (scorm)
model (cam) version 1.1.
Technical report, Advanced Distributed Learning
(ADL), 2009.
[ANSI, 2004] ANSI. Role-based access control, 2004.
[Baldwin, 1990] R.W. Baldwin. Naming and grouping privileges to simplify security management in large databases. In Research in Security and Privacy, 1990.
Proceedings., 1990 IEEE Computer Society Symposium on, pages 116132, May
1990.
[Bell and LaPadula, 1973] D. E. Bell and L. J. LaPadula. Secure Computer Systems:
Mathematical Foundations and Model. Bedford, MA: The Mitre Corporation, 1973.
[Brewer and Nash, 1989] D.F.C. Brewer and M.J. Nash. The chinese wall security
policy. In Security and Privacy, 1989. Proceedings., 1989 IEEE Symposium on,
pages 206 214, May 1989.
195
196
[Buchmann et al., 1992] A. Buchmann, M. T. Ozsu, M. Hornick, and D. Georgakopaulus. Database Transaction Models, chapter A Transaction Model for Active
Distributed Object Systems, chapter 5, pages 123158. Morgan Kaufmann Publishers, San Mateo, CA, 1992.
[Chappell, 2004] David A. Chappell. Enterprise service bus. OReilly Media, Inc.,
2004.
[Chen et al., 2005] Meng-Che Chen, Chien-Tsun Chen, Yn Chin Cheng, and ChinYun Hsieh. On the development and implementation of a sequencing engine for
ims learning design specification. In Advanced Learning Technologies, 2005. ICALT
2005. Fifth IEEE International Conference on, pages 636640, July 2005.
[Dalziel, 2003] J. R. Dalziel. Implementing Learning Design: The Learning Activity
Management System (LAMS). In G. Crisp, D. Thiele, I. Scholten, S. Barker, and
J. Baron, editors, Proceedings of the 20th Annual Conference of the Australasian
Society for Computers in Learning in Tertiary Education (ASCILITE), Adelaide,
Australia, December 2003.
[Derntl and Motschnig-Pitrik, 2004] Michael Derntl and Renate Motschnig-Pitrik.
Patterns for blended, person-centered learning: strategy, concepts, experiences,
and evaluation. In SAC 04: Proceedings of the 2004 ACM symposium on Applied
computing, pages 916923, New York, NY, USA, 2004. ACM.
[Dobson and McDermid, 1989] J. E. Dobson and J. A. McDermid. Database Security, II: Status and Prospects, chapter Security Models and Enterprise Models, pages
139. Elsevier, New York, 1989.
[Dodero et al., 2005] Juan Manuel Dodero, Jorge Torres, Ignacio Aedo, and Paloma
Daz. Beyond descriptive eml: Taking control of the execution of complex learning
processes. In Simposio Pluridisciplinar sobre Diseo, Evaluacin y Descripcin de
Contenidos Educativos Reutilizables (SPDECE), 2005.
[Eliassen and Veijalainen, 1988] F. Eliassen and J. Veijalainen. A functional approach to information system interoperability. In Research into Networks and
Distributed Applications, pages 11211135, 1988.
197
[Elmagarmid et al., 1990] A.

M. Rusinkiewicz.
K.
Elmagarmid,
Y.
Leu,
W.
Litwin,
A multidatabase transaction model for interbase.
and
In 16
th Int. Conf. On Very Large Data Bases, pages 507518, 1990.

[Elmagarmid, 1992] Ahmed K. Elmagarmid, editor. Database Transaction Models
for Advanced Applications. Morgan Kaufmann, 1992.
[Ensher et al., 2002] E.A. Ensher, T.R Nielson, and E. Grant-Vallone. Tales from the
hiring line: Effects of the internet and technology on hr processes. Organizational
Dynamics, 31:224244, 2002.
[Erl, 2004] T. Erl. Service-Oriented Architecture: A Field Guide to Integrating XML
and Web Services. Prentice Hall PTR, 2004.
[Erl, 2008] Thomas Erl. SOA: Principles of Service Design. Prentice Hall, 2008.
[Ferraiolo et al., 2007a] David Ferraiolo, D. Richard Kuhn, and Ramaswamy Chandramouli. Role-based Access Control, chapter Integrating RBAC with Enterprise
IT Infrastructures, pages 271313. Artech House Inc., 2007.
[Ferraiolo et al., 2007b] David Ferraiolo, D. Richard Kuhn, and Ramaswamy Chandramouli. Role-based Access Control, chapter Introduction, pages 126. Artech
House Inc., 2007.
[Ferraiolo et al., 2007c] David Ferraiolo, D. Richard Kuhn, and Ramaswamy Chandramouli. Role-based Access Control, chapter Core RBAC Features, pages 5771.
Artech House Inc., 2007.
[Flavin, 2001] Christopher Flavin. State of theWorld 2001: A Worldwatch Institute
Report on Progress Toward a Sustainable Society, chapter Chapter 1: Rich Planet,
Poor Planet, pages 320. W . W . Norton & Company, 2001.
[Garca-Molina and Salem, 1987] H. Garca-Molina and K. Salem. Sagas. In ACM
SIGMOD Int. Conf. On Management of Data, pages 249259, 1987.
[Georgakopoulos et al., 1995] Diimitrios Georgakopoulos, Mark Hornick, and Amit
Sheth. An overview of workflow management: From process modeling to workflow
automation infrastructure. Distributed and Parallel Databases, 3:119153, 1995.
198
[Gray and Reuter, 1993] J. Gray and A. Reuter. Transaction Processing: Concepts
and Techniques. Morgan Kaufmann, 1993.
[Gray, 1981] J.. Gray. The transaction concept: Virtues and limitations. In 7th
International Conference on Very Large Data Bases, pages 144154, September
1981.
[Griths et al., 2005] David Griths, Josep Blat, Roco Garca, Hubert Vogten, and
KL Kwong. Learning Design, A Handbook on Modelling and Delivering Networked
Education and Training, chapter Learning Design Tools, pages 109135. Springer,
2005.
[Hadley, 2009] Marc J. Hadley. Web application description language (wadl). Technical report, Sun Microsystems Inc., 2009.
[Hagen and Alonso, 2000] C. Hagen and G. Alonso. Exception handling in workflow
management systems. Software Engineering, IEEE Transactions, 26(10):943958,
Oct. 2000.
[Hagen et al., 2006] K. Hagen, D. Hibbert, and P. Kinshuk. Developing a learning
management system based on the ims learning design specification. In Sixth International Conference on Advanced Learning Technologies, pages 420424, July
2006.
[Hevner et al., 2004] Alan R. Hevner, Salvatore T. March, Jinsoo Park, and Sudha
Ram. Design science in information systems research. MIS Quarterly, 28(1):75
105, March 2004.
[Hollingsworth, 1995] David Hollingsworth. The workflow reference model - issue
1.1. Specification TC00-1003, Workflow Management Coalition, 2 Crown Walk,
Winchester, Hampshire, UK, SO22 5XE, Jan 1995.
[IEEE, 2005] IEEE. Ieee standard for learning technology - data model for content
to learning management system communication. IEEE Std 1484.11.1-2004, pages
143, 2005.
[IMS, 2001] IMS. IMS Learner Information Packaging Information Model Specification, Version 1.0 Final Specification. Technical report, IMS Global Learning
Consortium, March 2001.
199
[IMS, 2003a] IMS. IMS Content Packaging Information Model, Version 1.1.3 Final
Specification. Technical report, IMS Global Learning Consortium, June 2003.
[IMS, 2003b] IMS. IMS Learning Design Information Model, Version 1.0 Final Specification. Technical report, IMS Global Learning Consortium, January 2003.
[IMS, 2003c] IMS. IMS Simple Sequencing Information and Behavior Model, Version
1.0 Final Specification. Technical report, IMS Global Learning Consortium, March
2003.
[IMS, 2004] IMS. IMS Question and Test Interoperability: Item Overview, Version
2.0 Public Draft. Technical report, IMS Global Learning Consortium, June 2004.
[IMS, 2009] IMS. Adoption of service oriented architecture for enterprise systems
in education: Recommended practices. Technical report, IMS Global Learning
Consortium, September 2009.
[Jochems et al., 2004] W. Jochems, J. van Merrinboer, and R. Koper. Integrated E-Learning: Implications for pedagogy, technology & organization., chapter An
introduction to integrated e-learning. Morgan Kaufmann, San Mateo, CA, 2004.
[Josuttis, 2007] Nicolai M. Josuttis. SOA in practice. OReilly, Farnham, August
2007.
[Knapper and Cropley, 2000] Christopher Knapper and A. J. Cropley.
Lifelong
learning in higher education. Routledge, 2000.

[Koper and Tattersall, 2005] Rob Koper and Colin Tattersall, editors. Learning Design, A Handbook on Modelling and Delivering Networked Education and Training.
Springer, 2005.
[Koper, 2001] Rob Koper. Modeling units of study from a pedagogical perspective:
the pedagogical metamodel behind eml. Technical report, Open University of the
Netherlands, June 2001.
[Koper, 2003] Rob Koper. Learning technologies: An integrated domain model., chapter 6, pages 6479. RoutledgeFalmer, London, November 2003.
[Lampson, 1969] B. W. Lampson. Dynamic protection structures. In Proceedings of
the November 18-20, 1969, fall joint computer conference, AFIPS 69 (Fall), pages
2738, New York, NY, USA, 1969. ACM.
200
[Martens and Vogten, 2005] Harrie Martens and Hubert Vogten. Learning Design, A
Handbook on Modelling and Delivering Networked Education and Training, chapter
A Reference Implementation of a Learning Design Engine, pages 91108. Springer,
2005.
[Martinez-Ortiz et al., 2007] I. Martinez-Ortiz, P. Moreno-Ger, J.L. Sierra, and
B. Fernandez-Manjon. Computers and education: e-learning from theory to practice, chapter Educational Modeling Languages: A Conceptual Introduction and a
High-Level Classification, pages 2740. Springer, 2007.
[Mehrotra et al., 1992] S. Mehrotra, R. Rastogi, A. Silberschatz, and H. F. Korth.
A transaction model for multidatabase systems. In 12th Int. Conf. on Distributed
Systems, pages 5663, June 1992.
[Milligan et al., 2005] Colin D. Milligan, Phillip Beauvoir, and Paul Sharples. The
reload learning design tools. Journal of Interactive Media in Education, 6:10, July
2005.
[Moss, 1981] J. E. B. Moss. Nested transactions: An approach to reliable distributed
computing. Technical report, Massachusetts Institute of Technology, Cambridge,
MA, USA, 1981.
[Neely et al., 2004] Steve Neely, Helen Lowe, David Eyers, Jean Bacon, Julian Newman, and Xiaofeng Gong. An architecture for supporting vicarious learning in a
distributed environment. In Proceedings of the 2004 ACM symposium on Applied
computing, SAC 04, pages 963970, New York, NY, USA, 2004. ACM.
[OMG, 2009] OMG. Business process modeling notation (bpmn) version 1.2. Technical Report formal/2009-01-03, Object Management Group, 2009.
[Pierre and Paquette, 2007] Samuel Pierre and Gilbert Paquette. E-Learning Networked Environments and Architectures: A Knowledge Processing Perspective,
chapter E-Learning Networked Environments: Concepts and Issues, pages 124.
Springer, 2007.
[Rawlings et al., 2002] A. Rawlings, P. van Rosmalen, R. Koper, M. RodrguezArtacho, and P. Lefrere. Survey of educational modelling languages (emls). Technical report, CEN/ISSS WS/LT, September 2002.
201
[Reuter and Schneider, 1992] A. Reuter and K. Schneider. Database Transaction

Models, chapter The ConTract Model, chapter 7, pages 219263. Morgan Kaufmann Publishers, San Mateo, CA, 1992.
[Reuter and Schneider, 1997] A. Reuter and K. Schneider. Advanced Transaction
Models and Architectures, chapter Contracts Revisited, pages 127151. Kluwer
Academic Publishers, 1997.
[Rosmalen et al., 2003] Peter Van Rosmalen, Francis Brouns, Colin Tattersall, Hubert Vogten, Jan Van Bruggen, and Rob Koper. Towards an open framework
for adaptive, agent-supported e-learning. In International Journal of Continuing
Engineering Education and Life-Long Learning, 2003.
[Russell et al., 2006] N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and
N. Mulyar. Workflow control-flow patterns : A revised view. Technical report,
BPM Center, 2006.
[Sampson and Karampiperis, 2006] D.G. Sampson and P. Karampiperis. Towards
next generation activity-based learning systems.
International Journal on E-
Learning, 5(1):129149, 2006.

[Sarukhn and Whyte, 2005] Jos Sarukhn and Anne Whyte, editors. Ecosystems
and Human Well-being: General Synthesis, chapter Summary for decision makers,
page 43. Millennium Ecosystem Assessment, 2005.
[Shrivastava and Wheater, 1990] S. K. Shrivastava and S.M. Wheater. Implementing
fault-tolerant distributed applications using objects and multi-coloured actions. In
10th Int. Conf. on Distributed Computing Systems, pages 203210, 1990.
[Sipser, 1997] M. Sipser. Introduction to the Theory of Computation. PWS Publishing, Boston, MA, 1997.
[Stallings, 2004] William Stallings. Operating Systems: Internals and Design Principles, chapter Process Description and Control, pages 108156. Pearson Prentice
Hall, 2004.
[Tattersall et al., 2005a] Colin Tattersall, Hubert Vogten, and Henry Hermans.
Learning Design, A Handbook on Modelling and Delivering Networked Education and Training, chapter The Edubox Learning Design Player, pages 303310.
Springer, 2005.
202
[Tattersall et al., 2005b] Colin Tattersall, Hubert Vogten, and Rob Koper. Learning Design, A Handbook on Modelling and Delivering Networked Education and
Training, chapter An Architecture for the Delivery of E-learning Courses, pages
6373. Springer, 2005.
[Thomsen, 1991] D. J. Thomsen. Database Security, IV: Status and Prospects, chapter Role-Based Application Design and Enforcement, pages 151168. Elsevier,
New York, 1991.
[Torres et al., 2005a] J. Torres, J. M. Dodero, I. Aedo, and P. Das-Prez. A characterization of composition and execution languages for complex learning processes.
In Proceedings of the 4th IASTED International Conference on Web-Based Education (WBE 2005), 2005.
[Torres et al., 2005b] J. Torres, J.M. Dodero, I. Aedo, and T. Zarraonandia. An
architectural framework for composition and execution of complex learning processes. In Advanced Learning Technologies, 2005. ICALT 2005. Fifth IEEE International Conference on, pages 143147, July 2005.
[Torres et al., 2006] J. Torres, J.M. Dodero, I. Aedo, and P. Diaz. Designing the execution of learning activities in complex learning processes using lpcel. In Advanced
Learning Technologies, 2006. Sixth International Conference on, 2006.
[Torres et al., 2009a] Jorge Torres, Eduardo Juarez, Juan Manuel Dodero, and Ignacio Aedo. Advanced transactional models for a new generation of educational
modelling language engines. In Advanced Learning Technologies, 2009. ICALT
2009. Ninth IEEE International Conference on, pages 107108, Los Alamitos, CA,
USA, July 2009. IEEE Computer Society.
[Torres et al., 2009b] Jorge Torres, Eduardo Juarez, Juan Manuel Dodero, and Ignacio Aedo. Eml learning flow expressiveness evaluation. In Advanced Learning
Technologies, 2009. ICALT 2009. Ninth IEEE International Conference on, pages
298300, July 2009.
[Torres et al., 2009c] Jorge Torres, Eduardo Jurez, Juan Manuel Dodero, and Ignacio Aedo. Advanced transactional models for complex learning processes. In
Recursos Digitales para el Aprendizaje, 2009.
203
[Torres et al., 2009d] Jorge Torres, Eduardo Jurez, Juan Manuel Dodero, and Ignacio Aedo. An eml expressiveness evaluation based on wcp. In Recursos Digitales
para el Aprendizaje, 2009.
[Torres et al., 2010a] Jorge Torres, Csar Crdenas, Juan Manuel Dodero, and Eduardo Jurez. Advances in Learning Processes, chapter Educational Modelling
Languages and Service-Oriented Learning Process Engines, pages 1738. In-teh,
Vukovar, Croatia, 2010.
[Torres et al., 2010b] Jorge
Juan Manuel Dodero.
tributed environment.
Torres,
Eduardo
Jurez,
Roberto
Garca,
and
Enhancing adaptation with web services in a disIn Recursos Digitales para la Educacin y la Cultura:
Volmen SPDECE, pages 193202, 2010.

[Turban et al., 2008] Efraim Turban, Dorothy Leidner, Ephraim McLean, and James
Wetherbe. Information Technology for Management: Transforming Organizations
in the Digital Economy. John Wiley & Sons, Inc., 6th edition, 2008.
[van Rosmalen and Boticario, 2005] Peter van Rosmalen and Jess Boticario. Learning Design, A Handbook on Modelling and Delivering Networked Education and
Training, chapter Using Learning Design to Support Design and Runtime Adaptation, pages 291301. Springer, 2005.
[Vogten et al., 2005] Hubert Vogten, Rob Koper, Harrie Martens, and Colin Tattersall. Learning Design, A Handbook on Modelling and Delivering Networked
Education and Training, chapter An Architecture for Learning Design Engines,
pages 7590. Springer, 2005.
[Vrasidas, 2000] Charalambos Vrasidas. Constructivism versus objetivism: Implications for interaction, course design, and evaluation in distance education. International Journal of Educational Telecommunications, 6(4):339362, 2000.
[W3C, 1999] W3C. Html 4.01 specification. Technical report, World Wide Web
Consortium (W3C), 1999.
[W3C, 2007] W3C. Web services description language (wsdl), version 2.0. Technical
report, World Wide Web Consortium (W3C), June 2007.
204
[Weikum and Schek, 1992] G. Weikum and H. J. Schek. Database Transaction Models, chapter Concepts and Applications of Multilevel Transactions and Open Nested Transactions, chapter 13, pages 515554. Morgan Kaufmann Publishers, San
Mateo, CA, 1992.
[Wiley, 2000] D. A. Wiley. Learning Object Design And Sequencing Theory. PhD
thesis, Brigham Young University, 2000.
[Wiley, 2002] David A. Wiley. The instructional use of learning objects. Agency for
Instructional Technology, 2002.
[Worah and Sheth, 1997] Devashish Worah and Amit Sheth. Advanced Transaction
Models and Architectures, chapter Transactions in Transactional Workflows, pages
345. Kluwer Academic Publishers, Norwell, MA, USA, 1997.
[Zhang et al., 1994] A. Zhang, M.odine, B. Bhargava, and O. Bukhres. Ensuring
relaxed atomicity for flexible transactions in multidatabase systems. In Int. Conf.
on Management of Data, pages 6778, 1994.

Tecnológico de Monterrey: Campus Querétaro

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tecnológico de Monterrey: Campus Querétaro

Uploaded by

Copyright:

Available Formats

Tecnolgico de Monterrey

Rectora Zona Centro

Un Marco de Referencia para la Construccin de un

Eduardo Daniel Jurez Pineda

Quertaro, Mxico, 24 de febrero de 2011.

DASL4LTD Research Group [C-QRO-17/07]

Un Marco de Referencia para la Construccin de un

Identificador del entregable:

Fecha del entregable:

Quertaro, Mxico, 24 de febrero de 2011.

1.1. Contexto del problema . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2. Motivacin del trabajo de investigacin . . . . . . . . . . . . . . . . .

1.3. Objetivos del trabajo de investigacin . . . . . . . . . . . . . . . . .

1.4. Contribuciones esperadas . . . . . . . . . . . . . . . . . . . . . . . .

1.5. Metodologa de investigacin . . . . . . . . . . . . . . . . . . . . . .

1.6. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . .

2. Estado del arte

2.1. La evolucin de los Sistemas de E-learning . . . . . . . . . . . . . . .

2.2. Procesos de Aprendizaje Complejos . . . . . . . . . . . . . . . . . . .

2.3. Lenguajes de Modelado Educativo . . . . . . . . . . . . . . . . . . .

2.3.1. Caractersticas de Diseo, Ejecucin y Control de un LME . .

2.3.2. IMS Learning Design . . . . . . . . . . . . . . . . . . . . . . .

2.4. Motores de Ejecucin de Procesos de Aprendizaje . . . . . . . . . . .

2.4.1. Motores de Ejecucin de Flujos de Trabajo . . . . . . . . . .

2.4.2. El Motor de Ejecucin de IMS LD . . . . . . . . . . . . . . .

2.4.3. El Ambiente de Tiempo de Ejecucin de SCORM . . . . . . .

2.5. Diversidad Pedaggica y Descripcin del Flujo de Aprendizaje . . . .

2.5.1. Evaluacin de los Flujos de Aprendizaje Basada en Patrones

2.6. Composicin Dinmica y No Anticipada . . . . . . . . . . . . . . . .

2.7. Descentralizacin de los Servicios de Aprendizaje . . . . . . . . . . .

2.7.1. Servicios de Aprendizaje . . . . . . . . . . . . . . . . . . . . .

2.7.2. Arquitectura Orientada a Servicios . . . . . . . . . . . . . . .

2.8. Separacin del Proceso de Aprendizaje y Servicio . . . . . . . . . . .

2.9. Disponibilidad y Contenido del Servicio de Aprendizaje

2.10. Soporte Transaccional . . . . . . . . . . . . . . . . . . . . . . . . . .

2.10.1. Modelos de Transacciones Avanzados . . . . . . . . . . . . . .

2.11. Otros Aspectos a Considerar en el Diseo de Motores de Ejecucin .

2.11.1. Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . .

2.12. Resmen del captulo . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. Planteamiento del problema

3.1. Un escenario de aprendizaje . . . . . . . . . . . . . . . . . . . . . . .

3.2. Primera etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3. Segunda etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4. Tercera etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5. Cuarta etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.6. Problemas para la construccin de motores de ejecucin de procesos

3.6.2. O2. Integracin de servicios web . . . . . . . . . . . . . . . . .

3.6.3. O3. Sustituir y agregar de manera sencilla y transparente un

3.6.4. O4. Proveer al proceso de aprendizaje de soporte transaccional

3.7. Resmen del captulo . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1. C1. Modelo de la arquitectura de software del motor de ejecucin . . 100

5.1. E1. Ejecucin de un LME . . . . . . . . . . . . . . . . . . . . . . . . 135

5.2.4. Eleccin Exclusiva . . . . . . . . . . . . . . . . . . . . . . . . 150

5.2.7. Combinacin estructurada y sincronizada . . . . . . . . . . . 154

5.3.4. Eleccin Exclusiva . . . . . . . . . . . . . . . . . . . . . . . . 174

6.1. Resumen de objetivos y de su evaluacin . . . . . . . . . . . . . . . . 193

1.2. Relacin entre los problemas, los objetivos y las contribuciones . . .

1.3. Marco de referencia para la investigacin en Sistemas de Informacin

1.4. Relacin entre los problemas, objetivos, contribuciones y las evaluaciones 12

2.2. IMS Learning Design . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3. Estructura de IMS LD . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4. Ejecucin de IMS LD . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5. LAMS Learning Design . . . . . . . . . . . . . . . . . . . . . . . . .