Los contratos context-aware en Aplicaciones para Educación e Investigación

SARTORIO ALEJANDRO

Hacia un Dispositivo Hipermedial Dinámico. Educación e investigación para el campo audiovisual interactivo

Universidad Nacional de Quilmes

Lugar: Bernal, Buenos Aires; Año: 2008; p. 147 - 174

Entre la diversidad de propuestas de diseño de sistemas e-learning con características adaptativas, existen diferentes variantes metodológicas y tecnológicas, una de ellas es la incorporación de contratos context-aware. En el capítulo 5, expusimos las diferencias más significativas entre los sistemas tradicionales para e-learning y nuestra actual propuesta sobre los dispositivos hipermediales context aware dinámicos para educación e investigación. Como avance de la Tercera Fase de las tesis doctoral en curso Contratos para Context-Aware dinámico1y mostrando resultados de las fases anteriores, en este capítulo explicitaremos, qué es un contrato context-aware, cuál es su complejidad y, dónde y cómo se lo puede aplicar. Conceptualizar al contrato como una componente de primera clase, donde las demás componentes que lo relacionan dependen de su funcionamiento, nos brindará una visión más completa orientada a la arquitectura y a la conexión entres sus componentes. Pensar el contrato como una pieza de conexión (referenciado con el termino “connectors”, conectores, en el área de arquitecturas en ingeniería de software) nos permitirá incorporar (conectar) nuevos modelos independientes a los llamados framework e-learning en términos de dicha ingeniería. En la figura 6.1. representamos la integración de un modelo externo con un framework e-learning por medio de un conector referenciado con el nombre componente contrato. Figura 6.1. Representación del contrato como conector entre un framework e-learning y un modelo externo. La componente modelo externo representa una entidad, puede ser un modelo conceptual, una herramienta, applets, API (Application Programming Interface), o cualquier sistema independiente que cumpla con la funcionalidad de brindar información de contexto para ser incorporada en la semántica de la componente contrato. Las herramientas y servicios que componen el framework e-learning son los puntos de comunicación con la componente contrato. Luego, la entidad sistema representa el ambiente del servidor donde se encuentra el entorno de la plataforma e- learning. Este entorno abarca servidores web, servidores de base de datos, sistemas operativos, archivos y repositorios de recursos, sistemas institucionales, etc. La mayoría de los clientes deben ser estándares (similares a Web Browsers) y, las salidas de las aplicaciones deben poder ser presentadas a los clientes usando lenguaje de marcas tipo HTML. En el próximo punto, nos centraremos en la importancia del tipo de modelado y diseño con los que podríamos tratar a los contratos. 6.2. Perspectiva de modelado El modelado y diseño de sistemas orientados a servicios complejos, no sólo contribuye a una mejor comprensión de los problemas o posibles soluciones que se pueden adoptar en un proyecto de I&D como Obra Abierta, sino que facilita la comunicación entre el grupo de investigación, especialmente cuando se encuentran físicamente separados y/o afiliados a diferentes organizaciones. El trabajo de modelado, es la base de procesos de desarrollo orientados a servicios para educación y/o investigación, que debe guiar tanto a los diseñadores como a los desarrolladores en el relevamiento de los requerimientos pedagógicos y/o investigativos para implementarlos en un artefacto – objeto- de software. Esta tarea de modelado puede brindar una guía clara de trabajo al equipo de I&D, entregando las soluciones a tiempo y facilitando el logro de un producto final de alta calidad, con bajos riesgos en el desarrollo. Atendiendo a los cambios de la tecnología y a la continua evolución de los estándares, el correcto modelado y diseño de soluciones Web complejas, se torna cada vez más importante. Resultado de esto, es el nuevo paradigma de desarrollo en sistemas llamado “Model-Driver Architecture” (MDA). MDA está focalizado en la importancia de los modelos de plataformas independientes y plataformas específicas, que permiten una separación de la abstracción del dominio de conocimiento del particular entorno de implementación.En la actualidad, dependiendo de los objetivos de las plataformas, con el desarrollo de herramientas avanzadas para el diseño a partir de códigos de programación, el rol que cumple el modelo (o modelado) comienza a ser fundamental. A través del uso de MDA, el modelo representa a la programación de alto nivel construida para desarrollos de aplicaciones como por ejemplo, un dispositivo hipermedial dinámico como el de Obra Abierta, con requerimientos factibles de trazar (en el sentido del modelado desde el punto de vista de la Ingeniería de Software). Las herramientas avanzadas pueden proveer generación automática de código XML, Java u otro código de programación a partir de un determinado modelo. Un correcto método de modelado debe brindar el soporte necesario para poder tomar la decisión sobre qué parte de la aplicación debe ser expuesta como servicio, o qué parte de la arquitectura debe ser confeccionada para invocar a los servicios Web. El modelado de soluciones orientadas al servicio no es una tarea simple. Los servicios heredan algunas características de sus predecesores – objetos y componentes y también usan elementos del flujo de tareas y de los procesos de negociación. De esta manera, el modelado de servicios debe cubrir totalmente las diferentes facetas funcionales y tecnológicas para su prestación e implementación. El uso de Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) como notación semi-formal para el modelado de servicios es en la actualidad, una elección consensuada por la comunidad informática. Aunque en su origen, UML fue concebido para el modelado de sistemas orientados a objetos, puede ser fácilmente extendido para soportar modelos de otros conceptos tal como actividades de negocios, interfaces de usuarios y esquema de datos. Sin embargo, podemos observar que para el modelado orientado al servicio, todavía este lenguaje se encuentra en una etapa inicial, ya que no ofrece mecanismos para la representación de componentes y servicios a nivel lógico. En Obra Abierta adoptamos estrategias y modelos basados en el concepto de componentes de servicios; similar a la propuesta de Zoran (2006), en su publicación Modeling Services and Components in a Service-Oriented Architecture. Una componente servicio es un bloque principal que interviene en algún tipo de relación entre objetos del sistema, las componentes que conforman a los servicios para educación y/o investigación son modeladas como contratos de servicios en donde se efectúan algunos de los procedimientos pedagógicos o investigativos (en forma de reglas) como ejecuciones de operaciones entre los objetos. El concepto de la componente contrato ha sido introducido en el capítulo anterior, como una pieza de software que permitía la adaptación de servicios al contexto de los objetos que lo utilizaban, o sea como componente para establecer algún tipo de relación “controlada” entre ellos. En este capítulo, a los contratos los abordaremos desde la perspectiva de los MDA, haciendo referencia al propio modelo adoptado en Obra Abierta. 1El presente capítulo y desarrollos, gráficos y tablas sobre Context aware del capítulo anterior, forman parte del texto de la Tesis Doctoral en desarrollo del Becario Lic. Alejandro Sartorio. Doctorado en Ciencias Informática de la Facultad de Informática de la Universidad Nacional de La Plata. Plan de trabajo aprobado por resolución HCA 3300-6865/000 del 16-12-05 (Univ. Nac. de la Plata) Director: Dr. Gustavo Rossi, Codirectora: Dra. Patricia San Martín Conceptualizar al contrato como una componente de primera clase, donde las demás componentes que lo relacionan dependen de su funcionamiento, nos brindará una visión más completa orientada a la arquitectura y a la conexión entres sus componentes. Pensar el contrato como una pieza de conexión (referenciado con el termino “connectors”, conectores, en el área de arquitecturas en ingeniería de software) nos permitirá incorporar (conectar) nuevos modelos independientes a los llamados framework e-learning en términos de dicha ingeniería. En la figura 6.1. representamos la integración de un modelo externo con un framework e-learning por medio de un conector referenciado con el nombre componente contrato. Figura 6.1. Representación del contrato como conector entre un framework e-learning y un modelo externo. La componente modelo externo representa una entidad, puede ser un modelo conceptual, una herramienta, applets, API (Application Programming Interface), o cualquier sistema independiente que cumpla con la funcionalidad de brindar información de contexto para ser incorporada en la semántica de la componente contrato. Las herramientas y servicios que componen el framework e-learning son los puntos de comunicación con la componente contrato. Luego, la entidad sistema representa el ambiente del servidor donde se encuentra el entorno de la plataforma e- learning. Este entorno abarca servidores web, servidores de base de datos, sistemas operativos, archivos y repositorios de recursos, sistemas institucionales, etc. La mayoría de los clientes deben ser estándares (similares a Web Browsers) y, las salidas de las aplicaciones deben poder ser presentadas a los clientes usando lenguaje de marcas tipo HTML. En el próximo punto, nos centraremos en la importancia del tipo de modelado y diseño con los que podríamos tratar a los contratos. 6.2. Perspectiva de modelado El modelado y diseño de sistemas orientados a servicios complejos, no sólo contribuye a una mejor comprensión de los problemas o posibles soluciones que se pueden adoptar en un proyecto de I&D como Obra Abierta, sino que facilita la comunicación entre el grupo de investigación, especialmente cuando se encuentran físicamente separados y/o afiliados a diferentes organizaciones. El trabajo de modelado, es la base de procesos de desarrollo orientados a servicios para educación y/o investigación, que debe guiar tanto a los diseñadores como a los desarrolladores en el relevamiento de los requerimientos pedagógicos y/o investigativos para implementarlos en un artefacto – objeto- de software. Esta tarea de modelado puede brindar una guía clara de trabajo al equipo de I&D, entregando las soluciones a tiempo y facilitando el logro de un producto final de alta calidad, con bajos riesgos en el desarrollo. Atendiendo a los cambios de la tecnología y a la continua evolución de los estándares, el correcto modelado y diseño de soluciones Web complejas, se torna cada vez más importante. Resultado de esto, es el nuevo paradigma de desarrollo en sistemas llamado “Model-Driver Architecture” (MDA). MDA está focalizado en la importancia de los modelos de plataformas independientes y plataformas específicas, que permiten una separación de la abstracción del dominio de conocimiento del particular entorno de implementación.En la actualidad, dependiendo de los objetivos de las plataformas, con el desarrollo de herramientas avanzadas para el diseño a partir de códigos de programación, el rol que cumple el modelo (o modelado) comienza a ser fundamental. A través del uso de MDA, el modelo representa a la programación de alto nivel construida para desarrollos de aplicaciones como por ejemplo, un dispositivo hipermedial dinámico como el de Obra Abierta, con requerimientos factibles de trazar (en el sentido del modelado desde el punto de vista de la Ingeniería de Software). Las herramientas avanzadas pueden proveer generación automática de código XML, Java u otro código de programación a partir de un determinado modelo. Un correcto método de modelado debe brindar el soporte necesario para poder tomar la decisión sobre qué parte de la aplicación debe ser expuesta como servicio, o qué parte de la arquitectura debe ser confeccionada para invocar a los servicios Web. El modelado de soluciones orientadas al servicio no es una tarea simple. Los servicios heredan algunas características de sus predecesores – objetos y componentes y también usan elementos del flujo de tareas y de los procesos de negociación. De esta manera, el modelado de servicios debe cubrir totalmente las diferentes facetas funcionales y tecnológicas para su prestación e implementación. El uso de Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) como notación semi-formal para el modelado de servicios es en la actualidad, una elección consensuada por la comunidad informática. Aunque en su origen, UML fue concebido para el modelado de sistemas orientados a objetos, puede ser fácilmente extendido para soportar modelos de otros conceptos tal como actividades de negocios, interfaces de usuarios y esquema de datos. Sin embargo, podemos observar que para el modelado orientado al servicio, todavía este lenguaje se encuentra en una etapa inicial, ya que no ofrece mecanismos para la representación de componentes y servicios a nivel lógico. En Obra Abierta adoptamos estrategias y modelos basados en el concepto de componentes de servicios; similar a la propuesta de Zoran (2006), en su publicación Modeling Services and Components in a Service-Oriented Architecture. Una componente servicio es un bloque principal que interviene en algún tipo de relación entre objetos del sistema, las componentes que conforman a los servicios para educación y/o investigación son modeladas como contratos de servicios en donde se efectúan algunos de los procedimientos pedagógicos o investigativos (en forma de reglas) como ejecuciones de operaciones entre los objetos. El concepto de la componente contrato ha sido introducido en el capítulo anterior, como una pieza de software que permitía la adaptación de servicios al contexto de los objetos que lo utilizaban, o sea como componente para establecer algún tipo de relación “controlada” entre ellos. En este capítulo, a los contratos los abordaremos desde la perspectiva de los MDA, haciendo referencia al propio modelo adoptado en Obra Abierta. 1El presente capítulo y desarrollos, gráficos y tablas sobre Context aware del capítulo anterior, forman parte del texto de la Tesis Doctoral en desarrollo del Becario Lic. Alejandro Sartorio. Doctorado en Ciencias Informática de la Facultad de Informática de la Universidad Nacional de La Plata. Plan de trabajo aprobado por resolución HCA 3300-6865/000 del 16-12-05 (Univ. Nac. de la Plata) Director: Dr. Gustavo Rossi, Codirectora: Dra. Patricia San Martín