Universidad de las Ciencias Informáticas Facultad 10
Arquitectura de un
Repositorio de Objetos de Aprendizaje
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Autores:
Lisandra Hernández Osorio Alioscha Durand Vicet
Tutores:
MSc. David Leyva Leyva MSc. Daymy Tamayo Avila Ing. Lissette Rodríguez Verdecia
Ciudad de La Habana, Cuba
Julio, 2008
I
D D EC E CL LA AR RA AC CI I ÓN Ó N D D E E A A UT U TO OR RÍ Í A A
Declaramos ser autores de la presente tesis y reconocemos a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo.
Para que así conste firmo la presente a los ____ días del mes de ________ del año ________.
____________________ ______________________
Lisandra Hernández Osorio Alioscha Durand Vicet
_____________________ _____________________
MSc. Daymy Tamayo Avila MSc. David Leyva Leyva
_____________________
Ing. Lissette Rodríguez Verdecia
II
“Nunca desistas de un sueño. Sólo trata de ver las
señales que te lleven a él.”
Paulo Cohelo.
III
A A GR G RA AD DE EC CI I MI M IE EN NT TO OS S
Agradecemos a nuestros tutores David Leyva Leyva, Daymy Tamayo Ávila y Lissette Rodríguez Verdecia por haber confiado en nosotros siempre, por su comprensión, ayuda, apoyo y por todo el tiempo dedicado.
A todos los estudiantes y trabajadores del Polo Teleformación y en especial a los integrantes del proyecto ROA, gracias por su apoyo y sus contribuciones.
De Alioscha:
Agradezco grandemente a mis padres y abuela por darme la educación adecuada y guiarme por el buen camino toda la vida.
A nuestros profesores, que a lo largo de toda nuestra vida estudiantil han contribuido a nuestra formación profesional.
A mi compañera y hermana Lisandra por su dedicación, paciencia y entrega en la realización de este trabajo, por mantenerse firme en todo momento.
A todos mis amigos por mantenernos siempre unidos en los buenos y malos momentos y comportarnos como
una gran familia.
IV
De Lisandra:
Esta tesis, si bien ha requerido de esfuerzo y mucha dedicación por mi parte, no hubiese sido posible su finalización sin la cooperación desinteresada de todas y cada una de las personas que a continuación citaré y muchas de las cuales han sido un soporte muy fuerte en momentos de angustia y desesperación.
A mis padres, Cruz y Juan Francisco, les agradezco su apoyo, su guía y su confianza en la realización de mis sueños. Soy afortunada por contar siempre con su amor, comprensión y ejemplo. Los quiero con todo mi corazón. Aquí esta el fruto de lo que ustedes me brindaron, simplemente les estoy devolviendo lo que me dieron en un principio.
A mis abuelitos, a los cuales les agradezco infinitamente todo lo que soy hoy, mis ideas, mis pensamientos, mi postura ante la vida. Gracias por sus consejos y por guiarme por el buen camino.
A mis hermanos Carlos y Osmany por su cariño, gracias por apoyarme siempre.
A mi novio Norbert, por su constancia, dedicación, por apoyarme en todo este tiempo, por su amor incondicional. Eres muy importante.
A mis amigas Yane, Ra, Yury, Dayi, Yubi y Daymy por estar y compartir tan buenos momentos en esta universidad. Sepan ustedes que el recuerdo de estos años maravillosos los llevo en mi corazón.
A todos mis compañeros de aula, son tantos los que han estado a mi lado, que no puedo darme el lujo de pasar por alto el nombre de alguno de ustedes, saben lo mucho que representan para mí.
A Dios, por estar conmigo en cada paso que doy, por fortalecer mi corazón e iluminar mi mente y por haber puesto en mi camino a aquellas personas que han sido mi soporte y compañía durante todo el periodo de estudio.
A mi compañero de tesis Alioscha, por los buenos y malos momentos pasados para llegar hoy hasta aquí.
A todos los que de un modo otro han contribuido a la realización de este trabajo.
A todos Gracias.
V
D D ED E DI I CA C AT TO OR RI IA A
Alioscha:
A mi queridísima abuela que es lo que más quiero en este mundo, por estar siempre a mi lado en los buenos y malos momentos.
A mis padres y hermanos, que han sido los mejores, brindándome todo el amor que un hijo necesita. Por confiar en mí en todo momento.
A mis amigos por confiar en mí en todo momento, por su entrega y apoyo incondicional.
Lisandra:
A mi madre, fuente de inspiración, quien me dio todo el apoyo que necesité en los momentos más difíciles, por su incondicionalidad y su eterno amor, por ser mí amiga y mi refugio.
A mi padre, por su ejemplo y por sus consejos.
A mis hermanos por su cariño.
A Norbert, por su amor.
VI
R R ES E SU UM M EN E N
Para fundamentar dicha investigación se abordan de manera general los principales conceptos relacionados con el tema. Se realiza un estudio sobre los principales estándares más usados en la actualidad, así como proyectos sobre Repositorios de Objetos de Aprendizaje. Además se analizan los conceptos relacionados con la arquitectura de software. Para describir la solución se hace referencia a versiones anteriores del Repositorio de Objetos de Aprendizaje desarrollado en el Polo de Teleformación de la Facultad 10, así como las tecnologías y arquitectura haciendo énfasis en los estándares que conforman la propuesta.
Se propone una arquitectura de software que permite el desarrollo de un Repositorio de Objetos de Aprendizaje interoperable con la plataforma Moodle, basado en los estándares IMS-DRI y SQI para soportar el e-learning en la Universidad de las Ciencias Informáticas.
La gestión de los contenidos está soportada en el uso de los estándares LOM y SCORM.
Finalmente se proponen elementos que permitirán el desarrollo de futuras versiones.
Palabras Claves:
Objetos de Aprendizaje, Repositorios de Objetos de Aprendizaje, Interoperabilidad, Arquitectura de Software, IMS-DRI, SQI, LOM, SCORM.
VII
Í Í ND N DI IC CE E DE D E F F IG I GU UR RA AS S Y Y T T AB A BL LA AS S
Figura 1: Fases e Iteraciones de la Metodología RUP. ... 40
Figura 2: Paquetes de Casos de Uso Arquitectónicamente Significativos ... 43
Figura 3: Diagrama de CU del Paquete Gestión de usuarios. ... 44
Figura 4: Diagrama de CU del Paquete Gestión de paquetes. ... 44
Figura 5: Diagrama de CU del Paquete Gestión de repositorio. ... 45
Figura 6: Principales módulos del sistema. ... 52
Figura 7: Estructura Modelo-Vista-Controlador del sistema... 54
Figura 8: Componentes de la capa Vista ... 55
Figura 9: Componentes de la capa Modelo ... 55
Figura 10: Componentes de la capa Controlador. ... 56
Figura 11: Diagrama de clases del diseño del CU Buscar Paquetes. ... 57
Figura 12: Diagrama de clases del diseño del CU Subir Paquete. ... 58
Figura 13: Vista de implementación. ... 59
Figura 14: Vista de Despliegue ... 61
Tabla 1: Descripción y recomendaciones tecnológicas para las funciones de un repositorio ... 16
VIII
Í Í ND N DI I CE C E D DE E C C ON O NT TE EN NI ID DO O
Declaración de Autoría ... I Agradecimientos ... III Dedicatoria ... V Resumen ... VI Índice de Figuras y Tablas ... VII
Introducción ... 1
Capítulo 1 Fundamentación Teórica ... 5
1.1 E-Learning ... 5
1.2 Objetos de Aprendizaje ... 8
1.3 Repositorio de Objetos de Aprendizaje ... 9
1.4 Estándares y Especificaciones e-learning ... 10
1.4.1 Estándares de interoperabilidad de contenidos ... 12
1.4.2 Estándares de Interoperabilidad entre sistemas e-learning ... 14
1.5 Proyectos realizados en aras de lograr la interoperabilidad ... 19
1.5.1 CAREO ... 19
1.5.2 ARIADNE ... 20
1.5.3 AGREGA ... 20
1.6 Arquitectura de Software... 21
1.6.1 Estilos arquitectónicos ... 23
1.7 Web Services ... 29
1.8 Versiones anteriores de ROA ... 30
Conclusiones ... 31
Capítulo 2 Descripción de la Solución Propuesta ... 32
2.1 Estándares que conforman la propuesta ... 32
2.2 Tecnologías a utilizar para el desarrollo del sistema ... 34
2.3 Metodología de Desarrollo de Software ... 38
2.4 Requerimientos del sistema. ... 41
2.5 Organización de la arquitectura propuesta ... 42
IX
2.6 Descripción de los servicios ... 62
Conclusiones ... 69
Capítulo 3 Trabajo futuro ... 70
3.1 Repositorio Objetos de Aprendizaje Interoperable. ... 70
3.2 Repositorio Semántico ... 74
Conclusiones ... 76
Conclusiones ... 77
Recomendaciones ... 78
Bibliografía ... 79
Anexos ... 84
Glosario de Términos ... 85
1
I I NT N TR RO OD DU UC CC CI IÓ ÓN N
Las universidades en el mundo contemporáneo están muy vinculadas al uso de las Tecnologías de la Informática y las Comunicaciones (TICs) en el proceso de enseñanza- aprendizaje.
Con la integración de programas educativos bien estructurados, contenidos digitales y aplicaciones basadas en las TIC, se crean nuevos entornos de aprendizaje en los que es posible la comunicación, acción e interacción social. Estos entornos han dado origen a una opción más dentro de las modalidades de educación a distancia conocida como e-learning.
El e-learning hace uso de la tecnología y de los servicios de Internet para llevar a cabo procesos de formación y capacitación.
Esta modalidad ha cobrado fuerzas en los últimos años; su aplicación se ha convertido en un requisito casi indispensable en los centros de educación superior a nivel mundial.
Uno de los factores que se tienen en cuenta para la asimilación de las TICs en estos centros es la selección de un Learning Management Systems (LMS), sistema mediante el cual se realiza la distribución y gestión de cursos a través de la red, mejorando la calidad del proceso de enseñanza aprendizaje.
Entre los LMS más difundidos se encuentra la plataforma Moodle1 que es una plataforma gratuita de e-learning de gran flexibilidad que permite la creación de páginas Web y cursos en línea o a distancia2.
Moodle favorece una alta disponibilidad para satisfacer las necesidades de miles de estudiantes, administradores, creadores de contenidos y profesores simultáneamente, permitiéndoles permanentemente iniciar sesión y ejecutar sus tareas diarias.
Para lograr que otras plataformas de educación a distancia, como pueden ser Blackboard y WebCT, manipulen de la misma forma estos recursos educativos, organizaciones internacionales como el Institute for Electrical and Electronic Engineers Learning
1 Modular Object-Oriented Dynamic Learning Environment
2 Más información en www.moodle.org
2 Technology Standards Committee (IEEE LTSC); Advanced Distributed Learning (ADL); IMS Global Learning Consortium y Aviation Industry CBT Committee (AICC) han propuesto varias especificaciones y estándares que garantizan la interoperabilidad, reusabilidad, durabilidad y accesibilidad de los objetos de aprendizaje, que no son más que “cualquier recurso con una intención formativa, compuesto de uno o varios elementos digitales, descrito con metadatos, que pueda ser utilizado y reutilizado dentro de un entorno e- learning” (López, 2005).
Sin embargo, esto no es suficiente, pues sería muy útil poder reutilizar de una forma más eficiente los objetos de aprendizaje (OA), teniendo un lugar donde puedan estar almacenados, de forma que cualquiera pueda contribuir en su construcción y hacer uso de ellos. Los sistemas que hacen posible esto se conocen como Repositorios de Objetos de Aprendizaje (ROA).
En el mundo existen diversos Repositorios de Objetos de Aprendizaje, muchos de ellos brindan servicios gratuitos de inscripción y uso, pero su código no es abierto; otros lo son, pero no tienen en cuenta estándares para interoperabilidad entre sistemas. Algunos sólo soportan un tipo específico de los objetos de aprendizaje, como multimedia; o son para un tipo de enseñanza o nivel educativo en particular. Además existen varios repositorios de código abierto pero los mismos no permiten una gestión lo suficientemente eficiente de los objetos de aprendizaje acorde con las características que hacen posible su real reutilización.
En Cuba a partir del año 2000, varias universidades comenzaron a implantar el uso de una plataforma Web para impartir los cursos a distancia, y junto a ello numerosas instituciones desarrollaron otras herramientas para el uso del e-learning en los procesos docentes educativos, tanto así que en los últimos años se ha generalizado su uso, haciendo énfasis en el LMS Moodle, una de las plataformas de libre distribución más difundidas en el mundo.
La Universidad de las Ciencias Informáticas (UCI) en el año 2005 decide utilizar el LMS Moodle en el proceso docente para poder dar seguimiento al proceso de enseñanza aprendizaje. Aunque este cuenta con las principales ventajas que proporciona un LMS, carece de un lugar centralizado para poder reutilizar los contenidos cuando se crea un curso y además no maneja los contenidos como OA. (Tamayo, 2007)
Es por ello que en el Polo de Teleformación de la Facultad #10 de dicha universidad, se comienza a desarrollar un repositorio de objetos de aprendizaje, el cual lleva por nombre
3
“ROA”, con el objetivo de gestionar estos OA basándose en el estándar SCORM, para propiciar la reutilización de dichos contenidos educativos.
Este repositorio cuenta con varios roles (invitado, usuario, autor, revisor, administrador), permitiendo tener un mejor control de los paquetes subidos al sistema, además posibilita búsquedas tanto general como por diferentes metadatos, cuenta con una mensajería interna, un panel de administración donde puede gestionar a los usuarios, categorías, configurar el sistema y una sección dedicada a la seguridad para tener un control de las actividades realizadas en el mismo por cualquier usuario.
Actualmente este repositorio no posee mecanismos de comunicación con Moodle, lo que dificulta la reutilización de contenidos y las búsquedas de los mismos desde dicha plataforma.
A partir de lo expuesto anteriormente se plantea como problema ¿Cómo garantizar la interoperabilidad de un Repositorio de Objetos de Aprendizaje con la plataforma Moodle en la Universidad de las Ciencias Informáticas?
Se define como objeto de estudio de esta investigación los Repositorios de Objetos de Aprendizaje y el campo de acción los estándares que posibilitan la interoperabilidad en Repositorios de Objetos de Aprendizaje.
Para solucionar el problema planteado el presente trabajo tiene como objetivo general proponer una arquitectura de software que permita el desarrollo de un Repositorio de Objetos de Aprendizaje interoperable con Moodle, en la Universidad de las Ciencias Informáticas.
Idea a defender: La interoperabilidad de un Repositorio de Objetos de Aprendizaje con Moodle en la Universidad de las Ciencias Informáticas puede lograrse utilizando una arquitectura basada en estándares.
Para dar cumplimiento a los objetivos se han planteado las siguientes tareas investigativas:
Analizar conceptos básicos relacionados con los Repositorios de Objetos de Aprendizaje.
4
Analizar las especificaciones y estándares para interoperabilidad desarrollados para e-learning.
Analizar los principales conceptos relacionados con la arquitectura de software.
Analizar trabajos realizados anteriormente, así como otras versiones que existen de Repositorio de Objetos de Aprendizaje.
Proponer una arquitectura de software basada en estándares que permita la interoperabilidad con Moodle.
Para la realización de estas tareas se utilizarán diferentes métodos de investigación.
Analítico-Sintético: centrándose en el análisis de las teorías, documentos, y materiales, para así proceder a la extracción de los elementos más importantes de manera que se procese la información y se elaboren conclusiones.
Histórico-Lógico: para el estudio de la evolución y desarrollo del objeto de estudio de la investigación.
Revisión de documentos: permite encontrar los términos más importantes sobre los Repositorios de Objetos de Aprendizaje, incluyendo intentos anteriores de llevar a cabo esta actividad en la bibliografía consultada.
El presente trabajo consta de una introducción, tres capítulos, conclusiones generales, recomendaciones, referencias bibliográficas utilizadas durante el desarrollo de esta investigación, y por último, los anexos que complementan el cuerpo del trabajo.
En el primer capítulo “Fundamentación teórica” se aborda de manera general los principales conceptos que fundamentan la investigación. Se realiza un estudio sobre los principales estándares más usados en la actualidad, así como los principales proyectos sobre Repositorios de Objetos de Aprendizaje. Se analizan los conceptos relacionados con la arquitectura de software y se describen las versiones anteriores del Repositorio de Objetos de Aprendizaje desarrollado en el Polo de Teleformación de la Facultad 10.
En el segundo capítulo “Descripción de la solución propuesta”, se describen las tecnologías a utilizar y la arquitectura, haciendo énfasis en los estándares que conforman la propuesta.
Se realiza una breve descripción de los principales servicios.
En el tercer capítulo “Trabajos futuros”, se realiza una proyección de las investigaciones que deben realizarse a partir de los resultados de este trabajo.
5
C C AP A PÍ ÍT TU UL LO O 1 1 F F UN U ND DA AM ME EN NT TA AC CI IÓ Ó N N T T EÓ E ÓR RI IC CA A
En este capítulo se definen los conceptos generales relacionados con el e-learning, así como la necesidad de la incorporación de estándares para favorecer su desarrollo. Se analizan las características de interoperabilidad entre los repositorios y se definen los estándares y especificaciones que garantizarán dicha interoperabilidad. Luego se hace referencia a algunos proyectos que tienen como iniciativa la integración entre varios sistemas, se realiza una breve descripción de los conceptos fundamentales de Arquitectura de Software, así como de las versiones anteriores de ROA.
1.1 E-Learning
El concepto de e-learning se define de muchas formas, aunque la acepción más común para e-learning es la enseñanza a través de un entorno Internet/Intranet.
Según (MENDOZA 2003), el e-Learning es el suministro de programas educacionales y sistemas de aprendizaje a través de medios electrónicos. Se basa en el uso de una computadora u otro dispositivo electrónico para proveer a las personas de material educativo. La educación a distancia creó las bases para el desarrollo del e-Learning, el cual viene a resolver algunas dificultades y problemas típicos de la educación tradicional.
El concepto de e-Learning es comprendido fácilmente por la mayoría de la gente. Aun así, esta industria tiene pendiente una definición precisa de este término. Para darnos una idea de las variantes que existen actualmente en la concepción del e-learning, examinemos algunas de las definiciones más comunes:
“capacitación no presencial que, a través de plataformas tecnológicas, posibilita y flexibiliza el acceso y el tiempo en el proceso de enseñanza-aprendizaje, adecuándolos a las habilidades, necesidades y disponibilidades de cada discente, además de garantizar ambientes de aprendizaje colaborativos mediante el uso de herramientas de comunicación síncrona y asíncrona, potenciando en suma el proceso de gestión basado en competencias.”(PEÑALVO 2008).
Para los educadores, e-Learning es el uso de tecnologías de redes y comunicaciones para diseñar, seleccionar, administrar, entregar y extender la educación. (MENDOZA 2003)
6 Una de las principales ventajas del e-learning es la facilidad de acceso. La formación puede llegar a más personas, puesto que desaparecen las barreras espacio-temporales.
El núcleo central de los sistemas de e-learning es la plataforma de formación o entorno virtual de enseñanza-aprendizaje. Básicamente, se trata de una aplicación (o un conjunto de aplicaciones) basadas en tecnologías Web, las cuales se utilizan para la creación, gestión y distribución de cursos a través de la Web.
Es por eso que la inmensa mayoría de las universidades han comenzado a hacer uso de los LMS y los LCMS, aplicaciones que tienen estas características o que soportan estos procesos, como un complemento más de la formación educacional.
Learning Management Systems (LMS)
Entre las herramientas más utilizadas para los ambientes o sistemas e-learning están los Sistemas de Administración de Aprendizaje o LMS, también ampliamente conocidos como plataformas de aprendizaje.
Los LMS permiten planificar el aprendizaje de acuerdo a las necesidades de los usuarios, sean estos estudiantes, trabajadores, empresas. Permiten la distribución de cursos, recursos, noticias y contenidos relacionados con la formación en general; además, pueden servir como soporte para el registro de los estudiantes, acceso a recursos tales como material audiovisual, demos, entre otros.
La implementación de una plataforma LMS no garantiza, sin embargo, los medios para la creación y generación de los cursos necesarios para la organización. Desde la perspectiva de los materiales docentes simplemente actúa como plataforma de distribución donde se remarca la idea de que en un sistema LMS la mínima unidad de instrucción es el curso en sí mismo (LÓPEZ 2005). Los LMS permiten una eficiente gestión de los usuarios, pero demuestran carencias en la gestión de los contenidos.
Learning Content Management Systems (LCMS)
Los Sistemas de Administración de Contenidos de Aprendizaje o LCMS tienen su origen en los CMS (Content Management System) cuyo objetivo es simplificar la creación y la administración de los contenidos en línea, y han sido utilizados principalmente en
7 publicaciones periódicas (artículos, informes, fotografías…). En la mayoría de los casos lo que hacen los CMS es separar los contenidos de su presentación y también facilitar un mecanismo de trabajo para la gestión de una publicación web. Los LCMS siguen el concepto básico de los CMS, que es la administración de contenidos, pero enfocados al ámbito educativo, administrando y concentrando únicamente recursos educativos y no todo tipo de información (LÓPEZ 2005).
El aprendizaje a través de Internet necesariamente requiere de recursos que permitan tanto la creación como la distribución de contenidos integrados en una misma plataforma; esto permite a expertos en cualquier área del saber, pero no necesariamente a expertos en el manejo del software específico de generación de materiales, diseñar, crear, distribuir y controlar la eficacia del proceso de aprendizaje de una forma sencilla, rápida y eficiente.
Los LCMS podrían contribuir a resolver muchos de los problemas anteriormente mencionados. Por lo tanto, una plataforma LCMS además de garantizar el control del proceso de aprendizaje, debe facilitar la creación, almacenamiento y reparto de los contenidos, con las siguientes características:
Herramientas sencillas que facilitan la creación de contenidos
Sistemas flexibles de diseño y distribución de los cursos.
Posibilidad de rehusar los objetos de aprendizaje.
Herramientas para la administración del sistema que permita las matriculaciones, el seguimiento del aprendizaje, el uso de los tiempos, la trazabilidad de los usuarios, la adecuación de los contenidos, etc.
Herramientas para la evaluación tanto inicial como de los aprendizajes que se producen a lo largo del curso.
Conectividad con otros LCMS y en general adecuación a los estándares actuales.
Herramientas para la comunicación y el aprendizaje colaborativo.
Mecanismos de seguridad y protección del conocimiento almacenado.
Sencillez en la migración de contenidos para facilitar la adaptación a las diferentes necesidades y escenarios de formación que se puedan presentar.
Facilidad de instalación que hagan innecesarias las adaptaciones, personalizaciones y demás procesos que encarecen el producto y retrasan el proceso de instalación.
8 1.2 Objetos de Aprendizaje
En la literatura se pueden encontrar diversas formas de hacer referencia al término objetos de aprendizaje, y la vaguedad presente en los distintos conceptos que de él se ofrecen en ocasiones tiende a provocar confusiones.
Así en el contexto del proyecto ARIADNE se ha utilizado el término “documentos pedagógicos” y en el MERLOT (Multimedia Educational Resource for Learning and On-Line Teaching) se utiliza “materiales de aprendizaje on-line”.
Dada la amplitud y variedad de las definiciones, así como la diversidad de recursos que pueden considerarse como OA, es difícil llegar a término estricto, pero para fines de este trabajo, se considerará “que cualquier recurso con una intención formativa, compuesto de uno o varios elementos digitales, descrito con metadatos, que pueda ser utilizado y reutilizado dentro de un entorno e-learning” (LÓPEZ 2005), puede considerarse un OA.
Los metadatos son un conjunto de atributos o elementos necesarios para describir un recurso. A través de los metadatos se tiene un primer acercamiento con el objeto, conociendo rápidamente sus principales características. Son especialmente útiles en los recursos que no son textuales y en los que su contenido no puede ser indizado por sistemas automáticos.
Las principales características que presentan los OA, son las siguientes (LÓPEZ 2005):
Reutilizables: El recurso debe ser modular para servir como base o componente de otro recurso. También debe tener una tecnología, una estructura y los componentes necesarios para ser incluido en diversas aplicaciones.
Accesibles: Pueden ser indexados para una localización y recuperación más eficiente, utilizando esquemas estándares de metadatos.
Interoperables: Pueden operar entre diferentes plataformas de hardware y software.
Portables: Pueden moverse y albergarse en diferentes plataformas de manera transparente, sin cambio alguno en estructura o contenido.
Durables. Deben permanecer intactos a las actualizaciones de software y hardware.
Para la reutilización, así como para lograr los otros atributos descritos, es necesario que el objeto de aprendizaje cuente con los metadatos que le permitan ser identificado, organizado y recuperado, entre otros aspectos pero lo más importante es que esos metadatos estén
9 basados en un estándar, a fin de asegurar su compatibilidad e interoperabilidad con los sistema que puedan reutilizarlos ya sean estos plataformas de aprendizaje o repositorios que intercambien contenidos.
1.3 Repositorio de Objetos de Aprendizaje
Los repositorios permiten almacenar, buscar, recuperar, consultar OA. De ahí que el objeto y el repositorio sean elementos complementarios. Para que un repositorio cumpla su objetivo debe contar con objetos debidamente etiquetados para poder identificarlos, tal como se hace en una biblioteca común. La etiqueta del objeto se crea mediante un archivo asociado que se llama manifiesto, escrito en lenguaje XML.
Se distinguen dos tipos de repositorios:
Los que contienen tanto los objetos de aprendizaje como sus metadatos, y se encuentran dentro del mismo sistema e incluso dentro de un mismo servidor.
Los que contienen sólo los metadatos y se accede al objeto a través de una referencia a su ubicación física que se encuentra en otro sistema, en este caso el repositorio contiene sólo los descriptores.
Regularmente los repositorios de objetos de aprendizaje operan de forma independiente, aunque es común que los LMS (Learning Management System) tengan asociado un repositorio que en la mayoría de los casos es sólo para su uso dentro de la misma plataforma.
La importancia de que los OA y los repositorios se atengan a determinados criterios de estandarización facilita el intercambio de objetos entre repositorios.
Ya se ha planteado el uso de metadatos como una vía para describir objetos de aprendizaje, contribuyendo así a facilitar su intercambio y reutilización. Pero esto por sí solo no es suficiente, es necesario que sean conocidos e interpretados de la misma forma por los creadores de los mismos y por los usuarios finales. Esto solo es posible mediante el empleo de estándares y/o especificaciones.
10 1.4 Estándares y Especificaciones e-learning
Dentro de los entornos e-learning participan individuos con distintos intereses y objetivos, sistemas informáticos con funciones diversas y tecnologías diferentes, así como contenidos con características, objetivos y formatos de todo tipo. En este complejo ámbito, un reto es la interoperabilidad, entornos o sistemas de diferentes desarrolladores para distintas aplicaciones y contenidos diversos, que trabajen juntos en sistemas distribuidos de aprendizaje.
Para lograr dicha interoperabilidad es necesario apegarse a los estándares y a las especificaciones que importantes grupos del sector e-learning desarrollan.
En la educación en línea, los estándares se ven como necesarios ahora más que antes, dado el alcance global que tienen las aplicaciones e-learning en los sistemas de telecomunicación, y el creciente interés de los individuos en la autoformación y en el aprendizaje a lo largo de toda la vida (LÓPEZ 2005).
La estandarización se requiere a distintos niveles, primero, cuando los recursos son creados deben considerarse tecnologías, políticas y formatos compatibles con lo común en el sector;
segundo, cuando esos recursos son incluidos en un repositorio, y deben ser descritos se utilizarán esquemas que aseguren su fácil localización y compatibilidad con otros sistemas de metadatos; tercero, cuando esos recursos sean utilizados y tengan que incorporarse a diferentes servicios, repositorios, plataformas y aplicaciones en un contexto dado; y cuarto, cuando los sistemas involucrados en un entorno tengan que interoperar con otros para cumplir sus funciones o ampliar sus capacidades (LÓPEZ 2005).
El reto de los estándares es acordar de qué forma compartir, comunicar o desarrollar modelos y sistemas con la finalidad de lograr la interoperabilidad entre los diversos componentes.
Diferencia entre estándares y especificaciones
Un estándar es un patrón, una tipificación o una norma de cómo realizar algo (RAE 2003) y los hay de dos tipos: estándares de jure, cuando provienen de una organización acreditada que certifica una especificación, y estándares de facto, cuando la especificación se adoptan
11 por un grupo mayoritario de individuos. Es claro entonces que un estándar regularmente proviene de una especificación, esto es, un conjunto de declaraciones detalladas y exactas de los requisitos funcionales y particularidades de algo que quiere construirse, instalarse o manufacturarse.
Los estándares sólo pueden ser producidos por cuerpos internacionales reconocidos por uno o varios gobiernos nacionales, cualquier otro organismo genera sólo especificaciones.
Por ejemplo, cuando se habla de estándares web, producidos por el Consorcio de la World Wide Web (http://www.w3.org/), éstos, realmente, producen especificaciones no estándares.
Durante la pasada década surgieron varias iniciativas de organismos reconocidos internacionalmente encaminadas a la propuesta de estándares para los distintos componentes que forman la arquitectura de las plataformas de formación: alumnos, contenidos, pruebas, estrategias docentes, etc. Entre todas ellas se destacan cuatro: AICC (Aviation Industry CBT Committee), IEEE, IMS (Instruction Management Systems) y ADL (Advanced Distributed Learning).
AICC Aviation Industry Computer-Based Training Comitee, es una asociación de entrenamiento profesional basado en tecnología, especializado en el sector de la aviación pero que se ha permeado también a otros sectores. Se reconoce como una de los precursores de la estandarización de materiales del entrenamiento profesional.
IMS Global Consortium Inc., cuenta con miembros de organizaciones comerciales, educativas y gubernamentales dedicadas a definir y distribuir arquitecturas abiertas para actividades de educación en línea. Uno de sus resultados es lo que se conoce como el estándar IMS.
Advanced Distribuited Learning (ADL), la misión de ADL es proveer acceso de la más alta calidad en educación y entrenamiento, en cualquier lugar y en cualquier momento. Para cumplir con estos objetivos crean el modelo SCORM.
IEEE/LTSC Institute of Electrical and Electronics Engineers/Learning Technology Standards Committee, es una asociación internacional, cuya misión es promover los procesos ingenieriles para la creación, desarrollo, integración, compartimiento y aplicación del conocimiento sobre tecnologías electrónicas y de información. Dentro
12 de su organización cuenta con el Comité de Estándares para Tecnología del Aprendizaje o LTSC, que se encarga de desarrollar estándares técnicos, recomendaciones y guías para la tecnología educativa.
1.4.1 Estándares de interoperabilidad de contenidos
Shareable Content Object Reference Model (SCORM).
El modelo SCORM es un conjunto de estándares y especificaciones para compartir, reutilizar, importar y exportar OA. Este modelo describe cómo las unidades de contenidos se relacionan unas con otras a diferentes niveles de granularidad, cómo se comunican los contenidos con el LMS, define cómo empaquetar los contenidos para importarse y exportarse entre plataformas, y describe las reglas que un LMS debe seguir a fin de presentar un aprendizaje específico . SCORM es expandible e incluye a trabajos de IEEE, AICC y de IMS para algunas de sus funciones. Maneja las unidades de contenido con el nombre de SCO (Shareable Content Object) que son simplemente objetos de aprendizaje que cumplen con la especificación SCORM.
Aunque SCORM ha ido actualizando versiones y ha extendido sus funciones, su alcance es limitado y en su modelo sólo cubre el empaquetamiento y la comunicación del recurso con el LMS, lo que hace su entendimiento e implementación mucho más sencilla que la de IMS, quizá este sea el motivo por el que es el más ampliamente utilizado hoy día para el intercambio de paquetes entre plataformas. Sin embargo, para la creación de repositorios todavía no tiene un desarrollo específico, pero las funciones hasta ahora disponibles, con el uso de metadatos y la creación de paquetes para mover recursos entre sistemas, pueden jugar un papel importante para facilitar las funciones de los ROA.
SCORM está formado por un conjunto de tres libros técnicos que recogen los diversos aspectos de la especificación, más un cuarto libro que ofrece una visión general sobre el estándar. Los libros son (LÓPEZ 2005):
Overview: Introducción a los elementos de SCORM y su terminología.
Content Aggregation Model (CAM): Información sobre la confección, etiquetado y empaquetamiento de los contenidos de aprendizaje.
Run-Time Environment (RTE): Requerimientos para la ejecución de los contenidos, comunicación, seguimiento, transferencia de datos y gestión de errores.
13
Sequence Information & Navigation (SN): Descripción de las reglas que marcan los secuencia de navegación entre distintos objetos de aprendizaje.
Learning Object Meta-Data (LOM)
El modelo de datos LOM es el estándar de metadatos para OA. LOM especifica la semántica y la sintáctica de un conjunto mínimo de metadatos necesario para, completa y adecuadamente, identificar, administrar, localizar y evaluar un OA. Su propósito es facilitar a profesores, alumnos y a sistemas automáticos la tarea de buscar, compartir e intercambiar OA, permitiendo el desarrollo de catálogos que contemplan la diversidad cultural e idiomática de los contextos en los que se puedan utilizar los objetos y sus metadatos.
LOM es muy extenso por lo que para tener una mejor organización y estructura, los metadatos se organizan en forma jerárquica. Su comprensión no es trivial y las condiciones para llenarlos de forma adecuada deben estudiarse previamente, a fin de tener consistencia y contar con registros apegados a lo que el estándar recomienda. Para poder asignar valores, deben tenerse algunos conocimientos técnicos del recurso y conocimientos del campo pedagógico, por lo que se requiere de intervención humana (tal vez especializada) y difícilmente pueden llenarse los datos de forma automatizada.
LOM (LÓPEZ 2005) cuenta con 9 categorías dentro de las que se encuentran:
Categoría General: agrupa la información general que describe el objeto de aprendizaje como un todo.
Categoría Ciclo de Vida (Life Cycle): agrupa las características relacionadas con la historia y el estado presente del objeto de aprendizaje y de aquéllos que han afectado a este objeto durante su evolución.
Categoría Meta-Metadatos (Meta-Metadata): agrupa la información sobre los mismos metadatos, no sobre el objeto de aprendizaje que se está describiendo.
Categoría Técnica (Technical): agrupa los requisitos y características técnicas del objeto de aprendizaje.
Categoría Educativa (Educational): agrupa las condiciones del uso educativo del recurso.
Categoría Derechos (Rights): agrupa las condiciones de uso para la explotación del recurso.
14
Categoría Relación (Relation): agrupa la relación del recurso descrito con otros objetos de aprendizaje.
Categoría Anotación (Annotation): agrupa los comentarios sobre el uso educativo del objeto de aprendizaje.
Categoría Clasificación (Classification): Describe la temática del recurso en algún sistema de clasificación.
LOM se ha posicionado como un esquema de metadatos estable y con reconocimiento internacional, características que lo proyectan para ser implementado en aplicaciones de larga escala dentro del e-learning.
No cabe duda de la complejidad de LOM y de su cuestionable pero necesaria adopción, sin embargo, su utilización está siendo la tendencia para muchas aplicaciones que lo interpretan y adaptan, en cuatro grupos principales:
Los que combinan LOM con elementos de otras especificaciones o estándares de metadatos.
Los que se enfocan en la definición de elementos de extensión y otras adaptaciones de LOM.
Los que hacen énfasis en la reducción de los elementos de LOM.
Los que combinan la reducción de los elementos LOM y, además, hacen elementos de extensión.
LOM, como estándar de metadatos para los ROA, está ofreciendo una opción que facilita, a los emprendedores de proyectos e iniciativas, decidir qué esquema de metadatos utilizar, con la idea de que éste cubre las necesidades para la descripción de los recursos educativos y que facilitará el mapeo y la reutilización de metadatos entre aplicaciones.
1.4.2 Estándares de Interoperabilidad entre sistemas e-learning
A nivel mundial se están llevando a cabo proyectos cuyo interés general no es otro que enfocar, conectar y utilizar recursos distribuidos en repositorios heterogéneos El objetivo final es la interoperabilidad, es decir, que los sistemas tengan la capacidad para trabajar fácilmente con otro u otros. Entre estos sistemas se busca, a través de una normalización tecnológica o procedimental, poder interconectarse para realizar diversas transacciones o actividades, siendo la principal actividad el intercambio de contenidos. A continuación se
15 definirán las características fundamentales de algunos de los estándares de interoperabilidad que se consideran más significativos en el contexto de esta investigación.
IMS-DRI
El grupo de especificaciones más ambicioso en e-learning y que está teniendo trabajos específicos para la estandarización de los repositorios es IMS, que dentro de sus propuestas maneja IMS Digital Repositories Interoperabilitiy y otras especificaciones que se relacionan con ésta, haciendo posibles, con su implementación, la interoperabilidad de los repositorios en los ambientes e-learning .
A continuación se describe con detalle esta especificación, que se considera una de las especificaciones IMS más relevantes para la construcción e interoperabilidad de los ROA.
IMS DRI tiene como objetivo facilitar el acceso a los contenidos en los repositorios para contextos educativos, con los LMS y los LCMS, pero también con otros sistemas como los portales de búsquedas. Esta especificación se propone para la interoperabilidad entre servicios o aplicaciones que tienen las funciones más comunes de un repositorio: buscar, exponer, colectar, enviar, almacenar, pedir, entregar y alertar. Entre estas funciones, se reconocen cinco combinaciones como actividades principales: Buscar/Exponer, Colectar/Exponer, Enviar/Almacenar, Pedir/Entregar y Alertar/Exponer.
La especificación considera que los repositorios digitales tienen diversidad de formatos en sus contenidos, diferentes sistemas, tecnologías y objetivos, por lo que no tiene requisitos para la operación interna de los repositorios y sus recomendaciones. Para la implementación de las funciones principales, están orientadas a dos tipos de repositorios:
los que ya tienen establecido un protocolo para la interoperabilidad, como Z39.50 (comúnmente utilizado en las bibliotecas digitales), y aquellos repositorios que tienen la capacidad de implementar XQuery (para búsquedas de metadatos en XML) y como protocolo de acceso a SOAP, recomendados por la especificación para los ROA. En la Tabla 1 se resumen las recomendaciones tecnológicas que la especificación hace para cada una de las funciones principales.
16 Tabla 1: Descripción y recomendaciones tecnológicas para las funciones de un repositorio
Función Descripción Recomendación tecnológica
Buscar/Exponer (Search/Expose)
Ejecuta la búsqueda de metadatos asociados con los contenidos que el repositorio expone.
XQuery para colecciones con metadatos en XML y Z39.50 para búsquedas en sistemas bibliotecarios.
Colectar/Exponer (Gather/Expose)
Define la solicitud de metadatos que el repositorio expone, la agregación de los metadatos para utilizarse en búsquedas subsecuentes y la agregación de metadatos para crear nuevos repositorios.
No hay recomendación específica, pero IMS DRI sugiere que OAI puede proveer una funcionalidad adecuada.
Enviar/Almacenar (Submit/Store)
Se enfoca a la manera en la que un objeto se mueve a un repositorio desde un sitio accesible por red y cómo el objeto será representado en el repositorio para su acceso.
Se recomienda el uso de paquetes IMS a través de SOAP.
Pedir/Entregar (Request/Deliver)
Permite, que una vez que el usuario a localizado los metadatos en la función Buscar, pueda solicitar al repositorio el acceso al recurso.
Recomendación general para utilizar HTTP, y FTP, para diferentes tipos de recursos. También IMS CP.
Alertar/Exponer (Alert/Expose)
Función clave, en la que a través de correo electrónico se notifica a los usuarios sobre eventos en el repositorio, pero no está contemplada todavía en esta versión de la especificación.
No hay recomendación específica ya que esta función sale del alcance de esta especificación.
En cuanto a los requisitos de conformidad para la interoperabilidad en esta especificación se apunta que no los hay, ya que las soluciones para el intercambio de información entre repositorios se pueden realizar de distintas maneras y no es posible determinar de forma
17 estricta estos requisitos. En su lugar, se da un listado de las especificaciones y estándares que se recomienda seguir para elegir las aplicaciones y llevar a cabo una implementación que fomente la interoperabilidad (consideradas en las recomendaciones de la Tabla 1). Para asegurar la interoperabilidad global la especificación requiere de más desarrollo.
Para la interoperabilidad de las funciones principales IMS DRI utiliza esquemas definidos en otras especificaciones como IMS LRM (IMS Learning Resource Metadata) e IMS CP (IMS Content packaging), así como de IMS RLI (IMS Resource List Interoperabilitiy) que se describen a continuación.
IMS Learning Resources Meta-Data (IMS LRM): Esta especificación hace más eficiente el proceso de búsqueda y uso de los recursos, ya que proporciona una estructura para los elementos (metadatos) que describen o catalogan los recursos de aprendizaje, incluye también cómo los elementos deben ser usados, representados y organizados. La especificación se basa en la aplicación de LOM.
IMS Content Packaging (IMS CP): Provee la funcionalidad para describir y empaquetar materiales de aprendizaje, tales como cursos individuales o una colección de cursos, en paquetes interoperables y distribuibles. Esta especificación direcciona la descripción, estructura y ubicación de materiales de aprendizaje en línea, así como la definición de algunos tipos específicos de contenidos. Los proveedores y desarrolladores de contenidos utilizan este formato para asegurar que sus productos serán compatibles e importables/exportables con cualquier herramienta que soporte esta especificación.
IMS Resource List Interoperabilitiy (IMS RLI): Detalla como los metadatos estructurados pueden intercambiarse entre sistemas que almacenan y proveen recursos para la creación de listados y para aquellos que reúnen y organizan esos listados para fines educativos o de capacitación.
IMS-DRI será uno de los estándares propuestos para la solución de este trabajo, aunque no serán utilizados todos los estándares que se proponen para cada función, sino se realizarán otras propuestas las cuales han surgido a raíz de esta investigación.
18 SQI (Simple Query Interface)
Es una especificación que pretende ser una capa que garantice la interoperabilidad entre redes o entornos educacionales heterogéneos. El objetivo es ser una parte del sistema que sea capaz de buscar en los distintos repositorios (heterogéneos) de OA existentes en las redes a pesar de que posean interfaces propietarias de búsqueda de cada fabricante.
SQI es neutral en términos de lenguaje de consultas. Es un API (Application Program Interfaces) para establecimiento de sesión y realización de consultas síncronas y asíncronas que define los servicios que un repositorio puede tener disponibles para recibir y responder consultas de otros repositorios, es decir, SQI es parte de la arquitectura para la interoperabilidad de repositorios educativos, la cual define los servicios necesarios para permitir la interoperabilidad entre los mismos. Estos servicios incluyen servicios básicos como por ejemplo servicios de autenticación, gestión de la sesión y servicios de aplicación como gestión de las consultas; para lograr esto SQI define un conjunto de métodos que se muestran a continuación3: (SIMON 2004).
Query Management: Métodos que permiten la configuración de los parámetros de las consultas como son:
setQueryLanguage ():
setResultsFormat ():
setMaxQueryResults ():
setMaxDuration ():
Synchronous Query: Los resultados de las consultas son directamente retornados por el método (synchronous Query). Métodos adicionales permiten la elección de los números de resultados retornados por una consulta (setResultsSetSize) y además permiten conocer el número total de resultados de una consulta (getTotalResultsCount).
3 Estos métodos serán tratados más a fondo en el capítulo siguiente, y se mantendrán los nombres en ingles para no alterar el orden.
19 Asynchronous Query: Los resultados de consultas son enviados por el destino hacia la fuente, este último debe tener implementado un listener (queryResultsListener). Esto implica que la fuente ha de indicar la localización de su listener (set-SourceLocation) antes de enviar una consulta asíncrona.
Para poder comprender como interviene SQI en la conexión entre repositorios ver Anexo 1.
Como se describió en el acápite anterior, IMS DRI define algunas propuestas de estándares a utilizar pero en este trabajo para la implementación de las funcionalidades que tienen que ver con los mismos, se utilizará SQI por las ventajas que presenta, las cuales fueron explicadas anteriormente.
1.5 Proyectos realizados en aras de lograr la interoperabilidad
Son varios los proyectos que existen y que han puesto en práctica muchos de los estándares explicados anteriormente para garantizar la interoperabilidad entre aplicaciones e-learning. A continuación se realiza un pequeño estudio de cada uno de ellos, haciendo énfasis en todo lo que concierne a los repositorios.
1.5.1 CAREO
CAREO (Campus Alberta Repository of Educational Objects), es un repositorio distribuido donde los metadatos de cada objeto de aprendizaje están mucho más detallados, muchos de los objetos de aprendizaje se pueden descargar en forma de paquete comprimido pero el paquete no es estándar, porque no contiene los metadatos. Entre sus metadatos utilizados están: IEEE LOM, CanCore (una adaptación canadiense de LOM). Presenta interoperabilidad con otros repositorios a través de la especificación IMS DRI.
La Aplicación del Repositorio (LCMS) realiza para los usuarios y administradores la búsqueda y acceso al almacén de meta-datos con una interfaz HTML
Los usuarios acceden a los metadatos a través del repositorio CAREO, pero accederán a los objetos educativos distribuidos a través de un servicio Web común.
20
Los recursos u objetos de aprendizaje son distribuidos por toda la red del proyecto CAREO a través de servidores.
Cuando se crea un recurso en un servidor Web, los metadatos que describen dicho recurso son enviados directamente al repositorio CAREO, o se recogen de otro repositorio o almacén de repositorios.
CAREO también recogerá los metadatos de los repositorios que contengan ambos elementos: metadatos y recursos, empleando para ello los protocolos aceptados.
El Componente para el intercambio de metadatos del repositorio CAREO debe recopilar la colección de registros disponibles en otros repositorios o almacenes de metadatos.
1.5.2 ARIADNE
La fundación ARIADNE (Alliance of Remote Instructional Authoring & Distribution Networks for Europe) es una asociación internacional cuyo propósito es fomentar el intercambio de experiencias en el área de la educación abierta y a distancia. En este contexto, la fundación provee a sus miembros de una plataforma computacional común para la edición, clasificación, almacenamiento y consulta de cursos en línea. La principal ventaja que presenta ARIADNE es la posibilidad de hacer búsquedas federadas en otros repositorios externos (MERLOT, EDNA, CGIAR). Para realizar las búsquedas federadas se utiliza un lenguaje de consulta llamado SQI (Simple Query Interface) y utiliza como metadatos IEEE LOM y Dublin Core.
1.5.3 AGREGA
Agrega no es más que un proyecto de software que tiene como objetivo la creación de un conjunto de repositorios federados. Está orientado a compartir los contenidos mediante estándares y utiliza protocolos Open Source de amplia aceptación por la comunidad educativa. Utiliza el estándar de interoperabilidad de Repositorios de IMS (IMS-DRI), que proporciona la funcionalidad básica para explotar los objetos digitales presentes en el repositorio (presentar/almacenar, y solicitar/entregar). Se ha implementado usando Web Services, constituyendo los servicios de una arquitectura orientada a servicios (SOA). En la definición de los servicios no incluidos en IMS DRI se han incorporado las “Open Service Interface Definitions” (OSIDs) elaboradas por el MIT en Open Knowledge Initiative (OKI).
21 La búsqueda de contenidos entre repositorios se ha implementado usando la especificación
“Simple Query Interface” (SQI). Respecto al mecanismo interno de búsqueda en un nodo, se basa en la indexación de un subconjunto de los metadatos que vienen rellenos en el manifiesto de un objeto. Estos metadatos son indexados a través de una herramienta denominada Lucene, que es la que se usa posteriormente para llevar a cabo las búsquedas.Los contenidos almacenados se encuentran empaquetados conforme al estándar SCORM. La información de catalogación se almacena conforme al estándar LOM v.1.0 en español (LOM-ES). (CANABAL and SARAZA 2007).
Para realizar la gestión de los objetos digitales se proporciona un conjunto de herramientas que facilitan la creación, catalogación, validación, publicación, visualización, de los objetos digitales. La interfaz y funcionalidad de ésta se adapta atendiendo al perfil del usuario (docente, gestor,…) y al grado de conectividad disponible (off-line, on-line ligado a un nodo o independiente de los nodos).
1.6 Arquitectura de Software
La necesidad del manejo de la arquitectura de un sistema de software nace de los sistemas de mediana o gran envergadura, que se proponen como solución para un problema determinado. En la medida que los sistemas de software crecen en complejidad, bien sea por el número de requerimientos o por el impacto de los mismos, se hace necesario establecer medios para el manejo de esta complejidad, sin la pérdida de tiempo o la elevación de los costos y gastos de operación.
Con el tiempo se han ido desarrollando mecanismos para conseguir dichos propósitos. En la última década cambió la visión que se tiene de los sistemas de software. Esta nueva visión se llamó “Arquitectura”. Desde los pequeños programas hasta los sistemas mas grandes poseen una estructura y un comportamiento que los hace clasificables según su
“Arquitectura”. Se convirtió en el nuevo aspecto que hizo posible el estudio de sistemas ya implementados así como el desarrollo de nuevos, según la categoría del problema que resuelven y el tipo de “Arquitectura de Software” que se emplea para construirlos.
22 ¿Qué es la Arquitectura de Software?
Existen variadas definiciones de arquitectura de software, para el desarrollo de la presente investigación se tuvo en cuenta la definida por PRESSMAN que plantea lo siguiente:
“… es una descripción de los subsistemas y los componentes de un sistema informático y las relaciones entre ellos (...)” (PRESSMAN 2005)
En introducción a UML, Grady Booch, James Rumbaugh e Ivar Jacobson específicamente refiriéndose a la metodología RUP han formulado un esquema de cinco vistas interrelacionadas que conforman la arquitectura de software. En esta perspectiva, la Arquitectura de Software es un conjunto de decisiones significativas sobre:
La organización del sistema de software.
La selección de elementos estructurales y sus interfaces a través de los cuales se constituye el sistema.
Su comportamiento, según resultados de las colaboraciones entre esos elementos.
La composición de esos elementos estructurales y de comportamiento en subsistemas progresivamente mayores.
El estilo arquitectónico que guía esta organización: los elementos estáticos y dinámicos; sus interfaces, sus colaboraciones y su composición
Estos autores, plantean que la Arquitectura se ve condicionada por los siguientes factores (JACOBSON and BOOCH 2005):
Sobre qué productos de software se desea desarrollar el sistema. (Sistema Operativo, Gestor de Base de Datos, etc.)
El o los productos de Middleware que se quieren utilizar.
23
Sistemas heredados a incorporar en el sistema.
Los estándares y políticas corporativas.
Los requisitos no funcionales generales.
La distribución física de cada uno de los elementos del sistema.
Además en la Arquitectura influye la experiencia del equipo con respecto a este tema, así como los patrones seleccionados para su confección.
Llegar a una Arquitectura estable para el desarrollo de un Software es un proceso complejo y voluminoso que se desarrolla en iteraciones en la fase de elaboración del sistema donde intervienen el o los arquitectos y los desarrolladores del sistema.
Como se ha podido apreciar la Arquitectura de Software no tiene una sola dimensión, está formada por las múltiples vistas concurrentes siguientes: (JACOBSON and BOOCH 2004)
La vista de Casos de Uso.
La vista Lógica.
La Vista de Implementación.
La vista de Procesos.
La vista de Despliegue.
Las mismas, serán explicadas más adelante una vez escogida la metodología para el desarrollo del Sistema y descripción de la Arquitectura.
1.6.1 Estilos arquitectónicos
24 Durante la definición de la arquitectura de software de un sistema están presentes las soluciones que se le darán a las diferentes problemáticas que enfrentará el equipo de desarrollo en la fase de construcción del sistema, muchas de estas soluciones constituyen patrones estándares que son reutilizados y ayudan a realizar diseños mejores y más comprensibles.
La comunidad de patrones ha aplicado estas ideas para registrar soluciones estándares a problemas de la arquitectura que ocurren frecuentemente, los Estilos Arquitectónicos ocupan un lugar importante. Los patrones de arquitectura están dentro de la disciplina arquitectónica, solapándose con los estilos.
Un estilo arquitectónico encapsula decisiones esenciales sobre los elementos arquitectónicos y enfatiza restricciones importantes de los elementos y sus relaciones posibles.
Es decir los estilos arquitectónicos comprenden los componentes (elementos), conectores, configuraciones y restricciones de las aplicaciones informáticas así como sus relaciones y comportamiento.
Los estilos casi siempre se usan combinados; cada capa o componente puede ser internamente de un estilo diferente al de la totalidad; muchos estilos se encuentran ligados a dominios específicos o a líneas de producto particulares.
A continuación se describen de forma resumida algunos estilos, apenas los más representativos, y que de una forma u otra pudieran estar representados en el diseño de la arquitectura del Repositorio de Objetos de Aprendizaje y que son los más usados en la actualidad por muchos arquitectos de software en el Mundo (REYNOSO 2008)
Estilos de Flujo de Datos:
Tubería y filtros.
Estilos Centrados en Datos:
Arquitecturas de Pizarra o Repositorio.
Estilos de Llamada y Retorno:
25
Modelo-Vista-Controlador (MVC).
Arquitecturas en Capas.
Arquitecturas Orientadas a Objetos.
Arquitecturas Basadas en Componentes.
Estilos Peer-to-Peer (punto a punto):
Arquitecturas Basadas en Eventos.
Arquitecturas Orientadas a Servicios.
Estilos de llamada y retorno
Esta familia de estilos enfatiza la modificabilidad y la escalabilidad. Son los estilos más generalizados en sistemas en gran escala. Dentro de los miembros de la familia son las arquitecturas de programa principal y subrutina, los sistemas basados en llamadas a procedimientos remotos, los sistemas orientados a objetos y los sistemas jerárquicos en capas.
Arquitecturas en Capas
Los sistemas o arquitecturas en capas constituyen uno de los estilos que aparecen con mayor frecuencia. (Garlan y Shaw)4 definen el estilo en capas como una organización jerárquica tal que cada capa proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le brinda la inmediatamente inferior.
La arquitectura por capas es un estilo de arquitectura en la que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño, un ejemplo básico de esto es separar la capa de datos de la capa de presentación al usuario.
La ventaja principal de este estilo, es que el desarrollo se puede llevar a cabo en varios niveles y en caso de algún cambio sólo se ataca al nivel requerido sin tener que revisar entre código mezclado.
4 Son personalidades que han influido en el desarrollo de Software, principalmente en la evolución de la arquitectura, tienen como nombre Mary Shaw y David Garlan, proporcionaron una sistematización iluminadora, explicando las diferencias entre definiciones en función de distintas clases de modelos.
26 Además permite distribuir el trabajo de creación de una aplicación por niveles, de este modo, cada grupo de trabajo está totalmente abstraído del resto de los niveles, simplemente es necesario conocer la API que existe entre niveles.
El diseño más se utiliza actualmente es el diseño en tres niveles (o en tres capas).
Capas o niveles
Capa de presentación: presenta el sistema al usuario, le comunica la información y captura la información del usuario dando un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Esta capa se comunica únicamente con la capa de negocio.
Capa de negocio: es donde residen los programas que se ejecutan, recibiendo las peticiones del usuario y enviando las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica de negocio) pues es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos para solicitar al gestor de base de datos para almacenar o recuperar datos de él.
Capa de datos: es donde residen los datos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.
Todas estas capas pueden residir en un único ordenador, si bien lo mas usual es que haya una multitud de ordenadores donde reside la capa de presentación (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o mas ordenadores. Así, si el tamaño o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales recibirán las peticiones del ordenador en que resida la capa de negocio.
Si por el contrario fuese la complejidad en la capa de negocio lo que obligase a la separación, esta capa de negocio podría residir en uno o más ordenadores que realizarían solicitudes a una única base de datos. En sistemas muy complejos se llega a tener una
27 serie de ordenadores sobre los cuales corre la capa de datos, y otra serie de ordenadores sobre los cuales corre la base de datos.
En una arquitectura de tres niveles, los términos “capas” y “niveles” no significan lo mismo.
El término “capa” hace referencia a la forma como una solución es segmentada desde el punto de vista lógico:
-Presentación/ Lógica de Negocio/ Datos.
En cambio, el término “nivel”, corresponde a la forma en que las capas lógicas se encuentran distribuidas de forma física. Por ejemplo:
Una solución de tres capas (presentación, lógica, datos) que residen en un solo ordenador (Presentación + lógica, lógica +datos). Se dice, que la arquitectura de la solución es de tres capas y un nivel.
Una solución de tres capas (presentación+ lógica, lógica+ datos) que residen en dos ordenadores (presentación+ lógica, lógica+ datos). Se dice que la arquitectura de la solución es de tres capas y dos niveles.
Una solución de tres capas (presentación, lógica, datos) que residen en tres ordenadores (presentación, lógica, datos). La arquitectura que la define es solución de tres capas y tres niveles.
Ventajas:
El estilo soporta un diseño basado en niveles de abstracción crecientes, lo cual a su vez permite a los implementadores la partición de un problema complejo en una secuencia de pasos incrementales.
El estilo admite muy naturalmente optimizaciones y refinamientos.
Proporciona amplia reutilización. Al igual que los tipos de datos abstractos, se pueden utilizar diferentes implementaciones o versiones de una misma capa en la medida que soporten las mismas interfaces de cara a las capas adyacentes. Esto conduce a la posibilidad de definir interfaces de capa estándar, a partir de las cuales se pueden construir extensiones o prestaciones específicas.
