Modelo Arquitectural para Sistemas Generadores de Ambientes de Enseñanza Aprendizaje para Elearning

Universidad Central de Venezuela Facultad de Ciencias Postgrado en Ciencias de la Computacin rea: Sistemas de Informacin
Modelo Arquitectural para Sistemas Generadores de Ambientes de Enseanza Aprendizaje para eLearning
Tesis presentada por Ing. DORIS JOSEFINA PERNALETE CHIRINOS
para optar al ttulo de DOCTOR EN CIENCIAS mencin CIENCIAS DE LA COMPUTACIN
Tutor: Dr. Yovanny Coello Universidad Nacional Experimental "Francisco de Miranda"
Caracas, Venezuela Febrero 2013
Dedicatoria
A Dios todo poderoso A mi madre Dilia A mi hija Doris Sabrina A la memoria de mi padre Jesus y abuela Mea A mis hermanos Dilia, Dexy, Jess y Denisse A mi familia Chirinos y Pernalete
TODOS PILARES DE MI VIDA. LOS AMO!!!!
ii
Agradecimiento
Deseo expresar mi ms sincero agradecimiento a todas las personas que de alguna manera u otra, me han ayudado en la realizacin de este trabajo, y especialmente:
Al Dr. Yovanny Coello tutor de esta tesis doctoral, por la conanza y ayuda que me permitieron concluir con la investigacin. Y a su esposa e hijos, quienes me abrieron las puertas de su hogar. Al equipo del proyecto AMBAR, en el cual se suscribe esta investigacin, por su apoyo en la consolidacin de las ideas iniciales de la tesis. En especial a Nora Montao, Vanessa Miguel y Maria Gertrudis Lpez, autoras del proyecto. Con ellas y junto a mis amigos de estudios: Yosly, Jose Manuel, Antonio, Mayela, Franklin y Luis, compart gratos momentos durante la consolidacin de la tesis. A la profesora Francisca Losavio, quien me apoy en una fase de la investigacin con la tutora para la entrega de proyecto de investigacin. A Rosiris, Gustavo, Wilfredo y el prof. Alfredo Matteo, quienes me han brindado su amistad y apoyo durante mi recorrido en la Universidad Central de Venezuela. A mis compaeros y amigos del Departamento de Informtica y Tecnologa Educativa, y de Aprendizaje Dialgico Interactivo (ADI), con los que da a da comparto y aprendo. A los miembros de la comunidad de objetos de aprendizaje LACLO. En especial a Xavier, Luis, Rafael, Jaime, Regina, Virginia, Ismar, y muchos otros, que ao tras ao debatimos sobre temticas asociadas al campo de tecnologia educativa. Con ustedes pude validar los avances de la investigacin. A mis amigos Marbelys, Helen, Lorena y Jess Acosta, a ustedes les adeudo la ternura, las palabras de aliento y el abrazo. Gracias por brindarme su paciencia ante mis arrebatos del
iii
iv
humor, mis vanidades, temores y dudas. A Jesus Rojas, hacia ti tengo un agradecimiento especial. Tu preocupacin, trasnochos y dedicacin para lograr el cierre de mi investigacin. Tu palabra de apoyo vital para retomar el camino perdido. A mi madre, ser maravilloso que me dio la vida. Me mostrate el camino marcando tu huella. No existe en mi mundo personas mas bella que TU. A mi hija Doris Sabrina (mi beba), el regalo mas hermoso de mi vida. Tu eres la luz de mi camino. Agradezco al innito universo por tu presencia. Este logro es por ti y para ti. Te amo. A mis hermanos Dilia, Dexy, Jesus y Denisse; A mis sobrinos Daniela, Samuel, Diana, Deina, jesus Miguel, Susej y Jesus Rafael, que llenan da a da mi vida de tanta alegra. Y mis cuados Henrys, Roberto y Adil. Para ustedes mis sinceras gracias A Leito, Soa y Andrea, los hijos que la vida me regalo. Y a su padre Leonardo por ser tan buen padre para mi hija. Gracias por estar siempre alli. A Carmen Victoria, quien da a da cuida de mi y de mi hija. Llegastes como una bendicin a nuestro hogar. Eres parte de nuestra familia. A mi familia Chirinos, en especial a tia Coromoto (eres nuestra segunda madre), Mara, Yola, Chava, Nelly y David. Gracias por brindarme su amor, techo y cobijo siempre. A mi familia Pernalete, en especial a Diana, Ta Francisca y Eugenia, quienes siempre estuvieron pendientes por mis avances de tesis.
Para concluir, debo agradecer a DIOS TODO PODEROSO!!! Gracias padre. Gracias a la Vida que me ha dado tanto.
Sin todos y cada uno de ustedes no hubiese sido posible concluir. MIL GRACIAS...
Resumen
En el mundo actual, las organizaciones son cada vez ms dependientes de las tecnologas de la informacin y comunicacin (TICs) para conseguir sus objetivos de negocio y los entes educativos no escapan a esa realidad. En este sentido, se presenta el eLearning c el cual ha sido un tema de creciente inters en los ltimos aos. La integracin de los recursos presentes en el dominio de eLearning se ha convertido en un reto. Una robusta infraestructura manejable, distribuida es absolutamente necesaria para la integracin de los recursos eLearning. Por otro lado, se necesitan marcos de aplicacin que faciliten a las instituciones educativas sistemas y herramientas, basados en estndares y especicaciones ms adecuadas y necesarias para la generacin de ambientes de enseanza aprndizaje relacionados con las tecnologas educativas dentro del eLearning. En el campo de desarrollo de software, desde que Zachman propuso su modelo en 1987 para el planteamiento de Arquitecturas Empresariales distintos autores han desarrollado sus propios modelos y metodologas. A partir del desarrollo de los servicios Web como tecnologa nace durante los ltimos aos la necesidad de construir aplicaciones con bajo acoplamiento, descripciones de interfaces independientes de la plataforma y el uso de estndares ya establecidos con el n de facilitar el uso, modicacin, construccin y distribucin de los servicios de las aplicaciones de forma exible. En este contexto, las Arquitecturas Orientadas a Servicios (SOA) son un medio de captura de principios, guas y tcnicas que proporcionan un modelo arquitectural para el desarrollo de estas aplicaciones. Esta investigacin propone un modelo arquitectural basado en SOA para la generacin, uso y reutilizacin de Ambientes de Enseanza Aprendizaje basados en patrones de aprendizaje, considerando un enfoque de modelado de procesos de negocios bajo el enfoque de BPM: Business Process Management. Este permite modelar y administrar los procesos del negocio educativo, hacindolo compatible con el (IMS: Instructional Management) Learning Design
vi
(IMS LD), como estndar de facto que apoya la estandarizacin y reutilizacin de las estructuras de aprendizaje o diseos de instruccionales. Esta solucin arquitectnica se justica porque las aplicaciones en el dominio de eLearning requieren contar con herramientas que provean una gua en la generacin de ambientes de enseanza aprendizaje, que les permita la reutilizacin e interoperabilidad entre sistemas heterogneos. Como resultado se elabor un prototipo para la generacin de ambientes de enseanza aprendizaje para eLearning llamado GTLE-E. Este permite crear ambientes apartir de patrones pedaggicos generados por diseadores instruccionales, que permiten el modelado guiado dentro de los procesos educativos a los docente. Con GTLE-E, se valida la arquitectura propuesta. Palabras Clave: SOA, AVEA, BPM, IMS LD, eLearning.
Abstract
In today's world, organizations are increasingly dependent on information technology and communication (ICT) to achieve their business goals and educational bodies do not escape this reality. In this sense, eLearning is presented as a topic of increasing interest in recent years. The integration of the resources in the domain of eLearning has become a challenge. A robust infrastructure manageable distributed is absolutely necessary for the integration of eLearning resources. Furthermore, application frameworks are needed to facilitate educational institutions systems and tools, based on standards and specications appropriate and necessary for the generation of learning environments related training slope into the eLearning educational technologies. In the eld of software development since Zachman proposed his model in 1987 for Enterprise Architectures approach dierent authors have developed their own models and methodologies. With the development of Web services as a technology born in recent years the need to build loosely coupled applications, descriptions of platform independent interfaces and the use of established standards in order to facilitate the use, modication, construction and distribution services exibly applications. In this context, Service-Oriented Architectures (SOA) are a means of capturing principles, guidelines and techniques that provide architectural model for the development of these applications. This research proposes a SOA-based architectural model for the generation, use and reuse of learning environments based Learning learning patterns, considering an approach to modeling business processes under the approach to BPM: Business Process Management. This allows to model and manage the business processes of education, making it compatible with the (IMS: Instructional Management) Learning Design (IMS LD) as a de facto standard that supports the standardization and reuse of learning structures or instructional designs. This architectural solution is justied because the applications in the domain of eLearning need
vii
viii
to have tools that provide guidance in creating teaching and learning environments, enabling them to reuse and interoperability between heterogeneous systems. As a result developed a prototype for the generation of learning environments called learning to eLearning GTLE-E. This enables you to create educational environments apartir generated pattern instructional designers, allowing modeling guided within the teacher education process. With GTLE-E, the proposed architecture is validated. Keywords:SOA, AVEA, BPM, IMS LD, eLearning.
ndice general
Dedicatoria Agradecimiento Resumen Abstract Lista de tablas Lista de Figuras 1. Ideas impulsadoras
1.1. 1.2. 1.3. 1.4. 1.5. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planteamiento y Justicacin del trabajo . . . . . . . . . . . . . . . . . . . . . . Hiptesis y Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contexto de La Investigacin . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
iii
vii
xii
xiii
1
1 2 11 12 16 17 22
Mtodo de Investigacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1. Mtodo de resolucin y validacin . . . . . . . . . . . . . . . . . . . . .
1.6.
Organizacin de la Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Hacia el modelado de AVEAS para eLearning

2.1. 2.2. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dominio del eLearning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. 2.2.2. Modelo de categorizacin de variables en el eLearning Marco de eLearning (eLearning framework) . . . . . . . . . .
25
25 27 29 30
. . . . . . . . . . . . . . . .
ix
NDICE GENERAL
2.2.3. Modelo de las preferencias del usuario de eLearning (Model of user Preferences in eLearning) 2.2.4. 2.3. 2.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 34 35 36 40 62 64 65 69 71 72 83
El Crculo eLearning (eLearning Circle)
Plataformas de eLearning Estndares 2.4.1. 2.4.2. 2.4.3.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
El proceso de estandarizacin . . . . . . . . . . . . . . . . . . . . . . . . Objetivos que persiguen los estndares de eLearning Futuro de los estndares de eLearning . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.
Perspectiva del concepto de AVEA en eLearning 2.5.1. 2.5.2. 2.5.3. Elementos constituyentes de un AVEA.
Modelo de AVEA con conceptos compartidos. . . . . . . . . . . . . . . . Relacin del AVEA con mtodo pedaggico (estndar de facto IMS-LD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.
Conclusiones del captulo
3. Anlisis del dominio bajo estndares de calidad

3.1. 3.2. 3.3. 3.4. 3.5. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estndares en eLearning para calidad del AVEA . . . . . . . . . . . . . . . . .
85
86 87 90 95 96 97 98
Estndar ISO/IEC 19796 como modelo de calidad . . . . . . . . . . . . . . . . . Requisitos de Calidad segn ISO 9126-1 . . . . . . . . . . . . . . . . . . . . . .
Construccin de un Modelo de Calidad para AVEA . . . . . . . . . . . . . . . . 3.5.1. 3.5.2. 3.5.3. 3.5.4. 3.5.5. Captura de Requerimientos Funcionales (RF) a travs de casos de usos. Captura de Requerimientos No Funcionales (RNF) . . . . . . . . . . . .
Priorizar los casos de usos . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Identicar las arquitecturas candidatas . . . . . . . . . . . . . . . . . . . 106 Denicin de los estilos arquitecturales para eLearnings . . . . . . . . . 107
3.6. 3.7.
Arquitectura candidata derivada del modelo de calidad . . . . . . . . . . . . . . 113 Conclusiones del captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4. Arquitectura para sistemas generadores de AVEAs

4.1. 4.2. Arquitectura para de sistemas de eLearning
118
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 . . . . . . . . . . . . . . . . . . . . 120
NDICE GENERAL
4.2.1. 4.2.2. 4.2.3. 4.3. Modelo de categorizacin de variables en el eLearning Arquitectura de CISCO
xi
. . . . . . . . . . 120
. . . . . . . . . . . . . . . . . . . . . . . . . . . 124
IMS Abstract Framework (IAF) . . . . . . . . . . . . . . . . . . . . . . . 129
Trabajos sobre servicios web en eLearning . . . . . . . . . . . . . . . . . . . . . 136 4.3.1. 4.3.2. Una arquitectura implementable para un sistema de eLearning [1] . . . 137
Framework orientado a servicios Web para sistemas eLearning dinmicos [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.3.3. 4.3.4. 4.3.5. 4.4.
Cmo el paradigma de los servicios Web puede mejorar el eLearning? [3]139 Capa de servicios de base de datos del Sistema Generador de AMBAR [4]139 A pattern based design process represented with IMS LD [5]. . . . . . . 140
Propuesta de utilizacin de SOA para los AVEAs . . . . . . . . . . . . . . . . . 141 4.4.1. 4.4.2. 4.4.3. Arquitectura Orientada a Servicios (SOA) . . . . . . . . . . . . . . . . . 142 Contextualizacin de SOA y algunos enfoques . . . . . . . . . . . . . . . 145 SOA y Modelos de Proceso de Negocios (BPM) . . . . . . . . . . . . . . 169 . . . . . . . . . . . . . . . . . . 173
4.5. 4.6.
Enfoque la arquitectura propuesta para AVEA Conclusiones del captulo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
5. Generando AVEAs con GTLE-E

5.1. 5.2. 5.3. 5.4. 5.5. 5.6. Generador de Ambientes de Enseanza Aprendizaje para eLearning (GTLE-E) Modelando a GTLE-E
179
181
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 . . . . . . . . . . . . . . . . . . . 193
Guiones en apoyo a la generacin de AVEAS Arquitectura software de GTLE-E Modelado del ujo del AVEA 5.6.1. 5.6.2.
. . . . . . . . . . . . . . . . . . . . . . . . . 197
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Interfaz grca GTLE-E . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Estudio de Caso: Diseo de estrategia Gaviln . . . . . . . . . . . . . . . 204 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.7.
Conclusiones del captulo
Conclusiones Finales Publicaciones
209 212
xii
NDICE GENERAL
Bibliografa Apndice A Apndice B Apndice C Apndice D Apndice E
215 224 225 236 240 248
ndice de cuadros
1.1. Proyecto AMBAR, investigaciones y contextos de esta investigacin . . . . . . . 13
2.1. 2.2.
Algunos acuerdos producidos por CEN/ISSS Adaptacin eLearning [6] sobre deniciones de EVEA
. . . . . . . . . . . . . . . . . . . para eLearning y AVEA para
62
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
3.1. 3.2. 3.3. 3.4.
Instanciacin del modelo de los RF de un AVEA con los RNF de ISO 9126 . . . 101 Modelo de calidad en el dominio de AVEA . . . . . . . . . . . . . . . . . . . . . 102 Principales estilos arquitecturales . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Aportes fundamentales de SOA y su ESB . . . . . . . . . . . . . . . . . . . . . 110
xiii
ndice de guras
1.1. 1.2. 1.3. Mtodo de Investigacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mtodo de Resolucin y validacin . . . . . . . . . . . . . . . . . . . . . . . . . 18 19 24
Organizacin de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1. 2.2. 2.3. 2.4. 2.5. 2.6.
Subsets of distance learning - Subconjuntos de la Educacin a Distancia [7] . . Categoras de Variables en eLearning [8] . . . . . . . . . . . . . . . . . . . . . .
28 29 32 33 35
eLearning framework [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model of user Preferences in eLearning [10] . . . . . . . . . . . . . . . . . . . . The eLearning Circle A holistic software design tool for eLearning [11] . . . . Comparacin de funcionalidades de los LMS y los LCMS (Basado en: [12] citado en [13]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37 38 40 44 46 48 50 52 54 55
2.7. 2.8. 2.9.
Entidades participantes en estandarizacin de especicaciones. . . . . . . . . . . Proceso de estandarizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Libros que componen la especicacin de SCORM . . . . . . . . . . . . . . . .
2.10. Diagrama ilustrativo de SCORM CAM 2.11. Estructura del Maniesto
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.12. Estructura del chero imsmanifest.xml . . . . . . . . . . . . . . . . . . . . . . . 2.13. Modelo conceptual de IMS Learning Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.14. Estructura de un paquete de contenidos IMS CP 2.15. Estructura de una UoL 2.16. Concepcin eLearning de los
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . y ambientes de enseanza aprendizaje para
entornos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69 77
2.17. Mapa conceptual de los AVEAs . . . . . . . . . . . . . . . . . . . . . . . . . . .
xiv
NDICE DE FIGURAS
2.18. Como est estructurada una UoL en IMS LD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
78 82
2.19. Modelo Conceptual de un AVEA basado en IMS LD
3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8.
Partes del estndar ISO/IES 19796 . . . . . . . . . . . . . . . . . . . . . . . . . Adaptacin de los Procesos y Subprocesos del estndar ISO/IEC 19796-1 . . . . Modelo de Calidad para calidad interna y externa del Software ISO/IEC 9126-1 Mtodo para identicar arquitectura basada en modelo de calidad . . . . . . . . Caso de uso para los sistemas generadores de AVEAs . . . . . . . . . . . . . . . Modelo de Caso de Uso con sus RNF asociados
91 94 96 97 98
. . . . . . . . . . . . . . . . . . 100 . . . . . . . 102
Reestructuracin de los RNF comunes en el modelo de caso de uso
Visin general de un ESB de SOA [14] . . . . . . . . . . . . . . . . . . . . . . . 111
4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9.
Arquitectura LTSA de IEEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Nivel 3- System Components Arquitectura de Cisco Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 . . . . . . . . . . . . . . . . . 131
Arquitectura lgica de los sistemas de eLearning
Modelo fsico de los sistemas de eLearning . . . . . . . . . . . . . . . . . . . . . 132 Modelo en capas del IMS Abstract Framework . . . . . . . . . . . . . . . . . . . 133 Descripcin de un servicio en IMS AF . . . . . . . . . . . . . . . . . . . . . . . 134
Interaccin de los servicios en IMS AF . . . . . . . . . . . . . . . . . . . . . . . 135 Modelo funcional de un sistema de eLearning . . . . . . . . . . . . . . . . . . . 137
4.10. Arquitectura orientada a servicios de un sistema de eLearning . . . . . . . . . . 138 4.11. Framework orientado a servicios Web para sistemas eLearning dinmicos . . . . 139 4.12. Dos aspectos claves de las Organizaciones: procesos del Negocio y tecnologas [15]143 4.13. Capa de servicios entre los procesos del Negocio y las tecnologas [15] . . . . . . 144 4.14. Evolucin de Arquitecturas de Software hasta SOA [16] 4.15. Granularidad de servicios en SOA [15] . . . . . . . . . . . . . 145
. . . . . . . . . . . . . . . . . . . . . . 150
4.16. Capas de servicios segn la clasicacin [15] . . . . . . . . . . . . . . . . . . . . 152 4.17. Agilidad organizacional con capa de servicios intermedia en SOA [15] . . . . . . 154 4.18. Pasos del enfoque SOA [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.19. Enfoque SOA para una iteracin [17] . . . . . . . . . . . . . . . . . . . . . . . . 163
xvi
NDICE DE FIGURAS
. . . . . . . . . . . . . . . . . . . 165 . . . . . . . . . . . . . . . . . 172
4.20. Fases del proceso de desarrollo propuesto [15]
4.21. SOA provee la infraestructura para BPM [17, 16]
4.22. Arquitectura propuesta para los sistemas generadores de AVEA . . . . . . . . . 173
5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. 5.9.
Elementos del AVEA adaptado de Olivier et al [18] . . . . . . . . . . . . . . . . 181 Representacin de GTLE-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Flujo de procesos en GTLE-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Distribucin funcionalidades segn acceso al sistema Componentes de GTLE-E basado en IMS LD Tipo de propiedades en el AVEA . . . . . . . . . . . . . . . 186
. . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . 191
Flujo del proceso de creacin de una actividad en GTLE-E . . . . . . . . . . . . 194 Uso de patrones en eLearning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Ubicacin de GTLE-E dentro del dominio de eLearning (Autora) . . . . . . . . 197
5.10. Detalles de la arquitectura propuesta . . . . . . . . . . . . . . . . . . . . . . . . 198 5.11. Ingreso al Sistema GTLE-E 5.12. Ingreso al Sistema GTLE-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.13. Creacin de Cuentas de usuarios
5.14. Busqueda de AVEAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 5.15. Declaracin de roles en el AVEA 5.16. Guin en GTLE-E . . . . . . . . . . . . . . . . . . . . . . . . . . 203
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
5.17. Modelo Gaviln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 5.18. Modelo Gaviln en GTLE-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 5.19. Paquete generado por GTLE-E desplegado en Reload Editor . . . . . . . . . . . 207
20.
Modelo de Base de Datos de GTLE-E
. . . . . . . . . . . . . . . . . . . . . . . 224
Captulo 1
Ideas impulsadoras
Este captulo presenta los principales problemas o vacios encontrandos en la generacin de ambientes de enseanza aprendizaje para eLearning en cuanto a su arquitectura e implementacin, elementos que motivan la disertacin. El captulo formula los objetivos, las contribuciones previstas y la metodologa de la investigacin aplicada, as como la estructura de la disertacin.
1.1. Introduccin
La evolucin de las tecnologas de informacin y comunicacin (TIC) ha hecho que se ensayen diversas opciones para su inclusin efectiva en el campo educativo. Desde la adecuacin de programas de propsito general y el uso de software educativos, pasando por el aprovechamiento de los servicios bsicos de Internet, hasta la creacin de espacios virtuales en plataformas exclusivas, arquitecturas tecnolgicas exibles que permitan una fcil interaccin y el uso de herramientas de la Web 2.0; son algunos de los hitos que marcan ese proceso de apropiacin educativa de las TIC.
En este sentido, la presente investigacin propone una arquitectura para la generacin, uso y reutilizacin de Ambientes de Enseanza Aprendizaje basados en patrones de aprendizaje. Para ello se consider un enfoque en el modelado de los procesos del negocios (en este estudio se ha utilizado el UML: Unied Modeling Language) que permite modelar y admi1
CAPTULO 1. IDEAS IMPULSADORAS

1
nistrar los procesos del negocio educativo, hacindolo compatible con el IMS Management), especcamente con su estndar de facto IMS LD
2
(Instructional
(Learning Design) que apoya
la estandarizacin y reutilizacin de las estructuras de aprendizaje o diseos de instruccionales.
Es importante destacar que una solucin arquitectnica adecuada se justica porque las aplicaciones en el dominio de eLearning requieren contar con herramientas basadas en una arquitectura de calidad. Ella debe proveer una gua en la generacin de ambientes de enseanza aprendizaje.
En este captulo se presenta: el planteamiento y la justicacin del trabajo; la hiptesis y objetivos; contexto de la investigacin; el mtodo de investigacin; y, por ltimo, la organizacin de esta memoria de Tesis Doctoral. La seccin 1.2, muestra el problema abordado y se justica la necesidad estudio del modelo arquitectural para sistemas generadores de ambientes de enseanza aprendizaje para eLearning. La hiptesis planteada al inicio de este trabajo, el objetivo principal y derivados del mismo, son presentados en la seccin 1.3. En la seccin 1.4 ,se presenta el contexto de la investigacin, describiendo los principales proyectos en los que se integra y productos generados. La meta recorrida para el desarrollo de la investigacin lo encontramos en la seccin 1.5.. Por ltimo, en la seccin 1.6 se describe la organizacin de los restantes captulos de esta memoria de Tesis.
1.2. Planteamiento y Justicacin del trabajo

Las necesidades actuales que tiene toda organizacin para el logro de sus objetivos, demandan la construccin de grandes y complejos sistemas de software que requieren de la combinacin de diferentes tecnologas y plataformas de hardware y software para alcanzar un funcionamiento acorde con dichas necesidades. Lo anterior, exige de los profesionales dedicados al desarrollo de software poner especial atencin y cuidado al diseo de la arquitectura, bajo la cual estar soportado el funcionamiento de sus sistemas [19].
1 http://www.imsglobal.org/ 2 http://www.imsglobal.org/learningdesign/
1.2. PLANTEAMIENTO Y JUSTIFICACIN DEL TRABAJO
En este sentido, la denicin de una arquitectura de software, debe concebir un diseo que responda a cabalidad a los requisitos exigidos Se considera a priori en el desarrollo de un sistema. Asumiendo estos requisitos se evita que la construccin de un sistema no cubra el total de los requerimientos establecidos.
As, segn Sharon
[20] el diseo de software se divide en tres fases importantes: anlisis
de requisitos, diseo arquitectnico (tambin conocido como diseo de alto nivel) y diseo detallado. El diseo de la arquitectura de software ocurre inmediatamente despus de la especicacin de los requisitos del software, en la fase de anlisis y considera como elementos principales los siguientes: componentes de software, propiedades de dichos componentes y la comunicacin entre ellos. El diseo detallado se lleva a cabo justo antes de la codicacin, y forma parte de las primeras tareas del desarrollador. Es importante describir la lgica, el control jerrquico, estructura de datos, empaquetado de componentes, entre otros.
A pesar de la importancia de cada una de las fases antes descritas, diversos autores coinciden en que una parte fundamental, crtica e imprescindible en el desarrollo de un sistema de software lo representa el diseo de su arquitectura, ya que es precisamente en esta fase en donde recae toda la creatividad, experiencia y creacin de la propuesta de solucin del rea de dominio a automatizar.
Ahora bien, el rea de dominio del estudio realizado se centra en sistemas generadores de ambientes de enseanza aprendizaje, en las ciencias educativas. En este sentido, se considera para este propsito, una de las primeras fases del desarrollo de la arquitectura: el anlisis del dominio, el cual consiste en caracterizar propiedades generales de las familias de aplicaciones en un cierto contexto, segn Losavio, Matteo y Rahamut [21].
En atencin a lo anterior, la descripcin del anlisis del dominio tiene mucha relevancia en la formulacin de una arquitectura inicial y es central para esta propuesta. Para ello, se deben considerar enfoques que permitan modelar aspectos de funcionamiento, procesos del negocio y requerimientos del sistema, que conlleven la automatizacin de herramientas para la
creacin, almacenamiento, gestin y publicacin de contenidos educativos y de los ambientes de enseanza aprendizaje.
En el marco de esta investigacin se presenta distintas concepciones sobre el trmino de ambiente de enseanza aprendizaje para eLearning, o lo que es lo mismo, ambiente virtual de enseanza aprendizaje (AVEA). Para Salazar y Merchn [22, pag 07]un AVEA se concibe como la relacin pedaggica y telemtica que establece un usuario con un conjunto de elementos instruccionales, tutoriales y tecnolgicos que le posibilitan construir, adquirir y modicar su conocimiento y sus estructuras de conocimiento de manera autnoma y exible.
Otra denicin es la referida por Miranda [23, pag 07], el cual lo concibe como un espacio virtual social que integra mltiples herramientas tecnolgicas, el diseo instruccional de la informacin propuesta, las estrategias psicopedaggicas, los actores y los objetos producidos resultado de las actividades y con el resto de los actores. Igualmente. Mendoza et al [24, pag 01] presenta el AVEA como ese espacio simblico en el que se produce la relacin entre los participantes en un proceso de enseanza y aprendizaje que, interactan entre s y acceden a la informacin relevante.
Las tres concepciones anteriores, asociadas a el AVEA, permiten reexionar sobre los nuevos ambientes generados con la TIC, y su posibilidad de verse como una forma diferente de organizar la enseanza a travs de la creacin de situaciones educativas. Esta orientacin debe permitar fomentar un aprendizaje en el estudiante de manera que desarrolle pensamiento crtico y creativo, potenciando el trabajo colaborativo y cooperativo, teniendo la tecnologa de punta como una herramienta viabilizadora de este propsito.
Sin embargo, los AVEAs no surgen por generacin espontnea, ni se dan de manera automtica. Para que sean efectivos dentro de un adecuado proceso de enseanza y aprendizaje se debe basar en un buen diseo pedaggico.
Es as que esta investigacin concibe al ambiente virtual de enseanza aprendizaje como el escenario donde existen y se desarrollan condiciones favorables para la enseanza y el aprendizaje donde lo dinmico, interaccin y dialogicidad estn presentes comprehensiva y transversalmente. asi se tiene Un espacio y un tiempo en movimiento, donde los participantes desarrollan capacidades, competencias, habilidades y valores, con el uso de las tecnologas de informacin y comunicacin (TICs).
De lo anterior deriva la necesidad para el diseo arquitectnico abordar en primera instancia el anlisis del dominio. Obligando a revisar aspectos educativos y pedaggicos y su inuencia en la generacin de ambientes virtuales de enseanza aprendizaje.
En este sentido, Koper
[25] plantea la necesidad de elaborar herramientas de autora de
material didctico que incluyan un enfoque pedaggico constructivista. Considerando un proceso de enseanza-aprendizaje participativo, en el que todos los agentes involucrados en el proceso, construyan, manipulen y organicen los objetos de aprendizaje (OA), enriqueciendo as la experiencia del usuario con el reporte de recursos adicionales. Para Jonassen [26], los
sistemas generados por los estudiantes son una experiencia de aprendizaje ms enriquecedora que la perspectiva tradicional del aprendizaje a partir de materiales generados slo por los docentes.
Resulta signicativo lo planteado por Burgos, Tattersall y Koper
[27],los cuales arman
que el aprendizaje virtual est caracterizado entre otras cosas por una adaptacin de la metodologa y de los contenidos a la capacidad de la herramienta o entorno donde se implementan. Esto conlleva una dependencia unilateral del estudiante y del profesor hacia la plataforma. La debilidad plateada por Burgos et al [27], obliga a suscribirse a una cierta opcin tecnolgica, con sus limitaciones, actualizaciones y circunstancias de supervivencia. Esta debilidad es posible revertirla con la incorporacin de estndares y especicaciones al mercado del aprendizaje y enseanza en lnea. Dicha accin facilita la independencia del recurso frente a la metodologa didctica, as como de las unidades de aprendizaje frente a la aplicacin que las edita o las
ejecuta.
Estos aportes plantean dos escenarios. El primero, es la necesidad de modelar los ambientes de enseanza aprendizaje para que las herramientas de autor satisfagan de una manera efectiva la inclusin de las TIC al dominio educativo. Y el segundo, la necesidad de contar con herramientas de autor que provean a los usuarios una gua pedaggica basada en patrones para la construccin de los ambientes de enseanza aprendizaje.
Para el primer escenario, existen varias deniciones de herramientas de autor, y posiciones diversas en este sentido. Sin embargo, la que posee mayor anidad a esta investigacin es la que provee Murray et al, [28, pag 341], para el cual:
Las herramientas de autor son aplicaciones que tienen la intencin de reducir el esfuerzo necesario para producir software, cargando con la responsabilidad en los aspectos mecnicos o la tarea, guiando al autor, y ofrecindole elementos predenidos que puede relacionar conjuntamente para satisfacer una necesidad particular educativa.
De esta manera, si generamos una herramienta autor, podemos ofrecer transparencia al usuario en cuanto a la adecuacin y utilizacin de estndares del contexto educativo para la generacin de su ambiente de enseanza aprendizaje.
Dentro del segundo escenario, Pernalete y Lpez [29], plantean la necesidad de incorporar un enfoque al proceso educativo, relacionado con las herramientas de autor, que provea la forma de descubrir, disear y administrar los procesos de enseanza aprendizaje, de manera que puedan ser adecuados, unicados y automatizados. Estos autores, proponen incorporar al mbito educativo el enfoque BPM (Bussines Process Management) que se dene como el conjunto de actividades que realizan las organizaciones para optimizar o adaptar sus procesos de negocio a las nuevas necesidades organizacionales.
Melenovsky
[30], dene BPM como una prctica de gestin que ofrece gobernabilidad de
los procesos de negocio hacia la consecucin de mejorar en agilidad y rendimiento operacional.
BPM es un conjunto estructurado de mtodos, poltico, mtrico, buenas prcticas de gestin y herramientas de software que permiten gestionar y optimizar continuamente las actividades y procesos de una organizacin. En el mbito educativo sera conveniente poder contar con un sistema de mtodos, herramientas y tcnicas que permitan sistematizar y reutilizar las estrategias educativas.
En base a esto, se propone incorporar un conjunto de pasos que en el mbito del BPM permita identicar los procesos claves asociados a la generacin de un ambiente de enseanza aprendizaje, analizando y modelando el ambiente, para generarlo de forma auto asistida (bien sea para un nuevo ambiente, como para uno ya existente - reutilizacin). El BPM va a permitir conjugar las especicaciones de los ambientes de enseanza aprendizaje (rea de dominio) con la solucin tecnolgica aplicada a la generacin de stos. A travs del BPM se pueden modelar aspectos de funcionamiento, procesos del negocio y requerimientos del sistema. Su enfoque orientado a procesos (un conjunto de actividades que deben llevarse a cabo en un orden y por los correspondientes actores, en tiempos aceptables), dirige a denir qu se debe hacer, quin lo debe hacer, con qu debe hacerlo y qu entiende la organizacin por tiempos aceptables.
En el rea del dominio educativo, se encuentran las especicaciones propuestas por IMS LD, diseadas y publicadas por el IMS Consorcio Global, quienes denen un Diseo de Aprendizaje o LD (Learning Design), como una descripcin de un mtodo que permite a los alumnos alcanzar objetivos de aprendizaje por medio del desarrollo de actividades de aprendizaje en un orden especco en el contexto de un ambiente de enseanza aprendizaje.
Ahora bien, en este contexto, sobre la existencia de otras herramientas disponibles, existe una gran gama de sistemas de gestin de aprendizaje (LMS: Learning Management System) y distintos entornos de aprendizajes virtuales (VLE: Virtual Learning Environment). Las aplicaciones que se pueden destacar, poseen caractersticas de software abierto y permiten la generacin de recursos que pueden ser interoperados. Se tienen: a. Moodle [31], un CMS
(Content Management System) o sistema gestor de cursos basado en diseo instruccional con

3 4
facilidades y servicios para aprendizaje colaborativo. b. Reload . c. Editores SCORM rable Content Object Reference Model) y d. editores IMS
(Sha-
[27]. Ninguno de estos sistemas
mencionados anteriormente, proveen una gua pedaggica explcita que permita construir ambientes basados en una estrategia pedaggica adecuada a los nes pedaggicos del diseador.
Dentro de los sistemas que ofrecen una secuencia fcil de lecciones y cursos, y que permite disear estructuras de aprendizaje, se encuentra el LAMS (Learning Activities Management System) o Sistema de Control de Actividades de Aprendizaje. LAMS es una aplicacin acadmica centrada ms que en la creacin tcnica, en el enfoque pedaggico de la construccin de materiales educativos. Inspirada en la especicacin IMS-LD, su nfasis se basa en establecer una secuencia de contenidos. Sin embargo, tampoco provee una gua pedaggica para el desarrollo de ambientes de enseanza aprendizaje.
5
De lo antes expuesto, se puede deducir que tanto la interoperabilidad como la reutilizacin de contenidos educativos (conjunto de saberes y actividades o experiencias que son seleccionados para alcanzar los objetivos) y de ambientes de enseanza aprendizaje, necesitan ms que una herramienta de autor, requieren un modelo arquitectnico que provea la generacin de aplicaciones asociadas a este dominio educativo, que se apoye en patrones de diseo pedaggicos, segn Pernalete, Lpez, Miguel y Montao [32]. Adems, mediante la utilizacin de herramientas como las plantillas, entre otras, puedan ofrecer una interaccin guiada al diseador en la construccin del ambiente de enseanza aprendizaje.
En ese sentido, en la Universidad Central de Venezuela (UCV) se lleva a cabo el proyecto de Investigacin y Desarrollo denominado AMBAR: Sistema Generador de AMBientes de Enseanza-ApRendizaje Constructivistas basados en objetos de aprendizaje (OA), que tiene como objetivo proveer una plataforma tecnolgica que soporte el almacenamiento, generacin, uso y reutilizacin de OA y estrategias de aprendizaje en ambientes instruccionales diseados bajo enfoques cognitivo-constructivistas y que a su vez sean compatibles con los estndares
3 http://www.reload.ac.uk/ 4 http://www.adl-ilce.org.mx/index.php 5 http://www.lamsinternational.com/

actuales en el rea
[33]. Con AMBAR se busca que los ambientes generados basen su diseo
en estrategias instruccionales cognitivo-constructivistas adecuadas a los objetivos pedaggicos del diseador, al tipo de audiencia y al tema a discutir.
En la Universidad de Valladolid, existe un grupo de investigacin, con sede en la Escuela Tcnica Superior de Ingenieros de Telecomunicacin de Valladolid, que tiene como objetivo trabajar con Sistemas Cooperativos, es decir en CSCW (Computer Supported Cooperative Work) con especial nfasis en CSCL (Computer Supported Collaborative Learning) y el proyecto TELL (Towards Eective network supported coLLaborative learning Activities), nanciado por la Unin Europea dentro de su programa eLearning.
Especcamente, el proyecto TELL se enfoca en la aproximacin pedaggica y didctica del aprendizaje colaborativo apoyado por ordenador/red (CSCL o NSCL). Es un esfuerzo metdico y sistemtico que pretende apoyar la comprensin de los procesos de aprendizaje que suceden en entornos CSCL mediante patrones de diseo y realizar meta-estudios de mtodos y herramientas que miden la efectividad de procesos CSCL. Igualmente busca ofrecer y proponer mtodos y herramientas para educadores que quieren medir la eciencia de actividades CSCL. Asi mismo, ofrece medios para la formacin de los actores humanos involucrados (o de los que quieren involucrarse) en actividades de aprendizaje colaborativo y apoyar el diseo de nuevas herramientas tecnolgicas efectivas para aprendizaje colaborativo.
Resulta signicativo destacar uno de los proyectos ms representativos en torno a IMS LD, el Collage , una herramienta de autor para aprendizaje colaborativo que proporciona patrones para el diseo de escenarios didcticos. [34]. Este proyecto, es uno de los primeros intentos
6
de la incorporacin de patrones en el desarrollo de herramientas de autor, para el manejo de diseo basado en patrones a travs de la creacin de macro-guiones de CSCL, representados computacionalmente con IMSLD. Sin embargo, slo ha sido diseado para soportar el aprendizaje colaborativo y en la actualidad slo maneja una parte de las especicaciones IMS-LD. A pesar de sus limitaciones, ste producto guarda mucha anidad con la propuesta que se hace en esta investigacin, ya que contempla la incorporacin de patrones para apoyar la represen-
6 http://gsic.tel.uva.es/collage
10
tacin computacional de ujo de procesos expresados en el marco del modelo conceptual del IMS-LD. Sin embargo, la propuesta del presente estudio ampla el alcance de manera que no se limite a patrones basados en CSCL, sino que permita incorporar patrones pedaggicos que puedan ser representados siguiendo las especicaciones de IMS LD.
Por otra parte, existen algunas organizaciones que proporcionan arquitecturas asociadas a sistemas de eLearning, entre las que se citan IEEE
9 7
, CISCO
e IMS Abstract Framework
. Para la denicin de la arquitectura del trabajos del grupo de IEEE P1484.1 Architecture
and Reference Model; se establece una arquitectura de alto nivel para sistemas de eLearning y sus componentes llamada LTSA (Learning Technology Systems Architecture). El Sistema de Componentes del LTSA identica las interfaces crticas para la interoperabilidad para sistemas de eLearning. Dentro del modelo de arquitectura planteado por CISCO, se ha desarrollado un modelo de arquitectura para sistemas de eLearning, caracterizada por ser un sistema abierto, escalable, global, integrado y exible. Su visin es mucho ms comercial que la del IEEE y provee una implementacin concreta.
En cuanto a la arquitectura denida por IMS en su Abstract Framework, es una referencia basada en una arquitectura orientada a servicios, la cual ofrece un mecanismo para denir un conjunto de servicios para los cuales se denen las especicaciones de interoperabilidad de un sistema de eLearning. El framework que propone IMS tiene como particularidades: a. la representacin abstracta del conjunto de servicios que se utilizan para construir un sistema eLearning en su sentido ms amplio. b. Centrado en el soporte de los sistemas de formacin distribuidos, y c. es un framework que cubre todo el rango de posibles arquitecturas eLearning que se podran construir a partir de un conjunto de servicios denidos [35].
En resumen, se presenta una situacin, donde existe un avance en el desarrollo de plataformas y arquitecturas para la gestin de contenidos y entornos de aprendizaje, donde se destacan dos problemas: el primero, es que las herramientas, plataformas y entornos existentes
7 http://www.ieeeltsc.org:8080/Plone 8 http://www.cisco.com/ 9 http://www.imsglobal.org/af/index.html
1.3. HIPTESIS Y OBJETIVOS
11
no proporcionan las guas pedaggicas para garantizar la calidad de los ambientes generados, y el segundo problema, es la no transparencia para el usuario en el manejo de los estndares que deben cumplir los ambientes y los elementos generados.
En denitiva, el problema existente es la falta de sistemas generadores de ambientes de enseanza aprendizaje que provean los mecanismos necesarios para guiar al diseador en el uso correcto de estrategias educativa que permitan generar sistemas efectivos a nivel pedaggico articulados con los estndares de una manera transparente para el usuario. En atencin a esta situacin, se hace necesario denir un modelo arquitectural que permita soportar todas esas caractersticas, evidenciandose asi el objeto de estudio de la investigacin.
1.3. Hiptesis y Objetivos

Al comienzo del trabajo de investigacin que se ha llevado a cabo en esta Tesis Doctoral, y teniendo en cuenta lo descrito en la seccin anterior, se plante la siguiente hiptesis de trabajo:
Es factible denir una arquitectura de un sistema capaz de generar Ambientes de Enseanza Aprendizaje basados en patrones pedaggicos, modelados siguiendo estndares existentes, e implementar un prototipo real para demostrar con su funcionamiento que la arquitectura planteada se puede llevar a la prctica
El objetivo principal de este trabajo de investigacin, derivado directamente de la hiptesis, es por tanto:
Proponer un Modelo Arquitectural para Sistemas Generadores de Ambientes de Enseanza Aprendizaje para eLearning basado en patrones pedaggicos para el modelado guiado de procesos educativos
Para la consecucin de este objetivo se han planteado los siguientes objetivos parciales: 1. Revisar bibliografa y documentos sobre el estado del arte de los sistemas generadores de ambientes de enseanza aprendizaje dentro del dominio de los sistemas de eLearning
12

2. Analizar el dominio de los sistemas eLearning, identicando las caractersticas de la familia de sistemas generadores de ambientes de enseanza aprendizaje, utilizando un modelo de calidad.
3. Modelar el negocio del sistema generador de ambientes de enseanza y aprendizaje basados en estndares
4. Denir una arquitectura inicial para un sistema generador de ambientes de enseanza y aprendizaje basada en el anlisis del dominio
5. Modelar el sistema utilizando una notacin para sus distintos ujos de procesos que permita la construccin de patrones pedaggicos para guiar la generacin de los ambientes de enseanza aprendizaje.
6. Crear un prototipo para la validacin de la Arquitectura propuesta.
1.4. Contexto de La Investigacin

El trabajo de investigacin que se presenta en esta Tesis Doctoral se inici a principios del ao 2007, y se realiz dentro del proyecto de investigacin de grupo titulado: Sistema Generador de AMBientes de Enseanza-ApRendizaje Constructivistas basado en Objetos de Aprendizaje (AMBAR). Lpez, Miguel y Montao [36],nanciado por el Consejo de
Desarrollo Cientco y Humanstico (CDCH) y de la Universidad Central de Venezuela (UCV). AMBAR integra diferentes proyectos de investigacin relacionados entre s, que tiene como objetivo principal proporcionar una plataforma tecnolgica que permita almacenar, generar, utilizar y reutilizar los Objetos de Aprendizaje (OAs) y patrones de aprendizaje en distintitos ambientes instruccionales. AMBAR consiste en un trabajo incremental e iterativo que actualmente posee productos desarrollados en trabajos de investigacin y desarrollo de aplicaciones, como puede verse en la Tabla 1.1
1.4. CONTEXTO DE LA INVESTIGACIN
13
Tabla 1.1: Proyecto AMBAR, investigaciones y contextos de esta investigacin
AUTORES
Adriani y Daz
TITULO
Estudio comparativo sobre dos Sistemas Manejadores de Bases de Datos Orientados a Objetos (SMBDOO): FastObjects t7 y Db4o. Caso de Estudio: Repositorio de Objetos de Aprendizaje
AO
2006
APORTE
Dio como resultado la seleccin del SMBDOO Database for Objects (Db4o) como SMBD a utilizar en el repositorio de AMBAR, ya que es eciente para el procesamiento de las consultas, provee los mecanismos apropiados para el manejo de los objetos, provee interoperabilidad y brinda APIs que permiten que la implementacin sea ms sencilla e intuitiva. A partir de estos resultados se decidi adoptar Db4o como SMBDOO para el desarrollo de la siguiente iteracin del proyecto.
Ramos y Villa-
Ontologa del Conocimiento Pedaggico del Sistema Generador de de Ambientes
2007
Desarrollo de una ontologa para el conocimiento pedaggico de AMBAR, con el n de representar conceptualmente los elementos del ambiente de aprendizaje constructivista del proyecto.
roel
Enseanza-Aprendizaje basados
Constructivistas
en Objetos de Aprendizaje (AMBAR) y el enlace con su repositorio de Objetos y Estrategias de Aprendizaje Continua en la siguiente pgina
14
Tabla 1.1 (cont.) Proyecto AMBAR, investigaciones y contextos de esta investigacin AUTORES TITULO AO APORTE
Ros Viloria y Interfaz Web de del Sistema 2007 Diseo de interfaz de usuario del Sistema y desarrollo de herramienta que permiti generar ambientes basados en estrategias de aprendizaje constructivistas como en la estrategia de formacin de conceptos. Tambin incorporan el almacenamiento Generador AMBientes
de Enseanza-ApRendizaje Constructivistas basado en Objetos de Aprendizaje
(AMBAR)
de los OA, utilizando el repositorio de AMBAR. Alegria y Nieves Repositorio de metadatos 2007 Desarrollo de un repositorio que contenga slo los descriptores (metadatos) de OAs en base a lo especicado en el estndar LOM (Learning Object Metadata) de la IEEE, permitiendo accederlos a travs de una referencia a su ubicacin fsica.
de Objetos de Aprendizaje del Sistema Generador de AMBientes de EnseanzaApRendizaje Constructivistas basado en Objetos de Aprendizaje (AMBAR)
Continua en la siguiente pgina
1.4. CONTEXTO DE LA INVESTIGACIN
15
Beleo Capa se de de servicios del de ba2007 Anlisis, diseo e implementacin de la capa de Servicios Web de base de datos del Sistema Generador de AMBientes de Enseanza-ApRendizaje (AMBAR) como implementacin de una Arquitectura Orientada a Servicios (SOA). La denicin de los Servicios Web para el acceso a la base de datos de AMBAR mejora la interoperabilidad entre las diferentes aplicaciones que constituirn el sistema, ya que stos ofrecen una alternativa de software independiente en cuanto a la plataforma basada en estndares para la integracin de aplicaciones, la automatizacin de procesos de negocio y la publicacin de la informacin de diversas fuentes. Los servicios desarrollados proporcionan un espacio para manipular Objetos de Aprendizaje (OA) que pueden ser almacenados y recuperados de la base de datos de AMBAR. Continua en la siguiente pgina datos de Sistema
Generador de
AMBientes
enseanza-ApRendizaje
AMBAR
16
Quintero Integracin del repositorio de AMBAR con el repositorio de metadata a travs de la capa de servicios 2009 Descripcin del proceso de integracin de la base de datos de AMBAR con el Repositorio de Metadata a travs de la Capa de Servicios Web asociado slo a los Objetos de Aprendizaje (OA). La integracin de los repositorios de metadata y de OA, proporciona un espacio para manipular OA que pueden ser almacenados y recuperados de manera eciente. Joubert y Ramirez Integracin del repositorio de Objetos de Aprendizaje de AMBAR con la plataforma MOODLE 2011 Con este trabajo, se est facilitando la gestin de los OA almacenados en el repositorio, desde el mismo entorno de trabajo de MOODLE, lo cual resulta en grandes benecios para los usuarios de dicha plataforma, debido que pueden incorporar los OA directamente en su curso y hacerlos disponibles para su uso general. Adems, permite hacer del ROA de AMBAR y de MOODLE sistemas mucho ms completos al incrementar sus usuarios, retroalimentacin, funcionalidades y recursos, respectivamente.
1.5. Mtodo de Investigacin

El mtodo de investigacin utilizado en este trabajo de Tesis Doctoral es el resultante de la combinacin de un mtodo propuesto por Marcos y Marcos [37], para la investigacin en
1.5. MTODO DE INVESTIGACIN
17
el campo de la Ingeniera del Software, y del mtodo denominado Investigacin en Accin (Action Research) Avison et al [38].
En Marcos y Marcos hipottico-deductivo
[37] se propone un mtodo de investigacin, basado en el mtodo
[39], que consta de una serie de etapas que, por su generalidad, son
aplicables a cualquier tipo de investigacin. Dichas etapas comprenden: la determinacin del problema, la creacin de la hiptesis, la denicin del mtodo de trabajo, la resolucin y validacin, el anlisis de los resultados y elaboracin de conclusiones, y la redaccin de un informe nal.
Como puede apreciarse en la gura 1.1, en el mtodo de investigacin se incluye una etapa de denicin del propio mtodo. Esta etapa es necesaria, puesto que cada investigacin posee sus propias caractersticas, lo que implica que no exista un mtodo genrico y universal que pueda aplicarse de forma directa y sin modicaciones a cualquier trabajo de investigacin. Esta depender de la naturaleza del problema a resolver.
Otra de las etapas del mtodo de investigacin es la de resolucin y validacin. En este caso, investigacin en el campo de la Ingeniera del Software y cuyo objetivo es la elaboracin de un prototipo que permita validar la arquitectura propuesta, para la etapa de resolucin y validacin utilizamos una adaptacin del mtodo de investigacin en accin, trabajando sobre diferentes casos de estudio. El mtodo de investigacin en accin utilizado en la resolucin y validacin de esta Tesis Doctoral se describe en el apartado siguiente.
1.5.1. Mtodo de resolucin y validacin

La Investigacin en Accin [38] es un mtodo de investigacin cualitativo utilizado para
la validacin de los trabajos de investigacin mediante su aplicacin en proyectos reales, reforzando la interaccin entre los investigadores y los participantes de dichos proyectos reales. Este mtodo, por su carcter de validacin prctica, es especialmente apropiado para la investigacin en Ingeniera y, especcamente, en Ingeniera del Software.
18
Figura 1.1: Mtodo de Investigacin
El mtodo de investigacin en accin es la forma que tienen los grupos de personas para preparar las condiciones necesarias para aprender de sus propias experiencias y hacer estas experiencias accesibles a otros, segn McTaggar como: [40]. Ms concretamente, puede denirse
el proceso de recopilar de forma sistemtica datos de la investigacin acerca de un sistema actual en relacin con algn objetivo, meta o necesidad de ese sistema; de alimentar de nuevo con esos datos al sistema; de emprender acciones por medio de variables alternativas seleccionadas dentro del sistema, basndose tanto en los datos como en las hiptesis; y de evaluar los resultados de las acciones, recopilando datos adicionales. [41]
Una de las caractersticas ms relevantes de este mtodo es que la investigacin se realiza a la vez que se aplican sus resultados, de modo que esta aplicacin permite validar y renar los resultados de la investigacin en un proceso iterativo. El proceso de investigacin denido en el mtodo de investigacin en accin no es por tanto un proceso lineal, sino que va avanzando mediante la realizacin de ciclos, llamados ciclos de investigacin en accin, en cada uno de los
19
cuales se ponen en marcha nuevas ideas, que son puestas en prctica y comprobadas hasta el siguiente ciclo [42]. Como puede verse en la gura 1.2, en este caso, los ciclos de investigacin en accin se realizan durante la etapa de resolucin y validacin.
Figura 1.2: Mtodo de Resolucin y validacin
A continuacin, se describen las etapas de cada ciclo de investigacin en accin:
Denicin del problema:
es la etapa inicial de cada iteracin, involucra la identicacin
de los aspectos a mejorar y los problemas a resolver propios de cada iteracin. Los problemas que se identican y describen en esta etapa guardan relacin con los problemas identicados durante la etapa de determinacin del problema, ilustrada en la Figura 1.2. Sin embargo, es importante tener en cuenta que, segn van sucedindose las iteraciones sobre los diferentes casos de estudio, pueden surgir nuevos problemas y oportunidades de mejora de los resultados de las iteraciones anteriores.
20

en esta etapa se consideran los diferentes cursos de accin a
Desarrollo de objetivos:
tomar para resolver los problemas detectados en la etapa anterior, a partir de los casos de estudios identicados preliminarmente durante la etapa de denicin del mtodo de trabajo se utiliza las etapas descritas por Losavio et al arquitectnica (ver Figura [43] para la propuesta
1.2). El resultado de esta actividad es la identicacin de
una serie de acciones a ejecutar sobre el mtodo seleccionado. implica la implementacin del curso de accin elegido en la etapa anterior sobre el caso de estudio seleccionado.
Aportes del diseo:
despus
de
completar
la
accin,
se
examinan
los
resultados.
La
evaluacin incluye determinar si se han alcanzado los efectos esperados de la accin, y si esos efectos mitigaron los problemas identicados previamente. Si los resultados obtenidos fueran no satisfactorios, los problemas identicados se trasladan a las siguientes iteraciones del ciclo de investigacin en accin.
Denir una arquitectura inicial
para un sistema generador de ambientes de enseanza y
aprendizaje basada en el anlisis del dominio
Propuesta:
si bien esta actividad gura al nal del ciclo, se trata de una actividad que se
lleva a cabo durante todo el ciclo. En ella, los conocimientos adquiridos durante el ciclo de investigacin en accin, por ms que hayan sido no satisfactorios, se comparten con las personas involucradas proyecto AMBAR, para que dicho conocimiento pueda ser asimilado en las tareas que realizan y para que se puedan planicar nuevos ciclos de investigacin en accin.
En el caso concreto de esta Tesis Doctoral, cada ciclo de investigacin en accin se aplic iterativamente sobre las diferentes fases propuestas por Losavio et al [43] para la propuesta
arquitectnica, revisando cada caso de estudio por fases. Desde el punto de vista de las ciencias sociales, los casos de estudio se utilizan para investigar una situacin o fenmeno que ocurre en un contexto real [44]. Sin embargo, cuando se habla de investigacin en arquitectura de
software, como es el caso de este trabajo, los casos de estudios pueden abordar casos como el desarrollo o la implantacin de un sistema de informacin en un contexto en particular [ ].
21
Los casos de estudio realizados para la validacin de este trabajo de investigacin, han consistido en el desarrollo de un prototipo arquitectural que provee diferentes servicios Webs, sobre los que se han ido aplicando las diversas versiones del mtodo propuesto de forma completa. En el captulo 5 de esta memoria, se describen detalladamente los casos de estudio realizados, incluyendo tanto los resultados obtenidos como las nuevas necesidades que fueron surgiendo a partir de cada uno de ellos.
continuacin,
se
presenta
los
diferentes
actores
de
la
aplicacin
del
mtodo
de
Investigacin en Accin a uno de los casos de estudio reales desarrollados para la validacin de esta investigacin, el caso de GTLE-E (siglas en ingls del Generador del Ambientes de Enseanza Aprendizaje para eLearning - Generators for Teaching and Learning Environments - eLearning):
El investigador, es aquel que impulsa, como sujeto, el proceso investigador. En este caso, la doctoranda.
El objeto investigado, que es el problema que se desea resolver. En este caso, modelo arquitectural para sistemas generadores de ambientes de enseanza aprendizaje, en particular, enmarcados en rea de dominio del eLearning.
El grupo crtico de referencia, es aquel para quien se investiga y que tiene un problema por resolver, por lo que participa en la investigacin. En este caso podra denirse como el conjunto de desarrolladores que han participado en las investigaciones y estudio realizados. As, por ejemplo, en el caso del proyecto macro AMBAR, el cuerpo crtico de referencia son los desarrolladores, que precisan los componentes del modelo arquitectural para sus desarrollos.
Beneciarios de la investigacin, son aquellos que pueden servirse de los resultados de la investigacin, aunque no haya participado directamente en el proceso. En este caso, cualquiera que pueda verse beneciado por la aplicacin de la arquitectura propuesta. Los principales beneciados de esta investigacin seran los desarrolladores de arquitectura de software, as como las organizaciones (clientes) y usuarios de los productos generados. As, para el caso del desarrollo del proyecto AMBAR, los beneciarios son los miembros
22

del grupo, los investigadores en el rea de ambientes de enseanza aprendizaje para eLearning, los propios desarrolladores y otros desarrolladores en este mbito.
1.6. Organizacin de la Memoria

La organizacin de los restantes captulos de este trabajo de Tesis Doctoral es la siguiente: (ver gura 1.3)
Captulo segundo:
Ac se analiza el estado actual de los sistemas generadores de ambientes
de enseanza aprendizaje, sus propuestas, estructuras, tendencias y limitaciones. Se revisan modelos y framework asociados a dominios educativos especcamente a en el dominio del eLearning. Igualmente se estudian y revisan los diversos estndares o especicaciones que existan para ste mbito.
Captulo tercero:
presenta la propuesta de este trabajo de Tesis Doctoral, es decir, partiendo
del modelo propuesto en el captulo anterior donde se caracteriza el rea de dominio, se dene el modelo de negocio asociado a los componentes presentes en los Ambientes de enseanza aprendizaje a ser generados y se construye un modelo de calidad para este dominio. Se obtiene una arquitectura candidata.
Captulo cuarto:
La presentacin de las alternativas de solucin a las reas de mejoras y
problemas detectados en la fase anterior se realiza en este capitulo. As mismo se redene la Arquitectura Propuesta, identicando los principales elementos que integran el sistema generador: componentes y conectores, y sus correspondientes relaciones, basndose en un modelo de calidad.
Captulo quinto:
Se muestra todo lo referido al prototipo que permite validar la arquitectura
propuesta, derivado de los casos de usos asociados a los distintos ujos de de los requisitos funcionales presentes en el Modelo de negocio bajo el enfoque de BPM. As mismo se especca el ujo asociado a los patrones de los ambientes a ser generados, el modelo de ujo de pantallas, el modelo conceptual en el cual se basa el prototipo y la base de datos.
1.6. ORGANIZACIN DE LA MEMORIA
23
Conclusiones:
anlisis
de
los
resultados,
las
principales
aportaciones
del
trabajo,
la
contrastacin de resultados en distintos foros tanto nacionales como internacionales, as como lneas de investigacin que quedan abiertas para futuros trabajos.
Bibliografa: Apndices:
en este captulo se incluye toda la bibliografa consultada para la realizacin
de este trabajo de investigacin.
nalmente, se incluyen dos apndices: el primero de ellos presenta la relacin
de siglas utilizadas a lo largo de este documento; y el segundo presenta, de forma detallada, el conjunto de casos de estudio utilizados en la validacin de este trabajo de Tesis Doctoral.
24
Figura 1.3: Organizacin de la memoria
Captulo 2
Hacia el modelado de AVEAS para eLearning

Este captulo tiene por objetivo establecer los aspectos inherentes a los ambientes de enseanza aprendizaje para eLearning, y sus relaciones, dentro de un proceso de desarrollo, que permita identicar el alcance del ambiente y los aspectos a considerar para lograr su efectividad.
El aporte de este captulo se concreta en la identicacin de los elementos clave en el modelado de los ambientes de enseanza aprendizaje para eLearning. Estableciendo sus puntos de comienzo y n, se proporciona las entradas necesarias para su compresin, automatizacin o incorporacin en diferentes procesos de desarrollo, especcamente en la propuesta arquitectural.
2.1. Introduccin
En los ltimos aos han aparecido sistemas informticos para la enseanza y aunque el objetivo de todos ellos es muy similar, los medios mediante los cuales llegan a dicho objetivo varan en gran medida. Muchos de estos sistemas, mal identicados como sistemas de eLearning, nicamente se centran en la gestin de documentos y en su provisin a discentes y docentes. Se acercan ms a ser meros repositorios, y aunque ciertamente faciliten la tarea 25
26
CAPTULO 2. HACIA EL MODELADO DE AVEAS PARA ELEARNING
de bsqueda y organizacin de informacin, no permiten realizar un seguimiento del proceso de aprendizaje del alumno. Carecen de exibilidad para generar una ambiente propicio para la enseanza y el aprendizaje. Por eso, entender lo qu es y no es el eLearning puede resultar confuso debido a la gran cantidad de trminos que han aparecido.
Para comenzar a diferenciar el concepto de eLerning mencionaremos algunas siglas, sus signicados y deniciones tcnicas que dieren de su uso: muchas personas preeren la palabra aprendizaje a formacin y utilizan el trmino Aprendizaje basado en Tecnologa (technologybased learning - TBL) o en lugar de Formacin basada en Tecnologa (technology-based training - TBT).
Otros trminos comnmente utilizados son Formacin basada en el computador (computerbased training - CBT), Aprendizaje por computador (computer-based learning - CBL), Instruccin basada en computador (computer-based instruction - CBI), Educacin Basada en el computador (computer-based education - CBE). En estos casos se utilizan para hacer referencia a subgneros especcos del eLearning, pero se emplean generalmente para describir la formacin basada en discos. Un trmino que comience con la palabra computer por lo general, se reere a tutoriales interactivos que se distribuyen en discos. El trmino formacin multimedia se utiliza para describir la formacin distribuida a travs de CD-Rom.
Por su parte, Formacin basada en el navegador (browser-based training - BBT) es un trmino referido a un curso que requiere un navegador Web para acceder al contenido, pero se puede ejecutar desde un CD-Rom. Estos tipos de cursos se llaman hbridos o CD-Roms hbridos.
Formacin basada en Web (web-based training - WBT), Formacin basada en Internet (Internet-based training - IBT), Aprendizaje basado en Hipermedia (Hypermedia-based learning - HBL) o Aprendizaje basado en Multimedia (Multimeda-based learning - MBL), Aprendizaje a Distancia o educacin a distancia (Distance learning o distance education) son otros trminos utilizados frecuentemente y aunque describen muchos tipos de eLearning se utilizan
2.2. DOMINIO DEL ELEARNING

para describir generalmente clases a distancia o cursos por correo.
27
Algunos tericos dividen el eLearning en tres ramas diferentes: Instruccin Asistida por el computador (computer aid instruction- CAI), computer-managed instruction (CMI) y computer supporter learning resources (CSLR). El primer trmino abarca la porcin de productos de eLearning que proporcionan enseanza como tutoriales, simulaciones y ejercicios. El segundo trmino se reere a los productos de eLearning que tienen funciones de evaluacin, seguimiento y gua de estudio. Finalmente, el tercer trmino cubre los aspectos del eLearning que dan soporte al desempeo, la comunicacin y el almacenamiento.
Aunque esta clasicacin puede ser til en el campo de la investigacin acadmica y en foros de discusin, para muchos es suciente con saber que todas ellas se reeren slo a partes del conjunto total representado por el eLearning.
2.2. Dominio del eLearning

En la literatura existe variedad de deniciones de eLearning. Muchas de stas son el resultado de las observaciones y el entorno en el cul se desarrollan sus autores. Es relativamente un nuevo concepto y gran parte de las anotaciones realizadas en este campo, son un tema actual de estudio y discusin de organismos y expertos involucrados con esta temtica.
El eLearning puede denirse como todos aquellos sistemas de educacin, entrenamiento y aprendizaje que son soportados por las Tecnologas de la Informacin y de las Comunicaciones (TIC).
Segn Urdan [7], el eLearning tambin hace alusin a la transmisin de contenidos a travs de medios electrnicos, incluyendo la Internet, intranets, extranets, difusin por satlite, cintas de audio/video, Televisin interactiva y CD-ROM.
28

El eLearning es un subconjunto del aprendizaje a distancia (Distance Learning), del
cual hacen parte el aprendizaje en-lnea (Online Learning) y el Aprendizaje Soportado en Computacin (Computer based Learning). Ver gura 2.1
Figura 2.1: Subsets of distance learning - Subconjuntos de la Educacin a Distancia [7]
Dentro del marco del eLearning han venido madurando varias corrientes o formas de dar soporte a los procesos educativos, cuya denicin se caracteriza por el tipo de tecnologa utilizada para ofrecer este soporte y/o los objetivos que se desean alcanzar.
Algunos ejemplos de estas corrientes o subconjuntos que vienen madurando dentro del eLearning son: a. el entrenamiento soportado en la Web (WBT) que se apoya en las tecnologas de la Internet en especial la Web; b. el aprendizaje colaborativo soportado en computacin (CSCL) que permite a grupos trabajar en conjunto para lograr un propsito comn, es decir, ayuda a los alumnos a aprender juntos efectivamente; y c. el entrenamiento basado en computacin (CBT), como su nombre lo indica soporta procesos de entrenamiento en el uso de computadoras.
En esta seccin del estado del arte se proporcionan referencias a trabajos relacionados con las contribuciones que se realizan en la tesis en cuanto a la teora de modelado el eLearning. Dichos trabajos pueden estar directamente relacionados con el modelado de diferentes aspectos
29
del eLearning, o tratar de factores a tener en cuenta a la hora de realizar el modelado, o bien es el repaso de tcnicas utilizadas en otras reas de conocimiento que pueden ser aprovechadas y extrapolables al rea del eLearning.
2.2.1. Modelo de categorizacin de variables en el eLearning

Investigadores de la Universidad de Kansas identican tres categoras de variables que facilitan el desarrollo de investigaciones en eLearning y ayudan a evaluar la naturaleza de los diferentes modelos, es decir, contribuyen como gua en la generacin y caracterizacin de interrogantes de diseo y pedagoga en cada uno de los modelos de eLearning. Ver gura 2.2
Figura 2.2: Categoras de Variables en eLearning [8]
Variables de salida (Outcome Variables) Se reeren al conjunto de condiciones que pueden ser afectadas por la implementacin de programas de eLearning y/o el compromiso de los alumnos dentro de este tipo de experiencias, es decir, son las variables medibles, asociadas con el resultado de implementar o emplear procesos de eLearning. Las variables de salida son anlogas a las variables dependientes. Estas variables nos permiten obtener resultados como logros alcanzados, tasas de ganancias, costos, necesidades para nuevas polticas, datos en eciencia educacional, etc. Las variables de salida son las siguientes: Implicaciones de la poltica
30
acadmica, ecacia pedaggica, implicaciones econmicas, implicaciones tecnolgicas y rendimiento del alumno.
Las Variables in situ (In situ Variables). relacionadas con las condiciones que rodean las experiencias de entrenamiento educacional. En investigaciones sobre eLearning es importante conocer las condiciones estables bajo la cual se est desarrollando. Mientras que ellas no puedan ser fcilmente controladas o manipuladas, pueden ser investigadas en trminos de su impacto, por ejemplo: la edad, el gnero, discapacidades, raza, contenido del tema, organizacin del programa o la escuela, la composicin de las clases y recursos tecnolgicos disponibles. Se hace imposible realizar investigaciones en eLearning sin tomar en cuenta variables in situ, entre las que se consideran las siguientes: atributos del alumno, ambientes de aprendizaje, naturaleza del contenido e Infraestructura tecnolgica.
Las Variables independientes (Independent Variables). referidas a las variables que pueden ser manipuladas para buscar el logro de los objetivos. Son afectadas tambin por la tecnologa de soporte, tal como: anchos de banda, poder computacional, sensores y tecnologas mviles. Son importantes para referenciar la interaccin con las variables in situ y de salida. Son las siguientes: niveles o tipos de interaccin, diseo instruccional, interfaces del alumno y ambientes instruccionales.
2.2.2. Marco de eLearning (eLearning framework)

Khan [9] desarroll un marco para el aprendizaje electrnico, que contena ocho dimen-
siones: institucional, pedaggicos, tecnolgicos, de diseo de la interfaz, evaluacin, gestin, apoyo de recursos y la tica. Cada dimensin posee sub-dimensiones, centrndose en aspectos particulares de un entorno de eLearning. (ver gura 2.3)
El Marco de Khan proporciona una lista de factores importantes que seran necesarias para la creacin de una experiencia exitosa para alumnos con necesidades diversas. El Marco de eLearning que se puede utilizar para capturar el inventario de una organizacin de eLearning
31
por abordar las cuestiones que abarca los siguientes ocho dimensiones de la abierta y distribuida ambientes de aprendizaje:
1. Pedaggico: Se reere a la enseanza y el aprendizaje. Esta dimensin se ocupa de cuestiones relacionadas con los contenidos, las audiencias, el objetivo y el anlisis de los medios de comunicacin; enfoque de diseo, organizacin y mtodos y estrategias de eLearning ambientes.
2. Tecnolgico: Examina las cuestiones de la infraestructura de la tecnologa en entornos de eLearning. Esto incluye la planicacin de la infraestructura, hardware y software.
3. Diseo de Interfaz: Se reere al aspecto general de eLearning. La dimensin del diseo de la interfaz incluye diseo de pgina y el sitio, diseo de contenidos, navegacin y pruebas de usabilidad.
4. Evaluacin: Incluye tanto la evaluacin de los alumnos, y la evaluacin del entorno de enseanza y aprendizaje.
5. Gestin: Se reere al mantenimiento del entorno de aprendizaje y la distribucin de la informacin.
6. Apoyo de recursos: Examina el soporte en lnea y los recursos necesarios para fomentar ambientes de aprendizaje signicativo.
7. tica: Se relaciona con la inuencia social y poltica, la diversidad cultural, los prejuicios, la diversidad geogrca, la diversidad de alumnos, la etiqueta de informacin sobre accesibilidad, y las cuestiones jurdicas.
8. Institucional: Problemas de los asuntos administrativos, asuntos acadmicos y servicios estudiantiles relacionadas con el eLearning
2.2.3. Modelo de las preferencias del usuario de eLearning (Model of user Preferences in eLearning)
Algunos autores han puesto de maniesto que la calidad en eLearning debe contemplarse desde diferentes perspectivas. Sin embargo, en este modelo se enfatiza en observar la calidad
32
Figura 2.3: eLearning framework [9]
sobre todo desde el punto de vista pedaggico y hacer hincapi en la perspectiva del alumno [10], mientras que no analizan en profundidad aspectos relacionados con el diseo de sistemas de software interactivo.
En consecuencia, [10] sugiere que los requisitos de calidad subjetiva se estructuran en siete mbitos de la calidad (ver Figura 2.4):
QF1 (de apoyo del tutor)
considera que las preferencias que tienen los alumnos para la
comunicacin y la cooperacin con el tutor de un curso en lnea.
QF2 (Cooperacin y Comunicacin en el Curso):
contiene los requisitos de calidad
para el curso que los alumnos expresa, que se reeren a la comunicacin y el entorno de cooperacin en los que trabajan con otros alumnos en grupos de aprendizaje, con expertos o tutor.
QF3 (Tecnologa)
Es importante que los requisitos tcnicos apoyen en la calidad de la
evaluacin a los alumnos. Para ello es importante que la tecnologa se encuentre normada de forma que no disminuya la calidad de la evaluacin.
33
Figura 2.4: Model of user Preferences in eLearning [10]
QF4 (Costos-Expectativas de Benecios)

ofreciendo el curso.
se reere a las posibilidades de los alumnos
para tener la Informacin sobre un curso o la institucin / organizacin que est
QF5 (Informacin de Transparencia del proveedor / Curso)
contiene
el
suministro
de informacin formal y estndar as como asesoramiento individualizado sobre los contenidos del curso, la metodologa de aprendizaje o de asesoramiento tcnico.
QF6 (Estructura de los estudios)
contiene los requisitos de los alumnos sobre la estruc-
tura de un eLearning. La preferencias de las clases presenciales como parte de un curso de eLearning (blended learning) es de gran importancia para ciertos grupos de alumnos, mientras que otros no los consideran importantes.
QF7 (Didctica)
cubre los aspectos de contenido, los objetivos de aprendizaje, mtodos y
materiales. Los Alumnos con experiencia en el campo de aprendizaje electrnico suelen ser muy precisos en sus requisitos relativos a la conguracin didctica de un curso de eLearning.
34

Los campos de la calidad se subdividen en 30 dimensiones, cada una de ellas representa un
conjunto de criterios de preferencias de los alumnos que se agrupan en una dimensin sobre la base de la evidencia emprica.
2.2.4. El Crculo eLearning (eLearning Circle)

El crculo eLearning es una contribucin al proceso de diseo de software de aplicaciones eLearning, ms especcamente una herramienta para asegurar el enfoque desde el principio pedaggico de la variacin y la individualizacin, incluyendo el aprendizaje, enseanza y evaluacin. Esta herramienta visua, provee de la conexin entre los principios pedaggicos y soluciones tecnolgicas.
El circulo eLearning se presenta con "subject.en el centro (Figura 2.5), que incluye un tema especco (por ejemplo, la programacin orientada a objetos) y un cuerpo completo a objeto (por ejemplo, Informtica). A continuacin, el crculo est dividido en tres sectores (ilustrado con colores diferentes):
Objetivos de aprendizaje.
El alumno.
El docente.
Cada sector cuenta con cuatro niveles, donde la pedagoga es el foco de los tres crculos internos recurriendo a la tecnologa en el crculo exterior. Esta propuesta se desarrolla como herramienta para asegurar la calidad del proceso de diseo de aplicaciones eLearning mediante la aplicacin de los principios pedaggicos en el proceso de diseo del sistema. El circulo eLearning es una herramienta de diseo, lo que garantiza el enfoque inicial de variacin, la individualizacin y meta-aprendizaje en un proceso de diseo de software.
Los puntos fuertes del Circulo eLearning es la presentacin compacta donde se combinan la informacin general que proporciona, as como la utilidad de una herramienta de diseo que tratan con la complejidad, proporcionando un lenguaje comn y la consideracin de las mejores prcticas. En l se ilustra de forma concreta la conexin entre los principios pedaggicos y
2.3. PLATAFORMAS DE ELEARNING
35
herramientas tecnolgicas. A pesar de no ser un mtodo preceptivo, es til en varios modelos de diseo y procesos.
Figura 2.5: The eLearning Circle A holistic software design tool for eLearning
[11]
2.3. Plataformas de eLearning

Las plataformas de aprendizaje en el escenario de uso para la docencia y el aprendizaje, generalmente se ha determinado que la herramienta o aplicacin principal a utilizar es la plataforma de aprendizaje en lnea o sistema de gestin del aprendizaje. Respecto a este tipo de aplicaciones, existe una indenicin terminolgica. As, sistemas de gestin de aprendizaje, entornos virtuales de aprendizaje, plataformas de eLearning, plataformas de aprendizaje en lnea, sistemas de gestin de cursos o sistemas de gestin de contenido educativo, entre otras, se abren a distintas interpretaciones, produciendo una cierta confusin semntica inevitable
36
en el discurso sobre eLearning y tecnologas educativas.
En trminos generales, se pueden distinguir dos grandes grupos de sistemas en razn de su enfoque principal: el aprendizaje o los contenidos. Por un lado, estn los sistemas centrados en la gestin del aprendizaje y la enseanza, es decir, la experiencia educativa, y a los que en castellano nos referimos principalmente como plataformas de eLearning o de aprendizaje en lnea, o ms formalmente como Sistemas de Gestin del Aprendizaje (SGA) por inuencia del trmino en ingles Learning Management System (LMS). Este trmino es equiparable al de CoMS (Course Management System) por sistema de gestin de cursos, ambos empleados de forma generalizada en Estados Unidos, o al de VLE (Virtual Learning Environment) por Entorno Virtual de Aprendizaje (EVA), termino mas comn en Reino Unido y otros pases europeos.
En el otro grupo, estn los sistemas centrados en la gestin del contenido educativo. Especialmente, los objetos de aprendizaje reutilizables, como son los LCMS (Learning Content Management System) o Sistema de Gestin de Contenidos Educativos, considerados un tipo de sistema de gestin del contenido o CMS (Content Management System) integrado a un Sistema de gestin de aprendizaje o Learning Management System (LMS). Este concepto de LCMS procede del mbito de la formacin en organizaciones y del desarrollo de tecnologas educativas.
Sobre las diferencias entre estos dos grupos de aplicaciones, identicados como LMS y LCMS, se ha escrito mucho en la ltima dcada [45, 46, 12, 47, 48, 49, 13]. Las diferencias
parecen estar claras para los expertos en tecnologas educativas, pero quizs no tanto para los docentes y los expertos en informacin. A continuacin se presenta una gura con la comparacin de funcionalidades entre los LMS y los LCMS. Ver gura 2.6
2.4. Estndares
En eLearning resulta esencial la interoperabilidad y reusabilidad entre los atributos indispensables de los recursos educativos entre diferentes sistemas y desarrolladores de cursos, as
2.4. ESTNDARES
37
Figura 2.6: Comparacin de funcionalidades de los LMS y los LCMS (Basado en: [12] citado en [13])
como la interoperabilidad y modularidad entre sistemas. Por ejemplo, si se comparten formatos de intercambio de la informacin, as como un modelo de informacin para diferentes aspectos del eLearning, entonces distintos materiales podran ser intercambiados entre diferentes plataformas, y los docentes y diseadores de cursos podran reusar, modicar y extender los recursos sin replicar esfuerzos. Es por ello que han surgido diversos estndares y especicaciones en eLearning para modelar diferentes aspectos, de forma que se dena ese marco comn que aporte tales ventajas. Diferentes estudios han argumentado sobre la importancia de la interoperabilidad y los estndares en eLearning. [50, 51].
En este punto conviene claricar la diferencia entre estndar y especicacin de eLearning. Se denomina estndar de eLearning cuando algn organismo de estandarizacin ha aprobado cierto documento. En tanto que especicacin es cuando algn organismo o persona lo ha propuesto pero no ha sido an aprobado por ningn organismo de estandarizacin.
38
No obstante, muchos autores llaman tambin estndares a las especicaciones, por lo que es aceptado el uso de estndares para referirse tambin a cualquier especicacin. Algunos de los organismos ms conocidos que abordan especicaciones son: IETF Engineering Task Force), W3C (World Wide Web Consortium), OMG Group), IMS (Instructional Management Systems). Por el
2 3 1
(Internet
(Object Management un estndar es
contrario,
una especicacin desarrollada y acreditada por comits de estandarizacin especcos. Ejemplo de este tipo de comits incluye a: IEEE
5 4
(Institute of Electrical and Electronics

6
Engineers), ISO (Organizacin Internacional de Normalizacin), ANSI (American National Standards Institute), BSI (British Standards Institution), AENOR
7 8
(Asociacin Espaola de
Normalizacin y Certicacin), entre otros. Incluso, en algunas industrias, el producto no puede ser vendido hasta que no recibe la certicacin necesaria o es aprobada por el gobierno pertinente, como en el caso de los productos y servicios elctricos o electrnicos, acreditados por IEEE. Ver gura 2.7
Figura 2.7: Entidades participantes en estandarizacin de especicaciones.
1 http://www.ietf.org/ 2 http://www.w3.org/ 3 http://www.omg.org/ 4 http://www.ieee.org/index.html 5 http://www.iso.org/iso/home.html 6 http://www.ansi.org/ 7 http://www.bsigroup.com/ 8 http://www.aenor.es/aenor/inicio/home/home.asp
2.4. ESTNDARES
39
Los estndares son acuerdos internacionales documentados o normas establecidas por consenso mundial. Contienen las especicaciones tcnicas y de calidad que deben reunir todos los productos y servicios para cumplir satisfactoriamente con las necesidades para las que han sido creados y para poder competir internacionalmente en condiciones de igualdad. El objetivo primordial al crear un estndar es impedir que en el mercado se impongan determinadas tecnologas ofrecidas por las empresas de un mbito industrial concreto, evitando as que imperen intereses econmicos privados.
Las diferentes organizaciones internacionales de estandarizacin ofrecen deniciones ociales de lo que es un estndar. De acuerdo a la ISO, estndar se dene como lo que contribuye para hacer la vida ms fcil, y para incrementar la conabilidad y efectividad de los bienes y servicios que utilizamos. Tambin, segn la ISO, se trata de acuerdos documentados que contienen especicaciones tcnicas u otros criterios, para ser utilizados constantemente como reglas o deniciones de caractersticas, lo cual permiten asegurar qu materiales, productos, procesos y servicios son adecuados para sus propsitos.
Los estndares ofrecen:
Una base de comparacin.
Una medida de la calidad, cantidad o nivel.
Un consenso de opiniones entre individuos, grupos u organizaciones.
Como vimos en los prrafos anteriores, los estndares son desarrollados por organizaciones ociales con nimo de evitar que intereses privados determinen normas y garantizar la comunicacin entre los diferentes dispositivos y/o plataformas con los denominados estndares ociales o de jure. En contraposicin a stos estndares, se encuentran los designados de facto. Estos sin estar impuestos por ninguna organizacin, y a veces sin estar emitidos por ninguna norma, hacen que se conviertan en estndares al usarse de manera repetitiva. El estado ideal de un estndar es cuando un estndar de jure es tambin de facto.
40

Por lo tanto, una especicacin es una descripcin documentada de una tecnologa. Las
especicaciones son recomendaciones tcnicas y de calidad que no se han adoptado de manera ocial en un mbito tecnolgico o de cualquier otra ndole. Es decir, no es obligatorio su uso. La mayora de los estndares tampoco son obligatorios, ya que solo lo son cuando los impone la ley.En esta tesis, seguiremos el criterio de utilizar indistintamente los trminos estndar o especicacin.
2.4.1. El proceso de estandarizacin

El proceso de elaboracin de un estndar es similar al de creacin y aprobacin de las leyes. Una vez se ha realizado el grueso del trabajo, este debe ser raticado por un organismo ocial. Puede parecer un proceso lento y poco efectivo, pero hay que tener en cuenta que el xito de un estndar radica en su nivel de aceptacin. En este sentido, un grupo de estandarizacin debe ser un organismo que se encargue de recopilar requisitos de mltiples fuentes y elabore con ellos una especicacin consensuada [52]
Algunas especicaciones acaban convirtindose en estndar, lo que signica que han recibido una acreditacin ocial.
Figura 2.8: Proceso de estandarizacin
2.4. ESTNDARES
41
Para que una especicacin evolucione hacia estndar debe pasar por un proceso, el cual tiene sus fases(Ver Figura 2.8). Entre las principales fases en el diseo y desarrollo
de estndares segn Masie [53], se tienen:
Fase 1- Requisitos:
El proceso comienza con grupos denominados consorcios y formados
por gobiernos, empresas, individuos, acadmicos, etc. Se recogen requisitos e ideas y experiencias de la comunidad de usuarios, instituciones acadmicas, la industria y dems entes involucrados.
Fase 2- Especicaciones:
Expertos
en
realizar
especicaciones
preparan
un
borrador
tcnico del tema en cuestin, donde se presentan las principales ideas de la especicacin que se desea desarrollar.
Fase 3- Prueba y uso: Fase 4- Estndar:
Se desarrollan modelos de referencias y documentos especcos para
ser usados y validados por grupos especcos de usuarios.
Si la especicacin generada es vlida y ampliamente aceptada despus
del perodo de prueba, puede ser enviada a cuerpos especializados para someterlos a su aprobacin como estndar. Algunas ocinas de acreditacin en eLearning son IEEE LTSC (Learning Technology Standards Committee), ANSI Standards Institute), o el CEN/ISSS
10 9
(American National
(European Committee for Standardization /
Information Society Standardization System). Una vez aprobada la especicacin ser reconocida como un estndar (por ejemplo, ISO) aprobado.
A continuacin se muestran las especicaciones ms importantes relacionadas con el eLearning que han aportado cada una de las organizaciones citadas. No todas ellas se comentan con el mismo nivel de detalle por no ser indispensables para esta investigacin
AICC:
Las especicaciones del AICC cubren nueve reas principales, que van desde los objetos de aprendizaje (LO) hasta los Sistemas de Gestin del Aprendizaje (LMS). Normalmente,
9 www.ansi.org/ 10 http://www.cen.eu/
42
cuando una compaa dice que cumple con las especicaciones AICC, signica que cumple con al menos una de estas Guas y Recomendaciones (AICC Guidelines and Recommendations, AGRs).
Se destaca del CMI Guide For Interoperability (CMI001), la cual estaba relacionado con la gestin tanto de cursos como de alumnos en diferentes sistemas CBT.
Las principales funciones de esta gua eran:
Desarrollo de la estructura de un curso
Pruebas
Gestin de usuarios
Gestin de datos
Por supuesto, la interoperatividad es una de las caractersticas de las que se ocupa AICC en sus AGR, las cuales especcamente abordan tres casos en los que una compaa necesita usar lecciones que se crean con diferentes sistemas y herramientas de autor y se ejecutan en un sistema especco:
Migracin de un curso de un sistema a otro distinto: La carga sin problemas en un LMS de cursos creados por terceros se consigue deniendo el curso como una entidad totalmente independiente de la plataforma, y creando un sistema (cheros) de descripcin del curso que pueda ser entendido por cualquier plataforma.
Comunicacin entre un sistema y la leccin: de tal modo que el curso pueda obtener informacin necesaria sobre el usuario y despus transmitir los resultados de las interacciones y evaluaciones realizadas por el mismo a la plataforma a n de su almacenamiento y tratamiento estadstico. Para este caso se dene un mecanismo de comunicacin entre el curso y la plataforma, y un conjunto de datos mnimos que deben ser transmitidos del curso a la plataforma y viceversa. AICC describe dos mecanismos, uno ms sencillo y extendido basado en el protocolo http, y otro mediante una API.
2.4. ESTNDARES
43
Almacenamiento de los datos de utilizacin del sistema de un usuario: Los datos referentes a lecciones superadas, leccin actual, tiempo invertido, intentos, etc. Se almacenan en un sistema de cheros independiente de la plataforma.
ADL:
Este organismo se apoy en las anteriores iniciativas para conformar su propio estndar: SCORM, Shareable Content Object Reference Model (Modelo de Referencia para Objetos de Contenidos Intercambiables). Combina muchas especicaciones (de IMS, IEEE y AICC principalmente) y las particulariza para un caso concreto como es el aprendizaje sobre la Web. Las especicaciones, debido a su generalidad, dejan sin concretar aspectos que son necesarios para facilitar la implementacin nal, y que SCORM trata precisar para lograr una mayor compatibilidad. Este estndar en particular tiene relevancia con esta investigacin, por lo cual la explicacin ser mas detallada.
Concretamente SCORM se apoya en las siguientes especicaciones:
IEEE Data Model For Content Object Communication
IEEE Learning Object Metadata (LOM)
IEEE Extensible Markup Language (XML) Schema Binding for Learning Object Metadata Data Model
IEEE ECMAScript Application Programming Interface for Content to
Runtime Services Communication
AICC CMI001 Guidelines for Interoperability
AICC Launch
IMS Content Packaging
IMS Simple Sequencing.
44

Actualmente es el modelo ms utilizado en la industria y el que cuenta con mayor cantidad
de herramientas que lo soportan. Esta especicacin permite:
Poder usar un LMS basado en Web para lanzar diferentes contenidos que se han desarrollado por varios autores usando herramientas de autor de diversos vendedores.
La posibilidad de usar con diversos LMS de diferentes vendedores para lanzar un mismo contenido.
La disponibilidad de mltiples productos o entornos LMS basados en Web para acceder a un almacn comn de contenidos Con SCORM, ADL propone un modelo de metadatos y estructura de los cursos (CAM), un entorno de ejecucin (RTE), y un modelo de secuenciacin y navegacin de los contenidos (SN), cada uno de ellos organizados en un libro independiente al que se aade un libro con un enfoque ms general, que resume toda la especicacin (Overview).
Figura 2.9: Libros que componen la especicacin de SCORM
En la gura 2.9 The SCORM Overview. Contiene una descripcin general de la iniciativa de ADL, un anlisis de SCORM, y un resumen de las especicaciones tcnicas contenidas en
2.4. ESTNDARES
las siguientes secciones.
45
SCORM Content Aggregation Model (CAM). Incluye una gua para identicar y agregar recursos dentro de un contenido de aprendizaje estructurado. En este libro se describe el SCORM Content Packaging o empaquetado de contenidos, en el que se identican los cursos y se distinguen los objetos de aprendizaje compartibles (Sharable Courseware Object, SCO), curso o componente de un curso que cumple con los requisitos de interoperabilidad, durabilidad y que dispone de la informacin suciente para poder ser reutilizado y accesible.
Un SCO es la mnima unidad intercambiable entre sistemas compatibles con SCORM, y consiste en un objeto de aprendizaje que incluye un mdulo software (el API de SCORM) que le permite comunicarse con el entorno de ejecucin proporcionado por el LMS. Adems se identican los recursos bsicos (assets) que son elementos bsicos, como cheros de texto, audio, video, etc. Estos recursos bsicos se agrupan en los SCOs. SCORM CP se sustenta sobre la especicacin IMS Content Packaging que se detalla en prximas pginas. Tcnicamente un SCO es un chero comprimido (.zip o .jar) que contiene un descriptor conforme a la especicacin de IMS Content Packaging. SCORM Run-Time Environment (RTE). Este libro incluye una gua para lanzar contenidos y poder realizar un seguimiento dentro de un entorno Web. Toma como punto de partida la recomendacin CMI001 Guidelines for Interoperability de AICC. RTE proporciona un entorno estndar en el que presentar un objeto de aprendizaje (en este caso un SCO) que es capaz de intercambiar datos con el LMS mediante el API de SCORM (para cuya implementacin se usa el lenguaje estndar ECMAScript, ms comnmente conocido por javascript). El LMS se encarga de enviar los contenidos al alumno y el contenido intercambia la informacin sobre el alumno y el seguimiento de su interaccin con el curso al LMS.
SCORM Sequencing and Navigation (SN). Es la informacin que permite controlar cmo se van a presentar dichos contenidos al usuario (en cuanto a ordenacin de los contenidos e interaccin con el usuario). Esta presentacin no tiene por qu ser siempre la misma, ya que puede depender de las respuestas o comportamiento de los alumnos. Para esta especicacin
46
Figura 2.10: Diagrama ilustrativo de SCORM CAM
ADL tom como punto de partida la especicacin IMS Simple Sequencing, que veremos a continuacin.
IMS:
IMS elabora sus especicaciones mediante la recoleccin de requisitos desde sus miembros, usuarios y otros grupos, a travs de reuniones que se celebran para atacar aspectos crticos sobre la interoperatividad entre plataformas. Los borradores de las especicaciones, basados en estos requisitos se publican internamente para someterlos a pruebas en las que participan los miembros del consorcio y desarrolladores que colaboran a travs de redes de desarrollo establecidas para tal efecto.
Una vez que el borrador ha sido probado y validado por el Comit Tcnico de IMS se libera como documento pblico. Una vez publicada la especicacin, puede ser propuesta a organismos de estandarizacin para su adopcin como estndar nacional o internacional, si
2.4. ESTNDARES
47
bien lo normal es que transcurra cierto tiempo prudencial, mientras terceras partes que no han participado en el proceso de creacin de la especicacin hacen uso de sta, contribuyendo a su futura mejora.
La estructura de las especicaciones de IMS se encuentra detallada al menos en tres documentos:
Gua de Implementacin y consejos.
En l se incluyen la forma de uso de la especica-
cin, ejemplos, la relacin con otras especicaciones, y cualquier tipo de informacin complementaria que pueda servir de ayuda. Se trata de un documento de introduccin que servir para entender los conceptos generales con los que se trata.
Modelo de Informacin.
Documento que describe de manera formal, los datos as como su
estructuracin, detallando cada uno de los elementos considerados en la especicacin. El modelo que se propone en este documento es independiente del formato fsico en el que nalmente se representa la informacin.
Documento de Enlace.
Documento que ofrece la forma de representar la estructura de
datos de la especicacin, generalmente, en XML. Adicionalm-ente se proporciona el XML Schema que nos permite comprobar la validez de la estructura de un documento que hayamos creado, respecto a la especicacin a la que est asociado.
IMS tiene muchas especicaciones ya que cada una de ellas est enfocada en una necesidad distinta del proceso de enseanza. A continuacin vamos a describir con ms detalle algunas de las ms relevantes:
a. Meta-Data Aqu se ndica cmo los contenidos deben ser identicados o etiquetados y cmo se debe organizar la informacin de los alumnos de manera que se puedan intercambiar entre los distintos servicios involucrados en un sistema de gestin de aprendizaje (LMS). Tras la publicacin del estndar IEEE 1484.12.1 2002, IEEE Standard for Learning Object Metadatah
11
(LOM)
en Julio de 2002, siendo IMS uno de los miembros que contribuy y particip en su proceso
11 ttp://ltsc.ieee.org/wg12/20020612-Final-LOM-Draft.html
48
de estandarizacin, la especicacin sobre meta-datos, pas a denominarse IMS Learning Resource Meta-data y se adapt al nuevo estndar de IEEE, recibiendo la etiqueta de Versin 1.3.
b. Content Packaging
Esta especicacin provee la funcionalidad para describir y empaquetar contenidos de forma que puedan ser procesados por otro LMS diferente. El empaquetamiento de contenidos est vinculado a la descripcin, estructura, y ubicacin de los materiales on-line, y a la denicin de algunos tipos particulares de contenidos. Esta especicacin ha sido comercializada por Microsoft bajo el nombre de LRN (Learning Resource Interchange).
IMS Content Packaging (IMS CP) ofrece una forma de empaquetar en un archivo comprimido tipo .zip (el mismo formato que usan los archivos de distribucin de Java o simplemente .jar) los contenidos educativos tales como cursos individuales, conjuntos de cursos, o cualquier tipo de recurso necesario en el proceso educativo (evaluaciones o exmenes, entre otros). Al distribuir una serie de contenidos empaquetados segn IMS CP, existe un documento fundamental que es el Maniesto. Dicho documento es un chero XML, cuyo nombre ha de ser imsmanifest.xml, en el que se describe la estructura de los contenidos incluidos en el paquete tal y como podemos apreciar en la gura siguiente 2.11.
Figura 2.11: Estructura del Maniesto
En el Maniesto, se describen dos niveles diferentes: organizacin del contenido del paquete y recursos utilizados por dichos contenidos. Una organizacin es una posible ordenacin jerrquica en forma de rbol de los Recursos de un paquete. El estndar permite que un Ma-
2.4. ESTNDARES
49
niesto contenga distintas organizaciones sobre los Recursos del paquete, dando as lugar a distintas vistas o cursos a partir de los mismos contenidos. Esta posibilidad podra facilitar la adaptacin del contenido a diferentes dispositivos, diferentes niveles de dicultad, diferentes idiomas, etc. El elemento bsico de estructuracin que se usa al denir las organizaciones son los tems. A cada tem se le puede asociar un Recurso, de modo que el rbol de tems es, efectivamente, una estructuracin de los Recursos del paquete.
Por su parte la etiqueta Resources, engloba la descripcin de un conjunto de recursos y sus dependencias. Se puede hacer una relacin casi directa entre un Recurso y un chero con contenidos visualizables, como por ejemplo cheros HTML, animaciones en Flash, imgenes, documentos PDF, entre otros. En realidad, en cada Recurso se puede incluir informacin sobre los cheros que lo componen, el tipo de los mismos (que puede ser uno de los tipos ya denidos por el estndar o una extensin de los propuestos) y, opcionalmente, metadatos con informacin adicional sobre dicho recurso. Se muestra en la gura presenta la estructura jerrquica en rbol del Maniesto. En resumen, el Maniesto es un chero XML que describe tanto los contenidos de un paquete como su organizacin, aadiendo informacin adicional (metadatos) que pueden ser procesada para llevar a cabo diversas tareas como catalogacin de contenidos o seleccin de un subconjunto de estos segn ciertas condiciones (adaptacin segn el contexto: idioma, edad o nivel de aprendizaje del alumno). 2.12,un esquema que
c. Question y Test Interoperability
Esta especicacin describe la forma de representar preguntas individuales o tems (assesment item) y gestionar evaluaciones o exmenes completos (assessment). Su objetivo es conseguir que tanto las evaluaciones cmo los resultados sean intercambiables entre los diferentes LMS. As, podemos disponer de almacenes de preguntas y bases de datos con los resultados obtenidos por los alumnos, a los cuales se puede acceder desde cualquier sistema de enseanza aelectrnico.
50
Figura 2.12: Estructura del chero imsmanifest.xml
Mientras que en versiones anteriores a la actual(actual versin 2.1 v2 de 2006), el principal foco de atencin fue cmo presentar la pregunta al usuario, ahora se denen los posibles tipo de interacciones por parte de ste: introducir texto, seleccionar un trozo de texto, seleccionar uno o ms elementos de una lista, crear asociaciones entre elementos de dos listas, etc. Adems de todas las interacciones contempladas, la especicacin introduce un tipo de interaccin abstracta que los desarrolladores pueden extender y crear nuevas formas de interaccin para poder introducir nuevos tipo de preguntas.
Tambin tiene plantillas de preguntas para crear preguntas similares, pero en las que hay partes variables que se seleccionan de forma aleatoria entre un conjunto de valores denidos. Otras de las novedades que introduce son los tems adaptativos, que permiten su correccin
2.4. ESTNDARES
51
adaptativa en funcin de una secuencia de intentos. Esto permite, por ejemplo, evitar que se le planteen preguntas adicionales al alumno en funcin de su respuesta actual.
d. Learner Information Package Specication
Dene estructuras en XML para el intercambio de informacin sobre los alumnos (individuales o grupos) entre diferentes LMS, sistemas de recursos humanos, sistemas de gestin del conocimiento, etc.
La existencia de formatos consensuados para la denicin de expedientes de alumnos permite su exportacin entre sistemas educativos diferentes. LIP dene qu informacin debe incluirse en el expediente y el formato para representarla. Dentro de los estndares para perles y expedientes debe contemplarse tanto la informacin esttica, que no depende de la interaccin con el sistema, como pueden ser los datos personales, como la informacin variable que se genera o se modica a medida que el alumno avanza en su proceso de aprendizaje, como pueden ser las calicaciones.
LIP incluye informacin de otra especicacin sobre informacin de alumnos denominada Personal and Private Information (PAPI) de IEEE y est complementada por otra denominada Accessibility for LIP que dene nuevas estructuras de datos para poder especicar preferencias de accesibilidad que tengan en cuenta las caractersticas del alumno, de modo que el LMS se pueda adaptar a dichas caractersticas. El objetivo es poder denir el orden en el que se presentan los objetos de aprendizaje o las reglas para seleccionar un objeto de aprendizaje entre varios posibles en funcin del comportamiento o de las respuestas del alumno.
e. Learning Design
Dene cmo describir y codicar las metodologas de aprendizaje y cmo incorporarlas en una solucin eLearning. Soporta el uso de un amplio rango de pedagogas para aprendizaje on-line y permite denir nuevas metodologas pedaggicas haciendo uso de un lenguaje gen-
52
rico y exible diseado para permitir la denicin de muchas pedagogas diferentes.
IMS Learning Design (IMS LD) ha sido muy bien recibida por los educadores, especialmente pedagogos, pues su objetivo radica ms en el diseo de pautas metodolgicas que en la mera distribucin de los contenidos. Actualmente est recibiendo gran protagonismo y algunos LMS como Moodle comenzaron a soportar esta especicacin.
Esta especicacin es un elemento neural en esta investigacin, por lo cual se extender ms su explicacin. Con IMS LD se puede considerar que los recursos son parte esencial para la adquisicin de conocimientos por parte del alumno, pero no son sucientes. Es decir, con IMS LD la adquisicin de este conocimiento vara en funcin del uso al que sea sometido el ambiente de enseanza aprendizaje, siendo un proceso ms complejo de aprendizaje en el que un mismo ambiente puede dar lugar a diferentes conocimientos dependiendo de las actividades realizadas con stos por docentes y alumnos.
Figura 2.13: Modelo conceptual de IMS Learning Design
2.4. ESTNDARES
53
Tal como podemos apreciar en la gura 2.13, el diseo de un aprendizaje es representado por la siguiente idea: todas las personas (person) asumen un rol determinado (role), que puede ser alumno (learner) o miembro del equipo docente (sta ). El rol lleva asociado una serie de posibles actividades (activity) que dicha persona puede realizar en busca de la consecucin de un objetivo (outcome). Al igual que con los roles, el modelo tambin especica una especializacin en cuanto a las actividades, que pueden ser de aprendizaje o de soporte. Las actividades se realizan en un entorno (environment) compuesto de servicios (service) y objetos de aprendizaje (learning object) necesarios para que las personas de distintos roles realicen dichas actividades.
Las UoL son ms complejas que los objetos de aprendizaje que dene SCORM, y permiten oportunidades de aprendizaje igualmente ms complejas y ricas.
Bsicamente, el principal uso de IMS LD es modelar unidades de aprendizaje introduciendo la informacin de IMS LD en un paquete de contenidos preferiblemente, aunque no obligatorio conforme a la especicacin de IMS Content Package (IMS CP), la misma especicacin adoptada por SCORM para empaquetar sus SCOs. IMS CP describe sus contenidos por medio de un chero XML: el Maniesto, cuyo nombre ha de ser imsmanifest.xml, y que se incluir junto con los recursos necesarios en un chero comprimido, en formato ZIP (puede ser por tanto un .JAR de Java). El Maniesto puede incluir vistas estructuradas de los recursos contenidos en el paquete.
Cada una de estas vistas es descrita como una jerarqua de elementos, a los que se denomina como una organizacin. Cada elemento de la organizacin hace referencia a un recurso que puede estar incluido en el propio paquete o bien ser un recurso externo accesible mediante una URL. Como se muestra 2.14.
La integracin de IMS LD en un paquete de contenidos IMS CP para obtener una Unidad de Aprendizaje, se lleva a cabo incluyendo un nuevo elemento al conjunto de organizaciones: el elemento learning-design. Ver gura 2.15
54
Figura 2.14: Estructura de un paquete de contenidos IMS CP
f. Digital Repositories
La especicacin IMS Digital Repositories v1.0, publicada el 30 de Enero de 2003, proporciona recomendaciones para la interoperacin entre almacenes de contenidos digitales. Esta especicacin dene un almacn digital (digital repository) como una coleccin de recursos que estn accesibles en la red sin que fuera necesario a priori el conocimiento de la estructura de dicha coleccin. Por eso, dicha especicacin recomienda su implementacin mediante servicios, para garantizar una interfaz comn a estos.
Reusable Denition of Competency or Educational Objective Specication. El trmino competencia aparece como parte de un plan de aprendizaje o de carrera, como pre-requisitos para acceder a un determinado nivel educativo, o como resultados (habilidades, conocimientos, tareas, etc.) obtenidos tras un proceso de aprendizaje. Esta especicacin proporciona una nomenclatura estndar para etiquetar los distintos componentes de un sistema de competencias y las caractersticas principales de una competencia, independiente de su uso en un contexto en particular, permitiendo as su interoperabilidad entre distintos LMS, sistemas de recursos
2.4. ESTNDARES
55
Figura 2.15: Estructura de una UoL
humanos, etc. IEEE LTSC ha solicitado y obtenido el permiso de IMS para utilizar RDCEO, cuya nica versin publicada data de Octubre de 2002, como base para una denicin estndar del concepto de competencia.
g. Vocabulary Denition and Exchange
IMS VDEX (Vocabulary Denition and Exchange) dene una gramtica para el intercambio de listas de valores o vocabularios, que puedan ser procesados automticamente y entendibles por las personas. Permite por ejemplo denir valores para ser utilizados en IEEE LOM, IMS LIP o en ADL/SCORM.
h. IMS Enterprise Information Model
Dene los modelos de datos que permiten la integracin y el intercambio de datos de los LMS con los otros sistemas de gestin de una empresa o centro educativo como, por ejemplo,
56
la gestin de alumnos o la administracin general.
i. Enterprise Services
IMS Enterprise Services es la denicin de cmo los sistemas gestionan el intercambio de informacin que describen personas, grupos y las adscripciones o pertenencias de las primeras a los ltimos en desde el punto de vista organizativo y no educativo, como en el caso de IMS LIP.
j. ePortfolio
El portafolio electrnico es una coleccin de documentos en formato electrnico que dan idea de las habilidades, formacin y desarrollo profesional de una persona. El concepto en el que se basa es el mismo que cuando se quiere juzgar la calidad de un fotgrafo y se le pide que ensee sus trabajos previos, o una modelo cuando entrega su book a una agencia de modelos. Esta especicacin se ha creado para hacer que los portafolios electrnicos se puedan intercambiar entre distintas instituciones y sistemas.
El objetivo es lograr que se pueda hacer un mejor seguimiento de las competencias de un alumno, que se mejore su impresin del proceso educativo y su desarrollo personal incluso en formacin continua o no reglada. Esto debera simplicar el intercambio de portafolios entre las instituciones educativas y los centros de trabajo. Esta visin del aprendizaje permanente, a lo largo de toda la vida profesional de una persona, se ha denominado Lifelong Learning(aprendizaje a lo largo de la vida) y es una prioridad clave para la Comisin de la Unin Europea, que se ha marcado un periodo de 10 aos (desde 2000 a 2010) para fomentar la formacin continua.
k. Shareable State Persistence
Describe una extensin a los entornos de ejecucin (como por ejemplo SCORM RTE) que permite el almacenamiento y el acceso compartido a la informacin de estado entre los objetos
2.4. ESTNDARES
57
de contenido. Trata de solucionar el problema de que un contenido pueda almacenar informacin de estado en el entorno de ejecucin para que pueda ser recuperada posteriormente por ese contenido o por otro. Esta caracterstica es vital para la ejecucin de contenido altamente interactivo como, por ejemplo, las simulaciones y hasta ahora se estaba realizando con mtodos y formatos propietarios, dicultando la estandarizacin completa de los sistemas.
l. Resource List Interoperability
Detalla como intercambiar metadatos estructurados entre sistema que almacenan y proporcionan recursos con el propsito de crear listas de recursos y aquellos sistemas que recogen y organizan estas listas de recursos con un propsito educativo o de entrenamiento. Un ejemplo tpico citado en la especicacin como lista de recursos es una lista de trabajos o artculos para que lean los alumnos durante un curso.
m. AccessForAll Meta-data
Pretende la identicacin de recursos que coincidan con las preferencias o necesidades de los usuarios, expresadas usando la especicacin IMS Accesibility for LIP. Estas preferencias incluyen la necesidad de utilizar presentaciones alternativas de los recursos, mtodos alternativos para controlar recursos, recursos alternativos a los predeterminados y mejoras o necesidades de ayuda que tenga el usuario. Esta especicacin proporciona un lenguaje comn para identicar y describir los recursos primarios o por defecto, y las alternativas equivalentes para dicho recurso.
IEEE LTSC:
Se trata de un organismo que promueve la creacin de una norma ISO, una normativa estndar real de amplia aceptacin. El LTSC se encarga de preparar normas tcnicas, prcticas y recomendaciones para el uso del software, herramientas, tecnologas y mtodos de diseo
58
que facilitan el desarrollo, despliegue, mantenimiento e interoperatividad.
Est compuesto por ms de una docena de grupos de trabajo (working groups o WGs) y grupos de estudio (study groups o SGs) que desarrollan especicaciones para la industria del eLearning.
Los siguientes grupos de trabajo son parte de las actividades generales de la IEEE LTSC:
EEE 1484.1 Architecture and Reference Model
IEEE 1484.3 Glossary
IEEE 1484.4 Digital Rights Expression Language DREL
Los siguientes grupos de trabajo son parte de las actividades relacionadas con los datos y meta-datos:
IEEE 1484.12 Learning Object Metadata
IEEE 1484.14 Semantics and Exchange Bindings
IEEE 1484.15 Data Interchange Protocols
Los siguientes grupos de trabajo son parte de las actividades relacionadas con los LMS y las aplicaciones:
IEEE 1484.11 Computer Managed Instruction
IEEE 1484.18 Platforms and Media Proles
IEEE 1484.20 Competency Denitions
LTSC tambin trabaja en forma coordinada con otra iniciativa denominada ISO JTC1 SC36, que es un subcomit formado conjuntamente por ISO y IEC (International Electrotechnical Commission), dedicado a la normalizacin en el mbito de las Tecnologas de la Informacin para la formacin, educacin y aprendizaje.
2.4. ESTNDARES
59
En algunos casos el IEEE LTSC ha comenzado una especicacin desde cero, pero en otros casos el trabajo ha sido retomado a partir de especicaciones de otras organizaciones como IMS o AICC. Este es el caso particular de los estndares IEEE 1418.11 y P1418.12. En este ltimo, IEEE LTSC cre la nocin de metadato (informacin sobre los datos) estableciendo una descripcin ms detallada de los contenidos del curso, tomando como punto de partida la ofrecida por la AGR010 de la AICC, la cual mejor.
a. Learning Object Metadata
Como ya hemos comentado, los metadatos son datos acerca de los propios datos. Esto es, una forma de denir las caractersticas de los datos de forma que nos ayuden en su bsqueda, identicacin, clasicacin, procesado y representacin. Es por tanto, la informacin relevante para nuestro sistema, extrada de la propia informacin relevante para el usuario. De forma coloquial, lo que se busca mediante esta informacin complementaria es poder saber cul es el contenido y el propsito de un objeto de aprendizaje sin tener que acceder a dicho contenido. Por tanto, los metadatos aportan informacin orientada a hacer ms eciente la bsqueda y utilizacin de los recursos. Los metadatos se pueden aplicar tanto a objetos de aprendizaje concretos como a cursos completos o a partes del curso.
Los estndares de metadatos permiten el intercambio de informacin entre distintos sistemas de eLearning, independientemente de la implementacin de cada uno en cuanto a la forma de almacenar la informacin.
Uno de los primeros estndares fue el denido por DCMI. Cada uno de los elementos de este estndar est denido por un conjunto de 15 atributos del estndar ISO/IEC 11179, incluyendo por ejemplo: ttulo, nombre, idioma, comentarios o identicador. A partir los esfuerzos previos hechos para la descripcin de recursos educativos de DCMI y con la ayuda aportada por IMS y el proyecto europeo ARIADNE, se cre IEEE Learning Object Meta-Data (LOM), actualmente el estndar de e-learning formalmente aprobado que goza de mayor aceptacin (estndar IEEE 1484.12.1 2002), y que ha sido adoptado en la especicacin de IMS Learning
60
Resource Metadata (si bien el proceso de estandarizacin fue promovido por IMS).
El objetivo de LOM es la creacin de descripciones estructuradas de recursos educativos. Su modelo de datos especica qu aspectos de un objeto de aprendizaje deberan ser descritos y qu vocabularios se pueden utilizar en dicha descripcin. Esta es una descripcin jerrquica con nueve apartados principales que agrupan el resto de campos:
General
Aqu se describe el objeto educativo. Incluye campos como identicador del objeto
de aprendizaje, ttulo, descripcin, etc.
Lifecycle
Almacena
un
histrico
del
objeto
su
estado
actual.
Detalla
quines
han
interactuado con este objeto desde que fue creado, y el tipo de interaccin que han realizado.
Meta-Metadata
Agrupa informacin sobre los metadatos. Esto puede parecer redundante a
primera vista pero resulta muy interesante tener informacin como quin ha contribuido a la creacin de los metadatos y el tipo de contribucin que ha realizado.
Technical
Incluye la informacin tcnica del recurso de aprendizaje, tal como tamao,
ubicacin, o formato en el que se encuentra. Adems, en este elemento se almacenan los posibles requisitos tcnicos necesarios para poder usar el objeto al que se reeren los metadatos.
Educational
En este elemento se encuentran las diferentes caractersticas pedaggicas del
objeto. Tpicamente se incluyen campos como tipo de recurso diagrama, ejercicio, gura -, nivel de interactividad entre el usuario y el objeto alta, media, baja-, o el contexto de uso del recurso universidad, enseanza primaria, secundaria, doctorado-, entre otros.
Rights
Se incluyen los detalles sobre la propiedad intelectual del recurso. Tambin se detallan
las condiciones de utilizacin y el precio en caso de tenerlo.
2.4. ESTNDARES
61
Relation
Explica el tipo de relacin que tiene el recurso de aprendizaje con otros objetos de
aprendizaje. Posee un par nombre-valor en el que detalla el nombre del objeto relacionado y el tipo de relacin: espartede, basadoen, entre otros.
Annotation
Incluye comentarios sobre la utilizacin del objeto de aprendizaje, adems de su
autor y la fecha de creacin.
Classication
Nos informa si el objeto de aprendizaje pertenece a algn tema en concreto.
Por ejemplo, es aqu dnde se almacenara que un objeto de aprendizaje pertenece a la asignatura de Fsica o a la de Matemticas, Literatura, etc. El modelo de datos indica tambin qu elementos de la descripcin pueden repetirse (cmo acabamos de ver en las anidaciones de Classication) y cules no. Adems, en algunos campos el contenido es de tipo libre, pudindose introducir cualquier cadena de texto (para la cual se puede especicar adems el idioma) y para otros campos se dispone de un conjunto de valores concretos entre los que hay que elegir (es decir, se tiene un vocabulario limitado y controlado por la especicacin).
CEN/ISSS:
El Centro Europeo de Normalizacin, fundado por la Comisin Europea, comenz su trabajo en 1997. CEN/ISSS ha establecido un procedimiento para la colaboracin y la consecucin de consenso denominado CEN Workshops Agreements (CWA), cuyo objetivo es proporcionar a los miembros industriales una herramienta eciente para establecer acuerdos tcnicos dnde no es necesario desarrollar un estndar. Parte de este trabajo est relacionado con los requisitos propios de la Unin Europea, teniendo en cuenta la diversidad lingstica y cultural.
La organizacin ha establecido CWAs en multitud de reas relacionadas con las TIC, siendo de especial inters el CWA in Learning Technologies. El grupo de trabajo en Tecnologas de Aprendizaje (Learning Technologies Workshop, LTW) se cre al principio de 1999 con el objetivo de potenciar el desarrollo de estndares para eLearning en Europa. Algunos (sera
62
muy extenso listarlos todos) de los CWA publicados por el LTW del CEN/ISSS se muestran en la tabla 2.1.
Tabla 2.1: Algunos acuerdos producidos por CEN/ISSS
Referencia CWA 14590 CWA14643 CWA14644 CWA14645 CWA 15515
CEN/ISSS Workshop Agreements

Descripcin de las caractersticas del idioma Internacionalizacin de IEEE LOM Estndares de Aseguramiento de la Calidad Disponibilidad de versiones de idioma alternativo en IEEE LOM Meta-Framework europeo para competencias en TICs. Revisin del estado del arte, aclaracin de realidades y recomendaciones para futuros pasos
Fecha
Octubre, 2002
Octubre, 2002 Enero, 2003
Enero, 2003
Febrero, 2006
2.4.2. Objetivos que persiguen los estndares de eLearning

Sin duda, el mayor problema que aborda la industria del eLearning en la actualidad es la ausencia de unas metodologas tcnicas, documentales y psicopedaggicas comunes y aceptadas, que garanticen los objetivos de accesibilidad, interoperabilidad, durabilidad y reutilizacin de los materiales curriculares encontrados en las redes.
En el mbito educativo, los estndares permiten evaluar, entre otros aspectos: los centros y la actividad acadmica; los contenidos educativos y la experiencia de aprendizaje; as como los resultados del aprendizaje. Su aplicacin a gran escala facilitara la comparacin de los programas y actividades educativas, as como los resultados y las competencias de alumnos de distintos centros, regiones e incluso pases.
Adems, habr que tener en cuenta un conjunto de estndares relacionados principalmente relativos a aspectos tcnicos, legales y de procesos, que se han desarrollado fuera del mbito de las tecnologas educativas pero que son utilizados conjuntamente con los estndares de calidad
2.4. ESTNDARES
y los de tecnologas de eLearning.
63
En cuanto a los estndares propiamente relativos a las tecnologas educativas, principalmente se encargan de hacer posible la interoperabilidad entre los distintos componentes de los entornos de aprendizaje, como pueden ser las herramientas de autora y de creacin de contenidos educativos, los sistemas de gestin del aprendizaje, los recursos y los servicios educativos.
Segn
[54, 51, 55, 56, 57, 58, 59, 60]es posible extraer las reas de estandarizacin ms
importantes en el mbito de las tecnologas educativas, y que se reeren a: los contenidos (modelos de contenido, metadatos, empaquetado); el diseo y secuenciacin de actividades de aprendizaje; la evaluacin de los contenidos y el proceso educativo; la accesibilidad de contenidos e interfaces; las plataformas de aprendizaje (despliegue de contenidos, gestin de cursos, de objetos educativos y de informacin sobre los alumnos; registro de informacin sobre el proceso de aprendizaje, entre otros.); la codicacin de informacin sobre los alumnos y otros participantes del proceso educativo; la creacin de portafolios electrnicos, as como el almacenamiento y la distribucin de contenidos mediante repositorios digitales.
Hay estndares genricos apoyados por diferentes organismos que, desde hace aos, establecieron sus propias especicaciones. Actualmente se est produciendo una convergencia hacia estndares comunes e intercambiables que soportan la denicin de recomendaciones y nuevos estndares para campos de actividad especcos como en el caso del eLearning.
Las principales razones que impulsan la creacin de estndares en el rea de eLearning son [61]:
Proteccin de la inversin ante quiebra de proveedores.
Portabilidad de contenidos de cursos entre diferentes tecnologas de adiestramiento y/o plataformas eLearning.
Integracin de iniciativas eLearning con sistemas de Recursos Humanos Corporativos, Sistemas de Control o Administracin de gestin acadmica.
64

Integracin de plataformas eLearning en la infraestructura tecnolgica existente.En denitiva, la mejora del eLearning.
Los objetivos que persiguen cumplir los estndares eLearning son [62]
Durabilidad: Que la tecnologa desarrollada con el estndar evite la obsolescencia de los cursos.
Interoperabilidad: Que se pueda intercambiar informacin a travs de una amplia variedad de LMS o LCMS.
Accesibilidad: Que se permita un seguimiento del comportamiento de los alumnos.
Reutilizacin: Que los distintos cursos y objetos de aprendizaje puedan ser reutilizados con diferentes herramientas y en distintas plataformas.
Adaptabilidad: Los estndares se reeren al hecho de poder facilitar la adaptacin o personalizacin del entorno de aprendizaje.
Productividad: Si los proveedores de tecnologa eLearning desarrollan sus productos siguiendo estndares comnmente aceptados, la efectividad de eLearning se incrementa signicativamente y el tiempo y costos se reducen.
2.4.3. Futuro de los estndares de eLearning

En los prximos aos, el trabajo de las distintas organizaciones que estn trabajando en las especicaciones para estndares eLearning, estar centrado en los siguientes temas [63]:
Repositorio de Contenidos: Las organizaciones estn orientando su esfuerzo en desarrollar estndares de contenidos eLearning. El principal objetivo es tener repositorios de objetos de aprendizaje reutilizables, de tal manera que puedan ser agrupados en objetos de aprendizaje adaptable y expedido por cualquier plataforma eLearning. Sin embargo, uno de los mayores problemas al que se enfrenta hoy en da la industria del eLearning es la interoperabilidad entre distintos sistemas de aprendizaje que quieran compartir sus contenidos.
2.5. PERSPECTIVA DEL CONCEPTO DE AVEA EN ELEARNING

Internacionalizacin y Localizacin: Los distintos grupos que estn
65
desarrollando
especicaciones para eLearning participan de forma activa en todo el mundo, y cada da existe una mayor colaboracin entre ellos. Esto genera dos desafos: la creacin de estndares culturalmente neutrales (internacionalizacin), y la adaptacin de los estndares a las necesidades locales (localizacin).
Programas de certicacin: Existe un creciente nfasis en crear test de compatibilidad y programas de certicacin. ADL est trabajando en un programa de certicacin. Actualmente slo existen los programas de certicacin de AICC.
Arquitectura: La industria del eLearning ha estado creciendo sin tener una clara visin de los componentes de un sistema de eLearning y de la forma en que interactan. La necesidad de denir una arquitectura global es crtica para la evolucin del desarrollo de estndares.
2.5. Perspectiva del concepto de AVEA en eLearning

La preocupacin por lograr una conceptualizacin ms acorde a lo que ocurre en los espacios educativos apoyados por las tecnologas de informacin y comunicacin, es lo que ha hecho que existan diversas acepciones y propuestas de signicados sobre los ambientes de enseanza aprendizaje para eLearning. As, la revisin hecha al respecto, se resume en la tabla 1, con la presentacin en orden cronolgico ascendente, de algunas de las deniciones sobre entorno de enseanza aprendizaje para eLearning y ambiente de enseanza aprendizaje para eLearning, a los nes de justicar la conceptualizacin que ser, en denitiva, tomada en cuenta para este trabajo. Ver tabla 2.2
Tabla 2.2: Adaptacin sobre deniciones de EVEA para eLearning y AVEA para eLearning [6]
EVEA
AVEA
66
Tabla 2.2 (cont.) Adaptacin sobre deniciones [6] EVEA AVEA

Espacios creados en Internet para Relacin pedaggica y telemtica que establece un usuario con un conjunto de elementos instruccionales, tutoriales y tecnolgicos que le posibilitan construir, adquirir y modicar su conocimiento y sus estructuras de conocimiento de manera autnoma y exible. [22, pag 07] Es una coleccin de herramientas que nos permiten administrar las actividades propuestas para los alumnos, poner a disposicin un sistema de comunicacin efectivo y tener control escolar. [23, pag 07] Espacio virtual social que integra la educacin. . . construidos en la no presencia, en la asincrona, son generadores de vivencias y de sensaciones, y por ello, capaces de crean conciencia valorativa en las personas que los integran. [64]
mltiples herramientas tecnolgicas, el diseo instruccional de la informacin propuesta, las estrategias psicopedaggicas, los actores y los objetos producidos resultado de las actividades y con el resto de los actores. [23, pag 07]
Sistemas que organizan y provee acceso a servicios de aprendizaje en lnea para alumnos, docentes y administradores. Se les conoce tambin como sistemas de gestin de prendizaje (SGA) en ingls: Learning Management Systems (LMS). [24]
Espacio simblico en el que se produce la relacin entre los participantes en un proceso de enseanza/aprendizaje que, interactan entre s y acceden a la informacin elevante. pag 01] [24,
67
Tabla 2.2 (cont.) Adaptacin sobre deniciones [6] EVEA AVEA

Conjunto de facilidades informticas y telemticas para la comunicacin y el intercambio de informacin en el que se desarrollan procesos de Espacio donde se crean las condiciones para que el individuo se apropie de nuevas experiencias, de nuevos elementos que le generen procesos de anlisis, reexin y apropiacin. [65, pag 02] Aplicacin informtica diseada para facilitar la comunicacin pedaggica entre los participantes en un proceso educativo, a sea ste completamente o de una Conjunto de entornos de interaccin, sincrnica y asincrnica, donde, con base en un programa curricular, se lleva a cabo el proceso de enseanza aprendizaje a travs de un sistema de administracin de aprendizaje. [67] Espacio digital, en el cual se interrelacionan diversos aspectos comunicacionales, pedaggicos, tecnolgicos y afectivos, los cuales ayudan a los alumnos a aprender. [69, pag 01]
enseanza - aprendizaje. [65, pag 02]
distancia,
presencial,
naturaleza mixta.
[66, pag 11]
Espacio en el cual se agrupan las distintas herramientas y servicios para el aprendizaje y donde interaccionan el personal de gestin instruccional, el docenteado y los alumnos. 07] Programa informtico que genera un ambiente estructurado de interaccin sociocultural, donde los sujetos en formacin se apropian de conocimientos, habilidades y valores a partir del modelo pedaggico que le sustenta. [70, pag 03] [68, pag
Espacio de interaccin sociocultural mediatizador de las relaciones entre los sujetos a travs de las TIC, construido por las signicaciones de los sujetos con los otros y de las signicaciones de los objetos sociales dando lugar a nuevas signicaciones. . . a partir del modelo pedaggico que lo sustenta. [67, pag 38]
68
Revisando la propensin de las deniciones, presentadas en el cuadro anterior, se desea destacar que los entorno de enseanza aprendizaje virtual, es un concepto que se asocia mas al conjunto de herramientas, aplicaciones y servicios informticos dentro de los procesos administrativos o de gestin de los procesos en lnea de una institucin, para desarrollar todos, o al menos la mayora, de los procedimientos y actividades educativas por medio de una red particular, o de la versin global de todas las redes del mundo: Internet.
A pesar de que algunas deniciones asociadas a los entornos de enseanza aprendizaje para eLearning, consideran aspectos pedaggicos no hacen nfasis en ello. Es abordado este concepto ms asociado con sistemas especialmente preparados para la comunicacin e intercambio de informacin que puede utilizarse independientemente de la modalidad de estudio. En otras palabras, puede servir como complemento de la clase presencial, constituirse en el soporte de los encuentros virtuales con algunas actividades presenciales, o bien, implementarse como el espacio exclusivo de toda la formacin a distancia.
En otro orden de ideas, tomando el concepto de ambiente de enseanza aprendizaje para eLearning se hace nfasis a la forma cmo se plantean las interacciones entre los participantes (docentes, alumnos u otras personas involucradas tanto a nivel acadmico como administrativologstico) y, entre stos y los objetos del conocimiento, aprovechando el conjunto de herramientas tecnolgicas dispuestas.
Una caracterstica muy marcada en las deniciones de los ambiente de enseanza aprendizaje para eLearning presentadas, es la de esa relacin entre personas que se establece con nes educativos a travs de, la vinculacin de lo pedaggico (diseo instruccional, estrategias didcticas, construccin de signicados, procesos de reexin, produccin de contenidos y aspectos afectivos) y lo tecnolgico (sistemas de gestin de aprendizaje, elementos de control, servicios para la comunicacin y el procesamiento de informacin, entre otros).En por ello, que los ambientes de enseanza aprendizaje para eLearning, es un concepto ms fundamentado en los aspectos pedaggicos. Visto as, un ambiente de enseanza aprendizaje
69
para eLearning, se caracteriza principalmente por la relacin pedaggica que logran los participantes y por el uso efectivo y eciente del entorno virtual en el establecimiento de tal relacin. Ver Figura 2.16
Figura 2.16: Concepcin de los entornos y ambientes de enseanza aprendizaje para eLearning
2.5.1. Elementos constituyentes de un AVEA.

En las propuestas de [22, 70], se describen una serie de componentes que, si bien, no
se presentan con el mismo nombre en sus distintas versiones, en la profundidad de sus descripciones resultan coincidentes y complementarios. Por tanto, se considerarn aqu de manera integrada los siguientes elementos constituyentes de un AVEA:
Actores/Agentes:
Se reere a QUIN va dirigido o dirige el proceso de Enseanza
Aprendizaje, son los protagonistas del proceso de formacin educativa. Constituyen el conjunto de personas involucradas en el proceso de aprendizaje, entindase, docentes, alumnos, participantes invitados, personal asesor, diseador y de gestin educativa, y por lo tanto, sus roles deben estar claramente denidos, no solo en torno a las funciones que ejercen dentro de la dinmica del ambiente, sino tambin de los valores que asumirn desde su vivencia.
70

El QU se va a aprender. Representa todos los recursos
Contenidos y actividades:
didcticos u objetos de aprendizaje, tratados en forma digital, las cuales pueden incluir, texto, sonido, audio, simulaciones, entre otros recursos planos o interactivos. Determinan las unidades de aprendizaje, los objetos de estudio y la estructura de las acciones que se ejecutarn para lograr el encuentro de los participantes con los temas, valindose de la interaccin humana y la interaccin con los materiales didcticos disponibles en formato digital en el entorno virtual, el anlisis, la reexin, la retroalimentacin, la metacognicin y el signicado de las situaciones en las que se encuentran involucrados los actores, procurando que, especialmente los aprendices, comprendan las dimensiones del aprendizaje logrado.
Mtodo pedaggico:
Ac se encuentra el CMO se va a aprender. Es a travs de este
elemento que se incorpora al AVEA los aspectos pedaggico asociado al diseo instruccional y a las teoras de aprendizaje. En esta parte se disea las estrategias didcticas que permiten articular las actividades simples o estructuradas que se seguirn por los alumnos en sus diferentes roles para lograr los objetivos instruccionales planteados. Todo estudio y establecimiento de mtodos sustentados en teoras del aprendizaje y enfoques pedaggicos especcos, que sealan los principios epistemolgicos, los valores y los procedimientos generales de la enseanza que marcarn las intervencin didctica y las interacciones socioculturales conducentes al logro del aprendizaje.
Entorno virtual:
Se reere a CON QU medios se va aprender. Representa la plataforma
de gestin en la cual se despliega el AVEA y donde se le hace el seguimiento del aprendizaje a los alumnos. Es la parte del acceso, soporte infraestructura, conectividad Sistema que provee las distintas herramientas tecnolgicas para la comunicacin y el acceso a la informacin, se caracteriza por dos variables: la interfaz y la navegacin. La primera se asocia a las condiciones visuales, grcas y de interactividad entre hombremquina, lograda mediante cdigos comunicativos, conos, dibujos, seales, tamao de texto, mapas, pantallas de trabajo, entre otros. La segunda, tiene que ver con las rutas, secuencias y herramientas de navegabilidad, y las posibilidades tcnicas de disear o
71
adecuar el entorno a las necesidades individuales y grupales de los participantes del acto educativo en el AVEA.
Otros espacios
autores,
como
[66],
consideran y segn
que la
un
AVEA que
debe
estar
constituido los
por
claramente
identicados
funcin
ejercern
participantes
en ellos. Especcamente, este autor seala: Espacios para la informacin (Contenidos, programa, calicaciones, recursos instruccionales, etc.), espacios para la comunicacin
(Tutora, calendario, noticias, mensajera, etc.) y espacios para la construccin (Actividades en lnea, simuladores, ejercicios, debates, foros, wikis, etc.)
2.5.2. Modelo de AVEA con conceptos compartidos.

Una vez que se han descrito por separado los aspectos compartidos entorno a Modelos de eLearning, estndares en el mbito educativo (en especial el IMS LD), y conceptualizacin de los AVEAs, conviene mostrarlos en un modelo unicado donde se presentan las nuevas relaciones no mostradas hasta el momento. Una de las principales relaciones es que los aspectos de preseleccin, evaluacin y seleccin estn basados en los aspectos relacionados con los estndares de eLearning y las mejores prcticas.
Por otro lado, al presentar todos los modelos de forma unicada, se destacan aquellos conceptos comunes y que a su vez sirven de integradores entre las partes involucradas. De esta forma se puede establecer que un AVEA forma parte de una solucin eLearning y que debe cumplir con estndares de eLearning.
En la gura
2.17 se muestra una versin unicada del modelo conceptual propuesto, in-
cluyendo las nuevas relaciones descritas anteriormente. Los recuadros no implican ningn tipo de orden ni relevancia entre conceptos, se utilizan slo para agrupar conceptos similares y facilitar la lectura del modelo.
72

Los AVEAs para e-learning toman un lugar de importancia dentro de la planicacin y
ejecucin didctica, siendo marcado, segn [23], por la forma de integracin entre tecnologa y la propuesta psicopedaggica (p.06).
Las posibilidades que brindan los AVEAs para generar espacios y proveer herramientas que facilitan la interaccin, la construccin y la comunicacin a distancia, han diversicado especialmente las estrategias didcticas.
La integracin entre tecnologa y la propuesta psicopedaggica, a la que hace referencia [23], ha venido adquiriendo la forma de ambientes de enseanza aprendizaje para eLearning, que es el mismo trmino, al que mucho autores reeren como ambientes virtuales de enseanza aprendizaje (AVEA) y tambin ha sido objeto de diversas denominaciones, precisamente por la importancia que se le da a uno u otro componente de la integracin.
2.5.3. Relacin del AVEA con mtodo pedaggico (estndar de facto IMSLD)
El trmino de mtodo pedaggico asociado al diseo instruccional, es considerado como un componente fundamental en la educacin y ms en el proceso de enseanza y aprendizaje, por esta razn tambin se le considera uno de los trminos elementales en la educacin basada en las tecnologas de la informacin y de la comunicacin (TIC).
En un sentido amplio y general, podra decirse que el diseo instruccional permite crear especicaciones detalladas para el diseo, desarrollo, implementacin, evaluacin y mantenimiento de situaciones que faciliten el aprendizaje de temas de estudio, cualquiera que sea su nivel de complejidad.
Para esta investigacin, el diseo instruccional es un punto focal en el diseo y la construccin de un AVEA. Desde esta perspectiva, es importante describir los fundamentos tericos del diseo instruccional, brindar una denicin, describir sus componentes y presentar como ejemplo algunos de los modelos de diseo instruccional implementados en la educacin basada

en las TIC.
73
En este orden de ideas, abordaremos las distintas acepciones del trmino de diseo instruccional (DI), los modelos y las teoras de aprendizaje que lo apoyan, y su proyeccin e inuencia sobre la creacin de programas de formacin de aprendizaje electrnico (eLearning), y de productos de eLearning, como ya hemos visto.
En lnea con Reigeluth [71] es fundamental reconocer el modelo terico instruccional que subyace a la creacin o en el diseo del programa de formacin, para adaptar el DI ms adecuado a los objetivos de aprendizaje. De ah parte la preocupacin del diseador instruccional, pues necesita identicar las herramientas tericas para traducir sus materiales a cursos en lnea en congruencia con un modelo de DI ms efectivo que permita al alumno lograr los objetivos de aprendizaje planteados.
Segn [71], las principales caractersticas del diseo instruccional como teora son:
Est orientado hacia el diseo, concentrado en los medios que permitan la obtencin de los objetivos de aprendizaje y desarrollo. El ser orientado al diseo resulta prctico y til para los educadores para mostrar cmo pueden lograr sus metas u objetivos de aprendizaje.
Es prescriptivo, es decir, ofrece las pautas para realizar las acciones que nos conduzcan hacia el logro de ciertos resultados.
Deben identicar mtodos de instruccin y situaciones en las que se puedan utilizar estos mtodos. Ambos componentes son necesarios para toda teora instruccional y esto indica que los mtodos son situacionales, no universales en aplicacin.
Los mtodos de instruccin se pueden dividir en componentes ms detallados que proporcionen ms pautas para los educadores. Estas partes pueden componerse de mtodos ms pequeos. La implicacin del mtodo es que tiene diferentes tipos de caractersticas. Los resultados dependen de la situacin. El criterio puede proveerlo el mtodo. El nivel de las orientaciones depende de su complejidad y puede variar.
74

Los mtodos se consideran ms probabilsticos que determinsticos pues incrementan las posibilidades de lograr las metas. Una meta desde el punto de la teora de diseo instruccional es obtener mayores posibilidades para propiciar que los resultados deseados ocurran.
Una meta de la teora de diseo instruccional tiene un valor o una losofa que lo soporta. Los valores son primordiales al decidir que vas se han de seleccionar en cuanto al mtodo para obtener esas metas.
En este complejo mundo se han desarrollado un rea de problema asociado al diseo instruccional tecnolgico, es decir, el desarrollo de especicaciones que sobre la base de una supuesta excelencia pedaggica permita a los desarrolladores de software elaborar aplicaciones educativas de calidad. En este rubro, tambin se quiere introducir la elaboracin, justicacin y denicin de especicaciones que permitan disear soportes digitales de aplicaciones educativas o Unidades de aprendizaje (UA, sus siglas en ingles- Units of Learning, UoL).
La elaboracin, justicacin y denicin de especicaciones que permitan disear aplicaciones educativas, est liderado por una corporacin de la industria del eLearning, IMS Global Learning Consortium.
Griths et al.
[72] explican perfectamente en esencia qu son y cmo funcionan las
especicaciones didcticas:
En 1997 la Open University of the Netherlands (OUNL) decidi convertir todos sus cursos en cursos on-line. Los cursos existentes empleaban una variedad de enfoques pedaggicos. La Universidad los clasic y empez a implementar unas plantillas representativas para intentar dar soporte a todas estas categoras pedaggicas. Rpidamente se constat que todos los docentes tenan su propia visin pedaggica, y que necesitaban casi tantas plantillas como docentes. Por otro lado, aunque haba muchas descripciones pedaggicas de los cursos, en la prctica todas consistan en combinaciones de tres elementos bsicos: recursos educativos, mltiples personas actuando en varios roles, y actividades pedaggicas. El EML

(Educational Modelling Language), introducido por la OUNL, permite denir estos tres elementos y as especicar la estructura de una Unit of Learning, UoL, mediante un documento XML.
75
IMS, consciente de las limitaciones pedaggicas de las especicaciones existentes, empez el proceso de desarrollo de una especicacin para la denicin de aspectos pedaggicos, pero ya que EML exista y funcionaba decidieron adaptarlo en lugar de crear una especicacin totalmente nueva. El resultado es una nueva especicacin, IMS Learning Design. Aunque presenta cambios importantes de estructura y enfoque, sus conceptos bsicos y capacidades son muy similares a los de EML.
Los aspectos importantes de IMS Learning Design son los siguientes:
Ofrece
soporte
para
mltiples
alumnos,
y contempla la
comunicacin
entre ellos
representa el papel de docente
Permite combinar recursos educativos con actividades pedaggicas, y con las interacciones entre personas en diferentes roles.
Estas capacidades facilitan que el diseador de las UoL pueda denir, por ejemplo, actividades de aprendizaje basada en problemas.
Una Unidad de aprendizaje (UoL) es el producto generado por la especicacin de IMS LD, en la cual se dene quin, cuando, donde, cmo y para qu se utilizan los recursos, en el modelado del proceso educativo y de comunicacin interactiva.
En la UoL podemos representar el modelado de un proceso de enseanza aprendizaje, aplicando distintas metodologas para darle sentido al uso de los recursos
As para facilitar su adopcin progresiva, la especicacin IMS LD propone tres niveles de detalle a los que denomina simplemente A, B y C. De este modo, el primer nivel es bastante sencillo de implementar y permite crear diseos instruccionales sencillos. Un LMS que
76
implemente solamente el nivel A no puede considerarse completamente compatible con la especicacin IMS Learning Design, pero si puede considerarse compatible con el Nivel A de la especicacin. Los Niveles B y C aaden funcionalidad y potencia, construyendo siempre sobre el nivel anterior.
Lo anterior permite a las organizaciones adoptar IMS Learning Design incrementalmente y, si las necesidades de la organizacin no requieren de la adopcin completa de la especicacin, se puede optar por una adopcin parcial llegando slo al nivel que fuese necesario.
Las siguientes secciones describen la funcionalidad especicada en cada uno de los niveles de IMS Learning Design. Ver gura 2.18
77
Figura 2.17: Mapa conceptual de los AVEAs
78
Figura 2.18: Como est estructurada una UoL en IMS LD
El Nivel A de la especicacin se centra en superar el modelo de un nico usuario (un alumno trabajando en solitario) reejado en el resto de las especicaciones de IMS. En este primer nivel de la especicacin se incluyen los conceptos bsicos expuestos en la seccin anterior, esto es, las obras, divididas en actos en las que distintos actores interpretan distintos roles.
La nocin de estructuras de actividades, que es la esencia de la denicin de los caminos de aprendizaje con ramicaciones, tambin aparece en el Nivel A. Con esta informacin es posible crear Unidades de Aprendizaje en las que se dene un proceso colaborativo en el que participan varios actores (tanto alumnos como instructores u otros miembros de apoyo) y se dene un secuenciamiento complejo de las actividades en el que en algunos casos se le da importancia al orden y en otros no. Lo que no se incluye en el Nivel A, es la posibilidad de modicar y consultar valores, con lo que los ujos de aprendizaje son jos y el resultado de las distintas actividades no puede afectar al resto.
An as, una implementacin que slo soporte el Nivel A podra soportar un modelo en el que aparezcan distintos tipos de participantes que realizan distintas actividades en un determinado orden. Por tanto, este nivel ya presenta una aportacin sobre el modelo dirigido a un nico tipo de usuario y abre la puerta a diseos instruccionales basados en los principios del aprendizaje colaborativo.
79
Por otro lado, dado que otra posible interpretacin de los roles es la de distintos perles de alumnos, el Nivel A de IMS Learning Design soportara modelos educativos en los que distintos tipos de alumno recorren distintos caminos al realizar un determinado curso.
Pese a ello, un sistema que implemente el Nivel A no podra ejecutar el ejemplo planteado en esta seccin, pues la presencia de roles, actividades y un orden de las actividades no implica la posibilidad de que el resultado de una determinada actividad afecte al resto del proceso de aprendizaje. En el ejemplo planteado, la actividad de evaluacin del examen no puede afectar al ujo del curso como se indicaba en la descripcin del mismo.
Las dos aportaciones fundamentales del Nivel B de la especicacin IMS Learning Design son las propiedades y las condiciones.
Las propiedades son pares atributo-valor que parten de un estado inicial y se modican a lo largo del proceso de ejecucin de la Unidad de Aprendizaje. Un ejemplo de propiedad sera examen-superado con un valor inicial de falso. Durante la actividad de evaluacin del examen es posible que este valor se convierta en verdadero o que se quede en su estado inicial.
En cuanto a las condiciones, stas son consultas que se realizan sobre el valor de las propiedades en un momento determinado. As, para llegar al estado nal del ejemplo de la seccin anterior, es necesario que la propiedad examen-superado tome el valor verdadero. Si tras la actividad de evaluacin del examen el valor siguiese siendo falso, el alumno deber recorrer el camino de aprendizaje nuevamente.
As, el Nivel B aporta la posibilidad de que el resultado de una actividad genere un cambio en alguna de las propiedades. Por su parte, el resto de actividades pueden estar condicionadas a un cierto valor de las propiedades. En la prctica esto signica que el resultado de unas actividades puede tener un impacto real en el resto del proceso de aprendizaje, cambiando el camino a seguir o incluso modicando el propio contenido de alguna actividad.
80

Adicionalmente, las propiedades pueden ser tambin externas. Esto es, no son modicadas
por la propia Unidad de Aprendizaje sino que son denidas por el propio LMS. Esto signica que en el Nivel B de la especicacin tambin se pueden crear Unidades de Aprendizaje que se comportan de manera distinta en funcin de las exigencias del propio LMS. Un ejemplo comn, sera que el LMS emplee este mecanismo para quitar del proceso de aprendizaje aquellas actividades inadecuadas para el perl de los alumnos o que simplemente requieran servicios no implementados por el entorno de aprendizaje (ejemplo, un foro de discusin).
La adicin de propiedades y condiciones en el Nivel B de la especicacin permite la creacin de Unidades de Aprendizaje cuyo recorrido cambia durante la propia ejecucin. Pero estos cambios son sncronos, es decir, las actividades se ejecutan en un determinado orden y esperan a que la actividad anterior termine antes de comenzar su ejecucin.
El Nivel C de la especicacin introduce un mecanismo de noticacin o de envo de mensajes entre las distintas actividades. Esto signica que una actividad puede estar ejecutndose en unas determinadas condiciones y en un momento no predecible recibir un mensaje desde otra actividad o desde el propio LMS que afecte a la ejecucin de la actividad inicial.
Esto permite soportar ujos de aprendizaje modicables en tiempo real mediante eventos. Los ujos predenidos se sustituyen por actividades que se disparan, modican o interrumpen a medida que cambia el estado de la Unidad de Aprendizaje.
Dado que en estos procesos de aprendizaje normalmente hay varios individuos, el camino que se seguir y el orden de ejecucin de las actividades ya no es predecible, pues es alterado por la accin de los distintos roles.
Las aplicaciones del Nivel C pueden ser algo tan sencillo como que en el momento de la ejecucin de la actividad de evaluacin del examen el alumno reciba un email, pero existen posibles aplicaciones mucho ms sosticadas que permiten incluso realizar simulaciones multi-
81
usuario en las que el entorno cambia continuamente en funcin de las acciones de cada actor.
En general debera denir estructuras sistmicas que describieran cmo se producen los aprendizajes diferencindolos, y relacionando contenidos, condiciones y mtodos, y no operar exclusivamente en principios o en procedimientos acabados, y a continuacin aplicarlos directamente en la fase de diseo y desarrollo de productos tecnolgicos y en tcnicas de programacin. Obteniendo productos orientados en una direccin: que cada vez sean ms autnomos de lo que es una intervencin docente directa.
En este sentido, esta investigacin propone un modelo conceptual para los AVEAs basado en el estndar IMS LD que permite integrar los elementos focales del proceso de enseanza y aprendizaje. Ver gura 2.19
82
Figura 2.19: Modelo Conceptual de un AVEA basado en IMS LD
Para poder permitir que los AVEAs cumplan con caractersticas como la reutilizacin y la interoperabilidad se acopl su diseo al propuesto por IMS LD. Sigue la mtafor del teatro, como lo sigue el estndar de facto. A continuacin se describe alguno de sus elementos:
Mtodo: representa el diseo instruccional completo. Lo conforma el guin
Guin: (Metfora de teatro): lo integran la sucesin de Actos.
Acto: es la participacin de distintos papeles secuenciados internamente de mltiples maneras.
Actuacin (RolPart o Papeles): relacin entre la estructura de actividades y los roles. Por ejemplo El rol X realiza la estructura de actividades Y.
2.6. CONCLUSIONES DEL CAPTULO
83
Roles: responsabilidades de los actores en distintas etapas de proceso de aprendizaje. Dependiendo del momento del proceso de aprendizaje un actor puede tener distintos roles.
Actores: Personas involucradas en el proceso de aprendizaje.
Actividades: proceso educativo granular que sucede en un entorno determinado (dentro o fuera del aula virtual) y que puede tener asociados contenidos que se distribuyen con la Unidad de Aprendizaje.
Estructura de Actividades: Las actividades se pueden agrupar en estructuras de actividades, lo que permite relacionar un conjunto de actividades granulares referenciadas en una sola entidad. De igual manera, las estructuras de actividades se pueden agrupar en estructuras ms complejas generadas de la anidacin de estructuras.
2.6. Conclusiones del captulo

En relacin con la adopcin y seleccin de estndares por las organizaciones, los educadores y los desarrolladores de tecnologas y de contenidos, el problema es que existen un enorme nmero de recomendaciones y estndares en el mercado, con distintos niveles en el proceso de estandarizacin y en cuanto a la validez u obsolescencia de las normas (llegando a existir estndares obsoletos que aun se siguen utilizando y promoviendo por motivos econmicos, para preservar inversiones previas), y con mltiples solapamientos entre distintas especicaciones.
Ante este panorama, se produce una importante confusin sobre que estndar utilizar para cada contexto educativo. Los estndares deberan ser ms exibles y con un enfoque ms amplio, para poder adaptarse mejor a distintas necesidades y contextos.
Se necesitan marcos de aplicacin que faciliten a las instituciones educativas y a los desarrolladores de servicios, sistemas y herramientas, la seleccin y adopcin de los estndares y las especicaciones ms adecuadas y necesarias para sus proyectos relacionados con las tecnologas educativas.
84

En la generacin y desarrollo de entornos y ambientes educativo se presentan adems otros
problemas de tipo tcnico. La mayor parte de documentacin y deniciones de estndares y especicaciones resultan muy tcnicas y complejas, prestando escasa atencin a los aspectos pedaggicos relacionados con su aplicacin. Muchos de los estndares existentes son difciles de interpretar e implementar sin contar con el apoyo de sus responsables, y en ocasiones, llegan a ser tan complejos que su implementacin resulta tan cara, que no compensan los benecios de su adopcin.
Lo anterior deriva que su cumplimiento o soporte en distintas plataformas de eLearning es limitado y poco homogneo, producindose errores y fallos de integracin derivados de problemas terminolgicos, denicin de roles y permisos, o incompatibilidades de la arquitectura e los interfaces. Pero no todos los estndares cuentan con herramientas que permitan comprobar el nivel de cumplimiento con el mismo, llegando a darse el caso de incompatibilidad entre dos sistemas que han adoptado un mismo estndar pero lo han interpretado de distinto modo.
Es por ello que el tema de la estandarizacin asociado a los entornos y ambientes de enseanza aprendizaje para eLearning tiene mucha vigencia, y es tomado en cuenta en esta investigacin.
Captulo 3
Anlisis del dominio bajo estndares de calidad

En el captulo 2 se describi la caracterizacin de los AVEAs y se propuso un modelo conceptual que permite acoplarse al estndar IMS LD. Es objetivo del presente captulo es describir el impactado de los AVEAs considerndolos como productos de software, incorporando los estndares ISO/IEC 9126(Calidad en productos de software) y el ISO/IEC 19796 (asociado a la calidad en eLearning) para obtener los atributos de calidad y poder determinar una arquitectura de software candidata, en funcin al anlisis de sus requerimientos funcionales y no funcionales.
La especicacin y evaluacin de calidad de productos de software, es un factor clave para garantizar la calidad adecuada de los mismos. Esto puede lograrse mediante la denicin de caractersticas de calidad apropiadas, teniendo en cuenta los propsitos de uso de los productos de software. Los requisitos no funcionales, son importantes para la integracin de aplicaciones, y en consecuencia para realizar comparacin entre soluciones que las realicen.
En particular los modelos de evaluacin de calidad de arquitecturas de software renen taxonomas de atributos de calidad, comnmente usados para especicar y evaluar requerimientos no funcionales. Buscan denir caractersticas que debe satisfacer un producto de software, de forma que se puedan cuanticar las mismas a travs de atributos medibles. La 85
86
CAPTULO 3. ANLISIS DEL DOMINIO BAJO ESTNDARES DE CALIDAD
diferencia entre modelos radica en dicha clasicacin [14].
Barbacci, Klein y Weinstock [73], establecen que el desarrollo de formas sistemticas para relacionar atributos de calidad de un sistema a su arquitectura provee una base para la toma de decisiones objetivas sobre acuerdos de diseo, y permite a los ingenieros realizar predicciones razonablemente exactas sobre los atributos del sistema que son libres de prejuicios y asunciones no triviales.
3.1. Introduccin
En el mbito de la ingeniera del software interesa, en primer lugar, denir la calidad del software. En este sentido, el objetivo de la norma internacional Quality Management Systems Fundamentals and vocabulary (ISO) o en su versin espaola: Sistemas de gestin de la calidad. Fundamentos y vocabulario (AENOR), es jar y tipicar el vocabulario relativo a la calidad. As, dene calidad como el Grado en el que un conjunto de caractersticas inherentes
cumple con los requisitos, donde esta se dene como la necesidad o expectativa establecida, generalmente implcita u obligatoria.
Tambin en el estndar IEEE Std 1061-1998: Standard for a software quality metrics methodology,nos presenta la calidad del software como el grado en el que el software posee
una combinacin deseada de caractersticas previamente denidas. La norma ISO 9000

conceptualiza caracterstica y caracterstica de calidad, de la forma siguientes:
Caracterstica:
rasgo diferenciador. Una caracterstica puede ser inherente o asignada. Una
caracterstica puede ser cualitativa o cuantitativa. Existen varias clases de caractersticas, tales como: fsicas, sensoriales, de comportamiento, de tiempo, ergonmicas y funcionales.
Caracterstica de calidad:
caracterstica inherente de un producto, proceso o sistema
relacionada con un requisito. Para este trabajo nos interesan las caractersticas de los productos software. Un producto se dene, segn de nuevo la norma ISO 9000, como el resultado de un proceso, donde proceso es el conjunto de actividades mutuamente
3.2. ESTNDARES EN ELEARNING PARA CALIDAD DEL AVEA
87
relacionadas o que interactan, las cuales trasforman elementos de entrada en resultados. En nuestro caso, el proceso es el de desarrollo del software.
La calidad est compuesta de muchas caractersticas, normalmente capturada en un modelo que describe las caractersticas compuestas y sus relaciones [74]. Por otra parte, segn el estndar ISO/IEC-2001 a-9126-1
1
, la calidad de un producto software se debera evaluar
usando un modelo. Aunque existen diferentes modelos para la evaluacin del software, el estndar comnmente aceptado por la comunidad internacional es la norma ISO/IEC 9126.
En ISO/IEC 9126 se dene un modelo bsico de seis caractersticas de calidad como base para la evaluacin de productos software cualesquiera. Dicha norma, dada su propia naturaleza de estndar, cubre un espectro tan genrico de productos que no es posible aplicarla directamente. Esto hace necesario adaptarla a dominios de productos especcos,haciendo posible concretar los factores a evaluarse y que peso tendrn unos con respecto a otros. El modelo as obtenido, ser entonces un modelo prctico para su aplicacin por parte de evaluadores.
3.2. Estndares en eLearning para calidad del AVEA

El desarrollo y adopcin de estndares persigue mejorar la exibilidad, la reutilizacin, la transparencia y la posibilidad de comparacin de los procesos, productos y servicios. En un proceso de enseanza aprendizaje apoyado en tecnologas, el principal objetivo que se pretende conseguir al adoptar un estndar es reducir el costo y el tiempo en el desarrollo y despliegue del mismo. Este objetivo se garantiza si se viabiliza: la durabilidad, la interoperabilidad, la facilidad de acceso (disponibilidad y accesibilidad), y la reutilizacin de los recursos educativos y cualquier otro medio para el aprendizaje [53].
Con el uso de estndares se persigue que los recursos educativos sean validos mientras su contenido sea relevante, y que pueda visualizarse y utilizarse del mismo modo en diferentes entornos, incluso de distintos fabricantes, independientemente de la tecnologa con la que se
1 http://www.iso.org/iso/iso atalogue/catalo gue c/catalogue etail.htm?csnumber = 22749 c t d
88
desarrollen y distribuyan, o de los entornos en los que se desplieguen. La aplicacin de estndares en repositorios de contenidos educativos facilita el acceso y visualizacin de los recursos para utilizarse con los navegadores web generales. Asi se eliminan las barreras tecnolgicas y de otro tipo. Los estndares pretenden que el contenido generado en diversas plataformas y distintos momentos, pueda ser agrupado, desagrupado o combinado con otros recursos, haciendo posible su reutilizacin, de forma fcil, efectiva y sin lmite en mltiples contextos de aprendizaje distintos de aquel para el que fueron diseados en su origen.
Junto a los objetivos y benecios relacionados directamente con los contenidos educativos, el uso de estndares de tecnologas educativas tambin afecta a los sistemas y plataformas. En efecto, facilitan su escalabilidad, es decir, que puedan congurarse para aumentar la funcionalidad de modo que se pueda dar servicio a mas usuarios respondiendo a las necesidades de la institucin sin exigir un esfuerzo econmico desproporcionado. Igualmente debe darse con su capacidad de gestin, de manera que el sistema pueda obtener y registrar la informacin adecuada sobre el contenido y los usuarios [53, 54]
La adopcin de estndares con estos objetivos, conlleva una serie de ventajas y benecios a todos los participantes en el proceso educativo Desde el punto de vista del docente, en su funcin de creacin de contenidos, la estandarizacin ha favorecido la aparicin de herramientas de autora que le permiten desarrollar objetos educativos conforme a estndares, sin necesidad de apoyo de especialistas, como los del servicio de produccin de TIC. Estas herramientas y la aplicacin de estndares tambin inuyen en la creacin de recursos de mayor calidad con la perspectiva de una mayor durabilidad, uso y reutilizacin de los contenidos.
El uso de formatos estndares, facilita a los docentes la reutilizacin de los contenidos generados o adaptados para un curso o asignatura en sucesivas ediciones, incluso en distintas plataformas, con una notable disminucin del esfuerzo en adaptacin de los contenidos a las distintas asignaturas y entornos de aprendizaje. De esta manera, se puede dedicar ms tiempo a producir un mayor nmero de recursos educativos y ponerlos a disposicin de los docentes
3.2. ESTNDARES EN ELEARNING PARA CALIDAD DEL AVEA
89
a travs de repositorios de objetos educativos o de proveedores de contenidos, tanto de acceso libre como de pago.
En cuanto a los estudiantes, la mayor produccin y reutilizacin de recursos educativos que conlleva los estndares les plantea mayores posibilidades de eleccin de contenidos educativos, tanto del repositorio de la institucin como de servicios externos. Al mismo tiempo les permiten acceder a recursos educativos de fuentes heterogneas, a travs de distintas plataformas educativas y desde diferentes entornos de hardware (computador porttil, PDA, mvil) y software, con prdidas mnimas tanto de contenido como de funcionalidad, ms aun cuando se cumplen estndares de accesibilidad. Adems, los resultados de su aprendizaje (tanto los crditos, como certicados) tendrn una mayor portabilidad, dentro y fuera de su institucin, e incluso a escala internacional.
De lo dicho anteriormente, se inere que estos estndares facilitan la administracin de los recursos educativos digitales, a la vez que ofrecen nuevas vas de comunicacin docenteestudiantes, y conguran nuevos entornos para el aprendizaje colaborativo. No obstante, estos sistemas plantean mltiples limitaciones en lo que se reere a la distribucin, acceso, permanencia y preservacin o reutilizacin de los contenidos digitales educativos.
Segn
Kapp
[75],
la
calidad
de
una
plataforma
eLearning
est
dada
por
cinco
caractersticas:
1.
Mantenimiento:
La habilidad de conservar, an por largo tiempo, la tecnologa
seleccionada. Se debe revisar que la aplicacin separe la presentacin del contenido. Las actividades diarias como crear cursos, reciclarlos, eliminar usuarios, crear ejercicios, deben ser sencillas. Si extender o actualizar el ambiente de enseanza aprendizaje para eLearning es una tarea complicada, no debe considerarse.
2.
Compatibilidad: Buscar soluciones que sean intercambiables con otras existentes que
permitan compartir contenidos. Debe soportar estndares de intercambio como SCORM o IMS-CP. A este respecto la interoperabilidad es la habilidad de tomar un curso y usarlo en otro ambiente de enseanza aprendizaje para eLearning.
90

3.
Usabilidad:
La plataforma debe ser fcil de usar. Si la tecnologa utilizada por la
plataforma es vista como mala o complicada sera abandonada. Se espera que el ambiente de enseanza aprendizaje para eLearning sea intuitivo: debe ser fcil encontrar elementos, ser simple y directo. La interfaz de la plataforma debe estar diseada de manera que no sea necesaria una larga fase de capacitacin.
4.
Modularidad:
el
ambiente
de
enseanza
aprendizaje
para
eLearning
puede
ser
desarrollado como una coleccin intercambiable de objetos de conocimiento o de funcionalidad. Cada uno de estos mdulos es una pequea pieza de contenido. Los componentes u objetos de aprendizaje podran ser reutilizados si cumplen con los requerimientos de los usuarios.
5.
Accesibilidad:
La accesibilidad se presenta desde dos aspectos: (a)el ambiente de
enseanza aprendizaje para eLearning es accesible para todos los individuos a pesar de sus deciencias fsicas, es decir, si est conforme con estndares de accesibilidad, y (b) Las tecnologas empleadas por la plataforma estn disponibles a todos los usuarios (componentes, extensiones, caractersticas del contenido).
Cada una de estas caractersticas es crtica para el xito. Muchas de ellas se traslapan pero si son evaluadas de forma individual aseguran un completo entendimiento de las necesidades tecnolgicas de una plataforma eLearning. Sin embargo, Kapp no establece criterios de medicin, dejando a los usuarios su denicin.
3.3. Estndar ISO/IEC 19796 como modelo de calidad

La norma ISO/IEC 19796 proporciona un enfoque armonizado y un lenguaje comn para administrar, asegurar o evaluar la calidad. Adems, la mayora de estndares, quasi-estndares y normas, pueden ser modelados utilizando esa norma, que consta de las siguientes partes:
ISO/IEC 19796-1:2005.
Enfoque general, es el marco para describir, comparar,
analizar y aplicar, los mtodos para la gestin y aseguramiento de la calidad. El aspecto principal es el marco de referencia para la descripcin de los enfoques de calidad (Reference Framework for the Description Quality RFDQ).
3.3. ESTNDAR ISO/IEC 19796 COMO MODELO DE CALIDAD
91
ISO/IEC 19796-3:2009. Mtodos y mtricas de referencia, que ampla el marco para la

descripcin de los enfoques de calidad, proporcionando una descripcin para armonizar los mtodos y parmetros necesarios para aplicar la gestin de la calidad y sistemas de garanta de calidad para que los interesados puedan realizar diseos, desarrollos o utilizar sistemas de informacin. Las siguientes partes del estndar estn en proceso de desarrollo:
ISO/IEC 19796-2.
Modelo de calidad armonizado, que describir la calidad para
organizaciones y para productos, servicios y soluciones.
ISO/IEC 19796-4. Gua de buenas prcticas, basada en el trabajo de la Gua de Buenas

Prcticas Europea.
ISO/IEC 19796-5. Cmo usar el ISO/IEC 19796-1?

Todas las partes que componen el estndar se interrelacionan segn el esquema mostrado en la gura 3.1 [58]:
Figura 3.1: Partes del estndar ISO/IES 19796
Si bien es cierto la armonizacin en la ISO/IEC 19796 se ha hecho en un nivel abstracto, sin recomendaciones o directrices especcas para dar un criterio de gestin de la calidad, por
92
tanto no proporciona mecanismos de apoyo para su implementacin. Sin embargo, la ISO/IEC 19796 puede proporcionar un modelo de calidad armonizado, adaptable a cada contexto especco, con procesos adecuados y medidas concretas para establecer una cultura de calidad en una organizacin.
Por otro lado, se desea hacer nfasis en el estndar ISO/IEC 19796-1 como primer estndar de calidad para el aprendizaje, la educacin y la capacitacin. Es un marco de referencia que describe, compara, analiza e implementa la administracin y aseguramiento de la calidad en los procesos asociados al aprendizaje y por ende pueden ser aplicados al eLearning. Permite comparar las distintas tendencias actuales y unicarlas en un modelo comn de calidad.
ISO/IEC 19796-1 se basa en el Marco de Referencia para la Descripcin de Calidad (RFDQ, Reference Framework for the Description of Quality Approaches) [76] . Consta de dos partes:
1. Un modelo de procesos como clasicacin de referencia.
2. Un esquema de descripcin para el control de la calidad.
El modelo de procesos considera todo el ciclo de vida del eLearning y puede ser utilizado para describir cualquier escenario educativo. Lo anterior es, debido a que tiene las siguientes caractersticas [77]:
1.
Integracin. Cualquier persona del rea puede utilizar el modelo, permitiendo ser un
marco comn de referencia entre las partes involucradas en los procesos educativos.
2.
Completitud. Todos los procesos educativos son cubiertos por el modelo de referencia.
El modelo puede ser adaptado a cualquier escenario educativo seleccionando un subconjunto de sus procesos.
3.
Apertura.
No hay requerimientos en trminos de los procesos o mtodos utilizados
dentro de los procesos del modelo, solo se requiere una especicacin de las relaciones y dependencias, los actores, las mtricas y medidas empleadas para satisfacer los requerimientos en un contexto determinado.
3.3. ESTNDAR ISO/IEC 19796 COMO MODELO DE CALIDAD

4.
93
Adaptabilidad.
Los subprocesos, objetivos y resultados de todos los procesos del
modelo son adaptables y extensibles de forma individual, permitiendo adaptar el modelo a un contexto educativo y organizacional.
5.
Unicidad. Este modelo est enfocado en la calidad del eLearning.
El modelo est dividido en siete categoras de procesos que contienen treinta y ocho subprocesos, todos enfocados al proceso educativo, tal como se describen en la gura 3.1.
El modelo de procesos describe el ciclo de vida del proceso educativo, pero no contiene ninguna descripcin de las estructuras o procedimientos sobre cmo realizar dichos procesos. Esta informacin es proporcionada por un modelo de descripcin de procesos, el cual forma parte del estndar. Este dene un formato para describir todos los procesos involucrados en el eLearning.
Para cada proceso del ciclo de vida se debe especicar un grupo de mtodos y mtricas que seran utilizados para establecer la calidad en los procesos, los productos, los componentes y los servicios. El estndar proporciona mtodos y mtricas de referencia que son descritos de forma genrica y pueden ser utilizados en cualquier contextos para los procesos del ciclo de vida [78] .
Las caractersticas presentadas por Kapp, a pesar de ser lo sucientemente genricas para ser aplicadas a cualquier ambiente de enseanza aprendizaje para eLearning, tienen como principal inconveniente esa misma generalidad.
Pernalete, Cnchica y Coello presentan una aplicacin del modelo presentado ajustado al contexto de los ambientes de enseanza aprendizaje para eLearning, como se evidencia en la gura 3.2
94
Ambiente Virtual de Enseanza Aprendizaje para eLearning basado en IMS LD

COMPONENTES Actividad MTODOS Actuacin
Crea Actuacin (Papel) | Asignacin de Rol Asignacin de Objetivos
Crea Actividad | Enlaza Entorno

Estructura de actividades
Crea una estructura de actividad | De ne tipos | Enlaza actividad
Acto
Asignacin de actuacin o papel | Slo Actuacin y Condiciones
Propiedades
Enlaza Entorno
Condicin
Crea Condicin | IF es correcta | ELSE parte correcta
Roles
Enlaza Entorno
Entornos
Crea Actividad | Enlaza Entorno
Leyenda Componentes Elementos Procesos
Figura 3.2: Adaptacin de los Procesos y Subprocesos del estndar ISO/IEC 19796-1
3.4. REQUISITOS DE CALIDAD SEGN ISO 9126-1
95
Segn Pernalete et al (Pernalete:2012), se pueden dividir el modelo de calidad del estndar ISO/IEC 19796 y ajustarlo segn sea el elemento a evaluar, es decir, se puede dividir las etapas.
3.4. Requisitos de Calidad segn ISO 9126-1

La Organizacin Internacional de Estandarizacin en su norma ISO 9126, permite valorar la calidad basndose en un conjunto de caractersticas que deben poseer los atributos del producto.
La norma ISO 9126 no dene la implantacin de la calidad a un software, slo dene un modelo con un enunciado de caractersticas que considera que deben tomarse en cuenta a la hora de establecer los requerimientos de calidad de la evaluacin del producto. Esta norma fue elaborada por la International Standard Organization (ISO) en conjunto con la International Electrotchnical Commission (IEC) para la gestin y el aseguramiento de la calidad del software. Esta norma dene un modelo de calidad de producto de software en donde se incluye calidad interna, externa y calidad de uso.
El modelo de calidad expuesto en la norma ISO/IEC 9126 categoriza los atributos de calidad en seis caractersticas (Funcionalidad, Fiabilidad, Usabilidad, Eciencia, Mantenibilidad y Portabilidad), cada una de estas se dividen a su vez en Sub-caractersticas que podrn ser medidas a travs de mtricas internas y externas (Ver gura 3.3).
96
Figura 3.3: Modelo de Calidad para calidad interna y externa del Software ISO/IEC 9126-1
3.5. Construccin de un Modelo de Calidad para AVEA

Un modelo de calidad estndar e integral permite establecer cules son los requerimientos o caractersticas deseables que debe cumplir un producto de software en funcin a las caractersticas y estndares asociados, as como tambin, plantea las mtricas para evaluar aspectos denidos.
Para la construccin del modelo de calidad para los AVEAs se estableci un esquema de trabajo, que corresponde a un proceso sistemtico, el cual parti de la caracterizacin del dominio de los AVEA. Una vez establecidos estos aspectos, se procedi a realizar una instanciacin del estndar internacional ISO/IEC 9126 y el ISO/IEC 19796 (asociado a la calidad en eLearning), con base a los rasgos de evaluacin de calidad que plantean, aplicables a los AVEA y que estn en relacin con las caractersticas denidas del recurso. En denitivan se establecen las caractersticas deseables, indicadas por los atributos a evaluar y las mtricas asociadas.
3.5. CONSTRUCCIN DE UN MODELO DE CALIDAD PARA AVEA
97
Es importante destacar que este proceso sistemtico puede ser empleado a cualquier tipo de AVEA, previamente caracterizado, siendo este un aspecto esencial a considerar. A continuacin, se muestra la gura 3.4 con cada una de las fases del proceso. Posteriormente en las siguientes apartados se describen cada una de ellas.
Figura 3.4: Mtodo para identicar arquitectura basada en modelo de calidad
3.5.1. Captura de Requerimientos Funcionales (RF) a travs de casos de usos.

La captura de los requisitos funcionales es el proceso mediante el cual se especican y validan las funciones que debe proporcionar un sistema, independientemente del ambiente donde deba funcionar (Web o no), as como las restricciones donde va a operar. Los diagramas de casos de uso representan la forma como un usuario opera con el sistema, adems de la forma, tipo y orden en cmo estos elementos interactan. Ver gura 3.5 Durante el levantamiento de informacin y la especicacin de requerimientos de software, se obtuvo un esbozo del sistema y los actores que interactan con el mismo. A continuacin se describe sus funciones:
Como Administrador, es un sper usuario que tiene todos los privilegios en el uso del sistema. Bsicamente se encarga de la administracin del sistema, la actualizacin de los servicios, el mantenimiento de la base de datos del sistemas e interfaz Web, entre otros.
Como diseador, tiene derecho de buscar, editar, modicar, almacenar y eliminar los guiones didcticos, creados por l de la base de datos del sistema.
Como docente, este usuario tiene derecho de buscar, editar, modicar, almacenar y eliminar los Ambientes de Enseanza Aprendizaje, creados por l de la base de datos del
98
Figura 3.5: Caso de uso para los sistemas generadores de AVEAs
sistema. Y utilizar un guin didctico del repositorio para la generar un nuevo Ambiente de Enseanza Aprendizaje.
Es importante aclarar, que un actor se dene como el rol o funcin asumido por una persona, sistema o entidad que interacta con la aplicacin que se est desarrollando, tiene la propiedad de ser externo al sistema y puede acceder al sistema como distintos actores: administrador, diseador y docente.
La denicin de los Casos de Uso consiste en una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. La descripcin de los Casos de Uso identicados de la aplicacin, los cuales se presentan utilizando la notacin UML como referencia (sConsultar en el apndice B)
3.5.2. Captura de Requerimientos No Funcionales (RNF)

Los requerimientos de calidad, segn la organizacin ISO, son aquellas necesidades que un usuario desea que sean satisfechas por el servicio que usa. Para Pressman [79], la calidad de
99
un sistema depende de como los requisitos que denen el problema y el diseo de la solucin han sido levantados.
En los requerimientos anteriores (RF), se han descrito algunas de las necesidades funcionales del sistema, haciendo nfasis en la usabilidad, funcionamiento e interaccin. Sin embargo, por tratarse este caso de una aplicacin Web, aparecen una serie de necesidades que no se pudieron catalogar en el apartado anterios.
En el caso de los RNF se pueden ver como las restricciones que afectan a los servicios o funciones del sistema, tales como restricciones de tiempo, sobre el proceso de desarrollo, estndares, entre otros.
Como se ha explicado en secciones anteriores de este captulo, dos de las caractersticas claves en los AVEAs son la interoperabilidad y la reutilizacin, pues inciden directamente en la mejora de la mayor parte de los factores que afectan a su calidad. A continuacin se presenta una adecuacin de los RNF de los AVEAs basados en los atributos de calidad del estndar ISO 9126:
Funcionalidad.
Se puede denir la funcionalidad de un AVEA como el conjunto de servicios
que ofrecen al usuario, as que sta guarda relacin directa con los requisitos iniciales. La reutilizacin proporciona una base para el establecimiento de prototipos rpidos de forma que permite al usuario estimar la funcionalidad del AVEA y ajustarla a sus necesidades o corregirla en las primeras etapas de sus desarrollo.
Fiabilidad.
La abilidad vista desde un AVEA, mide la capacidad de que ste mantenga sus
prestaciones de servicios bajo una serie de condiciones de aplicacin a lo largo de un perodo de tiempo. Cuando se reutiliza un AVEA, ste ha sido vericado y validado, pudiendo estar en muchos casos avalado por utilizaciones anteriores, mejorando as la abilidad del sistema global y su interoperabilidad.
Eciencia.
La eciencia de un AVEA relaciona su rendimiento con la cantidad de recursos
que consume durante su vida til, adems de los que se han invertido en su creacin.
100

Puede que la creacin de un AVEA reutilizable provoque que la eciencia se resienta: el AVEA creado particularmente para un contexto con particulares especcas, suele ser poco eciente si se aplica en otro distinto, adems ste requiere una inversin mayor en tiempo y costo para que sea reutilizable.
Capacidad de mantenimiento.
Es ms fcil el mantenimiento de AVEA construidas a
partir de otro reutilizable. Y la caracterstica de interoperabilidad permite que pueda ser trabajado en forma colaborativa.
Portabilidad.
Un AVEA ser ms portable cuanto ms fcil sea su transferencia de un
entorno (plataforma) a otro. Como sta es una de las caractersticas de mayor peso a la hora de generar AVEAs reutilizable e interoperables, la portabilidad se ver incrementar en sistemas donde se ha aplicado reutilizacin.
De acuerdo con lo expuesto anteriormente, se relacionaron las caractersticas denidas por AVEA, de la caracterstica de aplicacin Web, partiendo del caso de uso, haciendo una correspondencia con la terminologa de ISO/IEC 9126 - 1. Se obtiene as un modelo de calidad estndar. Ver gura 3.6
Figura 3.6: Modelo de Caso de Uso con sus RNF asociados
101
A continuacin se presenta el modelo de medicin para el dominio de los AVEAs y sus RF, donde se puede observar la forma de cuanticar los requisitos que deben ser considerados basados en la funcionalidad que debe prestar. Ver tabla 3.1
Tabla 3.1: Instanciacin del modelo de los RF de un AVEA con los RNF de ISO 9126 AVEA Requisitos Funcionales Instalacin del sistema Ingreso Sistema al Funcionalidad Precisin Requisitos de Calidad segn ISO/IEC 9126 y ISO/IEC 19796 Fiabilidad Usabilidad Mantenibilidad Portabilidad Disponibilidad, Recuperabilidad,Tolerancia a fallas Conabilidad Instalabilidad Eciencia Uso de Recursos, Tiempo de Respuesta Uso de Recursos, Tiempo de Respuesta Integracin, Apertura Reusabilidad, extensibilidad Adaptabilidad, Unicidad Adaptabilidad Reusabilidad Reusabilidad Adaptabilidad
Gestin de los AVEAs Gestin de la metadata en los AVEAs Construccin de AVEA Gestin de la informacin en AVEA Gestin de los roles en el AVEA Gestin de las propiedades en el AVEA Gestin de las actividades en AVEA Gestin de los entornos en AVEA Gestin de los guiones en AVEA Empaquetado de AVEA Generacin de estrategias
Autenticacin, autorizacin, No repudio, Integridad Interoperabilidad, Conabilidad Conveniencia, completitud Interoperabilidad, Conveniencia Conformidad, Interoperabilidad Interoperabilidad Precisin Precisin
Precisin
Reusabilidad
Interoperabilidad Conformidad Interoperabilidad, Conformidad,Completiud Interoperabilidad Apertura Integracin Apertura
Reusabilidad Reusabilidad Reusabilidad Reusabilidad Adaptabilidad Adaptabilidad
Uso de Recursos
102
3.5.3. Priorizar los casos de usos

Priorizar las caractersticas de calidad teniendo en cuenta los requerimientos de calidad y objetivos de calidad del sistema y su personalizacin con la norma ISO/IEC 9126 - 1 y ISO/IEC 19796, fue usada para organizar jerrquicamente las caractersticas. Ver gura 3.7 Esta priorizacin apoya el modelo de calidad obtenido por la integracin de la norma ISO/IEC
Figura 3.7: Reestructuracin de los RNF comunes en el modelo de caso de uso
9126
[U+2010]
1 y ISO/IEC 19796, que se presenta en la tabla 3.2
Tabla 3.2: Modelo de calidad en el dominio de AVEA Modelo de Calidad segn ISO/ICE 9126-1 y AVEAs
Caractersticas segn 9126-1 Funcionalidad Interoperabilidad(Interoperability) ISO/IEC Sub-caracterstica y sub-sub-caracterstica segn ISO/IEC 9126-1 y ISO/IEC 19796
(Funcionality)
ISO/IEC
Interoperabilidad
La capacidad del software de interactuar con otro software (ISO/IEC 9126-1) Continua en la siguiente pgina

Tabla 3.2 (cont.) Modelo de calidad en el dominio de AVEA
103
Se reere a la capacidad de cumplir con los objetivos propuestos, bajo determinadas condiciones de operacin. (Functionality, ISO/IEC N2228, 1999:6.2)
Modelo de Calidad segn ISO/ICE 9126-1 y AVEAs IMS LD (estndar de Interoperabilidad es eLearning que apoyo la si el software puede interoperabilidad) interactuar con otros sistemas, en el mbito de los AVEAs se relaciona a la accesibilidad del mismo.
ISO/IEC 19796 Completitud ISO/IEC 19796
Completitud Todos los procesos educativos son cubiertos por el modelo de referencia. El modelo puede ser adaptado a cualquier escenario educativo seleccionando un subconjunto de sus procesos
Adecuacin
ISO/IEC IMS-LD (estndar de eLearning que apoyo la idoneidad)
Para ISO/IEC consiste en proporcionar el conjunto de funciones apropiadas para tareas especcas del usuario.
tiene que ver si el AVEA tiene denido los Objetivos de aprendizaje, Contenidos, presencia de las actividades de aprendizaje y modelo pedaggico asociado
Fiabilidad
CONTROL DE FALLAS (FAILURE AVOIDANCE)
(Reliability)
ISO/IEC
Availability
Segn ISO/IEC 9126-1, availability es la combinacin de madurez(maturity, evitar fallas), mantenerse sin fallas (fault tolerance) y capacidad de recuperarse de fallas (recoverability) Continua en la siguiente pgina
104

Se reere a la capacidad de mantener un nivel de desempeo bajo determinadas condiciones de operacin. (Reliability ISO/IEC N2228, 1999:6.2)
IMS-LD
Modelo de Calidad segn ISO/ICE 9126-1 y AVEAs Tolerancia a Fallas es la habilidad de mantener un nivel de funcionamiento en caso de fallas del software o errores de interfaz, est relacionada a la forma en que el AVEAs se comporta en distintos entornos (plataformas). Se relaciona a la reutilizacin e interoperabilidad.
Completeness descripcin of
Usabilidad (Usability)
Apropiabilidad
ISO/IEC
Se reere a la capacidad de ser proveer integridad en la documentacin del usuario y facilidad de uso de los ambientes del sistema
Integridad en la descripcin
Segn ISO/IEC 9126-1, Completeness of descripcin es la Integridad en la descripcin y
IMS LD
ISO/IEC
Esta caracterstica es importante en los AVEAs pues representa la necesidad de ajustarse al estndar IMS LD para lograr la integridad de su descripcin
Completeness user facility of documenta-
Completeness of user documentation and or help facility es la Integridad en la documentacin del usuario y o facilidad de uso
tion and or help
IMS LD
Completeness of user documentation and or help facility Esta caracterstica es importante en los AVEAs pues proveer facilidad en el uso de la icorporacin de las tecnologas de informacin y comunicacin en el campo pedaggico es un gran reto.
Mantenibilidad (Maintainability)
Extensibilidad(changeability)
Segn ISO/IEC 9126 es la capacidad de soportar cambios Continua en la siguiente pgina

105
Se reere a la capacidad de ser susceptible a modicaciones: correcciones, mejoras, adaptacin al cambio del ambiente, requisitos y especicaciones funcionales. (Maintainability, ISO/IEC N2228, 1999:6.5)
Modelo de Calidad segn ISO/ICE 9126-1 y AVEAs ISO/IEC Changeability
IMS LD
Facilidad de Cambio mide el esfuerzo necesario para modicar aspectos del software, est relacionada a la Flexibilidad y Adaptabilidad Changeability
Gerencia y aprovisionamiento (changeability)
ISO/IEC IMS-LD ISO/IEC IMS-LD, SCORM
Integracin con la Web (changeability)
LOM,
Changeability La incorporacin de distintos estndares en la construccin de AVEAs representa la fcil integracin con la web y est asociado a los atributos de interoperabiidad y reutilizacin
Portabilidad
Escalabilidad (Scalability o adaptability)
Para ISO/IEC 91261, la adaptability implica la independencia de plataforma: del sistema operativo o tecnologa en particular. Scalability est incluida en adaptability y se basa en la capacidad del software de adaptarse en cuanto, por ejemplo, a tamao de la pantalla o volumen de transacciones.
(Portability)
Se reere a la capacidad de ser transferido de un ambiente a otro: organizacional, software o hardware.
ISO/IEC
adaptability
106

(Portability, ISO/IEC N2228, 1999:6.6)
Modelo de Calidad segn ISO/ICE 9126-1 y AVEAs IMS-LD, Los subprocesos, obSCORM(estndar jetivos y resultados asociado a los Objetos de todos los procesos de aprendizaje). del modelo (AVEA) son adaptables y extensibles de forma individual, permitiendo adaptar el modelo a un contexto educativo y organizacional.
ISO/IEC 19796
3.5.4. Identicar las arquitecturas candidatas

Para la identicacin de la arquitectura candidata se precis revisar los estilos arquitecturales y su relacin con el dominio del eLearning.
En la publicacin de Perry y Wolf
[80] se establece el razonamiento sobre estilos de ar-
quitectura como uno de los aspectos fundamentales de la disciplina de la Arquitectura del Software. Un estilo es un concepto descriptivo que dene una forma de articulacin u organizacin arquitectnica. El conjunto de los estilos cataloga las formas bsicas posibles de estructuras de software, mientras que las formas complejas se articulan mediante composicin de los estilos fundamentales.
Dentro de este marco, Shaw y Garlan [81] denen un estilo arquitectural como una familia de sistemas en trminos de patrones de organizacin estructural, un vocabulario de componentes y conectores con restricciones. Por su parte, Bass,Clements Y Kazman [82], determinaron que un estilo arquitectural est compuesto por un conjunto de componentes, su topologa de interrelacion, sus restricciones semnticas y el conjunto de conectores. Siguiendo la misma lnea, los estilos que habrn de describirse a continuacin son los ms representativos y vigentes dado que la agrupacin de estilos y sub-estilos dieren de autor a autor, es por ello que se combinaron los principales estilos arquitecturales segn Bass et al [82] y Fielding [83], los cuales se muestran en la Tabla 3.3
107
Tabla 3.3: Principales estilos arquitecturales
Estilo
Estilos de Flujo de Datos
Composicin
Tubera y ltros Model-View-Controller (MVC)
Estilo de Llamada y Retorno
Arquitectura en Capas Arquitectura Orientada a Objetos Arquitectura Basada en Componentes
Estilos Centrados en Datos
Arquitectura de Pizarra o Repositorio
Estilos de Cdigo Mvil Estilos heterogneos
Arquitectura de Mquinas Virtuales Arquitectura Basada en Atributos Arquitectura Basada en Eventos
Estilos Peer-to-Peer
Arquitectura Orientada a Servicios Arquitectura Basada en Recursos
3.5.5. Denicin de los estilos arquitecturales para eLearnings

Hasta hace poco ms de una dcada, las aplicaciones en el rea de tecnologa educativa para el dominio eLearning se han enfocado hacia el tipo de informacin que desean procesar y se han construido de manera aislada unas de otras. Entre las diferentes soluciones podemos encontrar diversos lenguajes y plataformas tecnolgicas donde han sido desarrollados:
Clientes servidores monolticos, sistemas n-capas y silos mainframe.
Sistemas orientados a objetos, procedurales y basados en componentes
Mltiples lenguajes de programacin.
Middleware diferente para manejar la comunicacin (MOMS, Object Request
Brokers (CORBA, RMI), RPCs)
Mltiples modelos de transmisin (conversacionales, requerimiento/respuesta, publicacin suscripcin )
Mltiples tecnologas de Persistencia de Datos (Bases de Datos(BD) relacionales, VSAM, BD de escritorio como Microsoft Access, XML BD, BD orientados a objetos, entre otros )
108
En el rea de ingeniera de software como resultado de los esfuerzos de resolver los problemas de integracin de las arquitecturas y sistemas anteriores surgi SOA (Service Oriented Architecture). SOA representa una arquitectura gil, abierta, federada, extensible y compuesta, comprendida de servicios autnomos con capacidades de calidad (QoS), interoperables, reusables, y con transparencia de locacin de los mismos. Permite establecer una abstraccin de la lgica y de la tecnologa de negocio de manera que se puede introducir cambios al proceso de modelado del negocio y de la arquitectura tcnica, dando por resultado bajo acoplamiento entre estos modelos. [15, 84].
No obstante, los procesos de educativos bajo el dominio de eLearning, existentes diferentes funcionalidades que usan distinta informacin procedente de los mismos y a travs de diversos componentes claves del dominio, existe una clara interrelacin de sus elementos.
Dicha caracterstica de los procesos de negocio del dominio eLearning, a la hora de integrar las aplicaciones, ha generado graves inconvenientes y costos de desarrollo al intentar automatizarlos como consecuencia lgica de las necesidades de procesamiento de los consumidores. Esto debido a que la informacin se encuentra frecuentemente en varios sistemas a la vez, con formatos dispares, y tecnolgicamente diferentes, con baja reutilizacin y poca interoperabilidad, a la vez que residen en lugares geogrcamente distintos.
Es por ello, que se propone una transferencia del campo de la ingeniera de software al campo educativo, especcamente en el dominio de eLearning con la incorporacin de la arquitectura SOA. La arquitectura SOA cumple con integracin, reusabilidad, transparencia de locacin, interoperabilidad y seguridad, mediante un componente central denominado ESB (Enterprise Service Bus). Un Enterprise Service Bus es una plataforma de integracin, basada en estndares y altamente distribuida, que permite a las aplicaciones ser accedida va servicios. Esta infraestructura combina, segn Chappell,M. Keen et al y Josuttis [85, 86, 84]
Middleware de mensajera (MOMs)
Web Services y REST-Based Services

XML
109
Transformacin de datos
Conversin de protocolos
Ruteo inteligente
Una descripcin detallada de cmo soporta SOA a travs del ESB estas caractersticas se encuentra en la tabla 3.4
El modelo de despliegue de los ESB es una red integrada de instancias de servicios, que se distribuyen y colaboran a travs de contenedores de servicios [85], como se visualiza en la
gura 3.8. Estos contenedores estn distribuidos a travs de la red y permiten descentralizar la arquitectura y el despliegue incremental de los mismos.
Un ESB desacopla a los consumidores de los servicios de los proveedores de los mismos, y permite virtualmente, conectarlos independientemente de la tecnologa de las aplicaciones. Adems proveen capacidades adicionales como [85, 86]:
Manejo centralizado de la seguridad
Envo de mensajes asegurado
Conguracin y monitoreo centralizado
Directorios de servicios
Gateways de acceso externo a la empresa
Servicios de coreografa de procesos
Los mismos soportan estilos de integracin empresarial como son arquitecturas manejadas por mensaje y arquitecturas manejadas por eventos, adems de SOA. Punto focal en la integracin de aplicaciones de eLearning.
Mtodos de evaluacin de ESB -SOA Existen varios mtodos para evaluar el ESB de
una Arquitectura Orientada a Servicios. El grupo Seybold [87], y Vollmer [88] disearon
110
Caracterstica que Descripcin de la mejora mejora SOA y ESB

Procesamiento tribuido dis-
Tabla 3.4: Aportes fundamentales de SOA y su ESB
EL procesamiento se distribuye a travs de contenedores de servicios, que permiten gestionar el despliegue y ciclo de vida de los servicios y puede ser distribuido en distintas locaciones geogrcas. Hacindolo escalable fcilmente la infraestructura.
Uso de estndares
A diferencia de las arquitecturas anteriores, hace alto uso de estndares, en especial de XML, lo cual baja costos de capacitacin y licenciamiento, permite cambiar de productos SOA en el ESB con relativa facilidad, y a la vez permite ms interoperabilidad entre los distintos componentes que conforman la infraestructura de integracin.
Web Services
Los ESB de SOA soportan completamente la mediacin y gestin de servicios va web servicies, a la vez que adhieren a la mayora de los estndares WS-*
Ruteo Inteligente
Un ESB es capaz de decidir el destino de los mensajes que transitan a travs de l, basado en el contenido del cuerpo del mensaje, basado en los datos de contexto del mensaje o por medio de motores de reglas como pueden ser los motores que implementan BPEL4WS.
Transformacin de protocolos
de y
Un ESB es capaz de de transformar los datos de un mensaje de un formato a otro, en especial por el uso de plantillas XSLT. Tambin es capaz de mediar transparentemente entre las aplicaciones para realizar conversiones entre protocolos distintos de comunicacin. La mensajera conable se logra a travs de los MOMs que posee el ESB.
mensajes, conversin mensajera conable
111
Figura 3.8: Visin general de un ESB de SOA [14]
frameworks y cuestionarios de evaluacin que agrupan las caractersticas funcionales y no funcionales que deberan tener un ESB. Estos mtodos son bastante completos pero no apuntan a medir los ESB mediante atributos de calidad sino por el grado de resolucin de caractersticas tcnicas.
Existe otro mtodo llamado ESB-QM, que presenta las caractersticas propias de los ESB, los cuales son [14]:
Ubicuidad
Es el conjunto de atributos de un ESB que brindan a un servicio la capacidad
de ser encontrado y utilizado independiente de su ubicacin e implementacin. Sus subcategoras son:
1. Transparencia de ubicacin: Capacidad de un ESB para localizar la instancia de un servicio independiente de su ubicacin. Se logra a travs del enrutamiento inteligente
112

y debe poder ser congurado basado en el asunto, contenido o itinerario del mensaje. Con la mediacin entre servicios, un servicio cliente que invoque al proveedor de servicio solo necesita saber que el servicio existe. El cliente no necesita saber dnde se est ejecutando el servicio. El ESB localiza el servicio cuando se invoca. Esto proporciona un cierto nivel de virtualizacin de los servicios, de forma que si un equipo falla, o si se cambia la ubicacin de un proveedor de servicio, no es preciso noticar el cambio a cada uno de los clientes individuales. La transparencia de ubicacin permite que los servicios se actualicen, muevan o reemplacen sin necesidad de modicar los cdigos de las aplicaciones. 2. Independencia de implementacin: Capacidad de un ESB para abstraer el contrato de la implementacin del servicio. 3. Facilidad de reubicacin: Permite al ESB la reubicacin transparente de la
implementacin de un servicio en caso de que esta haya cambiado. 4. Disponibilidad: Capacidad de un ESB para exponer servicios de negocio tanto a internos como a externos y componer servicios a partir de otros ya existentes a travs de lenguajes no procedurales, metalenguajes o cualquier otra metodologa.
Delegabilidad
Es el conjunto de atributos de un ESB que le permite a un servicio delegar
funciones a otro servicio y recuperar los resultados en forma transparente y conable a travs de ste. Sus subcategoras son:
1. Facilidad de desentendimiento: Capacidad de un ESB para permitir la entrega de un mensaje y liberar de responsabilidad al remitente. Esto es logrado a travs de la utilizacin de las facilidades brindadas por la mensajera asncrona y el paradigma publicacin/suscripcin.
Reusabilidad
Es la facilidad con la cual aplicaciones existentes o componentes pueden ser
reutilizados. Los servicios propios del ESB son modulares y auto-contenidos, reduciendo el nmero de dependencias de uso entre ellos. Por esta razn, es la capacidad de un servicio propio de ser reutilizado en muchas aplicaciones integradas va el ESB. Sus subcategoras son:
3.6. ARQUITECTURA CANDIDATA DERIVADA DEL MODELO DE CALIDAD
113
1. Separability: Es el conjunto de capacidades que permite independencia entre servicios y poca complejidad en sus relaciones. Est asociado con dos atributos: (a) Bajo acoplamiento que reere a la capacidad de un ESB para permitir la independencia entre las implementaciones de los servicios mediante la denicin de funcionalidades acotadas y especcas, y (b) Modularidad, que reere a la capacidad de un ESB para disminuir las dependencias entre dos servicios disminuyendo las dependencias articiales. 2. Flexibilidad: Los ESB facilitan la composicin de aplicaciones basndose en servicios. Permiten la denicin de sistemas complejos distribuidos, incluyendo la integracin de diferentes aplicaciones, sistemas, rewall, etc. Adems estos pueden ser construidos a partir de sistemas preconstruidos.
Manejabilidad
Los ESB deben tener las capacidades de administracin, de forma que puedan
gestionar y monitorear los servicios a los que dan soporte mediante registros y auditorias de servicios centralizados, fallas, estado de procesos, etc. Tambin deben ser capaces de integrarse en sistema de gestin del software. Sus subcategoras son:
1. Serviciabilidad: Capacidad de informar las condiciones de excepcin, proporcionando informacin de las causas y efectos de las mismas. 2. Trazabilidad: Capacidad de informar el paso por cada componente y noticar el estado de una transaccin de proceso de negocio en cada uno.
3.6. Arquitectura candidata derivada del modelo de calidad

Es importante destacar que los resultados obtenidos estn relacionados al anlisis de los requisitos funcionales y no funcionales en ambos casos (AVEA y SOA) y sus relacin con los modelos de ISO/IEC 9126-1 y ISO/IEC 19796 para los AVEAs y el modelo ESB-QM para SOA.
Como resultado de estos esfuerzos de integracin se plantea la incorporacin en los desarrollos tecnolgicos como la arquitectura candidata, la Arquitectura orientada a servicios (SOA por sus siglas en Ingles), que permite construir aplicaciones e integrar las existentes a partir de servicios autocontenidos y heterogneos, tanto en tecnologa como en locacin geogrca.
114
La herramienta tecnolgica que surge para resolver la parte tcnica de esta arquitectura, que reere a la integracin tecnolgica entre servicios, son los ESB (Enterprise Service Bus). En este Captulo se propone un anlisis de calidad a atributos que son propios de los productos de SOA, especcamente del ESB, basndonos en la taxonoma denida por el mtodo ESB-QM, que es el nico enfoque hasta la fecha que los considera.
A continuacin se comentan los resultados:
Funcionalidad:
se comprob que ambos modelos de enfoques contribuyen de manera
particular con el propsito del sistema, especialmente por el uso de ESB de SOA, que permite el manejo de los servicios y de la interoperabilidad entre las aplicaciones. Otro elemento considerado es la completitud, necesaria para los AVEAs propuesta por el modelo ISO/IEC 19796. Ambos enfoques, en general, presentan un soporte moderado a esta sub-caracterstica, as como a la Interoperabilidad, lo que favorece su adopcin.
Conabilidad:
en
esta
caracterstica
se
evaluaron
la
Madurez,
Tolerancia
Fallas
Recuperacin, pero tambin fue considerada la ubicuidad (ESB-QM) tomando en cuenta la transparencia de ubicacin de los servicios, la independencia de implementacin y la disponibilidad como caractersticas que propicia el enfoque de SOA. Esta
subcaratersticas presenta similitudes en ambos modelos.
Eciencia:
en el caso de esta caracterstica, se encontr que el modelo de SOA favorece un
mejor tiempo de respuesta, satisfaciendo tambin la Utilizacin de recursos. La razn para ello es la posibilidad de implementar el ESB para el acceso a distintas aplicaciones, manejadas en una unidad de componentes, lo que minimiza el nmero de conexiones.
Mantenibilidad:
La
arquitectura
SOA
posee
un
mayor
nivel
de
Modularidad,
esta
segmentada en servicios, destacando el modelo ESB-QM las caractersticas de exibilidad y separability.
Usabilidad:
la arquitectura SOA presenta una mayor modularidad y dbil acoplamiento, lo
que permite suponer que la complejidad de las interfaces y su operacin se pueden ver favorecidas.
115
Portabilidad:
en esta caracterstica se enfatizan la adaptabilidad, la unicidad que favorece
el uso compartido de recursos con otras aplicaciones. Es conveniente resaltar el hecho de que SOA resulte ser el ms conable, mantenible y destaca por su Eciencia.
Atributos de calidad presentes en SOA en correspondencia a los AVEAs

Segn Vojislav et al [89], la Arquitectura Orientada a Servicios puede evaluarse en los siguientes aspectos disponibilidad, seguridad y eciencia. La disponibilidad y seguridad estn presentes ya que este tipo de arquitectura provee garanta por encima de otras, por otro lado la eciencia no es muy adecuada, debido a la gran cantidad de capas que posee Web Service, adems de la necesidad de procesar estructuras de datos XML de esas capas, el procesamiento puede llegar a ser ineciente, y este tipo de arquitectura llega a ser catalogada como de baja eciencia y no adecuada para desarrollo de aplicaciones criticas.
Por su parte O'Brien et al [90], denen un conjunto de caractersticas de calidad asociados a la Arquitectura Orientada a Servicios como son alta abilidad, seguridad y eciencia media en relacin al rendimiento del sistema de software, en tanto que la eciencia tambin se puede observar a otro nivel, el de la organizacin, ya que se transforman los procesos de negocio en servicios compartidos con un menor costo de mantenimiento.
Por lo anterior descrito y analizado, el estilo Peer to Peer que establece la Arquitectura Orientada a Servicios es el candidato como solucin para el sistema generador de ambientes de enseanaza aprendizaje del dominio de eLearning como se detallar en el captulo 4.

En el contexto educativo actual, en el que las TIC se consideran un elemento impulsor fundamental para la innovacin y un verdadero catalizador del crecimiento acadmico en los prximos aos, las organizaciones educativas estn enfrentndose a un cambio de paradigma fundamental en la concepcin del desarrollo de software. Se est pasando de considerar el software como un producto que se adquiere a manejar un contexto en el que el software se concibe y se ofrece en forma de servicios que pueden seleccionarse y combinarse libremente por sus usuarios nales. Este cambio se apoya en un principio fundamental: el consumidor de
116
un servicio no posee el servicio y por tanto no necesita preocuparse de todos aquellos aspectos asociados generalmente a dicha propiedad, tales como infraestructura, tecnologa, integracin, operacin y mantenimiento. En su lugar, tan slo tiene que escoger el servicio o la combinacin de servicios que mejor se adapta a sus necesidades de negocio.
Este cambio de paradigma est contribuyendo notablemente a que la tecnologa cumpla con su rol de facilitadora del cambio en lugar de ser un factor inhibidor del mismo. La predisposicin al cambio, la exibilidad, la agilidad, la dinamicidad, la adaptabilidad y la capacidad de innovacin son requisitos de negocio y como tales deben constituir una premisa para los desarrolladores de software y nunca verse deteriorados o incluso inhibidos por estos ltimos, como sucede en muchas ocasiones.
Lo esfuerzos sobre tecnologa educativa buscan lograr que sea conable, escalable, robusta, segura y adaptable a los cambios es una necesidad ante el crecimiento y diversidad de sistemas y tecnologa ante los requerimientos de alta disponibilidad que exigen sus consumidores. Los AVEAs y su construccin no escapan a esta realidad. Es por ello que una vez diagnosticado el dominio, y determinado las requisitos funcionales y no funcionales.
La aproximacin SOA es muy clara con respecto a las capacidades de innovacin y de optimizacin de los procesos de negocio. Sus capacidades de simplicacin, anlisis y mejora de los procesos de negocio en tiempo real, junto con las facilidades que introduce para la reutilizacin (caractersticas bsica de los AVEAs) e integracin de servicios y tecnologas existentes. La presentan como una clara oportunidad para facilitar el cambio y acelerar el ritmo de innovacin. En los siguientes captulos se analizan las principales oportunidades existentes en torno a la tecnologa de servicios y SOA aplicado a la contruccin de AVEAs.
La integracin de aplicaciones de software representa un desafo no solamente para la industria sino tambin dentro de los mbitos acadmicos. Su evolucin ha dado lugar a la instrumentacin de mtodos y herramientas que la sustenten e incluso la denicin de nuevas arquitecturas como lo es SOA y su principal tecnologa de soporte, los ESB. El anlisis de
117
calidad, por su parte, es una actividad necesaria para asegurar el cumplimiento de atributos que son propios de SOA y ESB en el dominio de los AVEAs.
Captulo 4
Arquitectura para sistemas generadores de AVEAs

El desarrollo de los Sistemas para el dominio del eLearning involucra el anlisis de diferentes dominios de conocimiento y el estudio de metodologas que faciliten la integracin y distribucin de la informacin. Estos sistemas, usualmente combinan ciertas propiedades que plantean problemas particulares en su diseo vinculados a la heterogeneidad en la informacin del campo educativo. Por ello, uno de los requerimientos fundamentales, es brindar facilidades de integracin entre los mismos. En los ltimos aos, el desarrollo de software basado en arquitecturas orientadas a servicios, emergi como una importante solucin al problema del desarrollo de sistemas grandes y complejos. SOA brindan el soporte para la integracin de partes en sistemas mayores, facilitando la denicin de una estructura de ensamblado adecuada. En el presente captulo se plantea la utilizacin SOA, con el n de obtener un modelo arquitectural que ofrezca servicios reusables, que a travs de una plataforma conveniente de integracin, puedan ser ensamblados para distintos tipos de aplicaciones del dominio.
En el captulo 3, se realiz el estudio y comparacin de diferentes estilos y patrones arquitecturales, analizado segn el modelo de calidad obtenido. Esto permiti la obtencin de una arquitectura candidata para el desarrollo de sistemas en el dominio del AVEA. En este apartado se describe las arquitecturas existentes y estndares ms utilizados en la actualidad, en particular los vinculados al desarrollo de sistemas de eLearning. Luego se hace una 118
4.1. INTRODUCCIN
119
revisin bibliogrca de metodologas para implantar arquitectura seleccionada. Para nalizar con la propuesta arquitectural para el dominio especco de los sistemas generadores de AVEA.
El aporte de este captulo se concreta en la identicacin de los elementos clave en el modelado de los ambientes de enseanza aprendizaje para eLearning. Estableciendo sus puntos de comienzo y n, se proporciona las entradas necesarias para su compresin, automatizacin o incorporacin en diferentes procesos de desarrollo, especcamente en la propuesta arquitectural.
4.1. Introduccin
La Arquitectura del Software (AS) es la parte de la ingeniera del software que se ocupa de la descripcin y el tratamiento de un sistema como un conjunto de componentes, que facilite su organizacin en los diferentes subsistemas que lo forman. Esta disciplina surge ante la necesidad de describir sistemas software complejo, descomponerlos en un conjunto de componentes y ver qu relaciones existen entre ellos.
Especicar la arquitectura de un sistema software en etapas tempranas del ciclo de vida tiene muchas ventajas. La arquitectura del software puede denirse como el nivel del diseo del software en el que se denen tanto la estructura como las propiedades globales de un sistema, centrndose en aquellos aspectos del diseo y posterior desarrollo que no pueden tratarse adecuadamente dentro de los mdulos o componentes que lo forman.
As pues, desde el punto de vista del proceso de desarrollo, la arquitectura del software se encarga de realizar el diseo preliminar o de alto nivel del sistema, de la organizacin del mismo, y de aspectos relacionados con su desarrollo y adaptacin al cambio (composicin, reconguracin y reutilizacin); y se despreocupa, por tanto, del diseo detallado, del diseo de algoritmos o del diseo de las estructuras de datos. Se trata de una organizacin de alto nivel del sistema software como una coleccin de componentes, conexiones entre dichos componentes y cmo estos interactan entre s; donde cada componente puede tomar decisiones acerca de los mensajes que enva a su entorno y reacciona cuando recibe de ese entorno un
120
CAPTULO 4. ARQUITECTURA PARA SISTEMAS GENERADORES DE AVEAS
mensaje para el que est programado. Adems, la AS trata de la descripcin, vericacin y reutilizacin de los sistemas software.
La descripcin de la arquitectura de los sistemas software adquiere gran importancia al aumentar su complejidad. Es por ello que, dado que las expectativas de los usuarios aumentan cada vez ms y la gestin de estos sistemas por parte de los diseadores se hace ms difcil. Es necesario elegir una arquitectura adecuada para ellos, as como la posterior implementacin de cada una de las partes. Esta denicin arquitectnica es la que permitir gestionar los sistemas complejos, centrando su estudio en los componentes que lo forman y en las relaciones que se establecen entre ellos, de modo que, al nal, estas partes componentes puedan trabajar conjuntamente para resolver el sistema.
En esta seccin se presenta el abordaje de un conjunto de arquitectura del software para eLearning que fungen como estndar en la actualidad, las cules utilizan de base los Servicios Web, y cmo es que stas son impactadas con la incorporacin de los atributos de calidad tratados en el captulo anterior y dan forma al modelo de Framework que se presenta en este trabajo. Luego se denen los Servicios Web, la Arquitectura Orientada al Servicio, y los sistemas de gestores de Procesos de negocios (BPM), explicando sus componentes y caractersticas ms importantes. Posteriormente se presentan metodologas asociadas con el grupo de tecnologas propuestas para alcanzar las ventajas que se consiguen en este tipo de arquitectura de software. Y por ltimo, se presenta y describe la arquitectura usada para el prototipo que se presentar en el capitulo 5.
4.2. Arquitectura para de sistemas de eLearning

En este apartado se presentan algunas de las arquitecturas ms importantes que sirven de base en la construccin de sistemas de eLearning.
4.2.1. Modelo de categorizacin de variables en el eLearning

IEEE ha realizado un gran esfuerzo para crear un estndar para el desarrollo de arquitecturas de sistemas de eLearning. Su ltima versin es la IEEE P1484.1/D9 (IEEE, 2001), la
4.2. ARQUITECTURA PARA DE SISTEMAS DE ELEARNING
121
cual establece una arquitectura de alto nivel para sistemas de eLearning y sus componentes llamada LTSA (Learning Technology Systems Architecture).
En su arquitectura, IEEE especica cinco niveles, aunque solo establece como obligatorio el nivel 3 (System Components). En la gura 4.1 podemos ver grcamente estos niveles.
Figura 4.1: Arquitectura LTSA de IEEE
Nivel 1.
Learner and Environment Interactions. Es el nivel ms genrico: el estudiante
tiene conocimientos nuevos o diferentes despus de una experiencia educativa. Hay una interrelacin entre el estudiante y el sistema de eLearning. Se reere a la adquisicin, transferencia, intercambio, descubrimiento, etc., de conocimientos o informacin a travs de la interaccin con el entorno.
Nivel 2. Nivel 3. Nivel 4.
Learner-Related Design Features. Relacionado con los efectos de la naturaleza
humana del usuario sobre el diseo de los sistemas de aprendizaje informticos. System Components. Describe los componentes bsicos de la arquitectura. Implementation Perspectives and Priorities. Describe cmo una gran variedad de
organismos, industrias, empresas y entes educativos analizan los sistemas de eLearning, en cuanto a: vericacin y validacin de los principales componentes; importancia de cada componente en funcin de las distintas perspectivas y prioridad entre los niveles.
122

Operational Components and Interoperability. Proporciona una visin global de
Nivel 5.
cmo componentes e interfaces que permiten la interoperabilidad (codicacin, APIs y protocolos) puede estar relacionado con la arquitectura de sistemas de eLearning.
El Sistema de Componentes del LTSA identica los interfaces crticos de interoperabilidad para sistemas de eLearning. El propsito de este estndar es describir y entender los componentes generales identicando funciones generales. Las implementaciones reales de sistemas de eLearning pueden no corresponder componente a componente con este estndar, pero conceptualmente deben realizar las mismas funciones. Por ejemplo, por motivos comerciales, las funciones de evaluacin, entrega y entrenamiento pueden agruparse en la misma herramienta aunque conceptualmente sean componentes separados.
El estndar 1484.1 del IEEE, LTSA (Learning Technology Systems Architecture), dene una arquitectura neutral con respecto a los contenidos, metodologas pedaggicas y la tecnologa de la plataforma. Se trata de una arquitectura a muy alto nivel para sistemas de aprendizaje que usen la tecnologa como medio principal de transmisin y soporte para los procesos educativos. LTSA proporciona un marco para entender los sistemas de eLearning actuales y futuros, pero no especica detalles concretos para su implementacin (como lenguajes de programacin, herramientas de autor o sistemas operativos) ni para su gestin (como ciclo de vida de los componentes u objetos educativos, aseguramiento de la calidad, control de acceso o administracin de usuarios).
El desarrollo del estndar se centra en el nico nivel normativo existente: el nivel tres representado en la gura 4.2 En el diagrama que dene LTSA se diferencian tres tipos de elementos:
Procesos: Learner Entity, Evaluation, Coach y Delivery
Almacenes: Learning Resources, Learner Records
Flujos de datos: Learning Preferences, Learner Info, Assessment, Behavior, Multimedia, Interaction Context, Locator, Catalog Info, Query, Learning Content.
123
Figura 4.2: Nivel 3- System Components
Si observamos el nivel de abstraccin con que se describen las entidades de LTSA podremos deducir que no especica ningn sistema en concreto. La libertad y ambigedad que ofrece no facilita la interoperatividad entre diferentes implementaciones de este estndar. Para los procesos de este nivel deben denirse las entradas, funcionalidad y salidas. Los almacenes se describen en funcin de los datos que contienen y los mtodos de almacenamiento, bsqueda y actualizacin. Los ujos se asocian mediante el tipo de informacin que uye y el tipo de conectividad (unidireccional o bidireccional, esttica o dinmica). A continuacin se describen los procesos:
Learner Entity:
estudiante,
es un
una
abstraccin de
de
un
estudiante aprendiendo
humano.
Puede
representar un grupo
un de
grupo
estudiantes
individualmente,
estudiantes aprendiendo cooperativamente, un grupo de estudiantes aprendiendo de una forma heterognea (algunos colaborando, otros individualmente), estudiantes con distintos roles, etc.
Evaluation:
es el proceso encargado de analizar el comportamiento del estudiante, teniendo
en cuenta el contexto en el que se encuentra y la informacin relativa al propio estudiante.
Coach:
negocia las preferencias del estudiante y acta en consecuencia (por ejemplo para
mostrar la informacin en el idioma adecuado o a la resolucin preferida por el estudiante, etc.). De esta forma se permite establecer el estilo de aprendizaje, que puede ser seleccionado unilateralmente por el estudiante (learner entity) o por el sistema (coach),
124

mediante negociacin bilateral entre ambos, o bien por una autoridad externa padres, docente, institucin, desarrollador del curso...)
Delivery:
Recupera los contenidos del almacn de contenidos, a partir de su localizacin
y se encarga de su distribucin y presentacin para el estudiante. El mecanismo de distribucin puede variar ampliamente al igual que los formatos de presentacin, y puede implementarse teniendo en cuenta el proceso Evaluation para conseguir el acoplamiento necesario de cara a obtener experiencias de aprendizaje interactivos. De forma resumida, la operativa de los sistemas que implementan esta arquitectura es la siguiente: 1. Los estilos, estrategias y mtodos de aprendizaje los denen los estudiantes mediante preferencias de aprendizaje.
2. Los estudiantes son observados y evaluados a travs de sus interacciones con el sistema.
3. La evaluacin produce informacin sobre el estudiante y su conocimiento.
4. La informacin sobre el estudiante se almacena en la base de datos histrica de estudiantes.
5. El proceso de entrenamiento revisa la informacin sobre el estudiante y su conocimiento para establecer objetivos de aprendizaje futuros.
6. El proceso de entrenamiento busca los recursos de aprendizaje necesarios para cada contenido.
7. El proceso de entrenamiento extrae los localizadores del catlogo de recursos de aprendizaje y los pasa al proceso de entrega.
8. El proceso de entrega extrae los contenidos de aprendizaje y los transforma en una presentacin interactiva multimedia.
4.2.2. Arquitectura de CISCO

Cisco ha desarrollado un modelo de arquitectura para sistemas de eLearning, caracterizado por ser un sistema abierto, escalable, global, integrado y exible Cisco 2001. Su visin es
125
mucho ms comercial que la del IEEE, como corresponde a su carcter de empresa privada, y va ms encaminada a una implementacin concreta, la suya propia. En todo caso, vamos a presentarla brevemente por el inters evidente de su nivel intermedio.
La arquitectura completa se divide en tres niveles tal como se ve en la gura
4.3 Cada
Figura 4.3: Arquitectura de Cisco Systems
uno de los niveles tiene la siguiente funcionalidad:
Nivel 1. The Underlying Network Infrastructure
Este es el ltimo nivel o nivel de red
en el que se apoya el nivel intermedio. Segn Cisco, la arquitectura de red propuesta tiene por objeto proporcionar disponibilidad, seguridad y buenos resultados en tiempo y calidad de acceso; integrando tecnologas de:
IP Multicasting, para transmitir datos multimedia desde distintos servidores a muchos clientes diferentes a la vez y en cualquier momento. Quality of Service (QoS), para proteger la transmisin de datos crtico mientras se realizan tareas de eLearning muy costosas en cuanto a recursos de red, como transmisin de videos, clases virtuales, etc. Seguridad, para proteger los datos y aplicaciones de accesos indebidos: gestin de password, encriptacin de datos a transmitir, utilizacin masiva de recursos
126

y tecnologa VPN (Virtual Private Network) que gestiona la seguridad de redes privadas dentro de la red general. Mecanismos de entrega y distribucin de contenidos:
CDN (Content Delivery Network), que utilizando la tecnologa de red SODA (Self-Organizing Distributed Architecture), permite a los usuarios recibir localmente datos procedentes de servidores de intranet y extranet optimizando los accesos.
CDM (Content Distribution Manager), que maneja la distribucin de los contenidos seleccionando los servidores por proximidad fsica y disponibilidad y segn las restricciones establecidas por el administrador de la red.
Es un nivel excesivamente cercano a las infraestructuras fsicas y que carece de inters a los efectos de esta tesis, si bien la importancia de sus propuestas es ms que patente en entornos que dependen en gran medida del correcto funcionamiento de la tecnologa.
Nivel 2. The Application Blueprint
Este es el nivel intermedio que realiza la gestin
propia de eLearning: contenidos, estudiantes, cursos, etc. Es un modelo modular donde las tareas y responsabilidades se dividen en reas funcionales relacionadas e integradas. Estos mdulos son los siguientes:
Operaciones de Negocio-BOS (Business Operations Services). Est formado por un conjunto de herramientas y aplicaciones integradas que soportan los siguientes servicios:
Gestin de la efectividad del aprendizaje y de la experiencia del estudiante. Soporte a las consultas on-line, las llamadas gratuitas de apoyo y la distribucin por e-mail.
Servicio de ayuda on-line en las aplicaciones. Gestin de la seguridad de acceso aplicaciones y contenidos. Generacin de informes de progreso, utilizacin y resultados. Anlisis de necesidades: Gap Analysis mide la diferencia entre los conocimientos necesarios de un estudiante segn sus competencias y sus conocimientos reales;
127
y Cost Model Analysis que, extrapolando datos de los resultados anteriores, determina la clase de contenidos que deben ser creados en otros mdulos. Gestin de Contenidos-CMS (Content Management Service). Permite vericar, registrar utilizando metadatos, ensamblar, manejar y publicar contenidos. Est formado por los siguientes submdulos:
Workow Application. Aplicacin de ujo de datos de gestin de contenidos, en la que es posible personalizar el ujo de datos segn el grupo de trabajo que la utilice.
Authoring Tool Integration Service. Permite que distintos tipos de contenidos: texto, test, grcos, etc. se integren en cualquier nivel jerrquico de la estructura de contenidos.
Registry Services. Almacena la ubicacin, los metadatos descriptivos y la estructura de metadatos asociada de cada contenido. Fsicamente pueden almacenarse en el Content Storage System o en otra ubicacin segura.
Object Mining Service. Localiza contenidos mediante distintos criterios de bsqueda. Aplicacin muy til para poder aplicar reusabilidad.
Assembler.
Permite,
utilizando
los
resultados
del
mdulo
anterior,
crear
plantillas que son registradas y almacenadas. Permite ensamblar contenidos utilizando estas plantillas como base.
Content Storage Services. Proporciona la gestin de almacenamiento fsico de los contenidos: manejo de versiones, bloqueos, histrico, informes, etc.
Publishing Services. Cuando un curso est listo, proporciona los datos para su puesta a disposicin que har el mdulo DMS.
Gestin de la Demanda-DMS (Demand Management Services). Se encarga de poner a disposicin de los estudiantes los cursos terminados. Est formado por un conjunto de herramientas y aplicaciones integradas que soportan los siguientes servicios:
Presentar
al
estudiante
los
contenidos
de
un
curso
en
funcin
de
una
parametrizacin personalizada.
Manejar la distribucin de contenidos en funcin de las reglas establecidas por el administrador.
128
Controlar los contenidos que se distribuyen y en qu forma. Estos datos se pasan al mdulo LMS que es el que los utiliza para futuras peticiones e histrico.
Gestin del Aprendizaje-LMS (Learning Management Services). Es el mdulo al que acceden los estudiantes y que lleva el control de sus acciones. Est formado por los siguientes submdulos:
Personalization. Crea planes de enseanza personalizados en funcin del perl del usuario y de las preferencias personales.
Search/Browse. Permite realizar bsquedas y consultas en el catlogo de cursos. Registration. En unin al mdulo Search/Browse permite registrarse en un curso y gestionar las listas de espera, noticaciones, cambios de programacin, etc.
Learner Tracking. Contiene la historia del aprendizaje de cada estudiante: cursos realizados y situacin en los cursos actuales. Estos datos le permiten proponer cursos futuros en funcin del perl de cada estudiante.
E-Commerce. Junto con el mdulo Search/Browse permite realizar el pago de los cursos proporcionando varios mtodos de pago y gestin de datos nancieros.
Assessment. Analiza para cada estudiante su pre-assessment (diferencia entre lo que sabe y lo que debera saber para una determinada competencia) y su post-assessment (conrmacin de su conocimiento real). Con estos datos personaliza el material de estudio y informa comprensivamente del currculum del estudiante, para seguimiento personal o de la comunidad educativa.
Manager's Toolkit. Maneja la funcin de gestor educativo que puede aprobar o denegar altas en cursos, aadir o quitar estudiantes, seguir el progreso del aprendizaje, etc.
Survey. Recoge datos sobre la satisfaccin de los usuarios para envirselos al mdulo BOS.
Resource Management. Programa y asigna la utilizacin de recursos: equipos informticos, docentes, clases, eventos virtuales, etc.
129
Nivel 3. The Access Layer.
Este es el nivel ms alto o nivel de acceso a la aplicacin, donde
el tipo de persona o entidad que accede puede ser muy variado. Este nivel proporciona la posibilidad de denir diferentes portales de acceso personalizados.
4.2.3. IMS Abstract Framework (IAF)

Es interesante explicar de forma resumida el IMS Abstract Framework (IMS, 2003b), ya que es el contexto en el que se basa IMS para realizar las especicaciones de todas sus tecnologas de eLearning. Este framework no se ocupa de denir la arquitectura IMS, ms bien es un mecanismo para precisar un conjunto de servicios para los cuales se denen sus especicaciones de interoperabilidad. Como ya se indic en un apartado anterior, en los casos donde IMS no puede producir una especicacin, trata de adoptar o recomendar una especicacin conveniente de otra organizacin.
El framework de IMS tiene como particularidades:
Es una representacin abstracta del conjunto de servicios que se utilizan para construir un sistema eLearning en su sentido ms amplio.
Est centrado en el soporte de los sistemas de formacin distribuidos.
Cubre todo el rango de posibles arquitecturas eLearning que se podran construir a partir de un conjunto de servicios denidos.
Los principios orientadores del IMS IAF son:
Interoperabilidad: Las especicaciones estn basadas en el intercambio de informacin entre sistemas pero sin tomar decisiones acerca de cmo se tratan los datos en la comunicacin.
Orientada a servicio: La interaccin entre sistemas se dene en trminos de los servicios expuestos entre ellos para establecer esa colaboracin. Esta colaboracin puede realizarse de mltiples formas desde la basada en peer-to-peer a tcnicas cliente - servidor.
130

Basada en componentes: El conjunto de servicios ser ofrecido por componentes que pueden ser combinados para formar un servicio particular. Un componente puede proporcionar todos o una parte de los servicios.
Por capas: El conjunto total de servicios requeridos para hacer un sistema eLearning ser modelado como un conjunto de capas y cada capa proporcionar un conjunto claro de servicios denidos.
Comportamientos y Modelos de Datos: Un servicio ser denido en trminos de sus comportamientos y su modelo de datos. Los comportamientos causarn cambios en el estado del modelo de datos y el estado del modelo de datos slo cambiar como consecuencia de un comportamiento claramente denido.
Mltiples ligaduras: El modelo de informacin para una especicacin (comportamiento y datos) puede ser apoyado por mltiples ligaduras como por ejemplo Java, XML, servicios Web, etc.
Antes de empezar a describir este framework, es interesante introducir la visin que IMS hace de la arquitectura de los sistemas de eLearning en general. Da dos visiones distintas de estos sistemas, una sera la arquitectura lgica y otra sera la fsica.
La arquitectura lgica est basada en un modelo multicapa o multinivel como el que se utiliz para describir la que se propone en esta tesis. Este modelo se puede ver en la gura 4.4 y consiste en las siguientes capas:
Usuarios:
Representa al conjunto de usuarios de un sistema de eLearning, como los
estudiantes, administradores, docentes, etc. Los usuarios tienen acceso al sistema a travs de agentes de usuario.
Agentes de usuario:
Los agentes que proporcionan los servicios a los usuarios. Los agentes
de usuario son los sistemas de eLearning que proporcionan la interfaz para tener acceso y actuar con todos los servicios de eLearning. Los agentes de usuario incluyen sistemas como LMS, LCMS, herramientas de autor y contenido. Los Agentes de Usuario son construidos usando la coleccin de servicios proporcionados por la capa de servicios.
131
Herramientas:
Permiten el acceso a los diferentes servicios de una forma conveniente y fcil
de usar. Esto incluye la evaluacin, tutorizacin, simulacin, etc.
Servicios de educacin: Servicios comunes:
Incluyen todos los servicios y los componentes que tienen la
funcionalidad especca de eLearning.
tales como la autenticacin, el descubrimiento de recursos, etc.
Repositorios digitales:
Para el almacenamiento del material docente.
Infraestructura de comunicaciones:
La interconexin bsica y los servicios de transporte
de datos que entregan la informacin punto a punto.
Figura 4.4: Arquitectura lgica de los sistemas de eLearning
La arquitectura fsica es la que se muestra en la gura 4.5, est compuesta por las siguientes estructuras:
La red principal:
Red primaria que interconecta los sistemas informticos principales.
Estara representada por Internet. Es una parte de la Infraestructura de Comunicaciones en el modelo lgico.
La red de acceso:
La red que une los dispositivos de entrega para la red principal. Ejemplos
tpicos son redes de cable, redes inalmbricas, etc. Es una parte de la Infraestructura de Comunicaciones en el modelo lgico.
132

La serie de los recursos digitales que estn disponibles
Repositorios digitales federados:
en una variedad de repositorios digitales, bases de datos, servidores Web, etc. Representa la capa de Repositorios Digitales en el modelo lgico.
Motores de servicios de entrega:
Los sistemas responsables de la provisin de servicios
de eLearning. Corresponde a los servicios de educacin y de soporte en el modelo lgico.
Dispositivos de entrega:
Los dispositivos encargados de entregar el material docente al
usuario. Corresponde a las herramientas y a los agentes de usuario en el modelo lgico.
Figura 4.5: Modelo fsico de los sistemas de eLearning
Una vez vista la arquitectura general que representa a los sistemas de aprendizaje, se describe el framework de IMS, que ha sido diseado para que pueda ser usado en una amplia gama de arquitecturas. Este framework se representa como un modelo en capas, como se aprecia en la gura 4.6. IMS justica la adopcin de este tipo de modelo debido a la gran proliferacin de su uso en la denicin de arquitecturas eLearning. Las principales caractersticas de cada una de las capas que denen este framework son las siguientes:
133
Figura 4.6: Modelo en capas del IMS Abstract Framework
Capa de aplicacin:
de eLearning.
Sistemas, herramientas y aplicaciones que exponen los servicios de
aplicacin al usuario nal proporcionando un conjunto particular de funcionalidades
Capa de servicios de aplicacin:

especcos de funcionalidades especicacin de estos servicios.
Conjunto de entidades que proporcionan los servicios de eLearning. IMS se centra principalmente en la
Capa de servicios comunes:
Conjunto de entidades que proporcionan servicios generales
que sern usados por los servicios de aplicacin. Por ejemplo autenticacin.
Capa de infraestructura:
transacciones, etc.).
Servicios encargados del intercambio de informacin (mensajes,
Puntos de acceso a los servicios:

cada servicio.
Los puntos de acceso o interfaces correspondientes a
Entidades:
Los
procesos
que
se
utilizan
para
representar
un
servicio
particular.
La
implementacin de una entidad con sus puntos de acceso de servicio se denomina componente y su representacin abstracta se llama clase.
134
El acceso a un servicio se realiza mediante su Punto de Acceso al Servicio (denominado en la gura SAP: Service Access Point) apropiado. Cada servicio tiene un SAP nico. Un componente puede soportar uno o varios SAP (en una representacin orientada a objetos un SAP podra ser soportada por una o varias operaciones donde la clase es la denicin del servicio).
Uno de los principios de diseo para el IMS Abstarct Framework es la adopcin de la orientacin a servicio como forma de describir la funcionalidad de eLearning. El servicio se oculta detrs de un SAP y slo se puede acceder usando ese SAP. La gura 4.7 muestra una representacin esquemtica de un servicio.
Figura 4.7: Descripcin de un servicio en IMS AF
El servicio tiene un punto de acceso de servicio claramente denido. Cada servicio tiene slo un SAP. El SAP se dene en trminos de sus objetos constituyentes y sus comportamientos.
El SAP puede consistir en uno o varios objetos y cada objeto va a tener, en general, ms de una operacin. Cada objeto es denido usando una denicin de clase y consiste en un conjunto de atributos y operaciones. La operacin describe como el estado de los atributos puede ser cambiado. El juego de comportamientos permitidos para cada clase tambin debe ser denido.
135
La implementacin de Servicio Privado est fuera del alcance del IMS AF. La nica exigencia es que debe proporcionar todas las caractersticas apropiadas del servicio y nada ms.
En la capa de infraestructura lo ms importante es la interoperabilidad en el intercambio y manipulacin de datos. En esta capa, las especicaciones de IMS se utilizan para denir las estructuras de datos y los comportamientos permitidos para el intercambio de esas estructuras de datos entre los componentes que forman la capa. Esta interoperabilidad se dene en trminos de intercambio de documentos XML. El framework tambin describe los mecanismos de transporte que se pueden utilizar para intercambiar los documentos XML.
Figura 4.8: Interaccin de los servicios en IMS AF
En una implementacin distribuida de este framework, como en un ambiente de servicios Web, la interaccin entre los servicios sera como la mostrada en la gura 4.8 En este
framework de interaccin hay tres categoras de interfaces que deben ser apoyadas por la capa de Infraestructura, como son:
El interfaz de Servicios de Aplicacin (A1) - es usado para proporcionar la interoperabilidad entre servicios comunes de aplicacin; por ejemplo, entre sistemas de empresa-aempresa (B2B).
136

El interfaz de Servicios Comn (A2) - es usado para proveer la interoperabilidad del conjunto de servicios comunes ponindolos a disposicin de los servicios especcos de aplicacin; por ejemplo, la autenticacin y la autorizacin
El interfaz de ejecucin (B) - es usado para interconectar la ejecucin del cliente con el proveedor de servicios remoto. Hay dos tipos de comportamiento de interaccin que tienen que ser especicados para asegurar la interoperabilidad:
El paso de Mensajes - donde la informacin es intercambiada entre sistemas que usan alguna forma de paso de mensajes. El contenido y la secuencia de los mensajes denen el comportamiento esperado.
Ejecucin - donde los sistemas nales tienen que usar algn algoritmo predenido sobre la informacin que les llega. Los datos determinarn los resultados de los algoritmos pero el comportamiento estar bien denido para todos los resultados posibles.
4.3. Trabajos sobre servicios web en eLearning

Existe un conjunto de trabajos que presentan ideas sobre cmo incorporar los Servicios Web en el dominio de los eLearning, y que pudieran ser tomados en cuenta en el marco de la denicin del modelo arquitectural en el subdominio de los sistemas generadores de ambientes de enseanza aprendizaje en un eLearning Entre los trabajos destacan: Liu et al. [1]. Una arquitectura implementable para un sistema de eLearning.
Xu et al. [2]. Framework orientado a servicios Web para sistemas eLearning dinmicos.
Rodrguez et al. [3].Cmo el paradigma de los servicios Web puede mejorar el eLearning?
Beleo, C [4].Capa de servicios de base de datos del Sistema Generador de AMBientes de enseanza-ApRendizaje AMBAR.
Hernandez-Leo, D. [5]. A pattern-based design process for the creation of CSCL macroscripts computationally represented with IMS LD.
4.3. TRABAJOS SOBRE SERVICIOS WEB EN ELEARNING
137
4.3.1. Una arquitectura implementable para un sistema de eLearning [1]

En el trabajo de Liu et al [1]titulado Una arquitectura implementable para un sistema de e-learning los autores repasan los estndares y propuestas de arquitecturas de sistemas de eLearning y a continuacin presentan una arquitectura funcional y orientada a servicios para la construccin de sistemas de teleformacin interoperables. Se presenta tambin como se integran los servicios Web en las aplicaciones de e-learning y como se puede usar J2EE para la construccin de sus componentes.
Como se puede apreciar en la gura 4.9 el modelo funcional que propone Liu est muy relacionado con el de SCORM, en el que se divide la funcionalidad del sistema entre la asignada al LMS y al LCMS, existiendo intercambio de informacin entre ambos.
Figura 4.9: Modelo funcional de un sistema de eLearning
Para la implementacin de la arquitectura, los autores se basan en los servicios Web por varias razones: la utilizacin de XML para el intercambio de datos entre diferentes sistemas de eLearning, por la independencia de los servicios Web de la plataforma y el lenguaje de programacin y por sus posibilidades de interoperabilidad, extensibilidad y su integracin
138

4.10 dene como diferentes sistemas de
con Internet. La arquitectura, mostrada en la gura
e-learning intercambian mensajes mediante agentes que proporcionan los servicios Web.
Figura 4.10: Arquitectura orientada a servicios de un sistema de eLearning
4.3.2. Framework orientado a servicios Web para sistemas eLearning dinmicos [2]
El segundo trabajo relacionado es el titulado Framework orientado a servicios Web para sistemas e-learning dinmicos de Xu et al. [2]. El objetivo de este trabajo fue proponer un framework basado en servicios Web que proporciona la integracin de los componentes y aplicaciones que forman un sistema de eLearning facilitando su interaccin. Usando este framework, los proveedores de servicios de formacin podrn publicar sus objetos de aprendizaje o aplicaciones de forma universal permitiendo la interoperabilidad y la reusabilidad.
Como se aprecia en la gura
4.11, el framework se basa en una arquitectura orientada a
servicios donde se distingue entre los proveedores de servicios de formacin y los consumidores de stos. Para denir los contenidos docentes y hacerlos reutilizables se basa en SCORM
4.3. TRABAJOS SOBRE SERVICIOS WEB EN ELEARNING
139
Content Model. Todos los objetos de aprendizaje, contenidos y aplicaciones se construyen como servicios Web, se describen mediante su WSDL y se publicarn en un registro UDDI.
Figura 4.11: Framework orientado a servicios Web para sistemas eLearning dinmicos
4.3.3. Cmo el paradigma de los servicios Web puede mejorar el eLearning? [3]
El siguiente trabajo relacionado se titula Cmo el paradigma de los servicios Web puede mejorar el eLearning? de Rodrguez et al. Esta plataforma proporciona una forma comn de comunicacin y localizacin de servicios de formacin. Los desarrolladores de plataformas de eLearning pueden reutilizar los servicios de este intermediario para construir nuevos sistemas.
4.3.4. Capa de servicios de base de datos del Sistema Generador de AMBAR [4]
Otro de los trabajos destacados en este contexto lo representa el de Beleo, C [4] Capa de servicios de base de datos del Sistema Generador de AMBientes de enseanza-ApRendizaje
140
AMBAR. Este trabajo consisti en el anlisis, diseo e implementacin de la capa de Servicios Web de base de datos del Sistema Generador de AMBientes de Enseanza-ApRendizaje (AMBAR) como implementacin de una Arquitectura Orientada a Servicios (SOA).
La denicin de los Servicios Web para el acceso a la base de datos de AMBAR mejora la interoperabilidad entre las diferentes aplicaciones que constituirn el sistema, ya que stos ofrecen una alternativa de software independiente en cuanto a la plataforma basada en estndares para la integracin de aplicaciones, la automatizacin de procesos de negocio y la publicacin de la informacin de diversas fuentes. Los servicios desarrollados proporcionan un espacio para manipular Objetos de Aprendizaje (OA)que pueden ser almacenados y recuperados de la base de datos de AMBAR.
4.3.5. A pattern based design process represented with IMS LD [5].

Y por ltimo, uno de los trabajos de mayor relevancia por su similitud a esta propuesta es el de Hernndez-Leo [5] A pattern-based design process for the creation of CSCL
macro-scripts computationally represented with IMS LD, Tesis Doctoral, Universidad de Valladolid, Espaa. El mbito de investigacin especco de esta Tesis Doctoral recae sobre los denominados macro-guiones de CSCL(Aprendizaje Colaborativo Apoyado por Ordenador Computer-Supported Collaborative Learning), que describen mtodos pedaggicos formulados como ujos de actividades. Esta tesis identica y aborda tres retos relacionados con el problema de facilitar a los docentes el diseo de estos macro-guiones integrados en las TIC.
El primer reto hace referencia al diseo de los guiones de manera que stos sean potencialmente productivos, para ello. Presentan un modelo conceptual de lenguajes de patrones para guiones de CSCL, as como un lenguaje de patrones concreto segn el modelo.
El segundo reto, tiene que ver con la implementacin de los guiones en sistemas TIC y con ello su interpretacin automtica sin necesidad de desarrollar nuevos sistemas. Se propone representarlos computacionalmente utilizando la especicacin IMS Learning Design (IMSLD). Como ltimo reto, se plantea la integracin de los dos retos anteriores. Lo que permite
4.4. PROPUESTA DE UTILIZACIN DE SOA PARA LOS AVEAS
141
proponer un proceso de diseo basado en patrones para la creacin de macro-guiones de CSCL representados computacionalmente con IMS-LD. Los patrones concretos que se consideraron son los llamados Patrones de Flujo de Aprendizaje Colaborativo (Collaborative Learning Flow Patterns, CLFPs).
El objetivo principal del proceso de diseo es doble. Por una parte, pretende posibilitar la conceptualizacin de las interacciones esperadas de manera que los elementos crticos del CSCL sean considerados al renar plantillas LD basadas en los patrones. Por otra parte, persigue facilitar la creacin amigable de guiones de IMS-LD escondiendo los detalles de la especicacin. De este modo, se propuso una solucin para el tercer reto que se reere al hecho de que las representaciones computacionales no les son familiares para la mayora de los docentes. El proceso de diseo ha sido implementado en una herramienta de autora (denominada Collage) que demuestra la viabilidad de la propuesta y permite su conveniente evaluacin. En la herramienta Collage se provee una gua pedaggica sobre 3 CSCL plantillas estructurados combinadas de 3 CLFPs Pyramid, Jigsaw and TPS(Think-Pair-Share), que permite una guia en la construccin del Ambiente de Enseanza y aprendizaje.
4.4. Propuesta de utilizacin de SOA para los AVEAs

A continuacin se presenta el estado actual del conocimiento en el enfoque Service Oriented Architecture (SOA), que constituye la base para el trabajo de tesis realizado en la metodologa SOA propuesta para desarrollos con dicho enfoque. En primer lugar en la seccin 4.5.1 se presentan distintos enfoques SOA, brindando el contexto en que se inscriben, presentando deniciones, conceptos, elementos que los componen, enfoques de desarrollo con SOA y aspectos tcnicos de los mismos. En segundo lugar, en la seccin 4.5.2 se presenta el enfoque de Business Process Management (BPM) que constituye una parte importante del desarrollo orientado al negocio que es una de las bases de SOA y cuya utilizacin conjunta est tomando cada vez ms importancia. Finalmente, en la seccin 4.5.3 se presenta el enfoque la arquitectura propuesta para los sistemas generadores de Ambientes de enseanza Aprendizaje, se apoyandose en los conceptos sobre Diseo y Arquitectura de Software presentados al inicio de este captulo.
142
4.4.1. Arquitectura Orientada a Servicios (SOA)

El rea de Tecnologa Informtica (TI) en las organizaciones actuales se puede caracterizar por tener diversidad de sistemas que tienen entre s dependencias complejas, que han ido creciendo en forma separada y heterognea a lo largo de los aos. Un desafo que se plantea es poder integrarlos para reaccionar gilmente a los cambios en los requerimientos del negocio, principalmente en dos aspectos: los procesos de la organizacin y las tecnologas disponibles. La denicin y disponibilidad de estos servicios para toda la organizacin es la base del enfoque SOA Krafzig [17].
El concepto de SOA est enfocado en la denicin de una infraestructura del negocio, con el trmino servicio lo que se est denotando es un servicio del negocio como puede ser realizar una reservacin area o acceder la base de datos de la compaa de un cliente. El servicio provee operaciones del negocio como hacer una reservacin, cancelar una reservacin o recuperar el perl de un cliente. Sin embargo, tambin hay servicios tcnicos de infraestructura que proveen operaciones como comienzo de transaccin o modicacin de datos. Una SOA debe desacoplar aplicaciones del negocio de servicios tcnicos y hacer que la Organizacin sea independiente de una implementacin tcnica especca o infraestructura [17].
En Erl
[15]se establece que La lgica colectiva que dene y gua una empresa es una
entidad siempre en evolucin que cambia constantemente en respuesta a inuencias externas e internas. Desde la perspectiva de TI, esta lgica empresarial puede ser dividida en dos mitades importantes: lgica del negocio y lgica de la aplicacin. Cada una existe en un mundo por s mismo, y cada una representa una parte necesaria de la estructura organizacional contempornea. La lgica del negocio es una implementacin documentada de los requerimientos que se origina en el rea del negocio de la empresa. Adems, la lgica del negocio est generalmente estructurada en procesos que expresan esos requerimientos, as como cualquier restriccin asociada, dependencia e inuencias externas.
La lgica de la aplicacin es una implementacin automatizada de la lgica del negocio organizada en varias soluciones tecnolgicas. Esta expresa los ujos de los procesos del negocio
143
mediante sistemas adquiridos o desarrollados especcamente por la infraestructura de TI de la organizacin, con restricciones de seguridad, capacidad tcnica y dependencias con vendedores [15].En la gura 4.12 se muestran estos conceptos.
Figura 4.12: Dos aspectos claves de las Organizaciones: procesos del Negocio y tecnologas [15]
De acuerdo con Erl [15], los conceptos introducidos por la orientacin a servicios son realizados mediante la introduccin de servicios. Estos establecen una forma de abstraccin de alto nivel entre las capas tradicionales del negocio y la aplicacin. Los servicios pueden encapsular la lgica de la aplicacin fsica as como la lgica de los procesos del negocio. Los servicios modularizan la empresa, formando unidades de lgica independientes que existen mediante una capa comn de conectividad. Ellos pueden ser estraticados de forma que servicios padre puedan encapsular servicios hijos. Esto permite que la capa de servicios a su vez consista de mltiples capas de abstraccin. En un nivel fsico, los servicios son desarrollados y distribuidos en ambientes propietarios, mientras son individualmente responsables por el encapsulamiento de la lgica de la aplicacin especca.
En la gura
4.13 se muestra como los servicios en la capa de interface de servicios
representan lgica de la aplicacin realizada en distintas plataformas. En el mismo sentido, en Endrei [16] se menciona que los problemas de heterogeneidad,
interoperabilidad y requerimientos cambiantes, son solucionados por una SOA que provee una
144
Figura 4.13: Capa de servicios entre los procesos del Negocio y las tecnologas [15]
plataforma para la construccin de aplicaciones basadas en servicios con las caractersticas de bajo acoplamiento, ubicacin transparente de servicios e independencia de protocolos. Un consumidor de servicios no debe preocuparse por un servicio particular con el que comunicarse debido a que la infraestructura por debajo, el bus de servicios, puede hacer la eleccin en representacin del consumidor. La infraestructura esconde la mayor cantidad de detalles tcnicos posible al consumidor, y diferentes tecnologas de implementacin como J2EE 2 Platform, Enterprise Edition) o .NET
2 1
(Java
(MICROSOF NET) no afectan a los usuarios de una
SOA. Tambin debe ser posible sustituir una implementacin de un servicio por una mejor si la hay disponible, con mejores caractersticas de calidad de servicio, segn la metadata que lo describe.
1 http://docs.oracle.com/javaee/1.4/api/ 2 http://www.microsoft.com/net
145
4.4.2. Contextualizacin de SOA y algunos enfoques

En las ltimas dcadas se han experimentado cambios importantes en las tecnologas y paradigmas de desarrollo y uso de aplicaciones, que han impactado fuertemente en la forma en que las organizaciones realizan e implementan su negocio. Por un lado el acceso cada vez mayor a Internet pone a disposicin informacin y software, permite comunicacin entre distintas organizaciones, sus proveedores y clientes, ampliando tanto los requerimientos del negocio como sus necesidades y realizacin.
Las mejoras en la tecnologa continan en forma acelerada, incrementando a su vez el ritmo de los cambios en los requerimientos. El negocio debe adaptarse rpidamente para sobrevivir en el ambiente dinmico actual, y la infraestructura de TI debe permitir la habilidad de adaptacin del negocio [16]. Esta evolucin desde las tecnologas al negocio y viceversa, presenta una parte importante en la evolucin de las Arquitecturas de Software desde los primeros sistemas monolticos hasta la visin actual de orientacin a servicios, que se muestra en la gura 4.14.
Figura 4.14: Evolucin de Arquitecturas de Software hasta SOA [16]
As como no hay una nica denicin para Arquitectura de Software, tampoco existe una nica denicin para Service Oriented Architecture (SOA), sin embargo, comparten algunos conceptos base. A continuacin se presentan las deniciones de las organizaciones de mayor importancia y esfuerzos para la estandarizacin de este enfoque: OMG
4 3
(Object Management
5
Group), OASIS (Advancing Open Standards for the Information Society) y W3C
(World Wi-
3 http://www.omg.org/ 4 https://www.oasis-open.org/ 5 http://www.w3.org/
146
de Web Consortium). Estas organizaciones tienen entre sus estndares denidos, algunos tan importantes y ampliamente utilizados como UML (Lenguaje Unicado de Modelado o UML, por sus siglas en ingls, Unied Modeling Language) y XML (Lenguaje de Marcas Extensible o XML, por sus siglas en ingls, Extensible Markup Language).
Para el OMG la arquitectura orientada a servicios (SOA) es un estilo de arquitectura para que una comunidad de proveedores y consumidores de servicios alcancen valor mutuo. Permite que los participantes en las comunidades trabajen juntos con una mnima codependencia o dependencia tecnolgica, mediante la especicacin de contratos a los que las organizaciones, personas y tecnologas deben adherir para participar en la comunidad.Provee la realizacin por parte de la comunidad, de procesos del negocio y permite que una variedad de tecnologas sean utilizadas para facilitar las interacciones en la comunidad.
Segn la OASIS, SOA es un paradigma para organizar y utilizar capacidades distribuidas que pueden estar bajo el control de distintas organizaciones. stas crean distintas soluciones a los problemas que enfrentan en el curso de sus negocios, que constituyen las capacidades de la organizacin para cubrir sus necesidades. La correlacin entre necesidades y capacidades, no es uno a uno, por lo que una necesidad puede requerir ms de una capacidad para ser cubierta, y una capacidad puede cubrir ms de una necesidad. El valor percibido de SOA es que provee un framework fundamental para asociar necesidades y capacidades y para combinar capacidades para cubrirlas.
En W3C, SOA se dene como una forma de arquitectura de sistemas distribuidos que se caracteriza por presentar servicios como una vista lgica abstracta de programas, bases de datos, procesos de negocio, cuya semntica se documenta en su descripcin. Tienden a usar un nmero pequeo de operaciones con mensajes relativamente grandes y complejos, lo que dene su granularidad, y tienden a ser orientados a uso sobre la red, aunque esto no es un requerimiento absoluto. Los mensajes son enviados en formato estandarizado neutral a plataformas a travs de las interfaces, donde XML es el formato ms obvio que cumple estas restricciones.
147
Elementos de SOA
Segn Krafzig [17], SOA se compone de elementos claves que son: las application frontend, los servicios, el repositorio de servicios y el bus de servicios, donde los servicios constituyen la base del enfoque.
Las application frontend son los elementos activos de SOA. Inician y controlan las actividades en los sistemas empresariales. Pueden tener interfaces grcas para usuarios como las aplicaciones Web, o procesos batch que no interactan directamente con los usuarios. Aunque mucha de la responsabilidad sobre los procesos del negocio se delegue en uno o ms servicios, es siempre un application frontend quin inicia un proceso del negocio y recibe los resultados del mismo [17].
El repositorio de servicios provee facilidades para descubrir servicios y adquirir la informacin para utilizarlos, particularmente si estos servicios deben ser descubiertos por fuera del alcance funcional y temporal del proyecto que los cre.
Aunque mucha de la informacin requerida es parte del contrato de servicio, el repositorio de servicios provee informacin adicional como ubicacin fsica, informacin sobre el proveedor, personas de contacto, tarifas de uso, restricciones tcnicas, aspectos de seguridad y niveles de disponibilidad del servicio. Debe notarse que el enfoque est dado en repositorios dentro de los lmites de una organizacin, repositorios que son usados para integracin de servicios cruzando fronteras entre organizaciones, tpicamente tienen otros requerimientos, en particular, los que se hacen pblicos en Internet [17].
El bus de servicios conecta a todos los participantes de SOA - servicios y application frontends - entre si. Si dos participantes necesitan comunicarse - por ejemplo, si una application frontend necesita invocar alguna funcionalidad de un servicio bsico - el bus de servicios hace esto posible.
148

En algn aspecto, el bus de servicios es similar en concepto al bus de software como est
denido en el contexto de CORBA
(Common Object Request Broker Architecture). Sin em-
bargo, existen diferencias signicativas entre estos conceptos. La ms importante, es que el bus de servicios no est compuesto necesariamente de una nica tecnologa, sino que preferiblemente se compone de una variedad de productos y conceptos. Como caractersticas principales debe proveer: conectividad entre los elementos de SOA, heterogeneidad de tecnologa, heterogeneidad de conceptos de comunicacin y servicios tcnicos como seguridad, transformacin de mensajes, auditora, entre otros [17].
Los servicios representan grupos lgicos de operaciones relacionadas con algn concepto del negocio. Un servicio consiste en una implementacin que provee lgica de negocio y datos, un contrato de servicio, las restricciones para el consumidor, y una interfaz que expone fsicamente la funcionalidad. La implementacin del servicio provee la lgica del negocio requerida y los datos correspondientes. Es la realizacin tcnica que cumple con el contrato denido, en forma de componentes, programas, datos de conguracin, bases de datos. El contrato de servicios provee la especicacin del propsito, funcionalidad, restricciones y uso del servicio. La forma de esta especicacin vara dependiendo del tipo de servicio. Las funcionalidades del servicio se exponen en la interface del servicio a clientes conectados en la red. Existen distintos tipos de servicios con determinadas caractersticas que tienen distinto signicado en SOA, por ejemplo los procesos del negocio se realizan en servicios orientados a procesos que se componen de secuencias denidas de invocaciones a servicios [17].
Segn Erl [15], SOA se compone de mensajes, operaciones, servicios y procesos (e instancias de procesos). Un mensaje representa los datos que son requeridos para completar alguna o todas las partes de una unidad de trabajo. Los Message Exchange Patterns (MEPs) denen patrones de intercambios de mensajes comnmente utilizados. Una operacin representa la lgica requerida para procesar los mensajes de forma de completar una unidad de trabajo. Un servicio representa una agrupacin lgica de un conjunto de operaciones capaz de realizar unidades de trabajo relacionadas. Un proceso contiene las reglas del negocio que determinan que operaciones de servicio son utilizadas para completar una unidad de automatizacin, en
6 www.corba.org/
149
otras palabras, un proceso representa una pieza ms grande de trabajo que requiere que se completen unidades de trabajo ms pequeas.
Adicionalmente, los servicios adhieren a un acuerdo de comunicacin, denido en forma colectiva por una o ms descripciones de servicios y documentos asociados, llamados contratos de servicios. Los servicios tienen control sobre la lgica que encapsulan y minimizan la retencin de informacin especca de una actividad, siendo generalmente, sin estado. Son diseados para ser descriptivos de forma que puedan ser encontrados y evaluados va mecanismos de descubrimiento disponibles, por ejemplo registro de servicios [15].
Por ejemplo, las soluciones de automatizacin del negocio son tpicamente una implementacin de un proceso del negocio. Este proceso se compone de lgica que dicta las acciones realizadas por la solucin. La lgica se descompone en una serie de pasos que se ejecutan en una secuencia predenida de acuerdo a reglas del negocio y condiciones de ejecucin. Al construir una solucin automatizada que consiste en servicios, cada servicio puede encapsular una tarea realizada por un paso individual o un subproceso compuesto de un conjunto de pasos [15]. En la gura 4.15 se muestran estos conceptos.
Clasicacin y relaciones entre servicios

Existen varios enfoques para la clasicacin de servicios. Cualquiera sea la clasicacin o la granularidad de la misma, su importancia radica en el hecho de que sirven como gua al momento de disear los servicios. Sabiendo lo que se quiere obtener resulta ms fcil poder denir en base al negocio, los distintos servicios necesarios para cumplir con los requerimientos planteados.
Un aspecto comn en las clasicaciones que se presentan, reere a la existencia de servicios orientados a procesos del Negocio o servicios que encapsulan procesos del negocio, haciendo nfasis en el enfoque de desarrollo hacia el negocio que se plantea en SOA.
150
Figura 4.15: Granularidad de servicios en SOA
[15]
La clasicacin de servicios que fue considerada para esta investigacin es la dada en [15]. Esta clasicacin dene servicios de aplicacin, servicios del negocio y servicios de procesos.
Los
servicios de aplicacin
exponen
funcionalidad
en
un
contexto
especco
de
procesamiento sobre los recursos que proveen las plataformas. Son genricos y reusables. Presentan distinta granularidad en su interface. Pueden consistir en una mezcla de servicios desarrollados en forma particular y servicios de terceros comprados o arrendados. Un servicio de aplicacin puede componer otros servicios de aplicacin de menor granularidad en una unidad de mayor granularidad de lgica de la aplicacin. Esta agregacin es frecuente para soportar requerimientos de integracin, dando lugar a que estos servicios se nombren tambin como servicios de integracin, comnmente implementados como controladores. Los servicios de aplicacin se dividen a su vez en servicios de utilidad y wrappers.
Los servicios de utilidad ofrecen lgica reutilizable que es genrica y no especca a

una aplicacin. Cuando existe capa de servicios del negocio por encima se tiende a que los servicios de aplicacin sean servicios de utilidad, proveyendo operaciones reusables
151
que pueden componerse por los servicios del negocio para realizar requerimientos de procesamiento centrados en el negocio. Cuando no existe capa de servicios del negocio por encima, muchas veces se embebe la lgica del negocio en los servicios de aplicacin, dando lugar a los servicios hbridos, si bien no recomendados, son comunes.
Los servicios wrapper encapsulan y exponen lgica que reside en un sistema legado.
Son generalmente utilizados para propsitos de integracin. Consisten en servicios que encapsulan alguna o todas las partes de un ambiente legado para exponer funcionalidad legada a los servicios solicitantes. La forma ms frecuente de servicio wrapper es un servicio adapter provisto por los vendedores del sistema legado.
Los
servicios del negocio representan la lgica del negocio en la forma ms pura posible. Sin
embargo, esto no previene segn las variaciones de lo que implementa, un servicio del negocio pueda ser clasicado tambin como un servicio controlador (de integracin) o un servicio de utilidad (hbrido). De hecho, cuando la lgica de la aplicacin se abstrae en una capa aparte de servicios de aplicacin, los servicios del negocio pueden actuar como controladores para componer los servicios de aplicacin disponibles para ejecutar su lgica del negocio. Los servicios del negocio se dividen a su vez en servicios del negocio centrados en tareas y servicios del negocio centrados en entidades.
Los servicios del negocio centrados en tareas
encapsulan lgica del negocio
especca a una tarea o proceso del negocio. Este tipo de servicios en general es requerido cuando la lgica del proceso del negocio no est centralizada en servicios de procesos en la capa por encima. Los servicios del negocio centrados en tareas tienen potencial de reso limitado.
Los servicios del negocio centrados en entidades
encapsulan una entidad del
negocio especca. Son tiles para crear servicios del negocio altamente reusables independientes de los procesos del negocio, que luego puedan componerse en servicios de procesos o servicios del negocio centrados en tareas, o ambos. Los
servicios de procesos componen servicios del negocio y de la aplicacin de acuerdo
a reglas del negocio y lgica del negocio embebida en la denicin del proceso. Componen otros servicios que proveen conjuntos especcos de funciones independientes de las reglas del
152
negocio, con lgica especca de un escenario requerida para ejecutar una instancia de un proceso. Los servicios de procesos son tambin servicios controladores ya que requieren componer otros servicios para ejecutar lgica de los procesos del negocio. Estos servicios son de los ms complejos ya que involucran orquestacin de servicios, y por lo tanto la introduccin de nuevo middleware en la infraestructura de TI que incluye servidores de orquestacin, que no son una adicin trivial ni de poco costo.
En la gura 4.16 se presenta la ubicacin en capas de servicios y las relaciones entre servicios segn la clasicacin presentada en [15]
Figura 4.16: Capas de servicios segn la clasicacin [15]
Se puede observar en las clasicaciones presentadas, que la categorizacin de servicios que se realiza, tiene en todos los casos enfoque del negocio. Esto signica que cuando se est diseando con orientacin a servicios, las piezas de software a obtener deben tener todas relacin directa con conceptos, entidades, reglas y procesos del negocio en la organizacin, maximizando el desacoplamiento entre los elementos. Esto constituye un enfoque distinto de diseo incluso con el paradigma de desarrollo basado en componentes, donde el enfoque de diseo puede darse ms en aspectos tcnicos de la reutilizacin de software que en aspectos del ne-

gocio en si mismo, y el desacoplamiento muchas veces puede no ser el deseado.
153
Existen tambin ms clasicaciones de servicios que no se presentan en este trabajo. Esto se debe a que se consider que el estudio resulta ms simple y fcil de utilizar para servir como gua en la categorizacin de servicios.
Procesos del Negocio, Orquestacin y Coreografas de servicios

En las secciones anteriores se mencion brevemente como los procesos del negocio pueden ser representados y expresados a travs de servicios de procesos o centrados en procesos. Segn Erl [15], consiste en particionar la lgica del negocio en servicios que pueden componerse tiene implicaciones signicativas sobre como se pueden modelar los procesos del negocio. Los analistas pueden inuenciar estas caractersticas incorporando una extensin de orientacin a servicios a los procesos del negocio para su implementacin mediante SOAs. Los servicios adems pueden ser diseados para expresar lgica del negocio. Modelos de Business Process Management (BPM), de entidad, y otras formas de inteligencia del negocio pueden ser representadas con precisin a travs de la composicin coordinada de servicios centrados en el negocio. Esta es un rea de SOA que todava no est ampliamente aceptada o comprendida, el paradigma de modelado del negocio con orientacin a servicios.
Con la capa de servicios intermedia, que abstrae tanto los procesos del negocio como las tecnologas por debajo, ambas partes de la Organizacin pueden evolucionar en forma independiente, ms rpidamente y con menor impacto de los cambios originados en una en la otra. Como indica [15] es la mutua abstraccin del negocio y la tecnologa, lo que soporta el paradigma de modelado del negocio con orientacin a servicios y establece el modelo empresarial de bajo acoplamiento. ... En una Organizacin donde los principios de orientacin a servicios se aplican tanto en el diseo tcnico como el modelado del negocio, el concepto de bajo acoplamiento se amplica. Implementando capas de abstraccin de servicios estandarizadas, la relacin de bajo acoplamiento puede ser tambin alcanzada entre los dominios del negocio y de tecnologa de la aplicacin. Cada uno requiere solo consciencia del otro, permitiendo de esa forma que cada dominio pueda evolucionar de forma ms independiente. El resultado es un
154
ambiente que puede absorver mejor los cambios en el negocio y en la tecnologa, una cualidad conocida como agilidad organizacional. En la gura 4.17 se muestran estos conceptos.
Figura 4.17: Agilidad organizacional con capa de servicios intermedia en SOA [15]
La agilidad organizacional se ve incrementada con el uso de orquestaciones de servicios para modelar los procesos del Negocio con servicios centrados en procesos. Una orquestacin es una forma de composicin de servicios que permite denir procesos del Negocio especcos para un proyecto, mediante una secuencia denida de invocaciones a servicios existentes.
Segn Erl [15], la orquestacin expresa el cuerpo de la lgica de un proceso del Negocio que es tpicamente propiedad de una nica Organizacin. Establece un protocolo del negocio que dene formalmente la denicin de un proceso del Negocio. La lgica del workow en una orquestacin es separada en una serie de actividades bsicas y estructuradas que pueden ser organizadas en secuencias y ujos. El alcance de una nica orquestacin, entonces, puede ser clasicado como una actividad compleja, y posiblemente, de larga duracin. La orquestacin provee un modelo de automatizacin donde la lgica del proceso aunque centralizada, es an extensible y componible. Mediante el uso de orquestaciones, los ambientes de soluciones orientadas a servicios se vuelven inherentemente extensibles y adaptables. Las orquestaciones en s mismas tpicamente establecen un punto comn de integracin para otras aplicaciones,
155
lo que hace que una orquestacin implementada sea un punto clave para permitir la integracin.
Por otro lado, existe tambin otro tipo de composicin de servicios cuyo alcance va ms all de una nica Organizacin, permitiendo la interaccin entre diversas Organizaciones para realizar procesos del Negocio inter-organizacionales. En este caso el control de la secuencia de invocaciones a servicios no es propiedad de ninguna de las Organizaciones participantes en la coreografa.
En cualquier coreografa dada un servicio asume uno de varios roles predenidos. Esto establece lo que el servicio hace y lo que el servicio puede hacer en el contexto de una tarea del negocio particular. Cada accin que es mapeada en una coreografa puede ser descompuesta en una serie de intercambios de mensajes entre dos servicios.
Cada intercambio potencial entre dos roles en una coreografa es denido en forma individual como una relacin. Cada relacin entonces consiste de exactamente dos roles. La naturaleza de las conversaciones estn denidas por las caractersticas del intercambio de mensajes entre dos roles especcos por los canales de comunicacin. Dos servicios que pertenecen a dos organizaciones distintas, cada uno exponiendo funcionalidad de la solucin del negocio de la empresa entera, pueden interactuar va una coreografa bsica para completar una tarea compleja.
Tanto las orquestaciones como las coreografas son formas de composicin de servicios que permiten realizar procesos del Negocio dentro de una Organizacin o entre varias Organizaciones.
Niveles de realizacin de SOA

Para que una organizacin actual como lo reprentan las organizaciones educativas, que cuenta con varios sistemas separados en tecnologas heterogneas, para incorporar el enfoque SOA en el desarrollo de sus soluciones de software, se hace necesario realizar en forma previa una evaluacin y una planicacin de cmo ser la incorporacin de los distintos elementos que
156
componen SOA, en forma gradual, como forma de incorporar el cambio con riesgos controlados.
En Krafzig [17]se propone un architectural roadmap o itinerario arquitectnico que sirve como base para tener en cuenta las distintas etapas por las que debera transitar una Organizacin para incorporar SOA incrementalmente en forma segura. Las etapas identicadas indican distintos niveles de madurez de una SOA, desde el primer nivel de fundamental SOA, pasando por el de networked SOA hasta llegar al de process-enabled SOA que incluye la orquestacin de servicios para la implementacin de los procesos del Negocio en la Organizacin.
Fundamental SOA: este nivel consiste nicamente de dos capas de abstraccin, la capa bsica compuesta por servicios bsicos y la capa empresarial donde se encuentran las application frontend. Esta distincin ayuda a que las aplicaciones denan una estructura de alto nivel adecuada, se identican, denen e implementan servicios bsicos del negocio permitiendo que dos o ms aplicaciones compartan la lgica de negocio y los datos asociados.
Aunque es un enfoque bastante simple provee las bases para ir avanzando hacia una SOA de mayor nivel.
Networked SOA:
en este nivel se agrega la capa de abstraccin intermediaria que se
compone de servicios intermediarios, que pueden incluir servicios del tipo facades, technology gateways, adapters y funcionality-adding. Como se mencion, los servicios intermediarios encapsulan parte de la complejidad de los servicios bsicos, y permiten la integracin de conjuntos de software en forma independiente de la tecnologa. Parte de la complejidad de las application frontend es delegada a los servicios intermediarios.
Process-enabled SOA:
el nivel de process-enabled SOA es el nivel ms completo de SOA,
donde los procesos del Negocio se realizan con servicios centrados en procesos que orquestan servicios de las capas por debajo. Agrega la capa de abstraccin de procesos que se compone de servicios centrados en procesos que encapsulan la complejidad de los procesos del Negocio, comparten el estado entre mltiples clientes y manejan procesos de larga duracin. Las application frontend pasan a ser ms simples ya que la complejidad del Negocio es manejada por estos servicios. La complejidad de las aplicaciones en el
157
backend es manejada por los servicios intermediarios y los servicios centrados en procesos. La lgica de los procesos del Negocio queda claramente separada de otro tipo de lgica y cdigo especco que es manejada por los servicios por debajo.
En Erl [15] no se proponen niveles de SOA, sino que se plantea como realizar las etapas del ciclo de vida de creacin hasta puesta en produccin de los servicios, segn distintos enfoques. El objetivo principal que se plantea es soportar la transicin hacia una SOA completa y estandarizada, cumpliendo a la vez con requerimientos inmediatos especcos a distintos proyectos. Para esto se plantea utilizar enfoque top-down, bottom-up y gil o intermedio, a pesar de su nombre este ltimo no tiene que ver con enfoques de desarrollo gil.
Enfoque top-down:
esta estrategia promueve la denicin formal de modelos del negocio
corporativos antes de modelar los servicios. Es un enfoque de primero anlisis que requiere que no solo los procesos del Negocio se vuelvan orientados a servicios, sino que tambin promueve la creacin (o realineamiento) del modelo del negocio entero de una Organizacin. Este proceso est muy relacionado o derivado desde la lgica del negocio existente en la Organizacin. Soporta la creacin de las tres capas de servicios presentadas, y es comn que resulte en la creacin de numerosos servicios del negocio y la aplicacin reusables. Puede resultar en el nivel ms alto de calidad de SOA pero tambin impone un volumen signicativo de trabajo de anlisis previo.
Enfoque bottom-up:
esta estrategia se basa en la liberacin de servicios de aplicacin segn
sea necesario. Esencialmente fomenta la creacin de servicios como forma de cumplir con requerimientos centrados en las aplicaciones. Los servicios son construidos segn sea necesario y modelados para encapsular lgica de aplicacin para servir mejor a los requerimientos inmediatos de la solucin. La integracin es el principal motivador de diseos bottom-up, donde la necesidad de sacar ventaja de algunas propiedades de SOA puedan ser alcanzadas simplemente introduciendo servicios wrappers sobre sistemas legados. Este enfoque es fcil de seguir pero no resulta en una SOA avanzada con todas sus propiedades.
Enfoque gil o intermedio:

up.
propone una combinacin de los enfoques top-down y bottom
158

El desafo consiste en encontrar un balance aceptable entre la incorporacin de principios
de diseo orientado a servicios en los ambientes de anlisis del negocio sin tener que esperar por aspectos tecnolgicos asociados. Para muchas organizaciones puede ser til contar con un enfoque intermedio entre los otros dos extremos que se proponen. Esto es posible deniendo un nuevo proceso que permite que el anlisis a nivel del negocio se realice en forma concurrente con el diseo y desarrollo de servicios. Por lo tanto, soporta el anlisis continuo a la vez que permite la liberacin inmediata de servicios. A medida que el anlisis progresa, los servicios existentes son revisados cuando se requiera.
Enfoque para la adopcin de SOA

Endrei [16], propone un enfoque SOA que consiste en siete pasos, donde las actividades no son necesariamente lineales y secuenciales, sino ms bien exploratorias e iterativas, incrementando la funcionalidad y comprensin del equipo a medida que el proyecto avanza. Este enfoque combina los patrones de negocio de IBM con los conceptos SOA, y puede ser utilizado con el proceso de desarrollo existente en la Organizacin, ya que provee agregados para el diseo de SOA, incluyendo artefactos a obtener. Propone un enfoque top-down para descubrimiento de servicios, y bottom-up para obtencin de servicios de sistemas legados y aplicaciones empaquetadas. Utiliza como el RUP Casos de Uso del Negocio para modelar los procesos del Negocio. En la gura propuesto. 4.18 se muestran los siete pasos que componen el enfoque
1.
Networked SOA: en primer lugar se descompone el dominio en su cadena de valor de

reas funcionales, luego cada rea funcional se descompone en procesos, subprocesos y Casos de Uso del Negocio. Estos ltimos se utilizan para renar la descomposicin del dominio realizada, ubicndolos en sus reas funcionales. Luego cada rea funcional es mapeada a uno o ms subsistemas en la Arquitectura, y los Casos de Uso del Negocio son mapeados a Casos de Uso del Sistema. Luego se aplican patrones del Negocio y de Integracin de aplicaciones, que clasican y denen formas de interaccin entre los elementos identicados.
2.
Creacin de un modelo objetivos-servicios:
plantean que los Casos de Uso del
Negocio son buenos candidatos a ser servicios, por lo que la identicacin de servicios
159
Figura 4.18: Pasos del enfoque SOA [16]
objetivos parte de stos. Se identican los objetivos y sub-objetivos que deben ser cumplidos para alcanzar objetivos de ms alto nivel del negocio, asociando los subobjetivos con servicios requeridos para obtenerlos.
3.
Anlisis de subsistemas:
rena los Casos de Uso del Negocio en Casos de uso
del Sistema que soportan un proceso del Negocio dado. Se identican componentes del Negocio y tcnicos analizando los ujos de los procesos entre subsistemas para descubrir/identicar componentes del negocio candidatos. Se utilizan los requerimientos no funcionales para encontrar componentes tcnicos. Se identica la funcionalidad requerida para cada componente del negocio, esto es los Casos de Uso del sistema que cada componente debe soportar. Luego se aplican patrones de aplicacin para estructurar los servicios del negocio y tcnicos necesarios.
160
4.
Asignacin de servicios:
asegura que todos los servicios identicados tengan un
componente de implementacin asignado. Estos componentes pueden ser creados nuevos o pueden existir como funcionalidad implementada pero no en forma de componente.
5.
Especicacin de componentes:
para cada componente identicado se especican
propiedades como reglas, servicios, atributos, otros componentes que usa, puntos de variacin por ejemplo requerimientos de conguracin.
6.
Estructuracin de componentes y servicios utilizando patrones:
se aplican
patrones de tiempo de ejecucin del negocio, para establecer la estructura necesaria del middleware para soportar los servicios identicados y la asignacin de cada servicio a un nodo lgico del middleware.
7.
Mapeo de realizacin tecnolgica:
se denen los mecanismos de implementacin
adecuados para los servicios y componentes especicados. Esto reere tanto a decisiones del tipo realizar el desarrollo desde cero o hacer outsourcing como solucin llave en mano, o intermedio de anlisis implementar, reutilizar, comprar ya visto, y alternativas que pueden combinar estas opciones, y tambin reere a elecciones del tipo, implementar un wrapper de un sistema legado con un Web Service o con un servicio de cola de mensajes. Luego es posible realizar un anlisis de ventajas y desventajas de las decisiones tomadas, y aplicar mapeos de productos para seleccionar software de base e infraestructura necesaria y cubrimiento de las necesidades por cada vendedor.
El enfoque presentado plantea siete pasos para realizar un desarrollo SOA enfocado en el diseo de servicios a partir de procesos del Negocio identicados en la Organizacin. Utiliza como el RUP Casos de Uso del Negocio para describir los procesos del Negocio que luego son mapeados a Casos de Uso del Sistema. Sin embargo, no se provee una gua de cmo realizar este mapeo ni de la relacin y diferencias entre los dos tipos de Casos de Uso. Los pasos que se proponen no se identican como parte de disciplinas de un proceso de desarrollo, ni se describen las entradas, salidas y roles asociados a cada uno, lo que es ms, no se menciona en ninguno de los pasos que roles intervienen ni con que responsabilidades.
161
Plantea que los Casos de Uso del Negocio son buenos candidatos para servicios, pero esto sera ms bien aplicable a servicios centrados en procesos nicamente, segn la teora presentada, ya que los servicios que luego se orquesten para realizarlos, debieran ser de menor granularidad o alcance. No se propone una clasicacin de servicios ni distinto enfoque ni granularidad para los mismos, lo que como se vio previamente, ayuda a la denicin asociada, sino que los servicios se derivan directamente de las reas funcionales y los procesos asociados. No se indica tampoco como se relaciona la denicin de servicios con la denicin de la Arquitectura de Software del sistema, aunque sta se nombra en el anlisis de subsistemas como parte de las decisiones de diseo. La aplicacin de distintos patrones del negocio si bien es un enfoque interesante tambin puede agregar complejidad al desarrollo ya que se debe capacitar a los involucrados para su correcta aplicacin.
En los artculos Zimmermann [91] y Arsanjani [92] tambin de IBM, se presentan elementos del anlisis y diseo orientado a servicios, as como descripcin de los pasos del enfoque SOA planteado en Endrei [16], introduciendo los trminos Service Oriented Analysis and Design (SOAD) y Service Oriented Modeling and Architecture (SOMA), que luego fue intregado en el plug-in para SOA que se agrega al RUP sobre mediados del ao 2005 en su primera versin, cuya ltima actualizacin es de noviembre de 2006. Uno de los elementos que agregan estos artculos es el hecho que se mencionaba como faltante en el enfoque de [16] sobre la clasicacin o categorizacin de servicios.
Especcamente en Arsanjani [92] se plantea realizar esta actividad luego de identicar los servicios, estableciendo que es importante comenzar la clasicacin de servicios en una jerarqua de servicios, reejando la naturaleza de composicin de los servicios: stos pueden y deben ser compuestos de servicios y componentes de granularidad ms na. La clasicacin ayuda a de terminar la composicin y las capas de servicios, as como a la coordinacin de la construccin de servicios interdependientes basada en la jerarqua. Se cambia el orden de los siete pasos presentados y se agrupan en tres pasos generales: Identicacin, especicacin y realizacin de servicios, componentes y ujos.
162

Se destacan como aportes del enfoque SOA y los aspectos presentados en [16, 92, 91] la
conceptualizacin de los tres pasos generales de identicacin, especicacin y realizacin de servicios, la asignacin de servicios que permite identicar los componentes que se deben implementar, y la utilizacin de Casos de Uso del Negocio para modelar los procesos del Negocio. Estas caractersticas fueron tenidas en cuenta para la propuesta de metodologa SOA realizada.
Por otro lado, tenemos el enfoque presentado en Krafzig [17] es una gua que no establece un proceso de desarrollo, sino aspectos a tener en cuenta en el agregado de la orientacin a servicios en un desarrollo de software. La eleccin del proceso y metodologa de desarrollo depender del contexto del proyecto, aspectos como si la Organizacin tiene o no instaurado un proceso de desarrollo, la complejidad, alcance y duracin del proyecto, requerimientos de calidad, importancia estratgica, entre otros.
Sin embargo, dada la naturaleza compleja y frecuencia de cambios en los requerimientos del Negocio en proyectos del tipo SOA, se recomienda que el enfoque elegido sea del tipo iterativo incremental, fundamental para tratar con la complejidad y con los requerimientos inestables.
Adems, dada la importancia estratgica de este tipo de desarrollos, es esperable que la metodologa elegida tienda hacia el lado de los procesos pesados, donde se puedan ir obteniendo varios entregables intermedios en los hitos establecidos.
Plantea incluir diseo de servicios en la denicin del proyecto ya que son fundamentales tanto para la Arquitectura como para la planicacin del proyecto. Un entregable clave de la fase de denicin del proyecto debe ser una Arquitectura preliminar, en la que se hayan identicado las application frontend, los servicios externos, y lo servicios bsicos ms importantes. Sobre estos servicios se debe distinguir los servicios que sern construidos desde cero, los servicios nuevos basados en aplicaciones existentes, extensiones y modicaciones a servicios existentes.
163
El diseo de servicios intermediarios y centrados en procesos puede realizarse ms adelante. Por lo que adems de la identicacin de servicios en el diseo se realiza tambin la clasicacin o categorizacin de los mismos, como gua para la denicin de los mismos.
Para el diseo e implementacin se propone la aplicacin del modelo hilo no (thin thread) de desarrollo, que aplica el enfoque de desarrollo iterativo incremental de aplicaciones. Un hilo representa un corte vertical del sistema completamente funcional expandiendo todas las capas del sistema desde el frontend al backend. En la gura SOA para una iteracin. 4.19 se muestra el enfoque
Figura 4.19: Enfoque SOA para una iteracin [17]
Para la gestin de conguracin se recomienda mantener los servicios en diferentes proyectos dentro del repositorio de conguracin, ya que stos sern compartidos por varias aplicaciones, por lo que es importante mantener su independencia de versiones tambin. Parece
164
natural denir estos proyectos a partir de los servicios bsicos que sern los ms utilizados, a los que se pueden agregar algunos servicios intermedios que estn muy relacionados. Luego el resto de los servicios intermedios y los servicios centrados en procesos deberan estar tambin en proyectos separados, as como las application frontend especcas de cada proyecto. Las bibliotecas compartidas por varios proyectos se pueden factorizar y colocarlas agrupadas tambin en proyectos distintos.
El enfoque presentado no plantea un proceso de desarrollo sino que brinda buenas prcticas para las actividades a realizar en las distintas reas del mismo. Plantea, sin embargo, que el proceso ms adecuado sobre el cual construir un desarrollo SOA es un proceso iterativo incremental con caractersticas del tipo de los procesos pesados.
Se destacan como aportes del enfoque SOA presentado en [17] las guas propuestas para la realizacin de las distintas actividades en el proceso de desarrollo, principalmente las que tienen que ver con los aspectos de diseo de servicios incluyendo la clasicacin provista, fueron tenidos en cuenta para la metodologa SOA propuesta. La clasicacin de elementos de SOA provista tambin fue brindada como gua bsica para la comprensin y apoyo a la realizacin de las actividades denidas en la metodologa SOA propuesta.
En otro Orden de ideas, se presenta el enfoque que se presenta en Erl [15] plantea que proyectos de desarrollo para soluciones orientadas a servicios, en la supercie, son similares a proyectos de desarrollo para aplicaciones distribuidas. Cuando nos adentramos en las capas de la orientacin a servicios, sin embargo, encontramos que para construir y posicionar apropiadamente los servicios como parte de SOA, los ciclos de proyectos tradicionales requieren algunos ajustes. Se propone un proceso de desarrollo que consta de seis fases que, sin embargo, recuerdan los procesos de desarrollo tradicionales en cascada. En la gura 4.20 se presentan las fases propuestas. En la fase de anlisis orientado a servicios los objetivos principales son establecer las capas de servicios, y modelar servicios individuales como servicios candidatos que componen una SOA preliminar. Como objetivos especcos se plantean la denicin de un conjunto preliminar de
165
Figura 4.20: Fases del proceso de desarrollo propuesto [15]
operaciones de servicios candidatas, la agrupacin de estas operaciones candidatas en contextos lgicos que representarn los servicios candidatos, la denicin de los lmites preliminares de los servicios para que no se superpongan con servicios existentes o planicados, la identicacin de lgica encapsulada con potencial de reuso, la evaluacin de que el contexto de la lgica encapsulada es apropiada para el uso denido, y la denicin de modelos de composicin preliminares conocidos. La
fase de anlisis se compone de tres pasos:
1.
denir los requerimientos de automatizacin del negocio: los requerimientos del

negocio deben permitir la denicin de un proceso de automatizacin de alto nivel. La documentacin de este proceso del negocio ser usada como punto de entrada para el proceso de modelado de servicios del paso 3.
2.
identicar sistemas de automatizacin existentesla
lgica de aplicacin que
ya se encuentra, de alguna manera, automatizando cualquiera de los requerimientos identicados en el paso 1 debe ser identicada. En general este paso tiende a soportar esfuerzos de modelado de soluciones orientadas a servicios de larga escala.
3.
modelar servicios candidatos: en este paso se identican operaciones candidatas que

se agrupan en contextos lgicos que pueden dar lugar a servicios candidatos. La razn de distinguir que son candidatos es debido a que luego en el diseo son sujetos a las
166

realidades de la arquitectura tcnica en la que deben residir. Al incluir restricciones, requerimientos, limitaciones especcas al ambiente de implementacin, el diseo nal de un servicio puede ser bastante distinto del candidato original. Este es el paso ms importante en la fase de anlisis y se divide a su vez en doce subpasos que guan el proceso de anlisis hacia sus objetivos.
En la
Fase de Diseo se denen los siguientes objetivos: determinar el conjunto ncleo de
extensiones arquitectnicas, establecer los lmites de la arquitectura, identicar los estndares de diseo requeridos, denir el diseo de las interfaces abstractas de servicios, identicar las composiciones de servicios potenciales, evaluar el soporte a principios de orientacin a servicios y explorar soporte para caractersticas tecnolgicas de la implementacin de SOA (especcamente con Web Services). La fase de diseo se compone de cinco pasos, los que a su vez se dividen en subpasos para alcanzar los objetivos planteados:
1.
componer SOA:
se eligen las capas de servicios que sern utilizadas, as como los
estndares y tecnologas para la implementacin de los servicios (especicamente soporte para XML y WS), y extensiones que se utilizarn (especicamente de las especicaciones WS-* para seguridad, encriptacin, transaccionalidad, entre otros)
2.
disear servicios del negocio centrados en entidades: estos servicios representan

la capa de servicios menos inuenciada por otras. Debe representar las entidades de datos denidas en los modelos del negocio. Se disean para ser reutilizados por cualquier aplicacin que necesite acceder o manejar informacin asociada con una entidad en particular.
3.
disear servicios de aplicacin:
estos servicios representan servicios responsables
de realizar procesamientos requeridos por las capas de negocio y orquestacin. No se requiere conocimiento del negocio para su diseo, ya que son una abstraccin pura orientada a servicios del ambiente tecnolgico de una organizacin. Estn sujetos a cambios constantes segn las actualizaciones o cambios de la tecnologa y la lgica relacionada es construida o alterada.
4.
disear servicios del negocio centrados en tareas: el proceso para disear servicios
centrados en tareas usualmente requieren menos esfuerzo que los dos anteriores, ya que el
167
reuso no es una consideracin primaria. Solamente las operaciones candidatas de servicios identicadas en el anlisis se tratan en estos servicios.
5.
disear procesos del Negocio orientados a servicios:
consiste en interpretar
apropiadamente los requerimientos de los procesos del negocio que se han recolectado e implementarlos acertadamente. Hay que tener en cuenta las posibles variaciones de las actividades de los procesos, esto signica entender no slo que puede ir mal, sino como el proceso debe responder a condiciones no esperadas o anormales. En este paso se disean los detalles del workow, as como la interface del servicio de procesos.
En la
Fase de Desarrollo de servicios
se introducen las caractersticas especcas de
las plataformas, sin importar el tipo de servicio. Especicamente, la eleccin del lenguaje de programacin y del ambiente de desarrollo determinarn la forma fsica que toman los servicios y los procesos del negocio orquestados, de acuerdo al diseo denido.
Para la
Fase de Testing de servicios
se indica que dada la naturaleza genrica y el
potencial para ser reutilizados y compuestos en distintas situaciones, se requiere que los servicios pasen por un testing riguroso antes de su pasaje al ambiente de produccin. Sin embargo, no se introducen subpasos ni actividades, se brinda una checklist con preguntas para guiar el testing, como por ejemplo, que tipo de consumidores de servicios podran potencialmente acceder a un servicio, entre otras.
En la
Fase de Deployment de servicios se deben instalar y congurar los componentes
distribuidos, las interfaces de servicios y cualquier otro producto de middleware asociado, en los servidores de produccin.
La Fase de
Administracin de servicios ocurre luego de que se ha realizado el deploy-
ment de servicios. Son similares en naturaleza a la administracin de aplicaciones distribuidas, basadas en componentes, excepto que se deben aplicar a los servicios como un todo, en oposicin a los servicios en un ambiente de aplicacin especco.
168

El enfoque presentado consta de seis Fases que se realizan en forma secuencial, al estilo
de los procesos tradicionales en cascada. Si bien no plantea vueltas de feedback a las Fases anteriores, podra ser aplicado en forma iterativa incremental con algunas adaptaciones. No se indican roles intervinientes ni sus responsabilidades, ni tampoco los artefactos de entrada y salida de las actividades, aunque al estar presentado para realizar en forma secuencial, se puede asumir que se utilizarn para las actividades siguientes, los productos realizados en las anteriores. No se brindan tampoco plantillas o templates para la realizacin de los productos a obtener.
En la Fase de anlisis se menciona la necesidad de identicar los procesos del Negocio y los requerimientos del Negocio, pero no se propone como realizar su modelado, esto es con diagramas UML, Casos de Uso del Negocio, u otras formas. En la Fase de Diseo se nombra supercialmente la Arquitectura de Software sin indicar la relacin de los servicios con sta, ni la importancia en el enfoque. Adems, tambin en la Fase de Diseo, las actividades estn denidas sobre la clasicacin de servicios que se propone, lo que hace el proceso muy especco. En la metodologa SOA propuesta, por el contrario, las actividades de identicar y categorizar servicios, especicar servicios e investigar servicios existentes, pueden realizarse utilizando la clasicacin de servicios con la que se est ms cmodo, ya que solo se referencian a modo de gua para facilitar la denicin de servicios.
Tambin se observa en la descripcin de varias de las actividades, que si bien estn basadas en conceptos de orientacin a servicios, se introducen constantemente aspectos de la implementacin con Web Services que tambin las hacen especcas a dicho enfoque, al contrario de la metodologa propuesta que es tambin independiente del tipo de
implementacin elegida. De las seis Fases que se denen, solo se describen en profundidad las de Anlisis y Diseo, para la de Desarrollo se brindan ejemplos, pero para las ltimas tres de Testing, Deployment y Administracin, solo se dene su objetivo. Este enfoque de [15] fue el seleccionado para la propuesta arquitectcica, debido a su nfasis en el rea de Anlisis y Diseo, y en este caso al estar como Fase separada.
169
4.4.3. SOA y Modelos de Proceso de Negocios (BPM)

Como se vi previamente, uno de los aspectos principales de una SOA completa es que los procesos del Negocio se realicen como servicios centrados en procesos, que mediante orquestacin de otros servicios de menor granularidad, ejecuten los ujos denidos para dichos procesos.
Erl [15] plantea que histricamente, los procesos del negocio eran diseados por analistas utilizando herramientas de modelado que producan diagramas que se les entregaban a los arquitectos y desarrolladores para su implementacin. Los diagramas de workow y su documentacin eran la nica forma de comunicar como esta lgica deba ser realizada por la solucin automatizada. Aunque un buen anlisis y documentacin, adems de mentes abiertas y experticia tcnica sobre el negocio, pueden llevar a una colaboracin exitosa entre los miembros del equipo del negocio y tcnicos, este enfoque deja lugar a errores.
Segn Krafzig [17] los procesos del Negocio en general son dinmicos en el sentido de que estn propensos a cambios frecuentes y generalmente requieren una compleja coordinacin con los participantes del proceso. Tienen estado relacionado con el proceso en si mismo. Este estado del proceso incluye informacin sobre las participantes en el proceso (personas y servicios), entradas de los participantes, la posicin actual en el ujo del proceso, y reglas bsicas. Los servicios centrados en procesos son altamente dependientes de otros servicios, en particular de aquellos servicios que representan la lgica ncleo del negocio. Agrega que aunque los servicios centrados en procesos pueden ser realizados de varias maneras distintas (y por lo tanto pueden tomar muchas formas distintas), BPM representa posiblemente el enfoque ms consecuente para lograr una process-enabled SOA.
A continuacin se presenta brevemente el enfoque BPM, se introducen conceptos del enfoque, se presenta el modelado de procesos del negocio que propone, y nalmente se muestra como se incluye el enfoque en SOA. No es la intencin en esta seccin entrar en detalles del enfoque, sino presentar sus principales conceptos para poder establecer como y porqu se relaciona con SOA, y la importancia que tiene en SOA la inclusin de este enfoque.
170

En Smith [93], se introduce BPM planteando que la visin de BPM no es nueva, sin em-
bargo, las teoras y sistemas existentes no han podido lidiar con la realidad de los procesos del Negocio, hasta ahora. Al ubicarlos en el centro del escenario, las organizaciones pueden obtener las capacidades que necesitan para innovar, mejorar la performance y entregar el valor que el mercado actual demanda. BPM entonces acompaa el descubrimiento, diseo y deployment de procesos del negocio, as como el control ejecutivo, administrativo y de supervisin sobre los mismos para asegurar que se mantienen conforme a los objetivos del negocio.
Sobre los antecedentes de BPM en las organizaciones
[93], agrega que durante la ola de
reingeniera de procesos de los aos 90, diversos libros de gestin contaban experiencias de empresas para utilizar como gua de transformacin del negocio. A pesar de que la teora subyacente estaba basada en sentido comn de siempre y teora general de sistemas propuesta cincuenta aos atrs, no se ofreca un camino para su ejecucin. En contraste, la organizacin que gestiona sus procesos, toma control de sus procesos internos y se comunica con un lenguaje de procesos universal que permite que los socios ejecuten una visin compartida, comprendiendo las operaciones de cada uno, conjuntando diseo de procesos y gestionando el ciclo de vida completo de sus iniciativas de mejora del negocio.
En BPMI (Business Process Management Initiative) se dene BPM como el conjunto de actividades que realizan las Organizaciones para optimizar o adaptar sus procesos de negocio a las nuevas necesidades organizacionales.
Para Krafzig [17] BPM introduce el concepto de procesamiento de procesos y enfatiza que este concepto no est limitado a la ejecucin automtica de modelos de procesos digitales incluyendo la denicin en [93].
Segn Owen [94] BPM tiene que ver con manejar el cambio para mejorar los procesos de negocio que por aos se han gestionado con distintas tcnicas y herramientas (ej. workows), pero con falta de estndares y ciclo de vida completo para disearlos y ejecutarlos. El manejo
7 http://www.bpmi.org/
171
del cambio requiere control y entendimiento de los procesos para eso son necesarios estndares de modelado y ejecucin de procesos.
Modelado de Procesos del Negocio con BPM

BPMIpromueve tres estndares: BPMN (Business Process Modeling Notation) para modelado de procesos, como estndar de notacin para especicarlos; BPML (Business Process Modeling Language) para ejecucin de procesos, como estndar de BPEL (Business Process Execution Language) y BPQL (Business Process Query Language) para distribucin y ejecucin de procesos de e-Business, como interface de gestin estndar. BPMN ha sido adoptado en febrero de 2006 como estndar del OMG.
9 8
Los procesos diseados utilizando el estndar BPMN pueden ser manipulados directamente y creados con un lenguaje ejecutable y puestos a disposicin para su ejecucin inmediata. Siendo esto anlogo a la funcionalidad de los modelos de datos relacionales y la generacin de sentencias SQL/DDL [94].
Como se incluye BPM en SOA

En Krafzig [17] se plantea la visin de BPM como fuerte, en vez de incluir directamente en el cdigo informacin y reglas sobre procesos del Negocio importantes, esta informacin es retirada de los sistemas de aplicacin y puesta bajo el control de un BPMS. BPM facilita la modicacin, reconguracin, y optimizacin de deniciones de procesos con herramientas grcas que pueden ser utilizadas por analistas del negocio con menor orientacin tecnolgica. SOA provee la funcionalidad del backend que es requerida por un BPMS para implementar la funcionalidad de sus procesos. Todos los conceptos discutidos previamente respecto a SOA, incluyendo el desarrollo evolutivo de capas bsica, intermediaria y de procesos, tienen en sentido en este contexto. SOA se convierte en la infraestructura que permite la Organizacin orientada a procesos. En la gura SOA. 4.22se muestra como encajan juntos los enfoques BPM y
8 http://www.bpmn.org/ 9 https://www.oasis-open.org/committees/tc ome.php?wg bbrev = wsbpel a h
172
Figura 4.21: SOA provee la infraestructura para BPM [17, 16]
El modelo presentado se puede ver como el paso nal en la adopcin de SOA, donde las Organizaciones, luego de atravesar los niveles de SOA planteados, podrn contar con una base de servicios denidos e implementados, que permitan la introduccin de BPM incluyendo BPMS que permitan el modelado grco de los procesos del Negocio con BPMN, que sern traducidos en forma automtica a BPEL que podr ser ejecutado directamente en los motores de procesos que estos sistemas proveen. Esto permitir cerrar la brecha entre los analistas del negocio y los desarrolladores de software, donde cada uno podr enfocarse en su rea de conocimiento manteniendo a la vez un objetivo comn: la Organizacin centrada en procesos del Negocio que reacciona gilmente a los cambios originados en ambas partes.
La capa de orquestacin de servicios, que sera entonces realizada en el motor de procesos de un BPMS, permite absorber rpidamente los cambios originados tanto en los procesos del Negocio como en las tecnologas subyacentes, facilitando la reconversin de procesos existentes y la introduccin de nuevos procesos por parte de los analistas del negocio, a la vez que las actualizaciones de la implementacin de los servicios subyacentes (software implementado)
4.5. ENFOQUE LA ARQUITECTURA PROPUESTA PARA AVEA
173
originadas por cambios de tecnologa o requerimientos de actualizacin de plataformas o nuevas posibilidades que se incorporan a las plataformas existentes.
4.5. Enfoque la arquitectura propuesta para AVEA

Con base a todo lo anterior descrito, la propuesta arquitectural para los AVEAs se describe a continuacin: Se presenta una arquitectura orientada a servicios (SOA) con base en el enfoque de Manejos de procesos de Negocios (BPM) para automatizar la solucin. Figura 4.22
Figura 4.22: Arquitectura propuesta para los sistemas generadores de AVEA
La arquitectura que se presenta en la tesis esta asociada a los sistemas generadores de AVEAS (gura 4.10). Para su diseo se han utilizado la arquitectura orientada a servicios
174
(SOA), los servicios Web y el modelado en BPM, ya que constituyen una tecnologa muy adecuada para la generacin de ambientes de enseanza aprendizaje para eLearning pues permite integrar los recursos o components del ambiente almacenados en distintos lugares, a travs de una nica interfaz, un acceso transparente a los AVEAS basados en diferentes tecnologas de almacenamiento y de metadatos.
Siguiendo el ejemplo de la especicacin de IMS Abstract Framework (IAF) descrita al inicio del apartado, el patrn de diseo Layers [Buschmann, 1996] y el enfoque de SOA propuesto por Erl, se propone una arquitectura multinivel o multicapa basada en servicios Web y SOA para la implementacin de este tipo de sistemas, considerando tres capas generales representadas en la gura 4.22. La arquitectura se descompone en las siguientes capas:
Componentes Tecnolgicos:
Esta es la parte de un sistema a travs de la cual los usuarios
pueden interactuar con el sistema. Tambin existen los componentes necesarios para que otros sistemas puedan interactuar con dicho sistema, y las herramientas de usuario necesarias para que ste pueda desarrollar las funciones propuestas. Esta capa de comonentes tecnolgicos se conecta a la capa de Componentes de Aplicaciones para enviar y recibir solicitudes.
Componentes de Aplicaciones:
En esta capa el sistema tiene los mecanismos y los ujos
de informacin necesarios para recibir las peticiones tanto de los usuarios como de otros sistemas, procesarlas y actuar en torno a las solicitudes. Esta capa representa al ESB (Enterprise Service Bus), y se bas en BPEL. Ella se encarga de generar los servicios para Entre los Elementos a destacar esta los Componentes de Aplicaciones, la cual integra los servicios de aplicaciones: (a) la interaccin con las funciones de la aplicacin: que permiten presentar las funciones de un solo servicio o genera servicios con funciones de distintas aplicaciones, (b) servicios de aplicaciones: la cual se relaciona con los servicios propios del negocio, es decir, los procesos de los AVEAS modelados en BPM, (c) las aplicaciones colaborativas: que permiten la integracin de distintos servicios, y por ltimo, (d) la interfaz de aplicacin: presenta el frontend que ser utilizado por los distintos usuarios, en ella se encuentran denidos los servicios de las diferentes vistas que ofrecer el sistema, segn el rol que posea el actor del negocio
4.5. ENFOQUE LA ARQUITECTURA PROPUESTA PARA AVEA
175
Componentes del Negocio:
Ac
se
representa
el
modelo
funcional
de
los
sistemas
generadores de enseanza aprendizaje para eLearning. En esta capa se encuentran los servicios que proporcionan las funcionalidades del AVEA los procesos del negocio de los AVEAS basada en las reglas establecidas para su generacin, representada en el modelo conceptual de AVEA, planteado por esta investigacin para en el captulo 2. Es aqu donde se establecen los servicios del negocio que representan los procesos y funciones internas, la lgica se descomponen en una serie de pasos que se ejecutan en secuencia predenida segn las reglas del negocio y condiciones de ejecucin.
La arquitectura propuesta busca la transparencia en la integracin de elementos necesarios para la generacin automtica de los AVEAS, por lo que la orientacin a servicios prevalece para ocultar a las capas superiores los detalles de implementacin. Los servicios se comunican bajo el intercambio de mensajes usando archivos XML con la informacin solicitada por el usuario y conforme al modelo de procesos de negocio implementados, realizar las bsquedas pertinentes.
Una de las ventajas que tiene esta arquitectura, es que es totalmente adaptable a cualquier estndar actual o futuro, y por lo tanto, totalmente compatible con cualquier AVEA. Adems, como ya se ha indicado, est basada en servicios Web, lo que la hace totalmente accesible desde cualquier plataforma, lenguaje de programacin, estndares o protocolos utilizados, etc., por lo tanto, se trata de una arquitectura de sistema de una gran exibilidad.
El archivo XML es donde se detallan los campos indicados por el usuario, as como los distintos valores que se recogen del chero de metainformacin del AVEA. El archivo XML obtenido durante uno de los procesos de bsqueda que ms adelante analizaremos.
Una vez desarrollados los servicios de la capa anterior, stos deben ser publicados en un directorio de servicios para su posterior localizacin. El funcionamiento sera similar al de un motor de bsqueda, como Google, con el protocolo HTTP (Hypertext Transfer Protocol) y HTML (Hypertext Markup Language) para localizar y publicar contenidos.
176

Los servicios Web, fueron publicados en un registro UDDI, permitindole al sistema inter-
cambiar e interoperar stos servicios con slo descargarse el WSDL que lo describe. Por otro lado, en los casos donde se detecte que no se puede acceder a un servicio determinado, podamos acudir al UDDI y obtener su nueva descripcin, en la que se observan, entre otras cosas, el enlace indicado para dicho servicio. De esta forma, el usuario no tendr que preocuparse si los enlaces a los servicios de la aplicacin varan. En el apndice C podemos encontrar algunos servicios publicados.
Como se puede apreciar, la ejecucin de los servicios conlleva la realizacin de la orquestacin de los mismos, es decir, necesitamos realizar una ejecucin controlada de una serie de servicios que muchas veces dependen de la ejecucin de otros. Para llevar esto a cabo y siguiendo las recomendaciones expuestas en SOA se utiliz el BPEL.
En el caso de los servicios de aplicacin y comunes correspondientes a la funcionalidad explicada en los casos de uso en el captulo 3, encontraremos los servicios que el usuario invoca a travs de la capa del componente tecnolgico. Alguno de estos servicios desencadenan llamadas a los servicios de las capas inferiores. A continuacin se comentan algunos de los servicios que incluye esta capa:
Servicio de bsqueda de AVEAs:
Sin duda es el ms importante y es el que desencadena
todas las llamadas a los servicios de las capas inferiores. Lo primero que realiza este servicio es la recogida de los metadatos del formulario que el usuario ha rellenado con sus preferencias de bsqueda, as como la especicacin del estndar educativo que utiliza. Se basa en la bsqueda de empaquetadas que siguen el estndar IMS LD, que se despliegan a travs del archivo XML llamado imsmanifest. Como resultado del ujo de llamada a los servicios de la capa 2 recibir el conjunto AVEAs encontrados.
Servicio de creacin del aempaquetado de AVEAs:
Este servicio se encarga de generar
un archivo comprimido con los elementos que componen el AVEA y estructurados siguiendo el esquema del Imsmanifest o Servicio de descarga de AVEAs: Una vez que se presenten los AVEAs disponibles, se podr descargarlos para ser reutilizado en otro contexto.
177
Servicio de registro de Enlaces:
Este servicio se encarga de registrar los sitios donde
existan repositorios de UoL empaquetadas siguiendo el estndar IMS LD, para ello, recoger los datos de un formulario que previamente habr rellenado el usuario, y que describen al sistema como el registro UDDI donde est publicado el servicio, direccin de localizacin del servicio, claves asociadas a su registro, entre otros.

Existen diferentes factores que inuyen en la seleccin de una arquitectura candidata, como se pudo apreciar en el captulo 3. En primer lugar, se estableci el dominio, al cual va dirigida la arquitectura es una fase inicial. Esto nos permiti conocer los componentes del dominio y sus interrelaciones. En segundo lugar, lo conforman los casos de usos, los cuales representan una secuencia tpica de acciones del suistema desde el punto de vista del usuario. Muestra cmo el sistema interactua con el exterior y el resultado de la interaccin. En ellos se representaron los requisitos funcionales del sistema. El tercer momento lo representan la identicacin de los requisitos no funcionales, los cuales estanasociados a las caractersticas de calidad que se buscan satisfacer con el sistema. Asi con la determinacin de stos se revisaron los patrones y estilos arquitectnicos, para evaluar si existe correspondencia entre ellos y el dominio en cuanto a sus criterios de calidad.
Todos estos momento fueron generando as la arquitectura SOA como candidata para los sistemas generadores de AVEAs. Como se abord en ste captulo al adoptar a SOA como arquitectura candidata, se procedi a hacer una anlisis de distintas arquitectura aplicadas en el marco del dominio de eLearning, para luego estudiar algunos casos que tienen correspondencia con esta investigacin.
Se concluye en este sentido, que la propuesta arquitectural que se presenta en esta tesis tratar de sintetizar las mltiples visiones hasta aqu descritas con la idea de presentar la arquitectura del sistema en forma multicapa o multinivel con los componentes que forman cada nivel. Se representa en ella sus capas, componentes y el sistema de interrelacin. Con la descripcin del modelo arquitectural generado, se establen los objetivos que ha de cumplir para
178
satisfacer los requisitos e integracin con el sistema.
En la arquitectura basada en SOA planteada, se denen la utilizacin de servicios para dar soporte a los requerimientos de software del usuario. Esta arquitectura propuesta permite la creacin y/o modicaciones de los procesos de generacin de AVEAs de forma gil, a travs de la composicin de nuevos procesos utilizando las funcionalidades que estn contenidas en la infraestructura de aplicaciones actuales o futuras, expuestas bajo la forma de servicios Web.
La incorporacin de SOA representa un cambio fundamental en el dominio de ambientes de enseanza aprendizaje. La manera en la cual las nuevas aplicaciones se disean, desarrollan y se pueden integrar con aplicaciones existenten. Adems facilita el desarrollo de nuevas aplicaciones, como servicios modulares que pueden interoperarse y reutilizarse con facilidad.
Captulo 5
Generando AVEAs con GTLE-E

En la actualidad, a los nes de brindar soluciones apropiadas a los problemas expuestos, se requiere de enfoques exibles que permitan encapsular los datos y procesos relacionados en unidades que provean un grado de modularidad e independencia apropiada para el dominio.
El desarrollo de software basado en la arquitectura orientada a servicios emergi como una importante solucin al problema del desarrollo de sistemas grandes y complejos. Los servicios son piezas de software autocontenidas, reusables y accesibles slo a travs de interfaces bien denidas. Estn diseados para interactuar con otros servicios desarrollados en forma independiente y para ser ensamblados por tercero en sus aplicaciones.
Una de las grandes ventajas de los servicios es la reusabilidad. Un reuso efectivo depende no slo de la identicacin apropiada de los servicios, sino del modo en que dichos servicios son combinados y organizados. Las arquitecturas orientadas a servicios brindan el soporte para la integracin de partes en sistemas mayores, facilitando la denicin de una estructura de ensamblado adecuada. El empleo de esta tcnica de desarrollo de software requiere por lo tanto de un cuidadoso modelado arquitectural y anlisis, a los nes de asegurar reusabilidad y compatibilidad entre servicios interactuantes.
Considerando lo expuesto, en este captulo se plantea la realizacin de un prototipo basado en el anlisis y diseo arquitectural propuesto en el captulo 4, para la generacin de sistemas 179
180
CAPTULO 5. GENERANDO AVEAS CON GTLE-E
de AVEAs, con el n de obtener servicios reusables y sus interacciones, los cuales a travs de una plataforma conveniente de integracin, puedan ser ensamblados para distintos tipos de aplicaciones del dominio. Se enfatiza el desarrollo de AVEAs basados en procesos del negocio, siguiendo lo propuesto por BPM, a los nes de denir los procesos ms apropiados para este tipo de sistemas. Se utiliza el lenguaje de especicacin UML, ya que si bien el mismo no constituye un lenguaje formal de especicacin de servicios, resulta conveniente para el nivel conceptual y la generalidad del modelo que se quiere alcanzar. Finalmente, se desarrolla un generador de AVEAs y se implementa un estudio de casos basados en la estrategia Gaviln. Este modelo podr ser utilizado para la implementacin de diferentes aplicaciones correspondientes a procesos caractersticos del dominio.
5.1. Introduccin
En este captulo se describe la implementacin del diseo arquitectnico y del motor de ejecucin de diseos de aprendizaje para la generacin de los Ambientes de virtuales de enseanza aprendizaje (AVEAs) que estn basados en la especicacin IMS Learning Design (IMS LD), que incluyen parcialmente las caractersticas del nivel B de dicha especicacin que son ms relevantes desde el punto de vista de la personalizacin del diseo del aprendizaje. En este sentido, el motor manejar condiciones (o reglas) donde se modelan las situaciones en las que se seleccionarn las actividades a realizar por cada estudiante en cada momento (ver gura 5.1). Estas condiciones podrn hacer referencia a las caractersticas que denen la competencia y el perl de los estudiantes, de modo que en funcin de ellas el estudiante deber realizar unas actividades de aprendizaje u otras.
Este prototipo propuesto, consiste en apoyar la construccin de estrategias modelando la personalizacin a travs de reglas que se representan en IMS LD nivel B. Por otra parte, el motor de ejecucin de IMS LD nivel B, modela el ujo de aprendizaje de la especicacin a travs de UML, independizando la semntica de ejecucin de las unidades de aprendizaje del lenguaje en el que estn expresadas.
5.2. GENERADOR DE AMBIENTES DE ENSEANZA APRENDIZAJE PARA ELEARNING (GTLE-E)181
Figura 5.1: Elementos del AVEA adaptado de Olivier et al [18]
En otras palabras, una vez la unidad de aprendizaje AVEA-LD nivel B ha sido cargada en el sistema, el ujo de aprendizaje que gobierna la coordinacin entre los roles denidos en esa unidad se traduce al proceso diseado.. Finalmente, para ejecutar el ujo de aprendizaje se usa un motor de BPM del AVEA basado en LD, embebido en la arquitectura orientada a servicios que captura la semntica de ejecucin mediante un repositorio que constituye la base donde se almacena las estrategias diseadas en GTLE-E.
5.2. Generador de Ambientes de Enseanza Aprendizaje para eLearning (GTLE-E)

Una de las cuestiones que diculta la adopcin de los lenguajes del modelado educativo, en general, y del IMS LD, en particular, es la falta de herramientas de autora fciles de usar de apoyo que simplique el uso de estas lenguas.
Entre los objetivos de esta investigacin, estuvo crear un prototipo para validar la arquitectura propuesta, derivando una herramienta de autora, llamado GTLE-E (Generators
182
for teaching and learning environments - eLearning), basada en una Arquitectura Orientada a Servicios (SOA) y que provee un conjunto de herramientas de apoyo a los docentes en la generacin de sus ambientes de enseanza aprendizaje para eLearning (AVEAs) basados en el estndar IMS LD.
En GTLE-E, la creacin de los AVEAs pueden iniciar desde cero o seleccionar uno de los preexistentes como base. La herramienta ofrece una notacin grca de llenado de conjunto de metas, objetivos y competencias, para describir los objetivos de aprendizaje y sus relaciones. GTLE-E tambin proporciona soporte para el anlisis de un AVEA preexistente, lo que permite a los docentes evaluar si cumple con algunos de los objetivos de diseo de aprendizaje del ambiente a proponer, por lo tanto, convertirse en un candidato para su reutilizacin total o parcial.
Uno de los procesos ms lgidos es el diseo instruccional, el cual es el resultado del proceso de aprendizaje de diseo global que incluye la seleccin de las actividades (por ejemplo, cuestionarios, ejercicios, entre otros), los contenidos de aprendizaje y herramientas (por ejemplo, medios de comunicacin, la comunicacin) necesarios para lograr los objetivos de aprendizaje identicados. Adems, la secuenciacin de estas actividades. Este proceso representa el diseo de aprendizaje del docente.
Es justo en estos procesos donde encajan los lenguajes de modelado educativo, pues en lugar de crear un documento informal en lenguaje natural o relleno en una plantilla, el documento de diseo instruccional se crea siguiendo un modelo conceptual basado en un lenguaje de modelado educativo, que en nuestro caso particular es el IMS-LD, generando as un documento formal. Este documento permite su automatizacin, es decir, la interpretacin en un reproductores basados en el estndar. Ver gura 5.2 El objetivo de GTLE-E es permitir a los diseadores instruccionales crear un patrn de estrategias educativas con el uso de las TIC, compatible con IMS LD durante la generacin de los ambientes de enseanza aprendizaje para eLearning. En este sentido, esta herramienta proporciona a los diseador instruccional, una notacin visual para modelar el ujo empleado para
5.2. GENERADOR DE AMBIENTES DE ENSEANZA APRENDIZAJE PARA ELEARNING (GTLE-E)183
Figura 5.2: Representacin de GTLE-E
denir las actividades y su secuencia del diseo instruccional, teniendo en cuenta la disposicin de los elementos del estndar incorporados en el modelo conceptual. Estas herramientas de notacin visual para modelar el ujo son una de las tcnicas usadas para describir los procesos de negocio (BPMN, UML, entre otros). Adems, los diagramas de ujo han sido ampliamente utilizados en informtica para describir algoritmos independientes del lenguaje de programacin. Por tanto, creemos que un lenguaje orientado al ujo puede servir como base para la creacin de ambientes, ya que proporcionan ayuda poderosa para describir y comprender los sistemas complejos.
Es importante tener en cuenta que el proceso provisto por GTLE-E no impone ningn mtodo pedaggico durante la creacin de la AVEA basado en LD. El docente es por lo tanto responsable de la seleccin apropiada de la metodologa pedaggica para el diseo del AVEA. La aplicacin de la herramienta ofrece algunas ventajas. Por ejemplo, AVEAs formalizados con un IMS LD siendo menos propensos a errores que una AVEA descrito en
184
lenguaje natural, debido a que los elementos del IMS LD tienen semntica bien denida. Por otra parte, GTLE-E tambin permiten la formalizacin de las prcticas de enseanza y metodologas probadas pedaggicamente tales como plantillas, esqueletos o patrones que ms tarde puede ser personalizado. Es precisamente este ltimo aspecto el que describiremos con ms detalle, en prxima seccin de este apartado. Ver gura 5.3
Figura 5.3: Flujo de procesos en GTLE-E
5.3. Modelando a GTLE-E

A continuacin se presenta elementos de modelado en la creacin de AVEA basado en IMS-LD, donde priva el hecho del uso de notaciones grcas para proporcionar una sintaxis visual para lenguajes de modelado ha sido probado y puesto en prctica en muchos mbitos.
5.3. MODELANDO A GTLE-E
185
Algunos ejemplos incluyen bases de datos con los modelos Entidad-Relacin para la denicin de esquemas de bases de datos de aplicaciones, ingeniera de software con el Lenguaje Unicado de Modelado (UML) para la descripcin de los sistemas de software y, los negocios con la notacin de Gestin de Procesos de Negocio (BPMN) para la descripcin de los procesos de negocio.
Las notaciones grcas han sido desarrollados para reducir la carga cognitiva cuando se trabaja con complejos modelos semnticos. Ellos proporcionan una notacin ms simple que puede ser ms claramente comprendida por una amplia gama de usuarios, desde tcnico al personal no tcnico. Siguiendo esta tendencia, se propone el uso de notaciones grcas para el diseo de AVEAs en GTLE-E.
En GTLE-E las anotaciones visuales incluyen, los papeles de los participantes. Esta notacin proporciona a los docentes con una forma para la denicin de los tipos diferentes participantes (llamados roles). Estas funciones se utilizan para clasicar a los participantes en los diferentes tipos (por ejemplo, estudiante, docentes) y asignar responsabilidades a los diferentes roles denidos.
Igualmente permite a los docentes denir los objetivos (objetivos de aprendizaje) que cubrir en el AVEA. A estos efectos, el docente puede denir un objetivo de alto nivel como el objetivo general y, ms tarde, renar este objetivo en subobjetivos a alcanzar por las diferentes partes del AVEA. Con este tipo de notacin, tambin es posible denir los participantes en la consecucin de estos objetivos.
La
notacin
para
denir
las
actividades,
contempla
la
denicin
de
las
diferentes
actividades que se realizarn durante la ejecucin del AVEA. Utilizando esta notacin, los diseadores instruccionales pueden analizar cules son las actividades necesarias para alcanzar los objetivos de aprendizaje que conformar el mtodo o estrategia a disear. Por otro lado, ste puede disear las actividades que describan lo que se debe hacer y qu herramientas deben ser utilizadas (chat, dossier, herramienta de laboratorio, entre otras). Estas actividades tambin incluyen las instrucciones. Las actividades se pueden clasicar
186
en las simples y estructuradas. Las actividades estructuradas agregan actividades simples mediante la adicin de un comportamiento de tiempo de ejecucin implcita. Como actividades estructuradas pueden ser muy grandes y complejas, la notacin introduce elementos de abstraccin jerrquicos. En el caso de los recursos educativos (objetos de aprendizaje y herramientas) necesarios para realizar las actividades, ser insertados en el AVEA por el docente, una vez que haya seleccionado la estrategia o mtodo.Ver gura 5.4
Figura 5.4: Distribucin funcionalidades segn acceso al sistema
Para describir la secuencia de actividades, se provee al diseador una notacin para hacer que el ujo de aprendizaje explcito a travs de las diferentes actividades que conforman el AVEA. Adems, la notacin permite la denicin de funciones que intervienen durante la ejecucin de las actividades. La denicin de la secuenciacin puede ser una simple ordenacin de las actividades aplicadas a todos los participantes o pueden proporcionar una denicin personalizada del ujo de aprendizaje basado en el rendimiento de los participantes del AVEA. Esta misma denicin puede ser detallada. Por lo tanto, la notacin tambin introduce mecanismos jerrquicos de descomposicin. Los elementos compuestos se pueden contraer para
187
ocultar algunas partes del modelo que tambin puede ser renado en un diagrama separado. Ver apndice A
Todas estas anotaciones coexisten en un sistema unicado orientado al ujo. En la vista del diseo de aprendizaje, est integrado todos los aspectos del diseo. Esta caracterstica, junto con una representacin visual fcil de usar, debera aumentar la capacidad de uso de las anotaciones con respecto a la reutilizacin e interoperabilidad (tal como IMS LD). Esta notacin orientada al ujo grco se emplea dentro de la herramienta de GTLE-E para denir diseos de aprendizaje de los AVEA.
Una vez que los docentes crean sus diseos de aprendizaje en los AVEA, automticamente se puede exportar para crear UoLs(Unidades de Aprendizajes) compatible con la especicacin IMS LD. Ver apndice D
188
Anlisis de 1. Inicializacin Necesidades 2. Indenti cacin de Prioridades Anlisis de Marco de Trabajo

Ambientes de Enseanza y Aprendizaje Entornos de Enseanza y Aprendizaje
3. De nicin de Objetivos 4. Anlisis de Demanda
1. Anlisis de contexto externo 4. Anlisis del contexto institucional y organizacional 2. Anlisis de los recursos del grupo 5. Planeacin de tiempo y presupuesto 3. Anlisis de los grupos destino 6. Anlisis del entorno
1 Concepto | Diseo
Objetivos del aprendizaje Contenidos | Mtodos didcticos Roles y actividades | Organizacin Elementos tcnicos | Diseo de Interaccin y medios | Medios Comunicacin | Evaluacin y pruebas Mantenimiento
3 Implementacin
Evaluacin de los recursos de aprendizaje | Adaptacin de los recursos de aprendizaje | Activacin de los recursos de aprendizaje | Organizacin de uso | Infraestructura tcnica
2 Desarrollo | Produccin
Realizacin del contenido Realizacin del diseo Realizacin de los medios Realizacin tcnica Mantenimiento
4 Proceso de aprendizaje
Administracin | Actividades | Revisin de niveles de competencia
E-learning
5 Evaluacin | Optimizacin
Planeacin | Realizacin | Anlisis | Optimizacin - Mejora
Figura 5.5: Componentes de GTLE-E basado en IMS LD
Como podemos detallar en la gura
5.5, la ejecucin del modelo de ujo de aprendiza-
je asociado a este modelo conceptual, est asociado a la especicacin IMS-LD nivel B. El ujo de proceso permite detallar en cada momento qu actividades tiene que ir ejecutando cada estudiante en funcin de los valores de ciertas propiedades (denidas o modeladas en las competencias). Para ello se detallan los aspectos relacionados con el ujo de procesos espe-
189
ccamente en los roles de los participantes, propiedades y personalizacin, las actividades y secuenciamiento.
Los Roles de los participantes se denen en un diagrama que representa la jerarqua de las funciones. Cada denicin de funcin no slo incluye el nombre de la funcin, sino tambin valor especco IMS LD atributos relevantes desde el punto de vista del autor (por ejemplo, crear nuevos y referenciarlos - href ).
Como los papeles de UoL en IMS-LD, en GTLE-E los papeles de los participantes en el AVEAs se organizan en una jerarqua en la que las dos funciones bsicas de IMS LD, estudiante y personal (sta ), se utilizan como elementos raz de jerarqua. El papel de estudiante es un papel de base para las funciones que representan los diferentes tipos de estudiantes en el AVEA (por ejemplo, estudiante, compaero de estudios, jefe de grupo, etc.) El papel del personal (sta ), es un rol de base para los papeles que representan diferentes tipos de docentes y el personal involucrado en el AVEA (por ejemplo, instructor, docente ayudante, docente, vigilante, etc.)
La jerarqua de roles es una jerarqua de herencia. Es decir, cada subrol tiene las responsabilidades de sus superroles adicionales asignado a la subrol especco (es decir, subroles son especializaciones).
Con respecto a las propiedad y personalizacin la implementacin actual de GTLE-E es parcialmente compatible con IMS LD nivel B, y soporta la mayora de las caractersticas de la especicacin que facilitan la personalizacin del ujo del aprendizaje a las competencias y la evolucin de cada estudiante, pues soporta los siguientes elementos que se explican a continuacin:(Ver gura 5.6)
Propiedades (properties)
Hacen
referencia
variables
que
describen
el
estado
del
aprendizaje del estudiante durante la realizacin del AVEA. Las propiedades son un elemento clave en el estndar IMS LD nivel B y, en general, en cualquier estrategia
190

de personalizacin del ujo del aprendizaje en la medida en que permiten valorar al estudiante y orientar qu actividades debern ser ejecutadas en cada momento.
Propiedades personales
Pueden tener un valor diferente para cada usuario, y dependiendo
de su alcance distinguimos dos tipos: (a) locales (locpers-property), cuando estn limitadas a la ejecucin de un AVEA; y (b) globales (globpers-property), que toman valores independientemente de las diferentes ejecuciones de los AVEAs, deniendo el portafolio de cada usuario. Las propiedades personales, por tanto, estn especialmente orientadas a personalizar el ujo de aprendizaje.
Propiedades de roles (locrole-property)
Pertenecen a un determinado rol y son siempre
locales. Estas propiedades pueden tener valores distintos en diferentes ejecuciones de los AVEAs, de modo que cualquier usuario puede acceder a ella compartiendo el mismo valor con los dems usarios en una misma ejecucin.
Condiciones (conditions)
Tienen un formato de regla del tipo IF <expresion>THEN
<accion>[ELSE <accion>], en la cual el antecedente (IF) consiste en la evaluacin de una o varias expresiones lgicas en las que se pueden evaluar una o varias propiedades denidas en el AVEA. El motor de IMS LD puede manejar expresiones lgicas relacionadas con la evaluacin de los valores de las propiedades personales y de roles, con la nalizacin de los elementos que forman parte del ujo de IMS LD nivel B, y con la pertenencia a del usuario a un rol dado
Mostrar (show) y Esconder (hide)
Modican directamente la visibilidad de los principa-
les componentes del ujo del aprendizaje, tales como las representaciones, las actividades, las estructuras de actividad, y las unidades de aprendizaje. Con estos dos tipos de acciones es posible seleccionar indirectamente qu actividad se deber ejecutar en cada momento, dado que al esconder o mostrar una rama del ujo de IMS. En el AVEA el usuario no podr realizar las actividades que dependen de ella, y el entorno y los objetos de aprendizaje que utiliza el usuario al llevar a cabo una actividad. Un estudiante no puede modicar el ujo establecido por el diseador del AVEA.
191
Cambiar el valor de una propiedad (change-property-value)
Lo cual puede provocar
que se activen y ejecuten las partes consecuentes de otras reglas y, por tanto, esconder o mostrar otros elementos que forman parte del ujo de IMS LD nivel B.
Figura 5.6: Tipo de propiedades en el AVEA
Es importante sealar que GTLE-E soporta el anidamiento de condiciones, as como la vericacin de expresiones unidas a travs de los conectores lgicos and y or. Esto permite la creacin de condiciones ms complejas y, por tanto, renar la personalizacin de los AVEAs a cada estudiante, tal cual provee el modelo IMS-LD.
Con los elementos de la especicacin IMS LD nivel B soportados por el motor ser posible la personalizacin de unidades de aprendizaje con un nivel de complejidad medio, y en las que el ujo de aprendizaje est condicionado por los valores de las propiedades de los usuarios. Estos valores podrn ser actualizados cuando se haya ejecutado una condicin (change-property-value) o cuando haya nalizado una actividad (on-competion).
En el Flujo de Actividades y secuenciamiento, usando terminologa IMS LD, la notacin introduce dos tipos de actividades, simples y estructuradas. Actividades simples incluyen acti-
192
vidades de aprendizaje, que realizan normalmente por los estudiantes, y actividades de apoyo, que realizan por una funcin de apoyo, por lo general un docente. Las actividades estructuradas permiten a los docentes agregar actividades (a la vez simple y estructurada) aadiendo as un comportamiento de secuencia implcita. Con estas actividades, hay dos posibilidades: las actividades se realizan en secuencia al azar o actividades se puede elegir. De acuerdo con estas posibilidades, una actividad estructurada con un comportamiento de tiempo de ejecucin ja secuenciado y una actividad estructurada con un comportamiento de seleccin del usuario.
En un AVEA es posible utilizar la misma actividad (simple o estructurada) en diferentes lugares. Como se present anteriormente, el estado de nalizacin de una actividad de IMS LD se comparte entre todos sus ocurrencias.
Debido a la naturaleza jerrquica de estructuras de actividad, la notacin grca propuesta tambin permite que las actividades puedan contraerse o expandirse en un diagrama de aumentar la legibilidad del diagrama, as como la denicin de las estructuras de actividad en diagramas separados.
Todas las actividades, ya sea simple o estructurada, tienen un conjunto de propiedades no visuales que permiten la denicin completa de la actividad. Por ejemplo, esto puede incluir la denicin de las actividades de los recursos disponibles en tiempo de ejecucin o la descripcin de los objetivos de aprendizaje que deben alcanzarse. Teniendo esto en cuenta, las acciones que podrn ser llevadas a cabo seran las siguientes(Ver gura 5.7):
Seleccin automtica de actividades
En la que el motor decide cul es la actividad de
aprendizaje o de soporte a llevar a cabo por cada usuario cuando se ejecuta una AVEA. Esto signica, que los usuarios no pueden invocar la ejecucin del motor para seleccionar la siguiente actividad ni tampoco elegirla, salvo en el caso que el elemento del ujo en estado de ejecucin sea una estructura de actividad del tipo seleccin (selection).
Suspensin temporal de un elemento
Suspensin temporal de un elemento del ujo de
IMS LD, que implica que el estudiante no puede continuar con la ejecucin de la actividad asociada al elemento suspendido, ni tampoco usar los entornos vinculados a ella. Por
5.4. GUIONES EN APOYO A LA GENERACIN DE AVEAS
193
ejemplo, cuando se suspenda una representacin, todos sus actos sern suspendidos y, a su vez, todas las actividades asociadas a dichos actos tambin sern suspendidas. Tpicamente, los docentes sern los nicos usuarios que podrn suspender los elementos del ujo de IMS LD de otros usuarios (los estudiantes).
Reanudacin de un elemento
Reanudacin de un elemento del ujo de IMS LD, en la que
los usuarios pueden volver a realizar la actividad que ha sido previamente suspendida y, por tanto, volver a usar los entornos vinculados a ella. De la misma forma que sucede con las suspensiones, la reanudacin de un elemento operar sobre todos los elementos del ujo que dependen de l. Por ejemplo, al reanudar un acto, tambin se reanudarn todas aquellas actividades que estaban suspendidas. Nuevamente, los usuarios con permisos para realizar este tipo de acciones sobre otros usuarios (estudiantes) son los docentes.
Suspensin denitiva de un elemento
Suspensin denitiva de un elemento IMS LD, en
la cual los usuarios no podrn acceder a las actividades que dependen del elemento que ha sido suspendido denitivamente y que an no han sido realizadas. Por ejemplo, si se suspende una representacin, todas los actos que an no han sido ejecutados por los usuarios sern tambin suspendidos de forma dentiva y, por tanto, ya no se podr acceder a ellos. La suspensin denitiva de un elemento IMS LD solamente podr ser invocada por los docentes.
Finalizacin de una actividad
Lo que indica que el usuario ha concluido la realizacin de la
actividad. Cuando esta accin tiene lugar, el motor deber seleccionar automticamente la siguiente actividad a ejecutar por parte del usuario. Por tanto, en la ejecucin tpica de una unidad de aprendizaje, los estudiantes van indicando la nalizacin de cada actividad hasta que todas las actividades del ujo de IMS LD hayan sido realizadas.
5.4. Guiones en apoyo a la generacin de AVEAS

Un patrn puede relacionarse con una coleccin o con una clase de objetos de aprendizaje. Puede ser, por un lado, la parte comn de los objetos con la informacin para aplicarse a diversas situaciones de aprendizaje y, por otro lado, tambin puede adaptarse a nuevas
194
Figura 5.7: Flujo del proceso de creacin de una actividad en GTLE-E
situaciones (adaptatibilidad y reusabilidad) modicando su contenido especco. Para ello el proceso de construccin del Ambientes virtuales de Enseanza Aprendizaje (AVEA) debera contemplar al menos (Adaptado de Jones y Stewart [95]):
Identicacin y especicacin de patrones del mtodo de aprendizaje que capturan una secuencia de actividades genricas para el desarrollo de una competencia, aprendizaje especco o una actividad de aprendizaje.
Concretar los patrones de aprendizaje: seleccin de disciplinas, temtica, contextos especcos y contenidos multimedia, etc.
Aplicar los patrones para parametrizar los AVEAs, especicacin del diseo funcional y multimedia de los mismos y por ltimo su implementacin.
5.4. GUIONES EN APOYO A LA GENERACIN DE AVEAS
195
Creacin de repositorios de guiones de diseo instruccional representados mediante patrones, enlazando con criterios o variables que permitan diferenciar entre los diversos patrones de diseo.
Por otro lado, los patrones pueden utilizarse en la prctica y en el diseo de entornos de aprendizaje virtual, en la enseanza y en la organizacin. La inclusin del eLearning en las instituciones supone afrontar numerosos cambios, tanto a nivel organizacional como a nivel del proceso de enseanza. Algunos de los problemas que pueden surgir afrontarse con patrones son: [95] y que pueden
Roles multidisciplinares. Uno de los problemas que pueden surgir es la falta de entendimiento instruccional. entre los distintos roles que intervienen en el proceso de diseo
Inclusin de tecnologas y nuevos procesos de enseanza. Las nuevas metodologas docentes dieren notablemente de la tradicional, la enseanza presencial y los mtodos pedaggicos. Se precisa socializar la experiencia educativa y docente de una forma rpida y ecaz.
1
En la Central Quensland University
(Australia)
[95] han desarrollado un marco de
implementacin y catalogacin de patrones para mejorar las prcticas educativas en entornos virtuales. En l han realizado proyectos relacionados con los patrones aplicados a los procesos de aprendizaje virtual, con el n de solventar entre otros los problemas sealados. La alternativa que proponen se basa en 5 lneas:
Minera de Patrones.
Anlisis de las experiencias multidisciplinares para recopilar mejores
prcticas y experiencias.
Especicacin de los patrones. Catlogo de patrones.
Extraccin y anlisis de las soluciones aportaciones a
problemas que se hayan dado en la institucin.
Los patrones desarrollados se hacen accesibles de forma sistemtica
y organizada mediante un catlogo de patrones y se integran con sistemas de bsqueda y acceso a la informacin por temas, disciplinas, etc.
1 www.cqu.edu.au/
196

Los patrones seleccionados se integran con los Sistemas de
Creacin de plantillas.
Aprendizaje a travs de plantillas.
Evaluacin de los patrones.
Se realiza una evaluacin al proceso completo de elaboracin
de los patrones, con retroalimentacin progresiva.
Uso de patrones en eLearning
Listo para su puesta en prctica.
Figura 5.8: Uso de patrones en eLearning
Adoptando en la prctica a GTLE-E el enfoque propuesto por Jones et al [95], el diseador instruccional tiene la responsabilidad de efectuar la minera de patrones hasta llegar a la especicacin del patrn. El sistema GTLE-E genera una base de datos con la informacin relacionada con el patrn y la almacena en el repositorio de mtodos o estrategias, proporcionando as una plantilla asociada al mtodo o estrategia convertida en un patrn. En este punto, ya el docente tiene a sus disponibilidades un nuevo mtodo o patrn pedaggico que revisar para generar nalmente su AVEA. La gura 5.8 muestra los procesos y ujo del
proceso en la aplicacin de patrones en programas de eLearning. GTLE-E se ofrece como herramienta tecnolgica de autora (Ver gura 5.9), que permite la seleccin del mtodo o estratgia pedaggica apoyada por patrones. Los patrones estn generados explcitamente por el diseador instruccional dentro de herramienta. Lo que tiene
5.5. ARQUITECTURA SOFTWARE DE GTLE-E
197
de general el GTLE-E es que el docente puede crear AVEA especcos basados en el modelo elegido.
Figura 5.9: Ubicacin de GTLE-E dentro del dominio de eLearning (Autora)
La intencin es la propuesta de una herramienta autor GTLE-E que permita crear AVEA a partir de una serie de patrones pedaggicos, con un proceso guiando a los autores encargados del proceso de enseanza. Si entendemos como reusabilidad el potencial de usar en contextos diferentes cada AVEA y como generatividad el nmero de parmetros por los valores posibles, podemos establecer en tendencia cualitativa la covariacin entre ambas caractersticas de la forma siguiente, en funcin de lo estudiado (se trata de grasmos conceptuales, sin signicacin cuantitativa ni proporcional).
5.5. Arquitectura software de GTLE-E

El motor de ejecucin del ujo de aprendizaje de IMS LD nivel B presenta una arquitectura SOA, abierta y exible que est compuesta de servicios y bajo un modelado de lgica de
198
negocios que da soporte a la ejecucin de AVEA basados en Uol nivel B. El objetivo de este motor es permitir tanto la gestin como la ejecucin de un AVEA; es decir, la carga de ambientes empaquetadas siguiendo el estndar IMS LD y la ejecucin de diagramas BPM que modelan ujo de aprendizaje. Sin embargo, tal y como se ha comentado en la seccin de requisitos, para facilitar la integracin y uso de GTLE-E en plataformas de aprendizaje se ha considerado el desarrollo de una arquitectura orientada a servicios que externaliza las funcionalidades del motor a travs de servicios web accesibles mediante SOAP y descritos con WSDL. La Figura el esquema de componentes de la arquitectura, en el que podemos distinguir: 5.10 muestra
Figura 5.10: Detalles de la arquitectura propuesta
Una capa de componentes tecnolgico:
Se comunica con la capa de componentes de
aplicaciones donde se encuentra las plataformas de aprendizaje (por ejemplo Moodle) o, en general, a interfaces grcas (players) con las que los usuarios pueden visualizar el ujo de IMS LD y acceder a los recursos de las actividades.
5.5. ARQUITECTURA SOFTWARE DE GTLE-E
199
La segunda capa (componentes de aplicaciones):
Es
la
responsable
de
resolver
las
interconexiones entre los elementos de la arquitectura, particularmente entre los servicios web y los clientes. Para ello se ha usado OpenESB como servidor de aplicaciones e integrador de servicios debido fundamentalmente a que ofrece uno de los mejores rendimientos entre servidores de aplicaciones open source a la hora de resolver la invocacin de los servicios; integra mdulos (service engine) de procesamiento como, por ejemplo, la composicin de servicios a travs del lenguaje BPEL, y componentes para el tratamiento de protocolos de comunicacin (binding components) que pueden utilizar los clientes para acceder a los servicios web; y est integrado con la plataforma J2EE y el entorno de desarrollo Netbeans, facilitando enormemente el despliegue de servicios web implementados en Java. Por otra parte, OpenESB dene un bus (Normalized Message Router, NMR, en ingls) que es usado por los diferentes mdulos y componentes para comunicarse entre s a travs de los patrones de intercambio de mensajes especicados en WSDL 2.0. Esto mejora la interoperabilidad y facilita la integracin de diferentes tecnologas y protocolos de diferentes vendedores.
La tercera capa (Componentes de negocio)
Contiene el conjunto de servicios web que
implementan la lgica de negocio de GTLE-E. En este sentido, la arquitectura software del motor favorece la externalizacin de sus funcionalidades, en la medida en que estn declaradas a travs de los mtodos de la fachada implementado en Java y PHP, es decir, los servicios web invocan directamente a los mtodos de la interfaz del motor IMS LD. As, la arquitectura orientada a servicios ofrece nmero de servicios web asociados a las funcionalidades del sistema. (Apendice C)
El motor de ujos IMS LD nivel B, consiste en una librera de programacin que requiere de una interfaz grca en la que se vaya mostrando a cada usuario cules son las actividades que deber ir realizando en cada momento. Esta interfaz grca puede ser una aplicacin de escritorio, un cliente web ligero o incluso un pluggin de unas plataformas de aprendizaje (como Moodle o Sakai). Por otra parte, el pilar en el que descansa GTLE-E es la integracin de una serie de servicios educativos que se ofrecen a las aplicaciones a travs de bus de integracin. Por tanto, cualquiera que sea la tecnologa que se use para el desarrollo del motor, debera ser lo sucientemente exible y abierta como para permitir la integracin del motor
200
en cualquier aplicacin independientemente del lenguaje de programacin en el que se haya implementado. En este sentido, el lenguaje de programacin Java y la plataforma J2EE son soluciones muy asentadas que resuelven de forma efectiva los problemas de integracin entre aplicaciones, para lo cual soportan diferentes aproximaciones tecnolgicas, entre las que cabe destacar las arquitecturas orientadas a servicios (Software-Oriented Architecture, SOA, en ingls) (Papazoglou et col., 2008) desplegadas haciendo uso de servicios web (Curbera et col., 2001; Alonso et col., 2003). En este sentido, el uso de una SOA que externalice las funcionalidades del motor es la solucin natural al problema de integracin de GTLE-E en el bus de interoperabilidad y en las interfaces grcas utilizadas por los usuarios para acceder al ujo y a los recursos de la unidad de aprendizaje. Ver Apndice C
5.6. Modelado del ujo del AVEA

El motor del AVEA esta soportado en IMS LD nivel B (como se pudo observar en el captulo 2 gura 2.19 ) para representar y modelar la semntica de ejecucin de los componentes del ujo de aprendizaje. As, AVEA tiene asociada un ujo de alto nivel que captura la estructura de ejecucin de cada uno de los componentes del ujo de aprendizaje. Especcamente, el mtodo, las representaciones, los actos, las partes de rol, las actividades y las estructuras de actividad se modelan utilizando BPM y, por tanto, la red jerrquica que est asociada al AVEA dene la unin entre las diferentes diagramas de ujos correspondientes a los componentes del ujo de IMS LD.
5.6.1. Interfaz grca GTLE-E

Es importante enfatizar que GTLE-E provee un motor de ujos de aprendizaje basados en la especicacin IMS LD nivel B. Esto signica que la propuesta no va orientada al manejo de los entornos asociados a las actividades que los estudiantes y/o docentes deben de realizar en cada momento, es decir, ni presenta los recursos ni ejecuta los servicios especicados en los entornos. Esto se debe a que los entornos no forman parte de los componentes que dan forma al ujo de aprendizaje en la especicacin IMS LD (mtodo, actos, actividades de soporte y de aprendizaje, etc.). Por ello la aplicacin de los AVEAs generados por GTLE-E, requiere de una interfaz grca en la que se vaya presentando a los participantes en los ambientes de
5.6. MODELADO DEL FLUJO DEL AVEA
201
aprendizaje las actividades a realizar y los entornos (recursos y servicios) que deben manejar para completar dichas actividades. ver gura 5.11 y 5.12
Figura 5.11: Ingreso al Sistema GTLE-E
Figura 5.12: Ingreso al Sistema GTLE-E
202

Sin embargo, para demostrar que GTLE-E sigue la semntica de ejecucin de IMS LD
nivel B se ha desarrollado una interfaz grca en la que se puede visualizar cmo se ira ejecutando una unidad de aprendizaje por parte de estudiantes y docentes. En este sentido, el propsito de esta interfaz grca no es ofrecer a los estudiantes y docentes un medio para ejecutar unidades de aprendizaje IMS LD nivel B, sino que est pensada para vericar (a) que la interaccin entre los participantes en ellas tiene lugar de la forma deseada por el docente al disear la unidad de aprendizaje, y (b) que la unidad de aprendizaje sigue la semntica de la especicacin IMS LD; es decir, que est correctamente construida.(ver gura 5.13 )
Figura 5.13: Creacin de Cuentas de usuarios
Esta interfaz grca ofrece las siguientes funcionalidades:
Un usuario puede cargar un AVEA basado en IMS LD nivel B y que est representada en formato XML-Schema. Concretamente, se cargar el archivo imsmanifest.xml, dado que es el que contiene la descripcin del ujo de aprendizaje. Como resultado de esta operacin, la interfaz grca mostrar las caractersticas de dicho AVEA, focalizando en el rbol del ujo de aprendizaje que presenta la informacin sobre sus elementos IMS LD; y en las propiedades especicadas en el AVEA, donde podemos observar sus valores iniciales y tipo. Ver imagen 5.14
203
Figura 5.14: Busqueda de AVEAs
Figura 5.15: Declaracin de roles en el AVEA
Se puede realizar una validacin semntica para comprobar que la unidad est diseada correctamente, y no presenta incoherencias desde el punto de vista de la semntica de la especicacin IMS LD nivel B.
Una vez se ha cargado el AVEA, el usuario de la interfaz podr crear usuarios asociados a cualquier de los roles especicados en la unidad de aprendizaje. El objetivo de esta operacin
204
es poder visualizar los diferentes caminos del ujo de aprendizaje para un usuario en funcin del rol o roles que desempea en la unidad de aprendizaje.
Despus de crear a los usuarios correspondientes a los roles, el usuario de la interfaz podr visualizar el ujo de aprendizaje asociado a cada uno de los usuarios de la unidad IMS LD (Ver imagen 5.15); y comprobar que las interacciones entre los distintos usuarios siguen la semntica de ejecucin del estndar IMS LD niveles A y B. Por ejemplo, se puede comprobar que un acto no naliza hasta que todos los usuarios hayan nalizado todas las actividades asociadas a las partes de rol pertenecientes al acto o hasta que se haya suspendido denitivamente el acto por parte del usuario de la interfaz (que en ese caso se entiende que est jugando el rol de docente). Para ello se puede seleccionar a un usuario determinado para ejecutar acciones sobre el ujo asociado a dicho usuario.(Ver imagen 5.16)
Figura 5.16: Guin en GTLE-E
5.6.2. Estudio de Caso: Diseo de estrategia Gaviln

Para poner en prctica el sistema generador de AVEA, se introdujo un mtodo o estrategia denominada Modelo Gaviln 2.0, elaborado por EDUTEKA , y se encuentra como parte del Mdulo sobre Competencia para Manejar Informacin (CMI) Bsicamente el gavilan consiste
2
2 http://www.eduteka.org/CMI.php.
205
en un Modelo que ofrece orientacin para resolver efectivamente problemas de informacin, y ayuda al docente a disear y ejecutar actividades de clase conducentes a desarrollar adecuadamente la CMI.
Para lograrlo, se denen cuatro pasos fundamentales( 5.17).
Modelo Gaviln
Figura 5.17: Modelo Gaviln
Cada uno con una serie de subpasos que explicitan las acciones especcas que deben realizar los estudiantes para ejecutarlos de la mejor manera. Los cuatro Pasos del Modelo hacen referencia a procesos fundamentales que estn presentes en cualquier proceso de investigacin, y que, con uno u otro nombre, son comunes a todos los Modelos consultados. Una vez seleccionado el mtodo y evaluado sus pasos, se procede a especicarlo con el modelo conceptual que maneja GTLE-E. Ver gura 5.18:
206
Figura 5.18: Modelo Gaviln en GTLE-E
Luego el diseador elabora el patrn de la estrategia Gavilan en GTLE-E y genera el imsmanifest.xml el cual es el archivo de etiquetado que guarda la estructura del mtodo introducido. Ver apndice B Una vez concluida la exportacin del patrn del modelo gaviln en GTLE-E, se comprob que fuera interoperable y reutilizable validando que el archivo imsmanifest fuera ledo por herramienta de autora que soportara IMS LD. La herramienta seleccionada fue Reload Editor, por ser una de las ms usadas cuando se trata de generar una unidad en IMS LD. Ver gura 5.19:

Entre las concluiones de este captulo se destacan, que los aportes de GTLE-E son fundamentados en el modelo conceptual propuesto en el captulo 2 para un AVEA, que a su vez se basa en el modelo conceptual del IMS LD. Esto permite que el empaquetado que genera sea compatible e interoperable por otras herramientas o entornos que admitan el Learning Design. Esta herramienta de autora consiste en proveer una interfaz que permite hacer transparente para el usuario la compleja adopcin del estndar para representar los diseos pedaggicos.
207
Figura 5.19: Paquete generado por GTLE-E desplegado en Reload Editor
Otra de las bondades se relaciona a la divisin del proceso de diseo de AVEA segn el rol de usuario. En el caso de ser diseador, la herramienta te ofrece los elementos que permiten crear el mtodo o estrategias pedaggicas. Y en el caso de ser docente, la herramienta te provee una instanciacin donde puedes consultar distintos mtodos o estrategias almacenados para se adaptados a la generacin del AVEA nal. El docente personaliza el mtodo creado por el diseador, asocindolo a sus objetivos instruccionales.
En otro orden de ideas, la implementacin de GTLE-E se basa en la arquitectura SOA, y el modelado de sus procesos se realiz con BPM. Esto permiti tener una visin ampliada de los elementos que componen el modelo de un AVEA y como se interrelacionan. Uno de los resultados obtenidos en el caso aplicado en GTLE-E que corresponde al modelo Gaviln, fue con el empaquetado. Este se pudo desplegar en distintas herramientas que soportan IMS LD, por ejemplo, el Reload.
En el dominio de eLearning, especcamente en el caso de los ambientes de enseanza aprendizaje , se puede decir que GTLE-E se convierte en una herramienta innovadora pues articula la arquitectura orientada a servicios y el manejo de procesos con BPM, como solucin en los sistemas generadores de AVEAs basados en la especicacin o estndar de facto IMS
208
LD, que permiten disear mtodos pedaggicos que sirven de guiones en la generacin del ambiente. Esto lo consigue de forma sencilla tanto para el diseador quien elabora el guin, como para el docente, quien utiliza los guiones existentes para utilizarlos en diversos contextos.
Conclusiones
En el desarrollo del presente informe de investigacin fueron presentadas conclusiones parciales referidas a cada captulo realizado. La intencin de este apartado es recoger cada una de estasen atencin a los objetivos planteados:
Para el objetivo principal de proponer un modelo arquitectural para los sistemas generadores de ambientes de enseanza aprendizaje para eLearning basado en patrones pedaggicos para el modelado guiado de procesos educativos, podemos decir que se ha logrado con la propuesta de una arquitectura orientada a servicios con un estilo en capas que permite desglosar los servicios en funcin a la labor a realizar dentro del sistema. Adems se construy un prototipo que permite implementar las distintas funcionalidades de los ambientes de enseanza aprendizaje para eLearning. Este se implement siguiendo el modelado bajo el esquema de BPM. El prototipo realizado es til, ya que demuestra que se puede llevar a la prctica la arquitectura y de esta forma permitir la interoperabilidad y reutilizacin de los AVEAs y sus componentes.
Adicional a lo anterior, en el transcurso de la realizacin de la investigacin, se ha obtenido una serie de conclusiones derivadas de los problemas que han sido solventados en cada etapa. A continuacin se muestra como consecuencia directa de la misma, estas conclusiones: 1. Como ha quedado reejado en el captulo 2, se hizo una revisin del estado del arte sobre el dominio del eLearning, revisando algunos de los modelo asociados a ese contexto. Para luego revisar los estndares asociados. Sobre estos dos aspectos se obtuvo algunos elementos claves que permitieron categorizar los ambientes de enseanza aprendizaje bajo el dominio de eLearning, y la importancia de los estndares para su consolidacin. 209
210

La incorporacin de los estndares al modelado del AVEA, en especco el estndar IMS LD, permiti generarlos con caractersticas de interoperabilidad y reutilizacin. Aparte de establecer marcos comunes de actuacin que permiten aprovechar los avances de los diferentes equipos de investigacin en otros sistemas de caractersticas parecidas. El modelo de AVEA propuesto por estar basado en un estndar (IMS LD), permite asegurar, a travs de su empaquetamiento, pueda ser integrado en cualquier plataforma de eLearning compatible con este estndar.
2. En continuidad con la propuesta del concepto de AVEA y modelo conceptual surgido en el captulo 2, se plantea la necesidad de realizar un anlisis de los AVEAs bajo estndares de calidad. Esto permiti identicar los requerimientos funcionales y no funcionales que este tipo de dominio posee. Con la descripcin de los atributos no funcionales pudimos determinar las caractersticas de calidad que eran relevantes para el modelo. Aqu se presentan nuevamente la necesidad de generar ambientes interoperables, reutilizables, con capacidad de mantenimiento y alta portabilidad. De poco sirve un AVEA con un alto nivel de educativo si slo es accesible por unos cuantos usuarios de una determinada plataforma o repositorio. Los entes del entorno educativo requieren mecanismos de interoperabilidad, en un mundo cada vez ms interconectado y que clama por la colaboracin institucional como mecanismo para garantizar una educacin de calidad. Y la reutilizables por un nmero alto de usuarios, est marcada en la integracin en un sistema capaz de localizarlos y exponerlos a estos usuarios y sistemas. A travs de la arquitectura propuesta se proporciona los mecanismos necesarios para que la incorporacin de esta funcionalidad sea lo menos traumtica posible. De ah se identica que la arquitectura candidata sera la arquitectura orientada a servicio, ya que por su anlisis con modelos de calidad coinciden en las caractersticas que resalta el modelo de los AVEAs.
3. Una vez identicada SOA como arquitectura candidata, se aborda en el captulo 4 una revisin sobre arquitecturas de sistemas de eLearning, donde se comprob que la implantacin de arquitecturas basadas en servicios Web, como la presentada por IAF. De igual forma, se revisaron distintos mtodos y enfoques para aplicar soluciones con SOA, donde se consider la relevancia de incorporar BPM para el modelado del ujo de
211
procesos del sistema a desarrollar. Lo anterior deriv en el diseo de una arquitectura para los AVEAs con inclusin del modelo de capa presentado por IMS IAF, con la adopcin de una arquitectura orientada a servicios (SOA), donde el modelado del proceso se hace siguiendo las reglas de BPM, y la implementacin del SOA siguiendo el enfoque propuesto por Erl. Esto deriva en una arquitectura abierta, escalable, global , integrada y exible, propia del dominio de eLearning.
4. Para nalizar se implement la arquitectura propuesta a travs de un prototipo denominado GTLE-E, el cual permiti demostrar la generacin de ambientes de enseanza aprendizaje para eLearning basado en el estndar IMS LD. Este generador permite crear el ambientes en dos momentos, el primero es el asociado al diseador instruccional, el cual se propone que siga un modelo propuesto por Jones et al (cita) para la generacin de patrones para el modelado del mtodo o estrategia instruccional que tendr el AVEA; y el segundo, est relacionado con el docente, el cual revisa los mtodos propuestos y selecciona el que aplicar como guin en la generacin del AVEA nal. En este punto se aplic SOA para almacenar los AVEA e interoperar el producto generado con otras herramientas de autora para validad su interoperabilidad. En el estudio de casos se aplic sobre GTLE-E el modelo Gaviln de Eduteka. Este modelo fue el primer mtodo validado en GTLE-E, el cual con la funcin de exportacin, gener el paquete que luego se pudo desplegar en el reload editor y reload players, validando as la interoperabilidad. Este ltimo captulo responde a la hiptesis planteada al inicio de la investigacin. Esto deriva a que fue factible la generacin de ambientes de enseanza aprendizaje basados en patrones pedaggicos, los cuales se modelaron siguiendo el estndar IMS LD, y que se valid con la implementacin de un prototipo real que se llev a la prctica con el modelo Gaviln.
A modo de resumen, se destaca la arquitectura planteada en esta investigacin que est basada en SOA conduce a una solucin que emerge para dar solucin al dominio de los ambientes de enseanza aprendizaje para eLearning y plantea soluciones interesantes para la integracin e interoperabilidad de sistemas heterogneos en el dominio de eLearning. Por otro lado, la adopcin de estndares en el mbito de eLearning como el IMS LD para describir los AVEAs, apoya la necesidad de interoperar y reutilizar los recursos del dominio de eLearning.
Publicaciones
En el desarrollo del presente informe de investigacin se realizaron investigaciones parciales que derivaron en articulos presentados en eventos cientcos. A continuacin se presentan:
Pernalete, D, Lpez, M.,(2006)CREACIN DE UN OBJETO DE APRENDIZAJE CENTRADO EN LAS NECESIDADES DEL APRENDIZ. ARTICULOS PUBLICADOS EN ACTAS ARBITRADAS DE MEMORIAS Y CONFERENCIAS.III Simposio Pluridisiplinar Sobre Objetos y Diseos de Aprendizaje Apoyados en la Tecnologa. Oviedo Espaa ISBN: 978-84611-518
Pernalete, D., Lpez, M., Miguel, V., Montao, N.(2007) IMS LEARNING DESIGN Y ARQUITECTURA ORIENTADA A SERVICIOS (SOA) PARA LOS SISTEMAS GENERADORES DE AMBIENTES DE ENSEANZA APRENDIZAJE. LVII Convencion Anual . ISSN: 00015504
Pernalete, D., Lpez, M., Miguel, V., Montao, N.(2007) PROPUESTA ARQUITECTNICA DEL SISTEMA GENERADOR DE AMBIENTES DE ENSEANZA-APRENDIZAJE CONSTRUCTIVISTAS BASADOS EN OBJETOS DE APRENDIZAJE (AMBAR). ARTICULOS PUBLICADOS EN ACTAS ARBITRADAS DE MEMORIAS Y CONFERENCIAS. LACLO 2007 Chile.
Lpez, M., Hernndez, Y., Beleo C., Pernalete, D, Miguel, V., Montao, N.(2008) UN REPOSITORIO BASADO EN SERVICIOS WEB PARA EL SISTEMA GENERADOR DE AMBIENTES DE APRENDIZAJE AMBAR. Actas del V Simposio Pluridisciplinar sobre 212
213
Diseo y Evaluacin de Contenidos Educativos Reutilizables (SPDECE08). Espaa. ISBN: 978-84-7299-81
Pernalete, D., Lpez, M., Miguel, V., Montao, N.(2008) IMS LEARNING DESIGN MODELO ARQUITECTURAL DE AMBAR. CEUR Workshop Proceedings. Volumen 318. ISSN 1613-0073
Pernalete, D., Lpez, M.(2008) BUSSINESS PROCESS MANAGEMENT (BPM) Y IMS - LEARNING DESING (IMSLD) PARA MODELAR AMBIENTES DE ENSEANZA APRENDIZAJE. Universidad 2008. Cuba. Artculos publicados en actas arbitradas de memorias y conferencias. Pginas 30 57. ISBN 9789592820692
Pernalete, D., Delgado, M.(2008) DESARROLLO DE UN OBJETO DE APRENDIZAJE CON UN ENFOQUE DE CALIDAD PARA EL MODELADO DE MQUINAS DE ESTADOS. TERCERA CONFERENCIA LATINOAMERICANA DE TECNOLOGA DE OBJETOS DE APRENDIZAJE LACLO 2008. Pag, 163 -169. ISBN: 978-970-728-067-0
Pernalete, D., , Coello, Y., Cnchica, M (2009), HACIA UN MODELO DE DISEO INSTRUCCIONAL PARA FEDITIC BAJO LA ESPECIFICACIN DEL IMS LEARNING DESIGN IMS LD. Libro: Recursos Digitales para el aprendizaje. EDIC 2009. Paginas. 736746. ISBN 978-607-7573-17-3
Pernalete, D., Coello, Y., Cnchica, M (2009) EL LEARNING OBJECTS Y EL IMS LEARNING DESIGN. RETOS PARA EL DOCENTE INNOVADOR DE LA MODALIDAD SEMIPRESENCIAL ADI UNEFM. Memorias del Primer Congreso Virtual Iberoamericano de Calidad en Educacin a distancia. ISSN: 978-987-24871-8-8
Pernalete, D. , Delgado, M.(2009). DESARROLLO DE UN OBJETO DE APRENDIZAJE CON UN ENFOQUE DE CALIDAD SOBRE RBOLES BINARIOS DE BSQUEDA.
214
Revista Generacin Digital. COLOMBIA Volumen 8 Numero 1. Pgina 5 a 10. ISSN:1909-9223
Pernalete , D., Coello, Y., Cnchica, M , (2012) UN MODELO DE CALIDAD PARA AMBIENTES DE ENSEANZA APRENDIZAJE PARA ELEARNING . Artculo publicado en actas arbitradas de memorias y conferencias. LACLO 2012.
Pernalete , D., Coello, Y., Cnchica, M , (2012)ADOPCIN DE ESTNDARES Y ESPECIFICACIONES DE ELEARNING EN AMBIENTES VIRTUALES DE ENSEANZA APRENDIZAJE (AVEA) DE LA UNEFM. Artculo publicado en actas arbitradas de memorias y conferencias. 1er Congreso Venezolano de Ciencia, Tecnologa e Innovacin en el marco de la Locti y del PEII. Caracas
Bibliografa
[1] Liu, X., Saddik, A., Georganas, N.D.: An implementable architecture of an e-learning system. Electrical and Computer Engineering. IEEE CCECE - Canadian Conference (2003) 717 720
[2] Xu, Z., Yin, Z., Saddik, A.E.: A web services oriented framework for dynamic e-learning systems. Electrical and Computer Engineering. IEEE CCECE - Canadian Conference (2003) 943 946
[3] Rodrguez, J., Anido, L., Fernndez, M.J.: How can the web services paradigm improve the e-learning. Advanced Learning Technologies. The 3rd IEEE International Conference on Proceedings.
ISBN: 0-7695-1967-9 (2003)
[4] Beleo, C.: Tesis capa de servicios de base de datos del sistema generador de ambientes de enseanza aprendizaje ambar (2007)
[5] Hernndez-Leo, D.:
A pattern-based design process for the creation of CSCL macro-
scripts computationally represented with IMS LD. PhD thesis, Universidad de Valladolid Espaa (2007)
[6] Pea, K.: Metodologa para el desarrollo de ambientes virtuales de aprendizaje, bajo el enfoque dialgico interactivo. Master's thesis, Universidad de los ndes. Mrida (2001)
[7] Urdan, T., Weggen, C.: Corporate e-learning: exploring a new frontier (Marzo 2000)
[8] Meyen, E. and, A.R., Gauch, J.and Hinton, H., Isaacson, R., Smith, S., Tee, M.: elearning: A programmatic research construct for the future. Journal of Special Education Technology
17 (2002) 3746
215
216
BIBLIOGRAFA
[9] Khan, B.H.: A Framework for ELearning. Educational Technology Publications. (2001)
[10] Ehlers, U.: Workshop
Quality in e-learning from a learners perspective. 10
Third EDEN Research
0 (2004)
[11] Kols, L., Staupe, A.: The elearning circle a holistic software design tool for elearning. eleed
6 (2010)
23
[12] Donello, J.: Theory and practice: Learning content management systems (2002)
[13] Irlbeck, D., Mowat, J.: Learning content management system (lcms) (2007)
[14] Echeverra, D., Astudillo, H., Estrada, R.: esbs. http://ceur-ws.org
Esb-qm: Modelo de calidad para productos
488 (2008)
14
[15] Erl, T.: Service Oriented Architecture: Concepts, Technology, and Design. Volume ISBN: 0-13-185858-0. Prentice Hall (2005)
[16] Endrei M., Ang J., A.A.e.a.: Patterns: Service oriented Architecture and Web Services. Volume SG24-6303-00. IBM Redbook (2004)
[17] Krafzig, D., Banke, K., Slama, D.: Enterprise SOA, Service Oriented Architecture Best Practices. Volume ISBN 0-13-146575-9. Prentice Hal (2005)
[18] Olivier, B., Tattersall, C.: The Learning Design specication. Volume Chapter 2. Berlin: Springer Verlag (2005)
[19] Hernndez Surez, J.d.J.: Enterate en Linea
Arquitectura de software:importancia de su ciclo de vida. 5
46 (2006)
[20] Sharon, W., Cuauhtmoc, L.: The software architecture process (1997)
[21] F., L., A., M., R., R.: Caracterizacion de aplicaciones web basada en calidad. Conferencia IADIS IberoAmericana
isbn: 972-8924-20-8 (2006)
97
[22] Salazar B., C., Merchn B., C.: Elementos favorables para el diseo de ambientes virtuales de aprendizaje. Memorias Congreso Colombiano de Informtica Educativa Tecnologas de Informacin y Comunicaciones en Educacin
ISSN 0121-0947 (2004) 45 59
BIBLIOGRAFA
[23] Miranda D., G.:
217
De los ambientes virtuales de aprendizaje a las comunidades de
aprendizaje en lnea. Revista Digital Universitaria
volumen 5 numero 10 ISSN: 1067-
6079 (2004)
15
[24] Mendoza Rodrguez, J., B., Martnez Sebastin, Y., Milachay Vicente, M., Cano-Villalba, A., Gras-Mart: Uso de las tic en la formacin inicial y permanente del profesorado.
Didctica de las Ciencias Experimentales y Sociales 150
18 ISSN: 0214-4379 (2005) 121
[25] Koper, R.:
From change to renewal educational technology foundations of electronic
learning environments (2000)
[26] Jonassen,
D.,
Peck,
K.,
Wilson,
B.:
Learning
with
technology:
constructivist
perspective. Merrill Prentice Hall (1999)
[27] Burgos, D., Tattersall, C., Koper, R.: Utilizacin de estndares en el aprendizaje virtual: Funcionalidades didcticas de la especicacin ims learning design (2005)
[28] Murray, T., Blessing, S., Ainsworth, S.: Authoring tools for advanced technology learning enviroments. Toward cost-eective adaptive, interactive and intelligent educacional
software. Kluwer Academic Publishers (2003)
[29] Pernalete, D., Lpez, M.: Business Process Management (BPM) y IMS Learning Desing (IMS LD) para modelar Ambientes de Enseanza Aprendizaje. Volume isbn: 959161165X. Editorial Universitaria (2008)
[30] Melenovsky, M.J., Sinur, J., Hill, J.B., McCoy, D.W.:
Business process management:
Preparing for the process-managed organization. Gartner
0 (junio 2005)
[31] Dougiamas, M.: Moodle (2004)
[32] Pernalete, D., Lopez, M.G., Miguel, V., Montao, N.: Ims learning design y el modelo arquitectural de ambar. IV Simposio Pluridisciplinar sobre Diseo, Evaluacin y
Desarrollo de Contenidos Educativos Reutilizables (SPDECE)
318 (2007)
11
[33] Lpez, M.G., Miguel, V., Montao, N.: Sistema generador de ambientes de enseanzaaprendizaje constructivistas basados en objetos de aprendizaje (ambar). II Simposio
218
BIBLIOGRAFA
Pluridisciplinar sobre Diseo, Evaluacin y Descripcin 10 de Contenidos Educativos
Reutilizables (SPDECE)
ISSN 1578-7680 (2005)
[34] Burgos, D.: Estudio de la estructura y del comportamiento de las comunidades virtuales de aprendizaje no formal sobre estandarizacin del e-learning. (abril 2006)
[35] Pernalete, D., Lopez, M.G., Miguel, V., Montao, N.:
Propuesta arquitectnica del
sistema generador de ambientes de enseanza-aprendizaje constructivistas basados en objetos de aprendizaje (ambar). Conferencia Latinoamericana de Objetos de Aprendizaje (LACLO)
0 (2007)
10
[36] Montao, N., Miguel, V., Lpez, M., eds.: Ontologa del Dominio del Sistema Generador de Ambientes de Enseanza Aprendizaje Constructivistas Basados en Objetos de
Aprendizaje (AMBAR), III Simposio pluridisciplinar sobre objetos de aprendizaje y diseos de aprendizaje (2006)
[37] Marcos, E., Marcos, A.:
An Aristotelian Approach to the Methodological Research: a
Method for Data Models Construction. Mc Graw-Hill (1998)
[38] Avison, D., Lan, F., Myers, M., Nielsen, A.: ACM
Action research.
Communications of the
42 (1999) 9497
[39] Bunge, M.: La Investigacin Cientca. Ariel S.A. Barcelona. (1976)
[40] McTaggart, R.: Principles of participatory action research. Adult Education Quarterly SPRING
volumen 48 numero 3 (1999) 168 187
[41] French, W., Bell, C.J.: Desarrollo organizacional (quinta edicin). Prentice-Hall (1996)
[42] Wadswroth, Y.: What is participatory action research? (1998)
[43] Losavio, F., Ortega, d., Prez, m.: Modeling eai. Proceedings of the XXII International Conference of the Chilean Computer Science Society (SCCC 2002)
IEEE Computer
Society Press (2002) 195203

[44] Yin, R.: Case Study Research Design and Methods. Volume 5. Sage Publications (2003)
BIBLIOGRAFA
[45] McLean, N.: Versailles Towards global e-learning standards for interoperability. 4
219
Symposium de
0 (2003)
[46] Rosenberg, M.: eLearning: Strategies for Delivering Knowledge in the Digital Age. Volume ISBN-13: 978-0071362689. McGraw-Hill (2001)
[47] Greenberg, L.:
Lms and lcms: Whats the dierence?
Learning circuitsASTDs online
magazine (Diciembre 2002)
[48] Jacobsen, P.: Lms vs. lcms: take advantage of the dierences to save time and money. Gale Group, Farmington Hills, Michigan (junio 2002)
[49] Research., B.H.: Lms and lcms demystied (2007)
[50] Sharma, S., Kitchens, F.: Web services model for mobile, distance and distributed learning using service-oriented architecture. International Journal of Mobile Communications
Issue 2 (2006) 178192

[51] Fallon, C., Brown, S.: eLearning Standards: A Guide to Purchasing, Developing, and
Deploying Standards Conformant ELearning. Volume ISBN 1574443453, 9781574443455. st. lucie press (2003)
[52] Sancho, P.:
Lenguajes de marcado y su aplicacin en el dominio de las tecnologas de
aprendizaje web". revisin de las principales iniciativas de estandarizacin (2002)
[53] Masie, E.: Making sense of learning specications & standards: A decision maker's guide to their adoption (2002)
[54] Fernndez Manjn, B., Moreno Ger, P., Sierra Rodrguez, J., Martnez Ortz, I.: Uso de estndares aplicados a tic en educacin. Madrid: CNICE 187
Serie Informes n. 16 (2006)
[55] Foix, C. y Zavando, S.: Estndares de elearning: estado del arte. Centro de Tecnologas de la Informacin, INTEC (2002)
[56] Gibson, C., Harlow, S.: Elearning standards overview: prepared for use with the elearnz toolbox. The NZ consortium for e-learning (Marzo 2004)
220
BIBLIOGRAFA
[57] Marshall, S.: E-learning standards: Open enablers of learning or compliance straitjackets? ASCILITE - Proceedings Contents (2004)
[58] Pawlowski, J.: Habilitation: Quality in education and training: Reference models and the integration of working and learning. Global Information Systems (2008)
[59] Daz-Antn, G., Surez, A., Tahhan, E., Gonzlez, D.:
Estndares y especicaciones:
estudio preliminar sobre su adopcin en el desarrollo de cursos en lnea en la usb. V Simposio Pluridisciplinar sobre Dise o y Evaluacin de Contenidos Educativos Reutilizables (Septiembre 2007)
[60] Munro, M., Kenny, C.: standards for learning objects and learning designs. Handbook of research on learning design and learning objects: issues, applications and technologies. Hershey (Pennsylvania), Dublin City University, Ireland (2008)
[61] Rehak R., D.:
Elearning standards: Questions, decisions, actions.
Carnegie Mellon
University (2003)
[62] Hodgins, W.: Ieee ltsc learning technology standards committee p1484. ADLNET, USA, (2001)
[63] Otn, S.:
Propuesta de una Arquitectura Software Basada en Servicios para la PhD thesis,
Implementacin de Repositorios de Objetos de Aprendizaje Distribudos. Universidad de Alcal. (2006)
[64] Duart, J.M.: Aprender sin distancias. UOC Universidad Oberta de Catalua (2002)
[65] Mestre, G., Fonseca, P., Valds, T.: Entornos virtuales de enseanza aprendizaje. Editorial Universitaria
ISBN 978-959-16-0637-2 (2007)
78
[66] Ramirez, C.: (2009)
La modalidad blended-learning en la educacin superior".
utemvirtual
[67] Rayn, A., Escalera, S., Ledesma, R.: Ambientes virtuales de aprendizaje. Presimposio Virtual SOMECE (2002)
BIBLIOGRAFA
221
[68] Loaiza, R., Arvalo, M.: Metodologaa para la implementacin de proyectos de elearning. Unimet (2004)
[69] Muoz A., E.L., Muoz A., J.:
Interactividad en ambientes virtuales de aprendizaje:
Caractersticas. Centro de Ciencias Bsicas, Universidad Autnoma de Aguascalientes
[70] Malagn,
J.M.y.Y.F.:
Modelo
de
intervencin
didctica
en
entornos
virtuales
de
aprendizaje. Virtual- educa (2008)
[71] Reigeluth, C.:
The elaboration theory Guidance for scope and sequence decisions.
Lawrence Erlbaum Associates (1999)
[72] Griths, D., Blat, J., Garcia, R., Vogten, H., Kwong, K.: Learning Design Tools. SpringerVerlag (2005)
[73] Barbacci, M., Klein, M., Weinstock, C.: Principles for evaluating the quality attributes of a software architecture. CMU/SEI-96-TR-036 (1997)
[74] Fenton, N., Peeger, S.:
Software metrics. A rigurous and practical approach.
Course
Technology; 2 edition (1997)
[75] Kapp, K.: Five technological considerations when choosing an elearning solution. eLearn Magazine
ACM, 7 (2003)
10
[76] Ltd, V.: Qualitative evaluation systems of e-learning. Leonardo da Vinci WBT WORLD, RO/02/B/F/PP 141053 (2005)
[77] Stracke,
C.,
Hildebrandt,
B.:
Quality
development
and
quality
standards
in
e-
learning: Adoption, implementation, and adaptation. World Conference on Educational Multimedia, Hypermedia and Telecommunication (2007)
[78] Forth, S., Childs, E.: White paper on e-learning speci cations and standards. Recombo Inc., ITS Inc. (2003)
[79] Pressman, R.: Ingeniera de software. Un Enfoque prctico. McGraw Hil (2002)
[80] E., P.D., L., W.A.: Foundations for the study of software architecture. ACM Software Engineering Notes
17 (1992) 4052
222
BIBLIOGRAFA
[81] Shaw, M., Garlan, D.: Software Architecture. Perspectives of an Emerging. Volume ISBN: 0131829572, 9780131829572. Universidad de Michigan (1996)
[82] Bass, L., Clements, P., Kazman, R.:
Software architecture in practice. Volume ISBN:
0201199300, 9780201199307. Universidad de Michigan (1998)
[83] Fielding,
R.T.:
Architectural
styles
and
the
design
of
network-based
software
architectures. Universidad de California (2000)
[84] Josuttis, N.M.: SOA in practice. O'Reilly Media (2007)
[85] Chappell, D.: Theory in Practice: Enterprise Service Bus. OReilly Media (2004)
[86] Keen, M., Acharya, A., Bishop, S., Hopkins, A., Milinski, S., Nott, C., Robinson, R., Adams, J., Verschueren, P.: Patterns: Implementing an SOA Using an Enterprise Service Bus. ibm.com/redbooks (2004)
[87] Group, P.S.:
Enterprise service bus - evaluation framework, criteria for selecting an
enterprise service bus as an integration backbone (2005)
[88] Vollmer, K.: The forrester wave: Enterprise service bus (Abril 2011)
[89] Vojislav, M., D., Inessa, L.: Business environment and the incorporation decision (Mayo 2004)
[90] O'Brien, L., Smith, D., Lewis, G.: architecture reconstruction.
Supporting migration to services using software
STEP '05 Proceedings of the 13th IEEE International
Workshop on Software Technology and Engineering Practice (2005) ISBN:0-7695-2639-X.
[91] Zimmermann, O., Krogdahl, P., Gee, C.: Elements of service-oriented analysis and design, an interdisciplinary modeling approach for soa projects. Ibm (Junio 2004)
[92] Arsanjani, A.: Service oriented modeling and architecture, how to identify, specify, and realize services for your soa. IBM (Noviembre 2004)
[93] Smith, H., Fingar, P.:
Business Process Management: The third wave. Volume ISBN:
0-920-65233-9. Meghan-Kieer Press (2003)
BIBLIOGRAFA
[94] Owen, M., Raj, J.:
223
Bpmn and business process management, introduction to the new
business process modeling standard. Popkin Software (2003)
[95] Jones, D., Stewart, S.:
Patterns: using proven experience to develop online learning.
Proceedings of ASCILITE 1999
Apndice A
Base de datos de GTLE-E En este documento se muestran el modelo de diagrama de Entidad Relacin del sistema que denen la arquitectura esttica de un modelo. Se utilizan para modelar las relaciones y las dependencias entre los elementos. gura 20
Figura 20: Modelo de Base de Datos de GTLE-E
224
Apndice B
Archivo maniesto generado por GTLE-E
<?xml v e r s i o n ="1.0" e n c o d i n g ="UTF 8"?><! C o d i g o desarrollado p a r a GTLEE 2012. >
<m a n i f e s t
x m l n s=" h t t p : / /www . i m s g l o b a l . o r g / x s d / imscp_v1p1 " x m l n s : x s i=
x m l n s : i m s l d =" h t t p : / /www . i m s g l o b a l . o r g / x s d / i m s l d _ v 1 p 0 " " h t t p : / /www . w3 . o r g / 2 0 0 1 /XMLSchema i n s t a n c e " " h t t p : / /www . i m s g l o b a l . o r g / x s d / imscp_v1p1 h t t p : / /www . i m s g l o b a l . o r g / x s d / i m s l d _ v 1 p 0 h t t p : / /www . i m s g l o b a l . o r g / x s d /IMS_LD_Level_C . x s d " <o r g a n i z a t i o n s > R e g i s t r o <i m s l d : l e a r n e r " exclusively i d e n t i f i e r =" r o l e i d e n t i f i e r ="l d 5" Ejemplo l e v e l ="C"
x s i : s c h e m a L o c a t i o n=
h t t p : / /www . i m s g l o b a l . o r g / x s d / imscp_v1p1 . x s d
i d e n t i f i e r =" m a n i f e s t 5">
s e q u e n c e u s e d=" f a l s e "
v e r s i o n ="1.0" >
1
1"
c r e a t e new="n o t a l l o w e d "
h r e f =" a l g o "
match p e r s o n s=
i n r o l e s "
min p e r s o n s ="1" max p e r s o n s ="1">
D o c e n t e 
i d e n t i f i e r ="i t e m i d i n f o r o l p a r a m e t e r s ="uno "
10" 1">
i s v i s i b l e =" f a l s e "
i d e n t i f i e r r e f =" r e s o u r c e
r o l _ d e t a l l e s 1 
i s v i s i b l e =" t r u e "
r o l _ d e t a l l e s 2 
i n v e s t i g a d o r 
225
226
APNDICE B
r o l _ d e t a l l e s 3 
r o l _ d e t a l l e s 4 <i m s l d : s t a f f i d e n t i f i e r =" r o l e
3"
h r e f ="n i n g u n o "
min p e r s o n s ="2" max p e r s o n s ="2"
c r e a t e new=" a l l o w e d "
match p e r s o n s ="Not
E x c l u s i v e l y ">
s e c r e t a r i o 
r o l _ d e t a l l e s 5 
r o l _ d e t a l l e s 6 e j e m p l o 1
d a t a t y p e =" d a t e t i m e " /> initial
v a l u e >16041980
restriction >
12 12 2012 e j e m p l o 2
d a t a t y p e =" u r i " /> g o o g l e . comh t t p : / /www .
restriction
v a l u e >
restriction >
t y p e =" t o t a l D i g i t s ">25 e j e m p l o 
3
d a t a t y p e =" s t r i n g " /> initial
v a l u e >chune 
restriction >
t y p e =" m i n E x c l u s i v e ">1 
227
e j e m p l o 
d a t a t y p e =" t e x t " /> initial
v a l u e >a l g o 
 
e j e m p l o 
r e f =" r o l e
2"
/>
d a t a t y p e =" i n t e g e r " /> initial
v a l u e >12
restriction >
2.5 
i d e n t i f i e r ="p ro p 10">
p r o p e r t y
e j e m p l o 
r e f =" r o l e
3"
/>
d a t a t y p e =" r e a l " /> initial
v a l u e >3.14 
restriction >
100
i d e n t i f i e r ="p ro p 12"> u r i ="NA">
e j e m p l o 
v a l u e >8000
restriction >
t y p e =" m i n I n c l u s i v e ">23 u r i ="111111" >
e j e m p l o 
d a t a t y p e =" b o o l e a n " /> initial
v a l u e >t r u e 
restriction >
t y p e =" m i n E x c l u s i v e ">12 e j e m p l o u r i ="34">
10
d a t a t y p e =" i n t e g e r " /> initial
v a l u e >12
restriction > restriction >
12 
228
APNDICE B
e j e m p l o u r i ="12">
9
v a l u e >12
 
 GRUPO 01 r e f ="pr o p 6" /> r e f ="pr o p 9" /> r e f ="pr o p 12" /> r e f ="pr o p 14" />
 a c t i v i d a d i d e n t i f i e r =" l a
1"
p a r a m e t e r s ="nada">
1
 
o b j _ a c t i v i d a d 7 
o b j _ a c t i v i d a d 8 
p r e _ a c t i v i d a d 9 
p r e _ a c t i v i d a d 1 0 1"
i d e n t i f i e r ="i t e m i d d e s a c t
p a r a m e t e r s =" NO"
11">
d e s c r i _ a c t i v i d a d 1 1 
229
 
d e s c r i _ a c t i v i d a d 1 2 
 
f e e d _ a c t i v i d a d 1 3 
f e e d _ a c t i v i d a d 1 4 r e f ="env 2" />
 a c t i v i d a d i d e n t i f i e r =" l a
2"
p a r a m e t e r s ="no">
2
 
 SOPORTE 1 

d e s c r i p t i o n > 5"
i d e n t i f i e r ="i t e m i d d e s a c t
p a r a m e t e r s ="K"
15">
d e s c r i _ a c t i v i d a d 1 5 
d e s c r i _ a c t i v i d a d 1 6 
 
d e s c r i _ a c t i v i d a d 1 7 
230
APNDICE B
 
d e s c r i _ a c t i v i d a d 1 8 
 SOPORTE 2 
s t r u c t u r e t y p e =" s e q u e n c e "
 NUEVA ESTRUCTURA 
i n f o _ e s t r u c t u r a 1 9 
i n f o _ e s t r u c t u r a 2 0 <i m s l d : u n i t o f l e a r n i n g h r e f <i m s l d : l e a r n i n g a c t i v i t y <i m s l d : s u p p o r t a c t i v i t y r e f =" l a
r e f
1"
/>
r e f
r e f ="s a 4" />
r e f ="env 1" /> r e f ="env 2" />
s t r u c t u r e >
i d e n t i f i e r ="a s 2" numbert o s e l e c t ="12" s o r t =" v i s i b i l i t y
s t r u c t u r e
s t r u c t u r e t y p e =" s e l e c t i o n "
o r d e r ">
 SEGUNDA 
s t r u c t u r e >
 de Prueba 01
E n t o r n o

batman 
 c l a s s ="77777"
i s v i s i b l e =" f a l s e " 
e j e m p l o 
i d e n t i f i e r =" s e r v i c e i d e m a i l p a r a m e t e r s =" s i n
1"
c l a s s =" s i n
clase "
i s v i s i b l e =" t r u e " 
s e l e c t =" p e r s o n s i n r o l e ">
p r u e b a 
r e f =" r o l e
1"
/>
 
r e f =" r o l e
2"
/>
 c o n f e r e n c e t y p e ="an n o u nc e m en t"> de c o n f e r o l e r e f =" r o l e
1"
c l a s s ="no "
i s v i s i b l e =" f a l s e " e j e m p l o

r o l e r e f =" r o l e r o l e r e f =" r o l e
1"
/>
1"
/>
 /> i d e n t i f i e r r e f =" r e s o u r c e
i d e n t i f i e r ="i t e m i d f i l e p a r a m e t e r s ="na">
3"
22"
c a r r o 
batman
 c l a s s ="1"
 b u s q u e d a 1 e n v i r o n m e n t 1
232
APNDICE B
s e n d m a i l m o n i t o r s u p p o r t a c t i v i t y <i m s l d : i n d e x e l e m e n t <i m s l d : i n d e x e l e m e n t <i m s l d : i n d e x e l e m e n t i n d e x =" l a
1"
/>
i n d e x ="s a 4" /> i n d e x ="a s 1" /> i n d e x ="a s 2" /> i n d e x ="env 1" /> i n d e x ="env 2" /> i n d e x ="env 3" />
 de Prueba 02
E n t o r n o 
 
 GUION DE EJEMPLO 01 1 de p r u e b a s 
a c t o 
nuevo h r e f ="a " />
 
f e e d _ a c t o 2 3 
f e e d _ a c t o 2 4 
233
 2 de p r u e b a s 
a c t o 
aa h r e f ="a " />
 
f e e d _ g u i o n 2 5 </ o r g a n i z a t i o n s > <r e s o u r c e s > <r e s o u r c e i d e n t i f i e r =" r e s o u r c e
1"
t y p e ="w e b c o n t e n t "
h r e f =" r o l _ d e t a l l e s 1 . t x t "> <f i l e h r e f =" r o l _ d e t a l l e s 1 . t x t " />
</ r e s o u r c e > <r e s o u r c e i d e n t i f i e r =" r e s o u r c e
2"
3"
4"
5"
6"
h r e f =" r o l _ d e t a l l e s 6 . t x t ">
234
APNDICE B
<f i l e
h r e f =" r o l _ d e t a l l e s 6 . t x t " />
7"
h r e f =" o b j _ a c t i v i d a d 7 . t x t "> <f i l e h r e f =" o b j _ a c t i v i d a d 7 . t x t " />
8"
h r e f =" o b j _ a c t i v i d a d 8 . t x t "> <f i l e h r e f =" o b j _ a c t i v i d a d 8 . t x t " />
9"
h r e f =" p r e _ a c t i v i d a d 9 . t x t "> <f i l e h r e f =" p r e _ a c t i v i d a d 9 . t x t " />
10"
h r e f =" p r e _ a c t i v i d a d 1 0 . t x t "> <f i l e h r e f =" p r e _ a c t i v i d a d 1 0 . t x t " />
11"
h r e f =" d e s c r i _ a c t i v i d a d 1 1 . t x t "> <f i l e h r e f =" d e s c r i _ a c t i v i d a d 1 1 . t x t " />
12"
13"
h r e f =" f e e d _ a c t i v i d a d 1 3 . t x t "> <f i l e h r e f =" f e e d _ a c t i v i d a d 1 3 . t x t " />
14"
15"
16"
17"
235
18"
19"
h r e f =" i n f o _ e s t r u c t u r a 1 9 . t x t "> <f i l e h r e f =" i n f o _ e s t r u c t u r a 1 9 . t x t " />
20"
h r e f =" i n f o _ e s t r u c t u r a 2 0 . t x t "> <f i l e h r e f =" i n f o _ e s t r u c t u r a 2 0 . t x t " />
21"
h r e f ="841766 _carro_batman . j p g "> <f i l e h r e f ="841766 _carro_batman . j p g " />
22"
h r e f ="f 4 1 b 3 a _ c a r r o _ b a t m a n 2 0 1 2 . j p g "> <f i l e h r e f ="f 4 1 b 3 a _ c a r r o _ b a t m a n 2 0 1 2 . j p g " />
23"
h r e f =" f e e d _ a c t o 2 3 . t x t "> <f i l e h r e f =" f e e d _ a c t o 2 3 . t x t " />
24"
h r e f =" f e e d _ a c t o 2 4 . t x t "> <f i l e h r e f =" f e e d _ a c t o 2 4 . t x t " />
25"
h r e f =" f e e d _ g u i o n 2 5 . t x t "> <f i l e h r e f =" f e e d _ g u i o n 2 5 . t x t " />
</ r e s o u r c e > </ r e s o u r c e s > </ m a n i f e s t >
Apndice C
Plataforma Tecnlogica En este apndice se describe la plataforma tecnolgica que soportar la aplicacin, como su nombre lo indica una plataforma es precisamente el principio, ya sea de hardware o de software, sobre el cual un programa puede ejecutarse abarcando desde la tecnologa de desarrollo hasta la arquitectura de software que se va a implementar. Una de las ventajas principales de la arquitectura del sistema que se implement es que permite a los programas escritos en diferentes lenguajes sobre diferentes plataformas comunicarse entre s de una forma basada en estndares, hacindolo ms escalable e interoperable. Dependiendo de la funcionalidad, SOA tiene un vocabulario asociado. Adems existen distanta posibilidad de implementarla. A continuacin se muestra el volabulario y posibilidades de implementacin:
Para los Servicios Web los Principales Vocabularios:
Protocolo de transporte:
HTTP/HTTPs (principalmente)
Codicacin de datos y mensajes: Descripcin del servicio:
SOAP (Simple Object Access Protocol)
WSDL (Web Service Description Language)
Bsqueda y localizacin de servicios:
UDDI (Universal Discovery, Description and Integration)
Para la Implementacin de Servicios Web existen distintas posibilidades

Java( APIs de Sun: JAXRPC, JAXM, SAAJ, Libreras de Apache: Axis) Microsoft .NET
ASP.NET para C, VBasic, etc.
MS SOAP Toolkit
Otros: SOAP Lite (Perl), NuSOAP (PHP), Axis (C++).
Dada la descripcin anterior, en esta seccin se explica brevemente la plataforma tecnolgica seleccionada para la construccin de GTLE-E. A continuacin se describen las seleccionadas:
Java Server Pages (JSP): es una tecnologa Java que permite generar contenido dinmico para Web, en forma de documentos HTML, XML o de otro tipo que est basada en la tecnologa de Servlets. Permiten la utilizacin de cdigo Java mediante scripts. Tambin se puede utilizar algunas acciones JSP predenidas mediante etiquetas, las cuales pueden ser enriquecidas mediante el uso de Libreras de Etiquetas (TagLibs o Tag Libraries, por sus siglas en ingls) externas e incluso personalizadas.
236
237
Java Servlets: son objetos que corren dentro del contexto de un contenedor de Servlets, es decir, es un programa que se ejecuta en un servidor y extienden su funcionalidad. Tambin podran correr dentro de un servidor de aplicaciones que adems de contenedor para Servlet tendr contenedor para objetos ms avanzados como son los EJB.
Lenguaje de programacin JavaScript: es un lenguaje interpretado, es decir, que no requiere compilacin, es utilizado principalmente en pginas Web con una sintaxis semejante a la del lenguaje Java y el lenguaje C.
PHP: acrnimo de PHP: Hypertext Preprocessor. Es un lenguaje de cdigo abierto muy popular especialmente adecuado para desarrollo web y que puede ser incrustado en HTML. El desarrollo de PHP est centrado en programacin de scripts en lado-servidor, sin embargo, en este desarrollo fue utilizado para implementar servicios Web que fueron implementados en WSDL SOAP. En este sentido, WSDL (Web Services Description Language) es una especicacin del W3C para la comunicacin entre un cliente y un servidor a travs del protocolo HTTP. Al utilizar HTTP, un cliente conectado a Internet puede acceder a los servicios ofrecidos por servidores internet, de la misma manera que un navegador se conecta a un servidor web para solicitar una pgina. Para solicitar el servicio, el cliente enva un mensaje de solicitud en formato SOAP XML. La especicacin SOAP (Simple Object Access Protocol) establece la manera de representar, en el interior de la solicitud, el tipo de solicitud y los nombres y valores de sus argumentos. El servidor realiza la operacin solicitada, y le entrega al cliente un mensaje de respuesta que tambin est en formato SOAP XML. El mensaje de respuesta contiene los datos solicitados, y un status que indica si la solicitud se ha procesado correctamente o bien se ha producido algn tipo de error.
Kit de desarrollo Java (J2ee SDK): es un paquete que incluye el API de Java, el compilador de Java y lo que permite a Java funcionar en el computador: el JRE (Java Runtime Enviroment). Java es un lenguaje orientado a objetos, independiente de la plataforma en la que se vaya a ejecutar, es decir, que un programa de Java se puede ejecutar en cualquier mquina o plataforma.
Servidor Apache Tomcat: es un servidor Web con soporte de servlets y JSPs. Incluye el compilador Jasper, que compila JSPs convirtindolas en servlets.
Axis: Apache Axis es una implementacin OpenSource de SOAP (("Simple Object Access Protocol")) que proporciona un entorno de ejecucin para Servicios Web implementados en Java.
Sistema Manejador de Base de Datos MySQL: es un sistema de gestin de bases de datos relacional, multihilo y multiusuario con ms de seis millones de instalaciones. Se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en productos privativos deben comprar a la empresa una licencia especca que les permita este uso. Est desarrollado en su mayor parte en ANSI C.
NuSOAP: es un kit de herramientas (ToolKit) para desarrollar Web Services bajo el lenguaje PHP. Est compuesto por una serie de clases que nos harn mucho ms fcil el desarrollo de Web Services. Provee soporte para el desarrollo de clientes (aquellos que consumen los Web Services) y de servidores (aquellos que los proveen). NuSOAP est basado en SOAP 1.1, WSDL 1.1 y HTTP 1.0/1.1
JCreator: IDE para programacin en lenguaje Java en entorno Windows.
Dreamweaver: es un editor WYSIWYG de pginas web.
Instalacin y aplicacin del Software: proceso llevado a cabo para instalar y congurar las herramientas utilizadas para el desarrollo de la capa de servicios de base de datos de GTLE-E
238
APNDICE C
Kit de desarrollo Java (J2ee SDK)

Descargar jsdk 1.4.2 e instalar de la pgina web de sun (http://developers.sun.com/downloads/), luego se debe aadir la
variable de entorno JAVAH OM Ealsistema, cuyovalorsereldirectoriodondesehainstaladoeljdk.P arahacerestosedebenconf igurarlasvariablesd JAVAH OM E , conelvalordelarutadondesehainstaladoeljdk (porejemplo, C
: 1,4.,2).CLASSP AT H , conelvalordelasrutasdetodoslos
2sdk1,4,21 2.jar).
Instalar los Kits de Desarrollo de Servlets y JSP

Descargar el software que implementa las especicaciones Java Servlet 2.1 o 2.2 y Java Server Pages 1.0 1.1. de la pgina web de sun (http://java.sun.com/products/servlet/). Luego, indicar al javac dnde encontrar las clases Servlets y JSP cuando se compile el archivo. Esto se hace aadiendo al CLASSPATH las rutas de todos los .jar (por ejemplo, C:C: servlet.jar; C:.jar;. . . ).
Servidor Apache Tomcat

Decargar e instalar el binario de tomcat en formato exe de la pgina web del grupo Jakarta (http://jakarta.apache.org/).
Luego se debe aadir una nueva variable de entorno TOMCATH OM Ealsistemacuyovalorserlarutadeldirectoriodondesehainstaladoelto
Axis
Descargar la versin binaria de axis de la pgina web (http://ws.apache.org/axis/), descomprimir el archivo y
copiar el directorio de axis en el directorio de TOMCAT/webapps/, quedando un directorio de la siguiente manera: TOMCAT/webapps/axis. Luego se deben congurar las variables de entorno, aadiendo las siguientes variables al sistema:
1. AXISH OM E, conelvalordelarutadondesehacopiadoelaxis.AXISL IB, conelsiguientevalor/AXISH OM E/
2. AXISCLASSPATH, con el valor de todos los jar necesarios para su ejecucin
APIs adicionales Descargar los APIs Commons-leupload-1.2, commons-io-1.3.1 y JAX-RPC, colocarlos en el directorio
lib de la aplicacin y aadirlos al CLASSPATH.
Sistema Manejador de Base de Datos MySQL operada desde PHPmyadmin phpMyAdmin es una herramienta
escrita en PHP con la intencin de manejar la administracin de MySQL a travs de pginas web, utilizando Internet. Actualmente puede crear y eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar, editar y aadir campos, ejecutar cualquier sentencia SQL, administrar claves en campos, administrar privilegios, exportar datos en varios formatos y est disponible en 62 idiomas. Se encuentra disponible bajo la licencia GPL. Para visualizar los elementos que se encuentran almacenados en la BD, es necesario el archivo donde se cre la base de datos (por ejemplo: BDGtlee.yap) el cual contiene los elemntos almacenados en la base de datos de GTLE-E. Finalmente para ejecutar la aplicacin es necesario copiar el directorio de la aplicacin en el directorio de TOMCAT/webapps/, quedando un directorio de la siguiente manera: TOMCAT/webapps/aplicacin copiar los servicios en el directorio de TOMCAT/webapps/axis para ser publicados.
Codicacin de los Servicios Web de base de datos de GTLE-E

Los Servicios Web implementados se realizaron conforme al orden siguiente:
Se integr Axis con el servidor de aplicaciones (Tomcat), esto es, copiando el archivo completo del axis en
TOMCATH OM E/webapps/axis.SecreelServicioW eb, desarrolladounaclaseenjavaconlalgicaylosmtodosquesedeseanparaelser
Se activ el Servicio Web, se hace con la nalidad de que pueda ser invocado desde otra aplicacin. Para desplegar el servicio es necesario renombrar el archivo de la clase denida xxx.java a xxx.jws, se copia en el directorio de axis creado anteriormente. De esta manera al invocar el servicio por primera vez se compilar automticamente.
239
Se estableci su descriptor de despliegue (wsdd) y se ejecuta el comando java org.apache.axis.client.AdminClient xxx.wsdd.
Se cre el cliente utilizando un Proxy generado con Axis (wsdl), se hace ejecutando el siguiente comando: java org.apache.axis.wsdl.Java2WSDL, -o xxx.wsdl, -l http://localhost:8080/axis/services/xxx, -p xxx.class.
luego
se
ejecuta
el
comando
java
org.apache.axiswsdl.WSDL2Java
xxx.wsdl.
De
esta
forma
se
Axis
genera
automticamente las clases de java que funcionan como Proxy para que las diferentes aplicaciones puedan utilizar los mtodos expuestos por los Servicios Web.
Por ltimo se crea el cliente que invoca los Servicios Web. En este caso, el cliente corresponde a la Aplicacin Web de prueba implementada para probar los Servicios Web creados. Esta aplicacin invoca los servicios por medio de los Servlets denidos en la capa de la lgica de negocio.
El archivo wsdl generado en el paso 5 contiene una descripcin total del Servicio Web desplegado. Bsicamente se divide en 5 partes fundamentales:
Lo que hace el servicio, est formado por tres elementos: types, message, portType binding y service. Esto dene el mensaje y los tipos de datos intercambiados entre el cliente y el servidor.
Los types representan los tipos de datos que recibe el formulario.
El message es el elemento de comunicacin bsico de SOAP que puede constar de una o ms partes, en donde cada parte representa un parmetro con tipo. .portType una entidad donde los mensajes se agrupan en operaciones. Representa la interfaz del Servicio Web.
binding: describe los detalles de la implementacin tcnica del Servicio Web. Un binding une un portType a un protocolo de comunicacin (para el caso de los Servicios Web de base de datos de GTLE-E, SOAP sobre HTTP).
service: coloca juntos el porttype, el binding, y la localizacin real (una URI) del Servicio Web. Chequea el elemento service al nal del documento wsdl.
El archivo wsdl generado describe completamente al Servicio Web, proporcionando toda la informacin necesaria para crear una aplicacin cliente que pueda acceder al Servicio Web creado.
Es importante destacar que varias aplicaciones se desarrollaron utilizando nusoap, para ejecutar desde PHP los servicios.
Apndice D
Servicios Web de gestin de sesin y de ejecucin
Servicio 1
Ttulo Actor Descripcin
Inicializar el sistema
Administrador Permite el arranque del sistema mediante la creacin de la cuenta de usuario administrador y con esto, la activacin de las dems opciones del sistema
Precondiciones
Ninguna Si no se completan los campos solicitados el servicio lanzar una
Excepciones
excepcin indicndolo Si la informacin de campos especiales (correo y contrasea) no cumplen con los requerimientos, el servicio lanzar una excepcin indicndolo Si se produce una falla con la conexin al servidor o a la base de datos, el servicio lanzar una excepcin indicndolo Archivos: buscar_datos.php
Firma de Servicio
Campos: id_usu, ced_usu, nom_usu, ape_usu, nivel_usu, correo_usu, telef_movil, nick_usu, clave_usu, pregunta, respuesta Funciones: incluir_administrador($tabla, $campos, $valores)
Servicio 2
Iniciar sesin de usuario

Administrador, diseador y docente Permite el acceso al panel de opciones correspondientes a cada perl de usuario segn los parmetros de seguridad preestablecidos
Precondiciones Excepciones
Inicializacin del sistema y generacin de cuenta de usuario Si el usuario y contrasea no se corresponden con lo almacenado en el sistema, el servicio lanzar una excepcin indicndolo Archivos: contra.php
Firma de Servicio
Campos: nick_usu, clave_usu Funciones: mostrar($tabla, $campos, $condicion, $orden)
240
241
Servicio 3
Gestin de cuentas de usuario

Administrador Permite el registro, actualizacin o eliminacin de usuarios con acceso a las opciones del sistema segn su nivel del seguridad, pudiendo ser los mismos Administrador, Diseador o Docente
Precondiciones
Acceder como usuario Administrador No tener unidades o ambientes asociados a la cuenta Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Si la informacin de campos especiales (correo y contrasea) no cumplen con los requerimientos, el servicio lanzar una excepcin indicndolo Archivos: incluir.php, editar_borrar.php
Excepciones
Firma de Servicio
Campos: id_usu, ced_usu, nom_usu, ape_usu, nivel_usu, correo_usu, telef_movil, nick_usu, clave_usu, pregunta, respuesta Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
eliminar($tabla, $condicion);
Servicio 4
Gestin de AVEAs
Diseador Permite el registro, actualizacin o eliminacin de Ambientes Virtuales de Enseanza Aprendizaje para luego iniciar el proceso de construccin de sus elementos
Acceder como usuario Diseador Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: incluir.php, editar_borrar.php
Firma de Servicio
Campos: id_uni, titu_uni, version_uni, nivel_uni, id_usu Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
242
APNDICE D
Servicio 5
Actualizacin de Metadata de un AVEA

Diseador Permite la actualizacin de la informacin correspondiente a la metadata de cada AVEA registrado
Acceder como usuario Diseador Registro del AVEA correspondiente Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: incluir_meta.php
Firma de Servicio
Campos: titu_meta, idioma, desc_meta, palabras, ambito, estructura, agregacion, version, estado, formato, tamano, localiza, pautas, otros, duracion, tipo_inte, tipo_recur, nivel_inte, densi_seman, destinatario, contexto, edad, dicultad, tiempo_tipico, desc_peda, idioma_peda, costo, derechos, fecha_anota, ropo_clasi, desc_clasi, palabras_clasi Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
Servicio 6
Gestin de roles de un AVEA

Diseador Permite el registro, actualizacin o eliminacin de roles dentro del AVEA, as como la descripcin de los detalles correspondientes Acceder como usuario Diseador
Precondiciones
Acceder a la opcin Construir del AVEA Acceder a la pestaa Roles
Excepciones
Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: info_rol.php, uni_rol.php
Firma de Servicio
Campos: id_rol, id_uni, tipo_rol, nom_rol, rol_padre, href, min_per, max_per, crear_nuevo, exclusivo Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
243
Servicio 7
Gestin de propiedades de un AVEA

Diseador Permite el registro, actualizacin o eliminacin de propiedades dentro del AVEA, as como la descripcin de las restricciones correspondientes Acceder como usuario Diseador
Precondiciones
Acceder a la opcin Construir del AVEA Acceder a la pestaa Propiedades
Excepciones
Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: uni_pro.php, resti_pro.php
Firma de Servicio
Campos: id_pro, id_uni, tipo_pro, nom_pro, tipo_dato, valor_inicial, id_rol, uri_global Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
Servicio 8
Gestin de actividades de un AVEA

Diseador Permite el registro, actualizacin o eliminacin de actividades dentro del AVEA, as como la descripcin de las restricciones, objetivos, referencias, roles asociados, entre otros Acceder como usuario Diseador
Precondiciones
Acceder a la opcin Construir del AVEA Acceder a la pestaa Actividades
Excepciones
Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: uni_act.php, obj_act.php, descri_act.php,
Firma de Servicio
feed_act.php, rol_sopo.php, uol_estruc.php Campos: id_act, id_uni, tipo_act, nom_act, parametros, visible Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
244
APNDICE D
Servicio 9
Gestin de entornos de un AVEA

Diseador Permite el registro, actualizacin o eliminacin de entornos dentro del AVEA, as como la gestin de los elementos que lo componen (objetos y servicios). No se muestran aqu los entornos y elementos ingresados por los usuarios Docente Acceder como usuario Diseador
Precondiciones
Acceder a la opcin Construir del AVEA Acceder a la pestaa Entornos
Excepciones
Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: context.php, oa_moni.php, confe_con.php, bus-
Firma de Servicio
que_con.php, con_email.php, le_confe.php Campos: id_con, id_uni, id_amb, nom_con Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
Servicio 10
Gestin de guiones de un AVEA

Diseador Permite el registro, actualizacin o eliminacin de guiones dentro del AVEA, as como la gestin de los elementos que lo componen (actos y roles asociados). Acceder como usuario Diseador
Precondiciones
Acceder a la opcin Construir del AVEA Acceder a la pestaa Guiones
Excepciones
Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: guion.php, feed_gui.php, acto.php, rol_part.php,
Firma de Servicio
feed_acto.php Campos: id_gui, id_uni, nom_gui, visible, id_feed_gui, id_gui, texto, visible, parametros Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
245
Servicio 11
Generacin de empaquetados de un AVEA

Diseador, Docente Permite la generacin de un directorio comprimido con el contenido de los elementos descritos en el AVEA en cada una de sus partes, as como la creacin de un archivo XML con la informacin correspondiente a la estructura del AVEA. Acceder como usuario Diseador o Docente
Precondiciones
Acceder a la opcin Construir del AVEA Acceder a la pestaa Empaquetado
Excepciones
Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: paquete.php
Firma de Servicio
Campos: id_paque, id_uni, nom_paq, fecha, url Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
Servicio 12
Generacin de ambientes de un AVEA

Docente Permite el registro o actualizacin de ambientes a partir de un AVEA dado. El usuario Docente podr crear una cantidad ilimitada de ambientes usando como base el mismo AVEA.
Acceder como usuario Docente Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: incluir.php, editar_borrar.php
Firma de Servicio
Campos: id_amb, titu_amb, version_amb, id_usu, id_uni Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
246
APNDICE D
Servicio 13
Gestin de objetivos y prerrequisitos de un ambiente basado en un AVEA

Docente Permite el registro, actualizacin o eliminacin de objetivos y prerrequisitos dentro de un ambiente basado en un AVEA. Acceder como usuario Docente
Precondiciones
Acceder al enlace del ambiente Acceder a la pestaa Informacin
Excepciones
Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: uni_prere.php, uni_objetivo.php
Firma de Servicio
Campos: id_obj, id_amb, text_obj, visible, id_pre, text_pre Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
Servicio 14
Gestin de entornos en un ambiente a partir de un AVEA

Docente Permite el registro, actualizacin o eliminacin de entornos dentro del AVEA, as como la gestin de los elementos que lo componen (objetos y servicios). Se muestran aqu los entornos y elementos ingresados por los usuarios Diseadores, pero no se permite la edicin o eliminacin de los mismos Acceder como usuario Docente
Precondiciones
Acceder al enlace del ambiente Acceder a la pestaa Entornos
Excepciones
Si no se completan los campos solicitados el servicio lanzar una excepcin indicndolo Archivos: context.php, oa_moni.php, confe_con.php, bus-
Firma de Servicio
que_con.php, con_email.php, le_confe.php Campos: id_con, id_uni, id_amb, nom_con Funciones: incluir($tabla, $campos, $valores); actualizar($tabla, $campos, $condicion);
247
Servicio 15
Bsqueda de AVEAs
Diseador y Docente Permite consultar la existencia de un AVEA dentro del registro del sistema a partir de una bsqueda semntica del mismo
Acceder como usuario Diseador o Docente De no existir un AVEA relacionado con la bsqueda, el servicio lanzar una excepcin indicndolo Archivos: buscar.php
Firma de Servicio
Campos: nom_avea Funciones: mostrar($tabla, $campos, $condicion, $orden);
Apndice E
Diccionario de Datos
248
249
250
APNDICE E
251
252
APNDICE E
253
254
APNDICE E
255
256
APNDICE E
257
258
APNDICE E
259
260
APNDICE E
261
262
APNDICE E

Modelo Arquitectural para Sistemas Generadores de Ambientes de Enseñanza Aprendizaje para Elearning

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelo Arquitectural para Sistemas Generadores de Ambientes de Enseñanza Aprendizaje para Elearning

Cargado por

Copyright:

Formatos disponibles

Universidad Central de Venezuela Facultad de Ciencias Postgrado en Ciencias de la Computacin rea: Sistemas de Informacin

Tesis presentada por Ing. DORIS JOSEFINA PERNALETE CHIRINOS

para optar al ttulo de DOCTOR EN CIENCIAS mencin CIENCIAS DE LA COMPUTACIN

Tutor: Dr. Yovanny Coello Universidad Nacional Experimental "Francisco de Miranda"

Caracas, Venezuela Febrero 2013

TODOS PILARES DE MI VIDA. LOS AMO!!!!

Mtodo de Investigacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1. Mtodo de resolucin y validacin . . . . . . . . . . . . . . . . . . . . .

2. Hacia el modelado de AVEAS para eLearning

El Crculo eLearning (eLearning Circle)

Plataformas de eLearning Estndares 2.4.1. 2.4.2. 2.4.3.

Conclusiones del captulo

3. Anlisis del dominio bajo estndares de calidad

4. Arquitectura para sistemas generadores de AVEAs

Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 . . . . . . . . . . . . . . . . . . . . 120

IMS Abstract Framework (IAF) . . . . . . . . . . . . . . . . . . . . . . . 129

4.3.3. 4.3.4. 4.3.5. 4.4.

Enfoque la arquitectura propuesta para AVEA Conclusiones del captulo

5. Generando AVEAs con GTLE-E

Conclusiones del captulo

Conclusiones Finales Publicaciones

Bibliografa Apndice A Apndice B Apndice C Apndice D Apndice E

215 224 225 236 240 248

. . . . . . . . . . . . . . . . . . . para eLearning y AVEA para

3.1. 3.2. 3.3. 3.4.

2.1. 2.2. 2.3. 2.4. 2.5. 2.6.

2.7. 2.8. 2.9.

2.10. Diagrama ilustrativo de SCORM CAM 2.11. Estructura del Maniesto

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . y ambientes de enseanza aprendizaje para

2.17. Mapa conceptual de los AVEAs . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.19. Modelo Conceptual de un AVEA basado en IMS LD

3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8.

Reestructuracin de los RNF comunes en el modelo de caso de uso

Visin general de un ESB de SOA [14] . . . . . . . . . . . . . . . . . . . . . . . 111

4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9.

Arquitectura lgica de los sistemas de eLearning

4.19. Enfoque SOA para una iteracin [17] . . . . . . . . . . . . . . . . . . . . . . . . 163

4.20. Fases del proceso de desarrollo propuesto [15]

4.21. SOA provee la infraestructura para BPM [17, 16]

4.22. Arquitectura propuesta para los sistemas generadores de AVEA . . . . . . . . . 173

5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. 5.9.

5.13. Creacin de Cuentas de usuarios

Modelo de Base de Datos de GTLE-E

CAPTULO 1. IDEAS IMPULSADORAS

(Learning Design) que apoya

la estandarizacin y reutilizacin de las estructuras de aprendizaje o diseos de instruccionales.

1.2. Planteamiento y Justicacin del trabajo

1.2. PLANTEAMIENTO Y JUSTIFICACIN DEL TRABAJO

As, segn Sharon

[20] el diseo de software se divide en tres fases importantes: anlisis

CAPTULO 1. IDEAS IMPULSADORAS

1.2. PLANTEAMIENTO Y JUSTIFICACIN DEL TRABAJO

En este sentido, Koper

[25] plantea la necesidad de elaborar herramientas de autora de

Resulta signicativo lo planteado por Burgos, Tattersall y Koper

[27],los cuales arman

CAPTULO 1. IDEAS IMPULSADORAS

los procesos de negocio hacia la consecucin de mejorar en agilidad y rendimiento operacional.

1.2. PLANTEAMIENTO Y JUSTIFICACIN DEL TRABAJO

CAPTULO 1. IDEAS IMPULSADORAS

[27]. Ninguno de estos sistemas

3 http://www.reload.ac.uk/ 4 http://www.adl-ilce.org.mx/index.php 5 http://www.lamsinternational.com/

1.2. PLANTEAMIENTO Y JUSTIFICACIN DEL TRABAJO

CAPTULO 1. IDEAS IMPULSADORAS

2.10. Diagrama ilustrativo de SCORM CAM 2.11. Estructura del Maniesto

1.2. Planteamiento y Justicacin del trabajo

Resulta signicativo lo planteado por Burgos, Tattersall y Koper

[27],los cuales arman

e IMS Abstract Framework

Denicin del problema:

es la etapa inicial de cada iteracin, involucra la identicacin

1.2). El resultado de esta actividad es la identicacin de

Denir una arquitectura inicial

nalmente, se incluyen dos apndices: el primero de ellos presenta la relacin

5. Gestin: Se reere al mantenimiento del entorno de aprendizaje y la distribucin de la informacin.

QF4 (Costos-Expectativas de Benecios)