PROPUESTA PARA TRABAJO DE GRADO

Transcripción

1 Ingeniería de Sistemas PROPUESTA PARA TRABAJO DE GRADO ARQUITECTURA ORIENTADA A RECURSOS PARA APLICACIONES HIPERMEDIALES EN CONTEXTOS E-LEARNING APLICACIÓN PRÁCTICA CONSTRUIR UNA ARQUITECTURA ORIENTADA A RECURSOS QUE SOPORTE UN PROTOCOLO DE APLICACIÓN EN EL DOMINIO DE E-LEARNING ESTUDIANTE(S) Angélica María Vergara Granados Documento Celular Teléfono fijo Correo Javeriano cc vergara.angelica@javeriana.edu.co DIRECTOR Ing. Julio Ernesto Carreño Vargas Documento Teléfono fijo Correo Javeriano Empresa donde trabaja y cargo cc ext 5311 carreno-j@javeriana.edu.co; Pontificia Universidad Javeriana; Profesor Departamento de Sistemas 11/25/2013

2 Contenido 1 OPORTUNIDAD O PROBLEMÁTICA DESCRIPCIÓN DE LA OPORTUNIDAD O PROBLEMÁTICA FORMULACIÓN JUSTIFICACIÓN IMPACTO ESPERADO DEL PROYECTO DESCRIPCIÓN DEL PROYECTO OBJETIVO GENERAL OBJETIVOS ESPECÍFICOS ENTREGABLES O RESULTADOS ESPERADOS PROCESO FASE DE CARACTERIZACIÓN Metodología Actividades Hitos FASE DE DISEÑO Metodología Actividades Hitos FASE DE VALIDACIÓN Metodología Actividades Hitos GESTIÓN DEL PROYECTO CALENDARIZACIÓN PRESUPUESTO ANÁLISIS DE RIESGOS DERECHOS PATRIMONIALES MARCO TEÓRICO / ESTADO DEL ARTE FUNDAMENTOS Y CONCEPTOS RELEVANTES PARA EL PROYECTO TRABAJOS IMPORTANTES EN EL ÁREA GLOSARIO REFERENCIAS Y BIBLIOGRAFÍA REFERENCIAS BIBLIOGRAFÍA PROPUESTA PARA EL DESARROLLO DEL TRABAJO DE GRADO...23 Página 1

3 ILUSTRACIONES Ilustración 1. Entregables 8 Ilustración 2. Protocolo de Aplicación.20 TABLAS Tabla 1. Cronograma de Trabajo...12 Tabla 2. Estimación Horas Diarias.12 Tabla 3. Estimación Horas Semanales 12 Tabla 4. Estimación Horas por Fases 13 Tabla 5. Presupuesto de Recursos.13 Tabla 6. Especificación Presupuesto de Recursos..14 Tabla 7. Clasificación del Riesgo.15 Tabla 8 Riegos del Proyecto 16 Página 2

4 1 Oportunidad o Problemática 1.1 Descripción de la Oportunidad o Problemática En contextos académicos, se requiere que el acceso a contenidos de aprendizaje sea virtual y para esto, dichos contenidos deben ser creados y almacenados en repositorios como primera medida. Posteriormente se debe encontrar la forma de representarlos correctamente, los cuales se convierten en entidades de negocio que son representadas como recursos. Con los diferentes avances tecnológicos en la web, los procesos de aprendizaje han cambiado y hoy en día se da la posibilidad de implementar dichos procesos a través de e-learning, es decir diseñar, poner en práctica y evaluar un curso o plan informativo desarrollado, por medio de redes de computadores (Andrea M, 2009), es por esto que los sistemas de gestión de aprendizaje tienen la posibilidad de ofrecer este tipo de aprendizaje. Para que esto sea posible es necesario tener en cuenta el proceso que será utilizado para evaluar a cada consumidor del servicio, como por ejemplo un proceso de aprendizaje. Dicho proceso será tomado como un protocolo de aplicación, es decir como un conjunto de interacciones legales necesarias para llegar a un objetivo (Jim Webber, 2010), en otras palabras se podría decir que será tomado como un proceso de negocio. Construir aplicaciones basadas en e-learning es algo que se utiliza hoy en día en cualquier institución educativa, ya que es un medio que apoya el aprendizaje por parte del estudiante y que de igual manera, puede ser de apoyo para el docente. Estas aplicaciones, manejan diferentes contenidos académicos, los cuales son en su mayoría didácticos y son una forma diferente de fomentar el aprendizaje (Andrea M, 2009). Pero para construir estas aplicaciones, se debe tener en cuenta los requerimientos que debe satisfacer para que de esta manera se logre identificar la alternativa que mejor se adapte a lo que se desea. Por otra parte, muchas de estas aplicaciones existentes son hipermediales, es decir, manejan diferentes contenidos como imágenes, sonido, videos, entre otros y su conexión entre ellos (hipervínculos), pero no tienen un proceso de aprendizaje definido, es por esto que cuando se trata de aplicaciones hipermediales, la alternativa que se debe usar es REST (Ver Sección 5. Marco Teórico) ya que se acopla mejor por el manejo que proporciona a aquellos recursos que en este trabajo de grado serán mencionados como objetos virtuales de aprendizaje (Ver Sección 5.Marco Teórico), y de igual manera permite establecer un proceso de aprendizaje, el cual en éste Trabajo de Grado será tomado como protocolo de aplicación, es aquí donde entra a jugar un papel importante las arquitecturas orientadas a recursos puesto que uno de los principios de estos dos últimos términos mencionados es la hipermedia (Savas Parastatidis, 2010), que por definición establece que es la herramienta que permite comunicar e interactuar a los usuarios mediante el uso de hipervínculos en diferentes tipos de contenido (Jim Webber, 2010). Teniendo en cuenta lo ya mencionado, se puede decir que aplicar esto es una alternativa nueva para diseñar e implementar aplicaciones hipermediales que estén basadas en un estilo arquitectural y que expongan protocolos de aplicación en contextos e-learning e integren la hipermedia (Savas Parastatidis, 2010). Página 3

5 Ahora es importante tener en cuenta que actualmente existen varios tipos de sistemas de gestión de aprendizaje que manejan contenidos de aprendizaje virtuales de diferentes maneras y están diseñados con diferentes estilos arquitecturales según sea la necesidad de cada uno, es aquí en donde entra una comparación entre las arquitecturas tipo SOA y REST. Una arquitectura tipo SOA (Arquitectura Orientada a Servicios) es una forma lógica de diseño de un sistema de software que permite proporcionar servicios a cualquiera de las aplicaciones de usuario final o para otros servicios distribuidos en la red (Richard N. Taylor, 2010) (Ver Sección 5. Marco Teórico). Mientras que las arquitecturas tipo REST (Representational State Transfer), hacen referencia a una colección de servicios para el diseño de arquitecturas en red y son ideales para sistemas hipermedia distribuidos como lo es la web (Marset, 2006). Con estas breves definiciones, se debe aclarar cuando es útil hacer diseños arquitecturales tipo SOA o REST. Si lo que se desea es establecer una descripción formal de cómo es la interfaz del servicio, abordar requerimientos no funcionales y poco complejos (transacciones, seguridad, direccionamiento, entre otros) manteniendo información contextual y estados conversacionales, y centrado en el diseño de aplicaciones distribuidas, la solución que mejor se acomoda es un estilo arquitectural tipo SOA; pero si por lo contrario, lo que se quiere es un servicio web que no mantenga estado, mejor rendimiento y conocimiento del contenido que va a ser comunicado entre consumidor y proveedor, la solución arquitectural que soporta esto debe ser tipo REST (Marset, 2006). Aun así es necesario aclarar las características correspondientes a cada uno, las arquitecturas tipo SOA generan ciertos requisitos para el intercambio de mensajes como es la implementación de SOAP (Simple Object Access Protocol) que por definición es un protocolo de mensajería estándar usado en servicios web (ver Sección 5. Marco Teórico), el cual por lo general utiliza HTTP como medio de transporte para comunicar mensajes entre cliente y servidor. Aterrizando un poco los estilos arquitecturales tipo REST, existen las arquitecturas orientadas a recursos (ROA), que se basan en representaciones de recursos y acceso a éstos por medio de sus correspondientes URI (Universal Resource Identifier), ésta arquitectura usa el protocolo HTTP no como medio de transporte como en el caso de SOAP, sino como medio de interacción entre el cliente y el servidor, es decir que gracias a este protocolo se puede tener acceso a los recursos por medio de los métodos de éste protocolo; ROA maneja características específicas como lo es el direccionamiento que por definición dice que una aplicación es direccionable si expone sus datos o los aspectos interesantes de estos como recursos teniendo en cuenta la URI (Universal Resource Identifier) de cada uno de ellos (ruby, 2007); escalabilidad se enfoca en que las peticiones realizadas al servidor sean únicas, es decir cada vez que el cliente realiza una petición ésta termina donde empezó (ruby, 2007); interoperabilidad se refiere a las formas de representación según el dispositivo para que el recurso pueda ser consumido, también depende del estado del recurso y es mostrado por el servidor en xml, página web o texto separado por comas, puesto de HTTP es un protocolo que no maneja estados, cuando se utiliza de manera adecuada permite interpretar cada mensaje sin tener conocimiento alguno de los mensajes precedentes (Marset, 2006); interface única ya que ROA sólo usa el protocolo HTTP, usa los 4 métodos básicos para el manejo de recursos (GET, PUT, POST, DELETE) (ruby, 2007). Página 4

6 Con esto, se puede decir que los objetos virtuales de aprendizaje pueden ser tratados como recursos en un sistema de gestión de aprendizaje (requieren tener tus propias URI s para poder ser representados y trabajar con dicha representación) (Marset, 2006), posteriormente se pueden crear aplicaciones hipermediales teniendo en cuenta un protocolo de aplicación y así mismo tener en cuenta la novedad de contextos e-learning que permiten que los procesos de aprendizaje sean diferentes. Se puede decir que es una alternativa diferente para crear aplicaciones basadas en recursos (Jim Webber, 2010). 1.2 Formulación Cómo construir sistemas distribuidos hipermediales que expongan protocolos de aplicación para contextos e-learning basados en una arquitectura orientada a recursos? 1.3 Justificación Manejar objetos virtuales de aprendizaje como recursos en una arquitectura orientada a recursos, permite que el acceso a las representaciones de éstos sea más ágil gracias al uso del protocolo HTTP y de sus métodos. Pero el acceso a estos recursos debe estar definido en un orden según reglas establecidas, por esto la idea de un protocolo de aplicación basado en procesos de aprendizaje permite que esto sea posible, ya que al establecer un conjunto de interacciones entre los recursos (Jim Webber, 2010) hace que sea posible modificar el estado de la aplicación. Para que esto sea posible, es necesario escoger un diseño arquitectural que se acomode a lo que se quiere lograr, teniendo en cuenta lo mencionado anteriormente (Ver Sección 1.1Descripción de la Oportunidad o Problemática) el estilo más adecuado es una arquitectura orientada a recursos, puesto que sus ventajas permiten una facilidad en el diseño (interoperabilidad, rendimiento e interfaz única). Cabe aclarar que SOA permite también desempeñar esta labor mencionada anteriormente, pero es un estilo arquitectural que se acomoda de mejor manera en otro tipo de contextos y aplicaciones, y de igual manera el intercambio de objetos virtuales de aprendizaje por medio de SOAP implica empaquetar el mensaje en un documento XML teniendo en cuenta la estructura de los sobres (envelope), encabezados (header) y cuerpo del mensaje (body) (Papazoglou, 2008), y enviar todo esto a través de HTTP. Ya que este Trabajo de Grado se centra en la idea del uso de una arquitectura orientada a recursos para construir aplicaciones distribuidas, es importante aclarar las ventajas de este estilo arquitecturas, que en otras palabras vienen siendo las misma que REST, por esto se aclara que dicho estilo se enfoca en escalabilidad y rendimiento para este tipo de sistemas y tiene como ventaja que maneja muchos recursos por medio de pocas operaciones ya definidas por el protocolo HTTP, mientras que SOA se centra en el diseño de dichas aplicaciones y maneja muchas operaciones pero con escasez de recursos (Marset, 2006). Es importante aclarar que crear una aplicación que exponga protocolos de aplicación y que además, se base en procesos de aprendizaje permite al cliente extender y facilitar el acceso a la información no sólo a una persona sino de manera colectiva de tal forma que sea de Página 5

7 gran ayuda para aquellos que no pueden estar de manera presencial adquiriendo conocimientos en alguna asignatura o tema, dicha persona(s) que utilicen el servicio incrementará la autonomía y responsabilidad teniendo en cuenta el proceso de aprendizaje establecido y permite que las limitaciones de espacio/tiempo se hagan a un lado (Andrea M, 2009). De igual manera, permite que el aprendizaje logrado por el estudiante en una clase presencial, sea complementado por medio de aplicaciones hipermediales. 1.4 Impacto Esperado del Proyecto El diseño arquitectural que se genere en este proyecto tiene como fin a corto, mediano y largo plazo, ser una base para la creación de plataformas que se encuentren en contextos e- learning de manera que aprovechen el uso de la hipermedia junto con objetos virtuales de aprendizaje. A corto plazo, se pretende que se use en el desarrollo de aplicaciones que se basen en procesos de aprendizaje en contextos de e-learning, teniendo en cuenta la creación de objetos virtuales de aprendizaje y el correcto uso de estos en una arquitectura orientada a recursos. A mediano plazo y a largo plazo, se pretende que la arquitectura propuesta sea parte de una plataforma de aprendizaje que haga parte del departamento de departamento de ingeniería de sistemas, de manera que se convierta en un apoyo para estudiantes en las aulas de clase y por fuera de estas. Se tiene como meta principal, que el diseño arquitectural sea un apoyo para desarrolladores de aplicaciones y/o plataformas en contextos e-learning, manejando un protocolo de aplicación establecido junto con objetos virtuales de aprendizaje de modo que se generen diferentes alternativas, que apoyen el aprendizaje hacia los estudiantes. Página 6

8 2 Descripción del Proyecto 2.1 Objetivo general Construir una arquitectura orientada a recursos que soporte un protocolo de aplicación en el dominio de e-learning. 2.2 Objetivos Específicos Caracterizar el estilo arquitectural orientado a recursos en contextos de aprendizaje. Diseñar un protocolo basado en recursos hipermediales para una aplicación e- learning. Diseñar una arquitectura dirigida por recursos que soporte el protocolo diseñado. Validar la arquitectura mediante la implementación de un prototipo en el dominio de e-learning 2.3 Entregables o Resultados Esperados Objetivo Específico 1 Documento de investigación pertinente a una arquitectura orientada a recursos (Componentes, relaciones, restricciones, etc). Documento de investigación con especificación de objetos virtuales de aprendizaje en contextos e-learning. Documento de investigación con lista de objetos virtuales de aprendizaje adecuados para ser representados como recursos en una arquitectura orientada a recursos, y su respectiva representación. Objetivo Específico 2 Documento con la especificación del proceso de aprendizaje escogido. Objetivo Específico 3 Documento de arquitectura de software (S.A.D.) Objetivo Específico 4 Documentación de los objetos virtuales de aprendizaje creados y sus correspondientes especificaciones. Documentación del prototipo a implementar. Prototipo implementado con su respectivo código fuente. Ilustración 1. Entregables. Página 7

9 3 Proceso Para la realización de éste de trabajo de grado, se implementará una metodología SCRUM (Gallego), en donde como primera medida se generará un Product Backlog con los artefactos más relevantes que deben generarse, posteriormente se definirán los correspondientes Sprint Backlog que serán desarrollados en cada una de las fases metodológicas (estas serán tomadas como sprints en el desarrollo de éste proyecto). Se estimará una duración de 1 a 4 semanas por Sprint, en donde por cada una se realizará la ejecución del correspondiente Sprint Backlog y BurnDown chart (avance en horas del Product Backlog y/o Sprint Backlog). Cabe aclarar que las primeras fases de ése proyecto serán genéricas, con el fin de que el resultado de estas aplique para cualquier aplicación que se base en el proceso realizado. 3.1 Fase De Caracterización Esta fase será tomada como Sprint 1 en donde se pretende desarrollar el objetivo específico 1 (Ver Sección 2.2 Objetivos Específicos), para realizar esto se implementará una metodología de investigación especulativa que permitirá desarrollar el primer Sprint Backlog Metodología Para el desarrollo de éste Sprint se utilizará una investigación especulativa o deductiva, la cual permite que a través de conceptos se genere una estructuración teórica, que permita adaptar los elementos identificados en el contexto de una arquitectura orientada a recursos, teniendo en cuenta e-learning como el área en la que se trabajará Actividades Hitos Identificar componentes, relaciones, restricciones, y otros elementos de una arquitectura orientada a recursos. Identificar objetos virtuales de aprendizaje relevantes en el contexto de e-learning. Identificar procesos de aprendizaje en e-learning. Identificar tipos de objetos virtuales de aprendizaje adecuados para ser representados como recursos en una arquitectura orientada a recursos. Documento con investigación pertinente a una arquitectura orientada a recursos (componentes, relaciones, restricciones, etc). Documento con especificación de objetos virtuales de aprendizaje en contextos de e-learning. Documento con diagrama de proceso de aprendizaje, que incluye de igual manera una especificación de cada una de las fases del mismo. Página 8

10 Documento con listado de objetos virtuales de aprendizaje adecuados para ser representados como recursos en una arquitectura orientada a recursos, y su respectiva representación. 3.2 Fase De Diseño Esta fase será tomada como Sprint 2, en donde se desea dar solución a los objetivos específicos 2 y 3 (Ver Sección 2.2 Objetivos Específicos) generando un diseño arquitectural que soporte los elementos identificados en el Sprint anterior y que adicionalmente tenga en cuenta el uso de objetos virtuales de aprendizaje Metodología Para el desarrollo de éste Sprint, se usará una metodología de investigación inductiva, en donde por medio de los resultado adquiridos en el Sprint anterior, se pretende diseñar un protocolo de aplicación en base a un proceso de aprendizaje adecuado para contextos e- learning, y de igual manera se diseñará una arquitectura orientada a recursos que soporte tanto objetos virtuales de aprendizaje como el protocolo de aplicación diseñado Actividades Hitos Determinar requerimientos arquitecturalmente significantes del dominio de procesos de enseñanza para e-learning. Diseñar un protocolo de aplicación para contextos de e-learning basados en procesos de enseñanza. Realizar el diseño de una arquitectura orientada a recursos focalizada en un protocolo de aplicación diseñado. Documento con la especificación del proceso de aprendizaje escogido. Documento S.A.D. (Documento de arquitectura de software). 3.3 Fase De Validación Esta fase será tomada como Sprint 3, en donde se pretende dar solución al objetivo específico 4 (Ver Sección 2.2 Objetivos Específicos) generando un prototipo que permita verificar la implementación del Sprint anterior, se tomará un caso base para este Sprint puesto que la idea fundamental de éste proyecto se centra en el Sprint 2, dicho caso será un tema específico de una asignatura del departamento de ingeniería de sistemas Metodología Para el desarrollo de éste Sprint, se utilizará una metodología SCRUM (Larman, 2003), la cual permitirá por medio de iteraciones cortas, crear el prototipo correspondiente que permita Página 9

11 validar los resultados obtenidos en los Sprints anteriores. Se Establecerán 2 Sprints principales (construcción de objetos virtuales de aprendizaje y construcción de la aplicación), ya que se tendrán cuenta los resultados finales de los Sprints anteriores para poder desarrollar las etapas correspondientes a ésta última fase Actividades Hitos Planeación (Product Backlog). Puesta en escena (Identificación de requerimientos y priorización de los mismos). Desarrollo (Elaborar Sprint Backlog para cada iteración, estas iteraciones desarrollarán el prototipo que pruebe la arquitectura planteada y de igual manera incluyen la creación de objetos virtuales de aprendizaje correspondientes). Publicación (Documentación del prototipo). Documento con Product Backlog del caso de estudio. Documento con requerimientos priorizados y especificados. Documento con Sprint Backlog correspondiente al caso de estudio. Documentación de los objetos virtuales de aprendizaje creados y sus correspondientes especificaciones. Documentación del prototipo a implementar. Prototipo implementado con su respectivo código fuente. Página 10

12 4.1 Calendarización 4 Gestión del Proyecto Para realizar la estimación de duración de éste proyecto, se organizaron las actividades planteadas en la sección anterior (Ver Sección 3.Proceso), en sus correspondientes metodologías, del mismo modo se incluyeron fechas de inicio y de finalización para cada actividad, la estimación en horas a la semana, la persona responsable de realizar cada ítem allí establecido, y el entregable que se debe generar para esa actividad (Ver Cronograma.xlsx). La siguiente tabla muestra una aproximación de lo que se acaba de explicar. Cronograma de Trabajo Tarea Fecha Inicio Fecha Finalización Responsable Entregables Tiempo (horas) Metodología Tabla 1. Cronograma de Trabajo Para la asignación de horas por actividad, se tuvo en cuenta lo siguiente: Estimación de horas diarias: Día Lunes Martes Miércoles Jueves Viernes Horas de Trabajo Tabla 2. Estimación Horas Diarias Estimación de horas semanales: Horas por Semana Cantidad de Semanas Total Horas de Trabajo Tabla 3. Estimación Horas Semanales Estimación de horas por fases: Fases Horas Estimadas 1 32 Página 11

13 Total 136 Tabla 4. Estimación Horas por Fases Para una información más completa acerca del desarrollo de las actividades y su correspondiente camino crítico, puede dirigirse al Diagrama de Gantt.pdf. 4.2 Presupuesto Para el desarrollo de las actividades mencionadas en la sección anterior (Ver Sección 3.Proceso), se cuenta con los siguientes recursos: Hardware Computador $ USB $ Servicios Internet $ Energía $ Transporte $ Agua $ Licencias $ Otros Conocimientos Previos $ Costo Total $ Tabla 5. Presupuesto de Recursos Recursos Especificación Página 12

14 Computador Valor: $ Propietario: Angélica Vergara Marca: HP Pavilion dv4 SO: Windows 8 y Linux Mint. Disco Duro: 250GB RAM: 3GB USB Valor: $ Capacidad: 4GB Internet Valor por mes: MB ETB Energía Valor por mes: Transporte Valor por semana: $ Bus Agua Valor por mes: $ Licencias Valor: $ Licencia Microsoft Office 2013 Valor $ Enterprise Architec Conocimientos Previos $ Tabla 6. Especificación Presupuesto de Recursos Algunos de los costos presentados anteriormente son fijos, es decir en el caso de Computadores, medios de almacenamiento externo (USB), y licencias, son precios fijos, mientras que en el caso de los servicios se debe tener en cuenta que dicho valor es mensual y puede variar según sea el caso. 4.3 Análisis de Riesgos Esta sección abarca aquellas situaciones que se pueden presentar y que de igual manera pueden ser inesperadas, generando dificultades durante el desarrollo de éste proyecto. Para comenzar, se manejará una tabla de Clasificación de Riesgo, que permitirá clasificar los riesgos principales de éste Trabajo de Grado. Página 13

15 Cada riesgo será clasificado dentro de un porcentaje correspondiente a un rango. El siguiente paso permitirá visualizar qué tan probable es que ocurra el riesgo y cuál sería su efecto. Rango Probabilidad Efecto Prioridad <10% MB Insignificante 1 10%-25% B Marginal 2 25%-50% MOD Serio 3 50%-75% A Crítico 4 >75% MA Catastrófico 5 Tabla 7. Clasificación del Riesgo La columna de probabilidad se encuentra denotada de la siguiente forma: MB (muy bajo), B (bajo), MOD (moderado), A (alto), MA (muy alto). En la siguiente tabla se enuncian los posibles riesgos para cada fase y su correspondiente análisis. Riesgos del Proyecto Fase Riego Rango Probabilidad Efecto Prioridad Categorización Diseño Retraso en el desarrollo de alguna actividad Falta de evidencia bibliográfica para el desarrollo de cada actividad Retraso en la elaboración de entregables para cada actividad Retraso en el desarrollo de alguna actividad Identificación incorrecta de requerimientos arquitec- 50% A Crítico 4 45% MOD Serio 3 30% MOD Serio 3 50% A Crítico 4 20% B Marginal 2 Página 14

16 turalmente significantes Validación Diseño no adecuado del protocolo de aplicación Diseño arquitectural no adecuado Falla en la corrección de actividades anteriores. Retraso en la elaboración de entregables para cada actividad Retraso en el desarrollo de alguna actividad Falla en la corrección de actividades anteriores. Retraso en la elaboración de entregables para cada actividad 15% B Marginal 2 10% B Marginal 2 35% MOD Serio 3 30% MOD Serio 3 50% A Crítico 4 35% MOD Serio 3 30% MOD Serio 3 Falla en el levantamiento de requerimientos del 35% MOD Serio 3 caso de estudio Tabla 8 Riegos del Proyecto La mitigación de los riesgos identificados en la tabla anterior se basará en las revisiones diarias de cada Sprint, verificando qué se ha hecho, qué se está haciendo, qué se va a hacer, y qué problemas se han generado con respecto a la actividad. De igual modo se realizarán controles de avance, se establecerán recordatorios para cada actividad especificando qué se debe hacer, cómo debería hacerse y para cuándo debería estar listo en entregable correspondiente. Solo si se ve la necesidad, se asignará tiempo extra para completar la actividad o resolver el problema que se presente respecto a ésta. Página 15

17 4.4 Derechos Patrimoniales El presente Trabajo de Grado se llevará a cabo dentro del marco del grupo de investigación ISTAR de la Pontificia Universidad Javeriana de Bogotá y su resultado estará a disposición del grupo ISTAR para futuros trabajos en el área. Así mismo, el resultado del proyecto aportará al marco global del desarrollo del grupo ISTAR, servirá como base para futuros trabajos y proyectos del grupo, y estará a disposición del grupo, sin ninguna restricción de uso, ya sea éste de carácter académico o empresarial. El software producto de este trabajo de grado se licenciará bajo el modelo de software libre con licencia GPL. Página 16

18 5 Marco Teórico / Estado del Arte 5.1 Fundamentos y conceptos relevantes para el proyecto. Para tener mayor claridad de lo que se quiere obtener con éste proyecto, se enunciarán con más profundidad aquellos conceptos fundamentales que juntos, lograrán dar una visión más amplia al lector. Servicio web: Son sistemas que están especialmente diseñados para mantener una comunicación interoperable entre maquinas que se encuentren sobre una red. Por lo general, los servicios web suelen ser APIs web que pueden ser accedidas dentro de una red (principalmente internet) y son ejecutados en el sistema que los aloja. (Marset, 2006). Es común que los servicios web se comuniquen entre sí por medio del estándar SOAP (Simple Object Access Protocol) ya que la comunicación entre estos por lo general se da por medio de mensajes tipo XML. Servicios web tipo REST: Este tipo de servicios intentan imitar el protocolo HTTP estableciendo una interfaz uniforme, por medio de un conjunto de operaciones estándar y que son conocidas, en otras palabras métodos HTTP (GET, POST, PUT ), y por esta razón este tipo de servicios se encuentran enfocados en la interacción con recursos que posean estado. Por otra parte, es importante aclara que REST (Representational State Transfer) es un estilo de arquitectura de software que se acomoda perfectamente a aplicaciones hipermediales como lo es la web. Trabaja estrictamente con una colección de recursos para el buen diseño de arquitecturas en red (Marset, 2006). SOAP: (Simple Object Access Protocol) es un protocolo de mensajería estándar que es utilizado en servicios web, que permite la invocación remota de métodos entre aplicaciones que pasan mensajes y datos de la forma request/response. Su objetivo principal es la comunicación entre aplicaciones. Cubre cuatro áreas específicas como lo es el formato del mensaje (puede ser empaquetado en un documento XML), la descripción (como el mensaje debería ser transportado usando HTTP si se trata de una interacción basada en la web, o SMTP si la interacción está basada en ), un grupo de reglas (deben ser seguidas cuando se procesa un mensaje SOAP), y un grupo de convenciones (conversión de llamados RPC en mensajes SOAP y al contrario) (Papazoglou, 2008). Arquitectura Orientada a Recursos (ROA): una arquitectura orientada a recursos es un estilo arquitectural tipo REST, que utiliza las ventajas de este como lo es el uso de información y representación de ésta a través de recursos (trabaja con representaciones de estos) por medio de métodos HTTP (GET, POST, PUT ), gracias a esto y a la identificación de recursos por medio de URI s, este estilo arquitectural se basa en dos características fundamentales, accesibilidad y statelessness. Se puede decir que cuando se habla de accesibilidad se hace referencia a exponer un conjunto de datos como recursos, una vez realizado esto los recursos son expuestos a través de sus URI s; cuando una aplicación es accesible da a conocer dichas URI s de cada pieza de información que podría servir. Esta justificación es uno de los aspectos más Página 17

19 importantes en cualquier sitio o aplicación web, ya que cuando es accesible, simplemente basta con una URI que permita mostrar el recuso sobre el cual se está trabajando sin tener la necesidad de descargar el sitio o aplicación web y enviarla como archivo adjunto a través de HTTP. Para concretar y ser más precisos acerca del principio de accesibilidad, se puede decir que para que esto ocurra, cada sitio o aplicación web debe tener su propia dirección, la cual debe ser única, en otras palabras su propia URI al igual que los recursos que allí se representen; Por otra parte, la segunda característica de una arquitectura orientada a recursos es que es statelessness, es decir que no conserva estado conversacional, para que este término sea más claro y fácil de entender se explicará de la siguiente manera, cada petición que se realice debe incluir toda la información necesaria para que el servidor pueda cumplirla, puesto que éste no conserva la información de peticiones anteriores (Richard N. Taylor, 2010). Protocolo de Aplicación: En hipermedia, se define protocolo de aplicación como aquel conjunto de interacciones legales necesarias para entender el comportamiento de una aplicación, es decir su estado el cual se podría decir que es como se encuentra ésta en determinado estado del tiempo. Este protocolo define las reglas de interacción que lideran la interacción entre los integrantes de un sistema. Al manejar un protocolo de aplicación, el estado de la aplicación cambia constantemente gracias a un flujo de trabajo o la ejecución de un proceso de negocio, lo que implica que es posible construir aplicaciones que enuncien un flujo de trabajo usando hipermedia (Savas Parastatidis, 2010). Al implementar un protocolo de aplicación usando hipermedia, ésta facilita la el uso de un proceso de negocio reduciendo el acoplamiento entre los servidores y consumidores. En pocas palabras, el uso de un protocolo de aplicación en aplicaciones hipermediales, permite quitar la dependencia de un WADL (Web Application Description Language) ya que el al definir el proceso de negocio se está conociendo lo que la aplicación hace con exactitud. La siguiente ilustración muestra un ejemplo de un protocolo de aplicación. Página 18

20 Ilustración 2. Protocolo de Aplicación. Tomado de (Jim Webber, 2010) Aplicación Hipermedia: cuando se habla de hipermedia, se puede decir que es una tecnología que permite realizar una estructuración de la información (sonido, imágenes, texto), a través de nodos interconectados por enlaces o links, dichos nodos contienen la información ya mencionada antes (Rolando, 2011). Por lo tanto se puede afirmar que una aplicación que maneje la hipermedia, se caracteriza por la transferencia de representaciones de recursos (en este caso el tipo de información mencionada anteriormente), los cuales contienen links que se encuentran ordenados según un protocolo de aplicación. Dichos links, pertenecen a otras representaciones de recursos que hacen parte de la aplicación. Por otra parte también se puede afirmar que el uso de la hipermedia permite capturar el estado actual de la aplicación por medio de documentos hipertexto, los cuales deben estar tanto del lado del servidor (quien sólo conoce el estado de sus recursos) como del lado del cliente (conoce el estado de la sesión). Esta función es realizada por el navegador, quien se encarga de recopilar aquella información necesaria o que simplemente debe cambiar el estado de algún recurso, navegando entre estos (Marset, 2006). E-learning: Es una modalidad de enseñanza-aprendizaje que consiste en diseñar, poner en práctica y evaluar un curso, desarrollado en redes de computador y que a su vez, se puede definir como un tipo de educación ofrecida a personas que se encuentran geográficamente separadas o que actúan en tiempos diferentes al docente, empleando recursos informáticos (Andrea M, 2009). Se caracteriza por el desarrollo de un proceso formativo en aulas o entornos virtuales en donde hay una interacción estudiante-profesor de manera virtual, y en donde el estudiante de igual Página 19