Una metodología basada en XML para la configuración y despliegue de aplicaciones DDS

Transcripción

1 Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación Una metodología basada en XML para la configuración y despliegue de aplicaciones DDS Javier Sánchez Monedero Dirigido por: Juan Manuel López Soler Departamento de Teoría de la Señal, Telemática y Comunicaciones Universidad de Granada Granada, 22 de septiembre de 2008

2

3 Resumen En las últimas décadas, las redes de ordenadores han mejorado en prestaciones y calidad. Estos avances tecnológicos han permitido, y permiten, nuevos paradigmas en el desarrollo de programas, como son las aplicaciones distribuidas. Entre otras tecnologías, para facilitar el desarrollo de estas aplicaciones han aparecido los denominados middlewares: una capa software que facilita al programador la construcción del sistema distribuido abstrayéndole de las tareas de comunicación. Este es el caso de la tecnología DDS (Data Distribution Service), un middleware orientado a la difusión de mensajes en entornos distribuidos con restricciónes de tiempo-real. DDS se utiliza con éxito en redes relativamente pequeñas en las que intervienen unas decenas o centenares de nodos sobre los que ejecutan aplicaciones distribuidas. Actualmente se plantea conocer si DDS puede implantarse en entornos mayores y si mejorará las tecnologías existentes en este campo. El presente proyecto afronta algunos de los retos que aparecen en el desarrollo de grandes escenarios DDS mediante la propuesta de una nueva metodología en el desarrollo de aplicaciones DDS. La metodología planteada minimiza el esfuerzo de programación permitiendo especificar gran parte del escenario DDS mediante XML. En consecuencia, el tiempo de desarrollo de sistemas distribuídos y la probabilidad de que aparezcan errores de programación se reducen. Especialmente para el campo de la experimentación, en el que deben lanzarse muchas pruebas variando las aplicaciones distribuídas, este proyecto resulta de gran interés. La metodología se complementa con el desarrollo de aplicaciones para la coordinación de nodos de la red sobre la que se ejecuta el escenario. Estas herramientas presentan al desarrollador una vista global y de alto nivel para el control del escenario distribuido.

4

5 Agradecimientos En primer lugar quiero agradecer a mi familia, Luis, Maria Jesús y Amaya, el apoyo, el ánimo y la comprensión que me han dado durante mis años de estudios en Córdoba y Granada. En segundo lugar, agradecer los ánimos de mis amigos, en especial el de Carmen. Gracias a ella por aguantar mis dos proyectos y por ayudarme con la documentación. Gracias a todos por asistir a los ensayos de mis presentaciones. Gracias a la gente que hoy en día pasa por la universidad con la intención de aprender, enseñar, debatir y participar activamente en todos sus ámbitos. Gracias a los representantes de alumnos que han compartido su tiempo conmigo en el Consejo de Estudiantes de la Escuela Politécnica de la Universidad de Córdoba, la Delegación de Alumnos de la E.T.S. de Ingenierías Informática y de Telecomunicación de la Universidad de Granada y de la sectorial de estudiantes de Informática (RITSI). No todo tiene que ser lucrativo en esta vida. Dar las gracias mi tutor, Juanma, por el tiempo e interés que ha dedicado a este proyecto. Por último, me gustaría agradecer a Gerardo y Fernando de RTI la resolución de dudas, aportación de ideas y la revisión continua del proyecto. Resulta un verdadero lujo contar con el soporte de personas con gran conocimiento técnico y experiencia. Sinceramente, gracias.

6

7 ÍNDICE GENERAL 1. Introducción Presentación Contextualización La empresa Real-Time Innovations La plataforma PASITO Experimentación con DDS sobre PASITO Definición del problema Objetivos Recursos Humanos Hardware Software Fases de Desarrollo Restricciones Factores dato Factores estratégicos Antecedentes y estado del arte Antecedentes en distribución de datos El lenguaje XML Herramientas para el desarrollo de aplicaciones DDS Aproximación a la solución propuesta Especificación de Requisitos Requisitos Funcionales Requisitos no Funcionales Planificación 23 I

8 4. Análisis de Requisitos Casos de uso del sistema Identificación de los actores del sistema Diagrama de casos de uso Listado de los casos de uso Gramática de interacción con el escenario Definición de la gramática Estructura de datos de órdenes Lenguaje de descripción de aplicaciones Diseño Arquitectura del sistema Cómo describir un escenario DDS? La interacción y coordinación del escenario Funcionalidades para mejorar la flexibilidad del sistema Modelo de interacción de objetos Acción cargar escenario Acción crear entidad DDS Acción iniciar comportamiento Diagrama de clases Implementación Implementación de la orientación a objetos en C Implementación del analizador de gramática semi-natural Estructuración modular del código Modelo Estático: clases DDS XML y parser XML Modelo Dinámico Módulo de coordinación Pruebas Herramientas para la realización de pruebas Pruebas unitarias Pruebas de integración Pruebas de sistema Resultados y Trabajo Futuro Principales contribuciones de este trabajo Trabajo futuro A. Introducción a DDS 85 B. Despliegue y desarrollo de un escenario incrementalmente 93 II

9 C. Ficheros utilizados en las pruebas 103 C.1. Fichero de definición de tipo de documento (DTD) C.2. Fichero de prueba scenario.xml Glosario 109 III

10 IV

11 ÍNDICE DE FIGURAS 1.1. Mapa de la plataforma PASITO Especificación de entidades DDS con Enterprise Architect Descripción de escenarios DDS mediante los modelos Estático y Dinámico Detalle del diagrama de Gantt de la planificación inicial del proyecto Planificación inicial del proyecto en formato tabular Diagrama de casos de uso del sistema Descripción de aplicaciones DDS mediante los modelos Estático y Dinámico Árbol del el Modelo Estático para una aplicación DDS Coordinación del escenario distribuidos utilizando DDS Ejemplo explicativo del funcionamiento de las instancias y parámetros de recursividad Diagrama de secuencia cargar escenario Diagrama de secuencia crear entidad DDS, parte genérica Diagrama de secuencia crear entidad DDS, DDS XMLDomainParticipant Diagrama de secuencia crear entidad DDS, DDS XMLDomainPublisher Diagrama de secuencia crear entidad DDS, DDS XMLDomainSubscriber Diagrama de secuencia iniciar comportamiento, parte genérica Diagrama de secuencia iniciar comportamiento, DDS XMLDomainParticipant Diagrama de secuencia iniciar comportamiento, DDS XMLDomainPublisher Diagrama de secuencia iniciar comportamiento, DDS XMLDomainSubscriber Vista general del diagrama de clases Detalle del diagrama de clases: DDS XMLApplication Detalle del diagrama de clases: DDS XMLParticipant Detalle del diagrama de clases: DDS XMLPublisher Detalle del diagrama de clases: DDS XMLSubscriber Detalle del diagrama de clases: DDS XMLTopic Detalle del diagrama de clases: DDS XMLDataWriter V

12 5.21. Detalle del diagrama de clases: DDS XMLDataReader Detalle del diagrama de clases: CommandPublisher Detalle del diagrama de clases: CommandSubscriber A.1. Arquitectura de un sistema de distribución de datos sin DDS A.2. Arquitectura de un sistema de distribución de datos con DDS A.3. Infraestructura de DDS A.4. Entidades DDS participantes en un Dominio (Domain) A.5. Modelo conceptual de las entidades DDS B.1. Representación de despliegue de un escenario: estado inicial B.2. Representación de despliegue de un escenario: distribución del escenario y asignación de aplicaciones B.3. Representación de despliegue de un escenario: creación varias entidades DDS B.4. Representación de despliegue de un escenario: creación de dos DataWriters 98 B.5. Representación de despliegue de un escenario: inicio de la actividad de algunas entidades B.6. Representación de despliegue de un escenario: incremento del número de entidades y actividad en el escenario B.7. Representación de despliegue de un escenario: destrucción de las entidades DDS B.8. Representación de despliegue de un escenario: finalización de la ejecución de los CommandSubscribers VI

13 ÍNDICE DE CÓDIGO 4.1. Gramática BNF definida para interacción con el escenario Fichero IDL correspondiente al tema de control Descripción de una aplicación Descripción de un participante de dominio (Domain Participant) Descripción de un tema (Topic) Descripción de un publicador (Publisher) Descripción de un subscriptor (Subscriber) Código XML para mostrar el funcionamiento de la herencia Código XML para mostrar el funcionamiento de la herencia Estructura DDS XMLDataReader Tablas del Modelo Dinámico Entradas de las tablas del Modelo Dinámico Integración de CommandPublisher con las reglas de análisis sintáctico de Yacc 70 C.1. Fichero de definición de tipo de documento (DTD) C.2. Fichero de prueba scenario.xml VII

14 VIII

15 CAPÍTULO 1 INTRODUCCIÓN 1.1. Presentación En las últimas décadas, las redes de ordenadores han mejorado en prestaciones y calidad. Estos avances tecnológicos han permitido, y permiten, nuevos paradigmas en el desarrollo de aplicaciones. Este es el caso de las aplicaciones distribuidas: aplicaciones que se ejecutan en plataformas diferentes y que típicamente están conectadas a través de una red, sistemas de ficheros o memoria compartida. Las aplicaciones distribuidas han permitido el desarrollo de soluciones que han supuesto un salto en cuanto al aumento de la capacidad de cómputo y a la conexión entre gran cantidad de productores y consumidores de información. Ejemplos de aplicaciones distribuidas son el correo electrónico, la navegación web, los servicios de mensajería instantánea, la trazabilidad de mercancías, las aplicaciones de cálculo científico distribuidas o el control de tráfico aéreo entre otras. Dependiendo del objeto de la aplicación que se distribuye, la tecnología subyacente en la que se apoya varía sustancialmente. Por ejemplo, un servicio de mensajería instantánea no tiene los mismos requerimientos que una sistema para coordinar vehículos aéreos. Así, han ido surgiendo diferentes tecnologías para dar soporte a distintos sistemas con diferentes requerimientos. Estas tecnologías proporcionan funcionalidades orientadas a satisfacer problemas generales de aplicaciones distribuidas, liberando al desarrollador de las tareas comunes en este tipo de software, de manera que el desarrollo puede centrarse en lo específico del proyecto. Por lo general, estas tecnologías entran dentro del concepto de middleware. Este proyecto se centra en el middleware orientado a mensajes, cuyo objetivo es la distribución de datos a las distintas entidades, productores y consumidores de información, que componen la aplicación distribuida. Al delegarse la comunicación entre aplicaciones 1

16 1. Introducción al middleware, el diseñador de software puede centrarse en la resolución del problema en si. Ejemplos de tecnologías de distribución de datos son los servicios web[1] [2], los servicios de mensajería de Java (JMS, Java Message Service)[3], CORBA (Common Object Request Broker Architecture)[4], MPI (Message Passing Interface, interfaz de paso de mensajes)[5] o DDS (Data Distribution Service)[6]. Muchas aplicaciones con restricciones de tiempo real (RT, Real-Time) utilizan un middleware para resolver las cuestiones de comunicación. Para estas aplicaciones no sólo es importante la capacidad de distribución de datos, sino también la manera en que se distribuyen estos en cuanto a eficiencia, determinismo, seguridad, fiabilidad y notificación y gestión de errores. En este campo se han diseñado soluciones para satisfacer tales restricciones, y este es el caso de la tecnología DDS. DDS son las siglas del estándar Data Distribution Service for Real-Time Systems o servicio de distribución de datos para sistemas de tiempo real[6], estándar mantenido por la OMG (Object Management Group)[7]. DDS es el primer estándar internacional abierto que trata las comunicaciones de publicación subscripción para sistemas de tiempo real y sistemas empotrados. Las implementaciones más conocidas son NDDS[8] de Real Time Innovations[9], OpenSplice DDS[10] de PrismTech[11] y OpenDDS[12] de la empresa Object Computing[13]. Puede consultarse información sobre estas y otras implementaciones en el portal web sobre DDS[14] que mantiene la OMG. RTI Data Distribution Service, también conocido como NDDS, es un middleware de red que implementa un modelo de comunicaciones en tiempo real basado en el paradigma publicación-suscripción que permite a un proceso en un entorno distribuido compartir datos independientemente de la localización física o la arquitectura del resto de procesos. Incluye soporte para comunicaciones deterministas (best-effort) y comunicaciones fiables (reliable), incluyendo comunicaciones fiables basadas en multidifusión (multicast), así como también soporte para comunicaciones cliente-servidor. Una explicación detallada de DDS se proporciona en el Apéndice A. DDS se ha utilizado con éxito en redes relativamente pequeñas en las que intervienen unas decenas o centenares de nodos sobre los que ejecutan aplicaciones distribuidas. Conforme los sistemas distribuidos aumentan en número de nodos participantes, redes que unen estos nodos, y cantidad de entidades DDS que se encargan de la distribución de los datos, aparecen una serie de retos que deben superarse. Aspectos como la configuración de la capa de transporte, la gestión de la seguridad, la definición interfaces de interacción y monitorización de cientos o miles de aplicaciones, la especificación formal del sistema, la escalabilidad, los protocolos de descubrimiento[15] y más constituyen desafíos para las plataformas DDS. A día de hoy, no existen estudios sobre los problemas y límites que DDS puede encontrar en grandes escenarios. Independientemente de los nuevos retos para los fabricantes de productos DDS, el paso a grandes escenarios distribuidos necesita de metodologías y herramientas de prototipado rápido de aplicaciones que permitan hacer uso de todas las funcionalidades ofre- 2

17 1.2. Contextualización cidas por un middleware DDS. Gracias a estas técnicas, el despliegue y gestión de escenarios DDS permitirá identificar cuellos de botella de las implementaciones concretas o de diversas configuraciones posibles en cuanto a dominios, particiones, parámetros de calidad de servicio, temas, etc. El presente proyecto trata de dar solución al despliegue masivo de entidades DDS en redes de gran escala. El objetivo es proporcionar una metodología y herramientas que permitan el desarrollo rápido y libre de errores de aplicaciones distribuidas con la intención de realizar pruebas empíricas con plataformas DDS en redes de grandes dimensiones Contextualización La empresa Real-Time Innovations El proyecto se enmarca dentro del convenio de colaboración del Departamento de Teoría de la Señal, Telemática y Comunicaciones (TSTC en adelante) de la Universidad de Granada con la empresa Real-Time Innovations, inc (también conocida como RTI) 1 situada en Sunnyvale, en el estado de California de los Estados Unidos de América. El Departamento forma parte del programa de universidades de RTI (Real-Time Innovations University Program) 2, por lo que se dispone de licencias de desarrollo gratuitas del middleware RTI Data Distribution Service (o NDDS) La plataforma PASITO Profesores del Departamento TSTC forman parte del proyecto PASITO (plataforma de experimentación de servicios de telecomunicaciones)[16]. PASITO es un laboratorio de pruebas distribuido, que ofrece a los ingenieros la posibilidad de construir, depurar y evaluar escenarios de prueba de servicios de telecomunicaciones. PASITO es una infraestructura pública construida sobre la red académica española RedIRIS 3, utilizando tecnologías variadas para poder probar gran variedad de servicios de telecomunicaciones y, al mismo tiempo, garantizar que su actividad está aislada del resto de los servicios dela red académica, para evitar interferencias con otras actividades que estén en operación para la comunidad científica española. La Figura 1.1 muestra los nodos que componen en la actualidad PASITO. El propósito como laboratorio de servicios de telecomunicaciones es permitir investigaciones sobre: Arquitecturas para Internet

18 1. Introducción Figura 1.1: Mapa de la plataforma PASITO Protocolos de comunicaciones. Tecnologías de transporte con calidad de servicio. Virtualización y autoconfiguración de redes y servicios. Tecnologías y herramientas de monitorización de redes y servicios. Servicios ópticos para proyectos intensivos en datos. Tecnologías de distribución de grandes cantidades de información. Sistemas peer-to-peer. Servicios de movilidad. Tecnologías para mejorar la seguridad en redes. Estándares para servicios de colaboración de nueva generación Experimentación con DDS sobre PASITO PASITO ofrece un laboratorio de telecomunicaciones que brinda oportunidades de experimentación difíciles de conseguir si en la investigación sólo participa un centro. Si retomamos las ideas expuestas en la Sección de Introducción sobre la necesidad de 4

19 1.3. Definición del problema probar y experimentar con DDS en grandes escenarios de aplicaciones distribuidas, parece natural relacionar esto con la oportunidad que nos ofrece la plataforma PASITO. PASITO puede constituir, pues, la infrastructura necesaria para experimentar con DDS en un escenario situado sobre una red de área amplia. No obstante, tal y cómo se presenta en la Sección 1.1 y se concretará más adelante, el despliegue de grandes escenarios DDS en general, y para realizar experimentaciones en particular, requiere de herramientas de apoyo y metodologías de prototipado rápido de aplicaciones que liberen al experimentador de tareas tediosas y propensas a errores para dejar que se centre en el diseño del experimento. Así pues, contextualizamos el desarrollo del proyecto dentro del marco de investigación del despliegue de escenarios DDS sobre redes de área amplia y grandes redes de computadores Definición del problema El desarrollo de aplicaciones DDS, en general, conlleva una serie de tareas que deben realizarse programando, mediante el API proporcionada por la plataforma DDS, la aplicación que se ejecutará en cada nodo. Llamaremos despliegue y desarrollo de un escenario a una serie de tareas necesarias para la construcción, distribución y ejecución de un escenario DDS. Esta tareas incluyen: La creación de aplicaciones con un gran número de entidades DDS asociadas a nodos concretos de la red sobre la que se sitúa al sistema distribuido. La descripción de los parámetros de configuración (dominio, nombres de temas y tipos de tatos, parámetros de QoS... ) para cada una de las entidades DDS que se ejecutarán en cada nodo. El establecimiento de relaciones entre las entidades DDS a nivel intranodo e internodo. La descripción de cada entidad DDS del sistema y la definición de su comportamiento. Se entiende por comportamiento a la actividad que desarrollará la entidad. Por ejemplo, un DataWriter se dedicará a escribir datos en la red. La coordinación y sincronizado del ciclo de vida de de entidades DDS. Además, deben realizarse las tareas habituales en la construcción de una aplicación genérica (escritura del código fuente, compilación y enlazado, etc.) cada vez que se quiera modificar el comportamiento de la misma o los parámetros de uso de las bibliotecas utilizadas. Tras este proceso, se necesita distribuir el resultado de la construcción a los nodos correctos y ejecutar cada aplicación en el nodo adecuado y momento adecuado. 5

20 1. Introducción Este procedimiento a pequeña escala puede realizarse de forma manual. Sin embargo, cuando se trata de escenarios masivos en entornos de área amplia, como el que se propone en la Sección 1.2.2, aparecen problemas que este proyecto trata de resolver. Estos problemas son: 1. Aumento del tiempo de desarrollo con el tamaño del escenario. 2. Garantía de la consistencia relacionada con la probabilidad de cometer errores de programación en si, por un lado, y, por otro, en la correcta asignación de entidades DDS a nodos. 3. Dificultad para reproducir pruebas. El presente proyecto tratará de dar solución a los problemas que se han descrito. Así pues, como resultado final se deberá proporcionar al usuario, el desarrollador de un escenario distribuido de gran tamaño, un conjunto de herramientas que le permita: Automatizar la mayor parte posible de las tareas anteriormente enumeradas. Minimizar la tarea de programación del diseñador de pruebas y liberarle, en la medida de lo posible, del conocimiento profundo del API de DDS. De esta forma se pretende que el usuario se centre en el diseño del sistema y las pruebas, y no en las labores de desarrollo. Coordinar la realización y dar consistencia a las pruebas sobre escenarios en entornos reales Objetivos Descrito ya el problema, en este apartado se detallarán los objetivos que persigue el proyecto: Proporcionar una manera flexible de describir escenarios DDS. Se trata de proporcionar al usuario un conjunto de herramientas que permitan describir un escenario distribuido compuesto por aplicaciones que se comunican utilizando un middleware DDS. Este objetivo se divide en tres subobjetivos: 6 Diseñar un lenguaje de descripción de aplicaciones, esto es, especificar un lenguaje que permita al usuario describir los elementos que conforman el escenario y sus parámetros de configuración. Como resultado, se espera facilitar la descripción de aplicaciones minimizando al mismo tiempo los conocimientos necesarios del API de DDS.

21 1.5. Recursos Proporcionar una interfaz de descripción del comportamiento de las aplicaciones. Este objetivo complementa el anterior, puesto que añade a la descripción de entidades DDS en si, la descripción del comportamiento que éstas tendrán en el escenario. Proporcionar al usuario una metodología de desarrollo rápido de aplicaciones DDS. El proyecto ofrece una alternativa al desarrollo tradicional de aplicaciones 4, así pues, deberá proponerse una nueva metodología de desarrollo de aplicaciones DDS. Dicha metodología establecerá los pasos necesarios para la construcción y despliegue de un escenario distribuido utilizando el sistema desarrollado. Proporcionar mecanismos de control sobre un escenario DDS. El sistema debe proporcionar interfaces de interacción con el escenario de forma que el usuario sea capaz de: Distribuir la descripción del escenario entre los nodos y asignar las aplicaciones DDS adecuadas a los nodos adecuados. Controlar de manera conjunta los procesos de creación o destrucción de las entidades DDS que componen el escenario, esto es, el ciclo de vida de las entidades DDS. Controlar de manera global el comportamiento que tendrán las diferentes entidades DDS del escenario Recursos Definido el problema, en esta sección se describen los recursos humanos, de hardware y de software que se emplearán en el desarrollo del proyecto Humanos Prof D. Juan Manuel López Soler, profesor del Departamento de Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada, como tutor del proyecto. D. Javier Sánchez Monedero, alumno de la Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación de la Universidad de Granada, que será el encargado de realizar dicho proyecto siguiendo las directrices definidas por el tutor del mismo. 4 Entendemos como desarrollo tradicional al que se realiza programando, compilando y distribuyendo aplicaciones. 7

22 1. Introducción Hardware Para el desarrollo del proyecto se dispone de: Ordenador portátil. Impresora láser. Conexión a Internet Software Sistema Operativo GNU/Linux Ubuntu 8.04 Hardy Heron Paquete de utilidades GNU (GNU Binutils) Paquete procesador de textos L A TEX[17]. Entorno de trabajo Kile[18] para documentos escritos con L A TEX. Compilador GCC v3.4 y v4.2. Entorno de desarrollo integrado para C/C++ Eclipse C/C++ Development Tooling - CDT[19]. Depurador GDB v6.8[20]. Herramienta de depuración de problemas de memoria y rendimiento de programas Valgrind[21]. Alleyoop[22], interfaz gráfica para Valgrind. Biblioteca de distribución de datos RTI DDS 4.3b y 4.3e[23] Fases de Desarrollo Para el desarrollo de este proyecto se han considerado una serie de fases bien diferenciadas: 8 1. Revisión del estado del arte: en esta fase se realizará un estudio del campo de middleware y tecnologías relacionadas con DDS, se estudiarán alternativas en la descripción no programática de aplicaciones, así como de los alternativas en despliegue de aplicaciones distribuidas. Para esto se utilizarán todos los recursos bibliográficos y electrónicos disponibles.

23 1.7. Restricciones 2. Especificación: del proyecto para delimitar su ámbito. Para esto se identificarán objetivos y se capturarán los requerimientos funcionales y no funcionales del sistema. Tras esta fase se procederá a la estimación de la planificación temporal. 3. Análisis: de los requerimientos para sentar las bases de una solución al problema. Esta fase incluye la identificación a alto nivel de las necesidades del sistema. Esto incluye la especificación el lenguaje de descripción de escenarios. 4. Diseño: del sistema. Esta etapa incluye el diseño arquitectónico del sistema, la especificación de operaciones, el diagrama de clases del sistema, etc. 5. Implementación: esta etapa consiste en la implementación de los modelos descritos en las fases anteriores. 6. Evaluación: durante esta fase se evaluarán las prestaciones de las herramientas desarrolladas en entornos reales, valorando especialmente su flexibilidad. 7. Documentación: coincidente en el tiempo con las etapas anteriores, se procederá a la generación de la documentación de los resultados pertinentes Restricciones Las restricciones inherentes al proyecto se clasifican en factores dato y factores estratégicos. Ambos factores influyen a la hora de tomar decisiones y delimitan el desarrollo del proyecto Factores dato Se expondrán en esta sección una serie de factores limitativos que condicionan la realización del proyecto. Estas restricciones (también conocidas como factores dato) son limitaciones impuestas que no pueden ser modificadas a lo largo del desarrollo del proyecto, y cuya imposición no tiene por qué estar justificada. Para el presente proyecto son: Económicos: economizar el coste del sistema, tanto hardware como software. Tiempo: el proyecto deberá estar finalizado para septiembre de Hardware: para el desarrollo y simulación del sistema se dispondrá de: Dos ordenadores personales pertenecientes al autor del proyecto. Red LAN conectada mediante un switch Ethernet de 8 puertos 10/100 Mbit/s. Software: 9

24 1. Introducción Plataforma de desarrollo. El desarrollo del proyecto deberá realizarse sobre una de las plataformas (combinación de arquitectura, sistema operativo y versiones de compilador soportadas por NDDS). Considerando el hardware y software habitual en un ordenador personal, una combinación de plataforma de desarrollo aceptable es i86linux2.6gcc3.4.3, que se traduce en arquitectura Intel 86, sistema operativo Linux 2.6 y la versión del compilador GCC. Lenguaje de descripción de aplicaciones. NDDS ya utiliza XML para la configuración de algunas de sus funcionalidades. Es un requerimiento que la descripción de aplicaciones DDS se realice mediante el lenguaje XML para posibilitar la integración de funcionalidades actuales y futuras. Implementación del parser. En la actualidad, el procesado de ficheros XML que se hace en el producto NDDS utiliza la biblioteca EXPAT[24] para construir el reconocedor. Es un requerimiento utilizar esta biblioteca para implementar el procesador de ficheros XML dada su portabilidad a arquitecturas utilizadas por NDDS, entre otras características. Lenguaje de programación de la aplicación. El lenguaje de programación del prototipo será el lenguaje C, ya que es el lenguaje que debe utilizarse con la biblioteca EXPAT. Además, dada la manera en que integran las interfaces para diferentes lenguajes de programación en NDDS, el desarrollo base debe hacerse siempre en C. Humanos: en el desarrollo del proyecto participarán un alumno y el director del proyecto Factores estratégicos Los Factores estratégicos son factores que no dependen de la naturaleza del problema y, por tanto, permiten tomar decisiones entre varias alternativas, lo que abre la posibilidad de mejorar aspectos como por ejemplo los costes, la calidad o la extensibilidad del proyecto. 10 Para este proyecto, consideramos como decisiones estratégicas: Plataforma de desarrollo. Se ha elegido Ubuntu GNU/Linux como plataforma de desarrollo por ser un entorno libre e ideal para el desarrollo de aplicaciones. Muchas herramientas y bibliotecas son compatibles con este sistema operativo, entre ellas NDDS. Entorno de programación. Se ha elegido el entorno de desarrollo libre para C/C++ Eclipse C/C++ Development Tooling - CDT. Eclipse es un entorno de desarrollo excelente, además de por sus funcionalidades como editor y gestor de código, por integrarse a la perfección con otras herramientas libres como el depurador GDB, la herramienta GNU make y el compilador GCC. Además, Eclipse puede extender su funcionalidad para el tratamiento de ficheros XML.

25 1.8. Antecedentes y estado del arte Depuración de errores y rendimiento. Se incluirán opciones de compilación condicional para activar mensajes de depuración en el código, a fin de facilitar la detección de errores durante el desarrollo. Además, se utilizará la herramienta Valgrind para comprobar la correcta liberación de recursos en los momentos adecuados. Portabilidad del desarrollo. Para asegurar la portabilidad de desarrollo a otras plataformas a las que no tenemos acceso, como sistemas operativos de tiempo real, se utilizará de manera estricta el estándar del lenguaje C. El uso de algunas opciones de activación de advertencias del compilador puede ayudar a esto. Construcción del analizador sintáctico. Como se explicará durante el presente documento, se implementará un analizador de lenguaje semi-natural para facilitar la interacción del desarrollador con el escenario. Este analizador sintáctico se construirá utilizando las herramientas Lex y Yacc ya que, no sólo facilitarán la tarea, sino que generarán un analizador óptimo, robusto y fácilmente extensible Antecedentes y estado del arte El problema abordado se centra inicialmente en el prototipado rápido de aplicaciones y reutilización de componentes software. Desde este punto de vista, se pueden encontrar ideas de interés en algunas herramientas de automatización de pruebas distribuidas para DDS. Estas herramientas pueden configurarse, en mayor o menor medida, para adaptarse al tipo de prueba que el usuario quiere realizar. Para situar adecuadamente el trabajo realizado, en el apartado siguiente se examinan los antecedentes en sistemas de distribución de datos. A continuación se presentará brevemente el lenguaje XML y, en último lugar, se examinarán los trabajos más recientes en la configuración y prototipado de aplicaciones DDS Antecedentes en distribución de datos El desarrollo de aplicaciones distribuidas ha merecido grandes esfuerzos de investigación durante ya varias décadas. Entre las herramientas desarrolladas es de especial mención la API Berkeley Socket Distribution[25]. A partir de este punto, se han propuesto numerosos middleware, especificados para verificar los objetivos de simplificar los costes de desarrollo, optimizar las prestaciones y la utilización de los recursos de la red, ofrecer mayor escalabilidad, fiabilidad y disponibilidad, así como potencial interoperatividad entre diferentes plataformas. Mencionar específicamente la librería RPC (Remote Procedure Call[26]), desarrollada para facilitar la ejecución de procedimientos remotos. Recientemente, RPC ha evolucionado para aprovechar la extensibilidad de XML, dando lugar a XML-RPC, middleware que típicamente hace uso del protocolo HTTP para transportar las transacciones. El intercambio de mensajes basados en XML sobre HTTP[27] ha dado lugar al protocolo SOAP 11

26 1. Introducción (Simple Object Access Protocol)[28], el cual es parte fundamental de la pila de protocolos que da soporte a los así denominados Web Services[1], definidos por el consorcio W3C. En esta aproximación, se utiliza WSDL (Web Services Description Language)[2] para describir la interfaz a los objetos remotos. Es también destacable la API RMI (Remote Method Invocation)[29] para Java, la cual proporciona una funcionalidad parecida a RPC. Finalmente, no puede faltar mención a la arquitectura CORBA (Common Object Request Broker Architecture)[4] definida por el consorcio OMG. CORBA proporciona una aproximación basada en objetos, accesibles de forma remota a través de la interfaz IDL (Interface Definition Language)[30]. Todas las tecnologías anteriormente citadas tienen en común la adopción del así denominado paradigma cliente-servidor. Alternativamente, y especialmente diseñado para su utilización en aplicaciones con requisitos de tiempo-real, se ha propuesto middleware que adopta un paradigma distinto al anterior basado en una metodología publicaciónsubscripción. Este modelo se fundamenta en el intercambio asíncrono de mensajes. Aquí, las entidades generadoras declaran los temas que están dispuestas a publicar, y las consumidoras se subscriben a los temas que les sean de interés. Cuando un productor publica un dato en un tópico dado, todos los subscriptores lo recibirán de forma transparente a la aplicación. De esta forma, este paradigma adopta una aproximación denominada datacentric, ya que desacopla (en el tiempo y el espacio) la interacción entre los participantes (consumidores o generadores de información), y se enfoca en la distribución de los datos, con independencia de la localización y el instante del origen o del destino de los mismos. Para la distribución de datos de acuerdo con un paradigma publicación subscripción, la OMG ha especificado recientemente el estándar DDS (Data Distribution Service for Real- Time Systems)[6] lo que, dada la solvencia y reconocimiento de esta institución, ha venido a consolidar definitivamente este nuevo paradigma o modelo de interacción alternativo El lenguaje XML Antecedentes y relevancia de XML XML son las siglas en inglés de Extensible Markup Language ( lenguaje de marcas ampliable )[31]. Es un metalenguaje extensible de etiquetas desarrollado por el W3C (World Wide Web Consortium) y proviene de un lenguaje, inventado por IBM en los años setenta, llamado GML (General Markup Language), que surgió por la necesidad que tenía la empresa de almacenar grandes cantidades de información. XML se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo, etc. XML es una simplificación y adaptación del SGML que permite definir la gramática de lenguajes específicos. Por lo tanto XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Ejemplos de estos lenguajes que usan XML para su definición son XHTML, SVG o MathML. 12 Una manera de describir la gramática de un lenguaje específico basado en XML es

27 1.8. Antecedentes y estado del arte la definición de tipo de documento (DTD, Document Type Definition), que es una descripción de estructura y sintaxis de un documento XML. DTD se incluye dentro del estándar de XML inicial, aunque el propio W3C ha propuesto XSD (XML Schema Definition)[32] como alternativa que supera las limitaciones de DTD. XML presenta varias ventajas como tecnología: Se basa en estándares internacionales y como tal es un estándar abierto. Puede representar estructuras de datos comunes en el campo de la informática: registros, listas y árboles. Los algoritmos de análisis sintáctico son simples, eficientes y consistentes dadas sus restricciones de sintaxis y análisis. XML se utiliza se utiliza masivamente para el almacenamiento y procesamiento de documentos. La adopción de XML en la industria e campos de investigación es alta, y es por ello que existen multitud de herramientas libres para trabajar con XML desde la generación de documentos hasta el procesado de la información almacenada en XML. Un lenguaje basado en XML puede ser fácilmente modificado de manera incremental y sin perder compatibilidad hacia atrás. La validación de documentos mediante lenguajes de esquema como DTD o XSD facilita, entre otras tareas, las relacionadas con la especificación y construcción de software. La estructura jerárquica de XML se utiliza con éxito para representar conocimiento en multitud de campos de trabajo, si bien esta estructura jerárquica no siempre es válida para un dominio de conocimiento. Desventajas de XML y alternativas Existen multitud de debates sobre las ventajas de XML que ponen en relieve circunstancias ante las cuales el uso de XML presenta más desventajas que ventajas[33]. Algunas de estas son: La sintaxis de XML es redundante o grande, en términos de tamaño, en comparación con representaciones de datos alternativos, especialmente si se utiliza para representar datos tabulares. Esta redundancia afecta al rendimiento de las aplicaciones al aumentar el tamaño de almacenamiento y transferencia, así como al coste de procesamiento. 13

28 1. Introducción La sintaxis presenta sobrecarga de información para un lector humano en comparación con otros formatos de transferencia de datos. El modelo jerárquico de representación del conocimiento es limitado en comparación con otras alternativas, como por ejemplo, las orientadas a grafos. La expresión de solapamientos entre relaciones de los nodos requiere un esfuerzo extra. Promueve el uso de estructuras de datos no relacionales (datos no normalizados). XML introduce un fuerte acoplo entre la representación elegida y el procesamiento de la información, a diferencia de las alternativas de almacenamiento relacional y SQL. La mayor parte de las desventajas, como podemos ver, están relacionadas con la validez de XML para representar datos completos y relaciones entre estos datos. Especialmente para representar grandes cantidades de datos que deben procesarse y/o transferirse a través de una red, XML presenta una sobrecarga en el tamaño que ocupa la información al serializarse. En este sentido, han aparecido alternativas como JSON (JavaScript Object Notation, notación de objetos de JavaScript)[34][35]. JSON es un formato ligero para el intercambio de datos que puede sustituir a XML para la representación y transferencia de datos. JSON mejora notablemente el espacio de almacenamiento y ancho de banda durante la transferencia de información, aunque, a cambio, presenta limitaciones respecto a XML[36] Herramientas para el desarrollo de aplicaciones DDS Soporte para DDS de la aplicación Enterprise Architect La empresa Sparx Systems[37] ha desarrollado un complemento de soporte de DDS para su programa de diseño software Enterprise Architect llamado MDG technology for DDS [38]. Esta herramienta es capaz de generar código válido para su compilación mediante la especificación de la aplicación utilizando de la tecnología MDA (Model-driven architecture, arquitectura dirigida por modelos)[39]. La arquitectura dirigida por modelos es un nuevo enfoque para el diseño y desarrollo de sistemas software propuesto por la OMG. MDA es una arquitectura que proporciona un conjunto de guías para estructurar especificaciones expresadas como modelos. Bajo este enfoque, la funcionalidad del sistema se define mediante los modelos independientes de plataforma (PIM, Platform-Independent Model) utilizando un lenguaje específico para un dominio o de propósito general. Para diversas plataformas como CORBA, entornos Web o DDS se define un modelo de definición de plataforma (PDM, Platform Definition 14

29 1.8. Antecedentes y estado del arte Figura 1.2: Especificación de entidades DDS con Enterprise Architect Model). Un modelo PDM es capaz de traducir los modelos PIM en modelos específicos de plataforma (PSM, Platform-Specific Models). Los PSM pueden ser ejecutados directamente en un ordenador. Enterprise Architect permite especificar los modelos a partir de una serie de formularios y diagramas UML (ver Figura 1.2). A partir de esta representación genera código DDS listo para compilarse en la plataforma NDDS. Enterprise Architect es interesante como forma de especificación de parámetros para las entidades DDS sin especificar el comportamiento de estas. Al fin y al cabo, lo que genera esta herramienta es el esqueleto de una aplicación distribuida sobre la que empezar el desarrollo. DDS Benchmark Project El grupo de investigación Distributed Object Computing (DOC) Group for Distributed Real-time and Embedded (DRE) Systems[40] es un grupo compuesto por las universidades 15

30 1. Introducción estadounidenses de Vanderbilt, Washington y California. Este grupo ha desarrollado una herramienta para comparar el rendimiento de diferentes implementaciones del estándar DDS llamada DDS Benchmark Project[41]. DDS Benchmark Project tiene como objetivo evaluar las siguientes características de un producto DDS: El rendimiento respecto a la latencia (latency) y tasa de transferencia (throughput). La facilidad de programación de las interfaces ofrecidas. Las diferencias de rendimiento respecto a otros sistemas de publicación subscripción. Este conjunto de herramientas permiten al usuario configurar la ejecución de pruebas distribuidas. Este sistema cuenta con varias aplicaciones DDS y cada aplicación tiene una serie de entidades DDS predefinidas. Estas entidades admiten una serie de parámetros que se especifican mediante ficheros XML, aunque estos parámetros sólo incluyen la frecuencia de publicación de datos, el tamaño de los datos y algunos parámetros de configuración QoS para DDS. No se puede especificar, por ejemplo, el tipo de datos que se publica, ni combinar varios de estos tipos en un mismo escenario. La distribución del escenario se realiza ubicando una serie de ficheros ejecutables en un sistema de ficheros de red (NFS en concreto) al que todos los nodos tienen acceso. Por otro lado, la creación de entidades DDS y su actividad se controlan mediante una serie de guiones que se ejecutan en cada nodo que participa en la prueba para ejecutar el programa adecuado. El acceso a los nodos se realiza mediante conexiones SSH. El punto fuerte de DDS Benchmark Project es que crea una capa software que adapta los algoritmos genéricos de cada prueba a la interfaz de programación de cada producto DDS, lo que permite desarrollar pruebas idénticas para comparar el rendimiento de diferentes implementaciones de DDS. En la actualidad el proyecto funciona con los productos NDDS[8], OpenSplice[10] y OpenDDS[12] y los resultados experimentales son públicos[42] Aproximación a la solución propuesta Antes de entrar en el desarrollo del proyecto, a modo de resumen, se ofrece una visión general de la solución propuesta. La motivación del proyecto se puede resumir como la búsqueda de una solución al prototipado rápido y masivo de aplicaciones DDS. Ésta solución plantea una serie de retos. El primer reto corresponde a la descripción de aplicaciones que componen el escenario. Para ello, se propone dividir la descripción del escenario en dos modelos: 16

31 1.9. Aproximación a la solución propuesta El Modelo Estático describe las entidades DDS mediante un lenguaje basado en XML que especificará tanto las entidades en sí, como las relaciones entre éstas. El Modelo Dinámico describe el comportamiento de las entidades DDS mediante un lenguaje de programación. Los Modelo Estático y Dinámico son independientes. Esto es, el Modelo Estático de una entidad podrá asociarse a un Modelo Dinámico distinto en momentos diferentes. Esto permitirá cambiar por completo el comportamiento de una aplicación distribuida cambiando el Modelo Dinámico de sus entidades. La Figura 1.3 representa los conceptos de Modelo Estático, Modelo Dinámico y cómo un escenario puede cambiar su comportamiento reemplazando el Modelo Dinámico de sus entidades. El segundo reto corresponde al despliegue y ejecución del escenario. Para ello se dividen los nodos de la red en dos tipos: el nodo Command Master se encarga de publicar instrucciones para el despliegue del escenario, mientras que los nodos que del tipo Command Slaves estarán subscritos a las instrucciones que distribuya este nodo. El problema de la distribución de instrucciones se resuelve utilizando el propio middleware DDS. Los nodos Command Slaves desarrollarán aplicaciones ejecutando las órdenes que reciban los modelos estáticos y dinámicos que se les asocien. El último problema a resolver se refiere a la interacción del desarrollador con el escenario mediante una gramática semi-natural. Esta gramática permitirá especificar las órdenes que se quiere hacer llegar a los nodos del escenario. De esta forma se ofrece una interfaz para controlar el despliegue y permite una visión global del escenario. En resumen, se pretende simplificar la tarea del despliegue de uno o varios escenarios DDS de grandes dimensiones a: La descripción del escenario o escenarios mediante modelos estáticos y dinámicos. El uso los nodos Command Master y Command Slaves para desarrollar estos escenarios. El Apartado 5.1, de arquitectura del sistema, profundiza más en las ideas aquí expuestas. 17

32 1. Introducción Figura 1.3: Descripción de escenarios DDS mediante los modelos Estático y Dinámico 18

33 CAPÍTULO 2 ESPECIFICACIÓN DE REQUISITOS Este capítulo tiene como objetivo identificar el conjunto de requerimientos que el sistema debe de cumplir, diferenciándose en dos tipos: Requisitos funcionales, que son los que se encuentran orientados a la funcionalidad que debe desempeñar la aplicación de cara al usuario final. Requisitos no funcionales, orientados al funcionamiento final de la aplicación. Son requisitos que no tienen que ver con la funcionalidad de la aplicación, sino como se verá más adelante, están más orientados a características que debe cumplir el funcionamiento de la aplicación. El sistema en desarrollo consiste en la creación de un conjunto de herramientas para el desarrollador de aplicaciones que utilicen DDS. El usuario será, pues, un investigador o un desarrollador que pretenda comprobar la adecuación del middleware DDS a la red sobre la que experimenta o sobre el que planea implantar un sistema en producción Requisitos Funcionales Descripción de los parámetros de todas las entidades DDS existentes mediante XML. El punto de partida del proyecto lo constituye la descripción de entidades DDS. Esto se hará mediante la especificación de todos los parámetros que el API de DDS admite para la creación de entidades. Estos parámetros pueden ser datos simples u otras entidades DDS de manera que implícitamente quede definida la relación de jerarquía entre entidades necesaria para que el sistema funcione. Debe tener mención especial la especificación de los parámetros de calidad de servicio (QoS) que se quieran aplicar a las entidades. Es un requerimiento que la descripción de todo este conocimiento se haga mediante un 19

34 2. Especificación de Requisitos documento XML. Este requerimiento implica la definición de tipo de documento (DTD, Document Type Definition) para validar los ficheros XML que el usuario cree. Creación de un parser o analizador sintáctico para los documentos XML definidos. Puesto que se va a trabajar con XML, deberá crearse un analizador sintáctico que permita validar el documento y crear una representación en memoria del mismo que contenga la información del fichero XML de forma estructurada. Esta estructura en memoria será el resultado del proceso de análisis sintáctico del fichero. Es un requerimiento que el analizador sintáctico se implemente extendiendo el actual analizador construido sobre la biblioteca EXPAT (ver Factores Dato). Creación de un API de interacción con el documento XML. Deberá proporcionarse una API que permita al usuario consultar o modificar la información resultante del proceso de análisis sintáctico. Puesto que esta información se almacenará en una estructura de tipo árbol el API debe permitir operaciones comunes que permitan, partiendo de un nodo, acceder a nodos padres, hermanos o hijos. Esto incluye ofrecer al usuario métodos especializados de recorrido del árbol, esto es, dado, por ejemplo, un Tema, debe poder realizarse una operación de acceso directo al nodo del Participante del que es hijo. Complementando a las operaciones de navegación por el árbol, deben proporcionarse métodos de acceso a los datos almacenados en cada nodo. Creación un API que permita integrar métodos escritos por el usuario en el sistema. Como ya se argumentó en la redacción de los Objetivos (1.4), para la especificación del comportamiento será necesario el uso de métodos que describan programáticamente la actividad de cada entidad DDS. Será necesario crear una interfaz de integración de estos métodos del usuario en el sistema, así como definir los límites que el usuario tendrá para escribir este código. Interfaces de programación para la creación y destrucción de entidades DDS. Se debe proporcionar una interfaz de programación que permita la creación y destrucción de las entidades DDS descritas en el documento XML dado un identificador de la entidad o de entidades padres a las que pertenece. Interfaces de programación para la asignación y control del comportamiento de una entidad DDS. Se debe proporcionar una interfaz de programación que permita la asignación de métodos y listeners a entidades DDS descritas en el documento XML dado un identificador de la entidad o de entidades padres a las que pertenece. Interfaz de usuario para coordinar el ciclo de vida y actividad de las entidades DDS del escenario. Puesto que una de las aplicaciones directa del proyecto es la experimen- 20

35 2.2. Requisitos no Funcionales tación escenarios DDS compuestos de muchas entidades, será necesario proporcionar al usuario una interfaz de interacción con el escenario. Esto es decidir en qué momento se crean todas o algunas de las entidades DDS, así como el momento en el que se destruyen o el momento en el que inician su actividad. Podemos adelantar que esta interfaz se encargará de producir órdenes que los nodos del escenario deberán procesar correctamente Requisitos no Funcionales Ejecución de tareas concurrentes. La programación de aplicaciones que procesan flujos de datos diferentes, tanto para leerlos desde la red como para enviarlos a través de la red, de manera simultánea implica el diseño, programación y prueba del software para la ejecución de tareas concurrentes de manera correcta. Rendimiento y consumo de recursos. El uso del proyecto al crear y destruir entidades DDS, hebras de tareas, etc. conllevará la asignación y liberación constante de recursos. Ésta deberá hacerse de forma eficaz y eficiente para no degradar las prestaciones de la máquina donde se ejecuta el proceso y afectar a posteriores usos de la propia aplicación. Flexibilidad. El conjunto de herramientas desarrolladas y la biblioteca de funciones deberán ser flexibles para permitir la descripción de la mayor diversidad de escenarios posibles. Portabilidad. Se deberán cuidar los aspectos de portabilidad respecto de sistemas operativos, compiladores, versiones del compilador y respecto del estándar DDS. Fácil instalación. Puesto que las herramientas deberán distribuirse a muchos nodos de red, el procedimiento de instalación de las herramientas deberá ser lo más sencillo posible. Transparencia y abstracción. Deberá abstraerse al usuario al máximo respecto a las tareas de programación y la especificación de parámetros de las entidades DDS, así como de la difusión de órdenes. 21

36 2. Especificación de Requisitos 22

37 CAPÍTULO 3 PLANIFICACIÓN Una vez obtenidos los requisitos del sistema, se presenta una estimación inicial de las tareas en que se descompone el desarrollo del proyecto. La planificación del proyecto se gestiona con ayuda de la aplicación Planner[43]. La planificación se hizo mediante un diagrama de Gantt. Debido a el tamaño de este tipo de diagramas sólo se mostrará un detalle del mismo a modo de ejemplo (Ver Figura 3.1), mientras que la planificación completa se muestra en forma de tabla de datos. La estimación inicial de tareas y duración de las mismas se muestra en la Figura

38 3. Planificación Figura 3.1: Detalle del diagrama de Gantt de la planificación inicial del proyecto 24

39 Figura 3.2: Planificación inicial del proyecto en formato tabular 25

40 3. Planificación 26

41 CAPÍTULO 4 ANÁLISIS DE REQUISITOS Una vez descrito el problema mediante la identificación de requisitos, funcionales y no funcionales, el siguiente paso es realizar un análisis más detallado de estos. En este capítulo se analizan los requerimientos de la aplicación mediante la identificación y descripción gráfica y textual de casos de uso. De esta forma obtendremos una descripción a alto nivel de las operaciones que debe realizar el sistema. Además, se abordan las necesidades de la gramática de interacción con el escenario, así como la definición de formato de ficheros XML Casos de uso del sistema Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico Identificación de los actores del sistema Usuario Se identifica con el usuario de la aplicación, que en este caso es el desarrollador de aplicaciones distribuidas que quiere desplegar e interaccionar con el servicio de distribución de datos. El usuario interactúa con el sistema para distribuir la descripción del escenario y controlar el ciclo de vida y actividad de las entidades DDS que componen el escenario. Nodo El rol de este actor se identifica con un nodo que participa en el sistema distribuido. Un actor del tipo Nodo interactúa con el Usuario, del que obtiene las acciones a realizar, y mantiene contacto con el actor DDS Middleware para desarrollar las tareas que le asigne el usuario. 27

42 4. Análisis de Requisitos Figura 4.1: Diagrama de casos de uso del sistema DDS XMLParser El rol de este actor se identifica con el software encargado de procesar los ficheros XML que describen el escenario. Como resultado de este procesamiento el DDS XMLParser devolverá el árbol que representa el escenario. DDS Middleware El rol de este actor se identifica con el software encargado de gestionar la funcionalidad relacionada con un servicio de distribución de datos. Conceptualmente, cada Nodo mantendrá contacto con el actor DDS Middleware para realizar las gestiones pertinentes Diagrama de casos de uso En la Figura 4.1 se muestra el diagrama de casos de uso del sistema. En este se expone, con un gran nivel de abstracción, la interacción entre los tres actores del sistema y en qué casos participa cada uno. 28

43 4.1. Casos de uso del sistema Listado de los casos de uso A continuación se describen brevemente los casos de usos identificados en la Figura 4.1. Nótese que la descripción se hace a muy alto nivel. La descripción de estas operaciones se refinará en capítulos posteriores. Cargar escenario. Es un caso de uso base. El objetivo de este caso de uso es hacer llegar la descripción del escenario a todos los nodos que participan en la aplicación distribuida, y que estos seleccionen la aplicación que les corresponda. Este caso de uso se compone de los casos de uso distribuir escenario e interpretar escenario, descritos a continuación. Distribuir escenario. Este caso de uso está incluido en el caso anterior. Hace referencia a la distribución del escenario que el usuario quiere asignar a los nodos participantes. Interpretar escenario. Este caso de uso está incluido en el caso Cargar escenario. Representa las acciones que deben desarrollarse en cada nodo ante la recepción del escenario que se está distribuyendo. Típicamente un nodo que recibe la descripción de un escenario seleccionará una aplicación de entre las descritas en el escenario, dicha selección se hará en base a la información de asignación de aplicaciones a nodos que se etiquete en el fichero. Gestión entidades DDS. Caso de uso base. Abarca todas las operaciones relacionadas con la gestión de la creación y destrucción de las entidades DDS. En él participan todos los actores ya que las entidades se crean y destruyen ante peticiones del Usuario que cada Nodo interpreta. El Nodo se comunicará con el actor DDS para la realizar las operaciones de gestión pertinentes. Crear entidad DDS. Este caso de uso extiende al caso de uso Gestión entidades DDS. La operación consiste en la orden de creación de una entidad DDS dado el identificador de la entidad DDS XML que la envuelve. El Usuario proporciona un identificador de la entidad DDS XML que será utilizado por cada Nodo para buscar esa entidad dentro de la aplicación que tiene asignada. Los Nodos cuya aplicación contengan la entidad DDS XML buscada crearán la entidad DDS que se describe en la misma. Destruir entidad DDS. Este caso de uso extiende al caso de uso Gestión entidades DDS. El objetivo del caso es destruir las entidades DDS a partir de un identificador que proporciona el Usuario. La localización de la entidad se hace de manera similar al caso de uso Crear entidad DDS. La destrucción de una entidad implica el cese de su actividad. Gestión del comportamiento. Es un caso de uso base cuyo objetivo es el control del comportamiento que las entidades tienen en la red. 29

44 4. Análisis de Requisitos Iniciar comportamiento. Este caso de uso extiende al caso Gestión del comportamiento para controlar el inicio del comportamiento de las entidades. La localización de la entidad sobre la que aplicar la operación se realiza como en Crear entidad DDS. Cada Nodo deberá gestionar correctamente la ejecución paralela de tareas de cada entidad DDS que pertenezca a la aplicación que está desarrollando. Parar comportamiento. Este caso de uso extiende al caso Gestión del comportamiento para controlar el fin de la actividad de una entidad. El funcionamiento es el contrario a Iniciar comportamiento Gramática de interacción con el escenario Una de las partes esenciales del proyecto es la interacción que el desarrollador debe tener con el escenario. Como se comentó en la Sección 1.9, se ha optado por un método de interacción con el escenario basado un lenguaje semi-natural. Este lenguaje de interacción debe ser diseñado considerando los casos de uso presentados y las ideas aportadas en el Apartado 1.9. La gramática debe proporcionar mecanismos que hagan que el acceso al escenario DDS por parte del usuario sea lo más sencillo posible. Además de sencilla, debe de ser intuitiva, para que la curva de aprendizaje sea mínima. Es por ello que las palabras que se reconocerán estarán escritas en inglés y tratarán de coincidir con las palabras representativas de acciones similares en otros sistemas como load para indicar la carga de un fichero o create para indicar una acción de creación. Tras estas consideraciones, la gramática debe soportar las siguientes operaciones: 30 Carga, distribución y asignación de aplicaciones. Esta operación deberá distribuir el fichero XML que describe el escenario. La participación en esta operación depende del actor: La aplicación de interacción con el usuario deberá leer el fichero que se le proporciona y distribuirlo, mediante el uso de DDS, al resto de nodos de la red. Si es necesario, el fichero deberá ser dividido en fragmentos para su transmisión dadas las limitaciones de NDDS en este sentido[23]. Los nodos de la red deberán leer, reconstruir y procesar la descripción del escenario para seleccionar una aplicación. Creación y destrucción de entidades DDS dado un identificador de una entidad. Creación y destrucción de todas las entidades DDS del escenario. En este caso es obvio que no se necesita identificador alguno. Inicio y parada de la actividad de entidades DDS dado un identificador de una entidad.

45 4.2. Gramática de interacción con el escenario Inicio y parada de la actividad de todas las entidades DDS del escenario. En este caso es obvio que no se necesita identificador alguno. Liberación de recursos y finalización de la ejecución. El sistema debe proveer de una manera de terminar todas las aplicaciones remotas. Las aplicaciones deberán liberar todos los recursos en uso antes de finalizar la ejecución. Aclarar que una instancia DDS sobre la que aplicar una orden queda identificada por el nombre del objeto DDS XML que la envuelve más un número que indica a qué instancia, de entre las descritas por el objeto DDS XML, se aplica la operación Definición de la gramática Una vez que descritas las operaciones que debe soportar la gramática estamos en disposición de especificarla para dar soporte a estas operaciones. La definición de la gramática se realizará mediante la notación BNF (Backus-Naur form) por ser la forma de especificación más conocida. El Listado 4.1 muestra esta gramática en BNF. <commands> ::= <commands> <command> <command> ::= LOAD <string> CREATE <xml_entity_id> <dds_instance_number> DESTROY <xml_entity_id> <dds_instance_number> START <xml_entity_id> <dds_instance_number> STOP <xml_entity_id> <dds_instance_number> CREATEALL DESTROYALL STARTALL STOPALL TERMINATE <xml_entity_id> ::= <string> <dds_instance_number> ::= [0-9]* <string> ::= [a-za-z\._ 0-9]* Listado 4.1: Gramática BNF definida para interacción con el escenario El siguiente paso es identificar cada tipo de orden o comando con cada una de las operaciones que debe soportar nuestra aplicación: <commands> Es el símbolo inicial de la gramática. Cada línea de texto escrita en el terminal de entrada a la aplicación se considerará como una nueva orden. <command> Aglutina al conjunto de órdenes que son reconocidas. Estas son: LOAD <string>: cargar y distribuir el escenario cuyo fichero se indica como parámetro. Los siguientes parámetros se aplican bajo la premisa de haber cargado un escenario. CREATE <xml_entity_id> <dds_instance_number>: crear la entidad con el primer parámetro como identificador y segundo parámetro como número de instancia DDS. 31

46 4. Análisis de Requisitos DESTROY <xml_entity_id> <dds_instance_number>: destruir la entidad con el primer parámetro como identificador y segundo parámetro como número de instancia DDS. START <xml_entity_id> <dds_instance_number>: iniciar el comportamiento de la entidad con identificador <xml entity id> y número de instancia DDS <dds_instance_number>. STOP <xml_entity_id> <dds_instance_number>: detener el comportamiento de la entidad con identificador <xml entity id> y número de instancia DDS <dds_instance_number>. CREATEALL: crear todas las entidades del escenario. DESTROYALL: destruir todas las entidades del escenario. STARTALL: iniciar el comportamiento de todas las entidades del escenario. STOPALL: detener el comportamiento de todas las entidades del escenario. TERMINATE: destruye todas las entidades, libera recursos y finaliza la ejecución en todos los nodos del escenario Estructura de datos de órdenes Para poder transmitir datos en DDS, estos deben definirse previamente mediante el formato IDL[30]. Como se ha mencionado, las órdenes se transfieren a todos los nodos participantes utilizando un tema de control creado para el middleware NDDS, así que debemos definir el tipo de datos asociado al tema de control. El Listado 4.2 presenta el fichero IDL correspondiente al tema de control. // Valores maximos para los tipos de datos de tamanno variable const unsigned long CMD_ENTITY_NAME_SIZE_MAX = 256; const unsigned long CMD_DATA_NAME_SIZE_MAX = 256; const unsigned long CMD_DATA_MAX_SIZE = 1024; //@top-level false enum CommandKind{ CMD_NOCOMMAND, CMD_START, CMD_START_ALL, CMD_STOP, CMD_STOP_ALL, CMD_CREATE_ENTITIES, CMD_CREATE_ENTITIES_ALL, CMD_DESTROY_ENTITIES, CMD_DESTROY_ENTITIES_ALL, CMD_LOAD_SCENARIO, CMD_TERMINATE, CMD_EXIT }; 32

47 4.3. Lenguaje de descripción de aplicaciones struct Command { // Tipo de orden que contiene la instancia de // datos transferida CommandKind command; // ID de la entidad XML e ID de la instancia DDS a // la que aplicar la orden string <CMD_ENTITY_NAME_SIZE_MAX> entity_name; short instance_id; // Variables para la transferencia de datos auxiliares // como el contenido de un fichero XML string <CMD_DATA_NAME_SIZE_MAX>data_id; string <CMD_DATA_MAX_SIZE> data; }; Listado 4.2: Fichero IDL correspondiente al tema de control 4.3. Lenguaje de descripción de aplicaciones El lenguaje de descripción de escenarios será un lenguaje basado en XML, tal y como se indicó en el Apartado de Factores Dato, y lo describiremos mediante un documento DTD. En esta sección analizaremos la información necesaria que deben manejar los ficheros XML y que debe quedar reflejada en el DTD, junto con las restricciones en las relaciones entre entidades DDS. Comenzaremos introduciendo los atributos comunes a los elementos XML que definiremos más adelante: name: es el nombre o identificador del elemento XML. base name: es el nombre de la clase base para un elemento XML. Esto es, la clase de la que este objeto hereda. Los atributos y etiquetas de la clase base se utilizarán en la clase que hereda de ella, aunque podrán sobreescribirse. Los siguientes elementos podrán estar presentes en todas las entidades: listener: identifica a un listener del Modelo Dinámico que se utilizará con la entidad. behaviour: dentifica a un método del Modelo Dinámico que define el comportamiento de la entidad. instances: número máximo de instancias DDS que se pueden crear para el objeto XML definido. 33

48 4. Análisis de Requisitos El elemento raíz del escenario será dds. Este estará compuesto por una o varias aplicaciones DDS tal y como se muestra en el Listado 4.3. A su vez, estas aplicaciones estarán compuestas por uno o varios participantes de dominio. En el mismo listado también se muestran los elementos comunes enumerados antes. <!-- dds --> <!ELEMENT dds (application)*> <!-- Scenario description: an application --> <!-- Application (contains DDS Entities) --> <!ELEMENT application (participant+)> <!ATTLIST application name CDATA #IMPLIED> <!ATTLIST application base_name CDATA #IMPLIED> <!ELEMENT listener (#PCDATA)> <!ELEMENT behaviour (#PCDATA)> <!-- Number of instances which are going to be created of an entity. This is not mandatory so the default value if not present is 1 --> <!ELEMENT instances (#PCDATA)> Listado 4.3: Descripción de una aplicación El Listado 4.4 muestra cómo un participante de dominio está compuesto de varias entidades hijas que pueden ser temas, publicadores o subscriptores. <!-- participant --> <!ELEMENT participant (domain_id, participant_entities, listener?, behaviour?, instances?)> <!ATTLIST participant name CDATA #IMPLIED> <!ATTLIST participant base_name CDATA #IMPLIED> <!ELEMENT domain_id (#PCDATA)> <!ELEMENT participant_entities (topic publisher subscriber)* > Listado 4.4: Descripción de un participante de dominio (Domain Participant) El Listado 4.5 ilustra la estructura de un tema. No se ha considerado que un tema pueda tener varias instancias puesto que no tiene sentido que haya más de un tema por parti- 34

49 4.3. Lenguaje de descripción de aplicaciones cipante de dominio[44]. Además de los datos comunes a todas las entidades, la descripción de un tema incluye: topic name: el nombre del tema. type: el tipo de datos asociado al tema. <!-- topic --> <!ELEMENT topic (topic_name?, type?, listener?, behaviour?)> <!ATTLIST topic name CDATA #IMPLIED> <!ATTLIST topic base_name CDATA #IMPLIED> <!ELEMENT topic_name (#PCDATA)> <!ELEMENT type (#PCDATA)> Listado 4.5: Descripción de un tema (Topic) El Listado 4.6 muestra, además de los elementos comunes a otras entidades, cómo un publicador estará compuesto de varias entidades hijas escritoras. El mismo listado incluye la definición de un escritor o DataWriter. Destacar que el elemento datawriter topic correspondará a un tema previamente definido. Este tema será el que el DataWriter utilice para publicar datos. El Listado 4.7 es el equivalente al Listado 4.6, pero aplicado a los subscriptores y los lectores de datos. <!-- publisher --> <!ELEMENT publisher (datawriter*, listener?, behaviour?, instances?)> <!ATTLIST publisher name CDATA #IMPLIED> <!ATTLIST publisher base_name CDATA #IMPLIED> <!-- writer --> <!ELEMENT datawriter ( datawriter_topic, listener?, behaviour?, instances?)> <!ATTLIST datawriter name CDATA #IMPLIED> <!ATTLIST datawriter base_name CDATA #IMPLIED> 35

50 4. Análisis de Requisitos <!ELEMENT datawriter_topic (#PCDATA)> Listado 4.6: Descripción de un publicador (Publisher) <!-- subscriber --> <!ELEMENT subscriber (datareader*, listener?, behaviour?, instances?)> <!ATTLIST subscriber name CDATA #IMPLIED> <!ATTLIST subscriber base_name CDATA #IMPLIED> <!-- reader --> <!ELEMENT datareader (datareader_topic?, listener?, behaviour?, instances?)> <!ATTLIST datareader name CDATA #IMPLIED> <!ATTLIST datareader base_name CDATA #IMPLIED> <!ELEMENT datareader_topic (#PCDATA)> Listado 4.7: Descripción de un subscriptor (Subscriber) 36

51 CAPÍTULO 5 DISEÑO Tras la fase de análisis, en la que se identifica qué se quiere hacer, el siguiente paso es cómo se debe hacer. Durante este capítulo se proporcionan los detalles más relevantes del diseño de nuestro sistema Arquitectura del sistema El propósito de esta sección es describir, desde un punto de vista de alto nivel, la solución al problema que este proyecto propone. Esta sección de arquitectura del sistema constituye la parte central del diseño propuesto, y la más importante. En ella se apoya todo el desarrollo realizado Cómo describir un escenario DDS? El primer reto es encontrar la manera de describir un escenario DDS. Si consideramos que un escenario DDS es una gran aplicación distribuida que a su vez se compone de varias aplicaciones, se puede considerar como un primer nivel de descripción a la división del escenario en aplicaciones DDS. Estas aplicaciones DDS podrán ejecutarse en uno o muchos nodos, y a su vez, en un nodo podrán ejecutarse una o varias aplicaciones DDS distintas. Una aplicación DDS estará compuesta por un conjunto de entidades DDS de las identificadas en la Figura A.4 (Apéndice A), estas son: participante de dominio o participante (Domain Participant o Participant), tema (Topic), publicador (Publisher), subscriptor (Subscriber), escritor (DataWriter) y lector (DataReader). Las entidades se crean mediante llamadas al API de DDS ofrecida por el middleware. 37

52 5. Diseño En esta API, salvo algunos parámetros de calidad de servicio, los parámetros son estáticos, es decir, una vez que se crea una entidad con unos parámetros estos no pueden modificarse a no ser que la entidad se destruya y se cree de nuevo. La configuración y creación de entidades DDS constituye la preparación de la infraestructura de comunicación entre aplicaciones que se va a utilizar. Por otro lado, las entidades presentan métodos para realizar acciones en el sistema. Los más utilizados son los métodos para escribir datos en la red, utilizando un DataWriter, y los métodos para leer datos de la red mediante un DataReader. El uso de estos métodos, es decir, los datos que se escriben y se leen, representan la actividad del sistema distribuido y constituyen el punto de conexión entre el middleware DDS y el sistema que se distribuye en si. Por ejemplo, un publicador de información de sensores de temperatura comprobará los sensores de la plataforma en la que se ejecuta y utilizará los métodos de publicación para enviar los datos que recogen de los sensores. Esta división funcional nos lleva a identificar dos modelos necesarios para la descripción de una aplicación DDS: el Modelo Estático y el Modelo Dinámico. El Modelo Estático se corresponde con la especificación de todas las entidades DDS que servirán de soporte a la comunicación entre las aplicaciones distribuidas. El Modelo Dinámico define cómo se comporta cada una de las entidades DDS del escenario. Nuestra propuesta es describir las aplicaciones DDS mediante sus modelos estático y dinámico. Así, el escenario DDS global lo constituirán un conjunto de aplicaciones descritas con estos dos modelos. La Figura 5.1 presenta un escenario DDS compuesto de un conjunto de aplicaciones DDS. Como se puede observar, cada aplicación puede especificarse con los dos modelos propuestos. A continuación se describirán las responsabilidades que se asocian a cada modelo dentro del desarrollo global del escenario. El Modelo Estático El Modelo Estático de una aplicación tiene como objetivo describir la arquitectura de comunicación DDS que utilizará la aplicación distribuida. Esta descripción se hará mediante un fichero XML que especificará los parámetros necesarios de las entidades pertenecientes a la aplicación. Se definirá, pues, un lenguaje de descripción de aplicaciones basado en XML. Esto incluye la definición del tipo de documento (DTD) y la creación de un analizador sintáctico que extraiga información del fichero XML para construir el Modelo Estático de la aplicación. En términos de estructuras de datos, el Modelo Estático de la aplicación es una estructura jerárquica en forma de árbol en la que el nodo raíz es una aplicación DDS. De esta aplicación parten los nodos que representan a las entidades DDS que componen la apli- 38

53 5.1. Arquitectura del sistema Figura 5.1: Descripción de aplicaciones DDS mediante los modelos Estático y Dinámico 39

54 5. Diseño cación. La estructura jerárquica del árbol, definida en el DTD, respeta las relaciones entre entidades definidas en el estándar de DDS[6] (ver Apéndice A). El Modelo Estático se compone de una serie de clases que van a envolver a las entidades DDS. El procesamiento de un fichero XML que describa una aplicación dará lugar a la creación de un árbol cuyos objetos van a ser instancias estas clases. Estas clases reciben el nombre de Entidades DDS XML y existirá una por cada entidad DDS: DDS XMLDomainParticipant para el participante de dominio, DDS XMLPublisher para el publicador, etc. La Figura 5.2 muestra un ejemplo de un árbol que representa una aplicación DDS. Figura 5.2: Árbol del el Modelo Estático para una aplicación DDS Como puede observarse en la Figura 5.2, el Modelo Estático presenta una interfaz de navegación por esta estructura en árbol que facilita el recorrido del mismo y el acceso a la información contenida. Por ejemplo, la clase DDS XMLDataReader tendrá un método llamado get xml subscriber() que permite obtener el nodo del tipo DDS XMLSubscriber del que cuelga. Cada entidad DDS XML es capaz de controlar tanto el ciclo de vida (crear y destruir una entidad) y como el comportamiento de un tipo de entidad DDS (iniciar o detener las acciones que realiza la entidad). Para ello, gestiona información diversa que agrupamos de la siguiente manera: 40 Datos de configuración para la creación de la entidad DDS (identificador de dominio, nombre del tema... ). Parámetros de conexión de la entidad con el Modelo Dinámico correspondiente.

55 5.1. Arquitectura del sistema Otros datos, como los relacionados con la gestión de hebras en la ejecución concurrente de tareas. El Modelo Dinámico El Modelo Dinámico de una aplicación DDS describe el comportamiento que tendrán las entidades que forman la aplicación. El comportamiento se define como la actividad que realiza una entidad. Esto abarca no sólo a la ejecución de tareas programadas sino también la reacción de la entidad a eventos que se produzcan en el sistema. En el caso de la programación de tareas de una entidad, la especificación puede hacerse programando un método que podrá ser utilizado por una o varias entidades. En el caso de la reacción ante eventos se hará utilizando la interfaz de DDS para configurar qué eventos atiende un listener y cómo los gestiona. Un evento puede ser, por ejemplo, la llegada de datos a una cola de recepción o la pérdida de muestras de datos entre los recibidos. El sistema dispondrá de un Modelo Dinámico global que almacene todos los modelos dinámicos que se quieran utilizar. El conjunto de modelos dinámicos definidos formará una tabla sobre la que se podrán realizar búsquedas y obtener elementos que asociar a las Entidades DDS XML para su posterior uso. Mediante esta asociación el Modelo Estático y el Modelo Dinámico quedan conectados La interacción y coordinación del escenario Presentadas las cuestiones relativas a la descripción del escenario, esta sección presenta cómo abordar la coordinación entre las aplicaciones que componen el escenario, así como la interfaz de interacción que el desarrollador tendrá con él. Dicho problema puede ser dividido en dos subproblemas: La distribución de órdenes o comandos a todos los nodos para indicar qué acciones realizar. Para ello se propone delegar esta tarea en el propio middleware DDS. De esta forma se define un tema de control sobre el cual se publicarán datos para la coordinación del escenario. Todos los nodos participantes se subscribirán a este tema de control de forma que recibirán las órdenes publicadas. La interpretación y desarrollo de estas órdenes, que se realizará mediante los nodos Command Slave explicados más adelante. Para desplegar la infraestructura de coordinación necesaria, los nodos de la red participantes en el futuro escenario DDS lo harán con dos roles bien definidos. El papel de Command Master se encarga de publicar órdenes utilizando el tema de control. El resto de nodos participarán como Command Slaves y estarán subscritos al tema de control. Como puede deducirse, sólo puede haber un Command Master para un escenario. 41

56 5. Diseño Figura 5.3: Coordinación del escenario distribuidos utilizando DDS La aplicación que actúe como Command Master tiene dos funciones: interpretar órdenes del usuario y distribuirlas. Para implementar la primera, se propone la creación de una gramática de lenguaje semi-natural que permita al usuario interaccionar con el sistema. Respecto a la distribución de órdenes, se delegará esta función en el propio DDS. El rol de Command Slave implica la subscripción al tema de control para recibir órdenes de la red. El nodo deberá interpretar estas órdenes para desarrollar la parte del escenario que le corresponda. Para ello utilizará la funcionalidad ofrecida por Modelos Estáticos y Dinámicos. La Figura 5.3 ilustra los dos tipos de roles de los nodos participantes en el escenario. En la figura se introducen dos aplicaciones que deben ser lanzadas en los nodos correspondientes: cmdmaster, que se ejecutará en el nodo que juega el papel de Command Master. cmdslave, que se ejecutará en los nodos que actúan como Command Slaves Funcionalidades para mejorar la flexibilidad del sistema Para finalizar este capítulo se introducen algunas ideas de diseño que mejoran la flexibilidad y potencia descriptiva del sistema. 42

57 5.1. Arquitectura del sistema Distribución del escenario y asignación automática de aplicaciones a nodos La distribución del fichero XML que describe un escenario se hará utilizando también DDS para la transferencia. De esta forma se evitan dependencias de mecanismo externos, tal y como ocurre con algunas alternativas estudiadas en la Sección 1.8. Por otro lado, la asignación de aplicaciones DDS a nodos se realiza de forma automática. Cuando un nodo recibe un fichero XML que contiene la lista de aplicaciones de un escenario selecciona una de ellas para desarrollarla. Sobre esta aplicará, a partir de entonces, los órdenes recibidas. La asignación se especifica incluyendo una lista de atributos en las etiquetas XML que representan una aplicación. Estos atributos forman una lista de direcciones IP y nombres de máquina. Cuando un nodo recibe el fichero XML, comprueba si su nombre o dirección IP está en la lista de cada aplicación y así selecciona la aplicación adecuada. Creación de varias instancias, recursividad y herencia Una manera de aumentar la capacidad expresiva del Modelo Estático, y en consecuencia de las acciones que se pueden ejecutar con la interfaz que ofrece, es el soporte para: La especificación de un número máximo de instancias DDS que se pueden crear a partir de un objeto DDS XML. Esto significa que se podrán especificar descripciones del tipo crear 5 DataWriter como writer a en la aplicación a. Este número se especificará como una etiqueta más en el fichero XML. La aplicación recursiva de acciones en las entidades. Esto es, incluir un parámetro que permita especificar si una acción se aplica sobre una sola entidad o también sobre todos sus descendientes en el árbol. Herencia entre objetos DDS XML. A partir de un objeto DDS XML se podrán definir otros objetos como él, que heredarán sus atributos. De esta forma se consigue minimizar el código necesario para describir aplicaciones al permitir la reutilización de componentes anteriormente descritos.. La Figura 5.4 a modo de ejemplo ilustra de manera conjunta los conceptos de instancias y recursividad. Siguiendo la Figura 5.4, se presenta el siguiente subárbol dentro de una aplicación. Aparecen las siguientes entidades DDS XML: un DomainParticipant que tiene un Subscriber que a su vez tiene 2 DataReaders, cada uno de estos con un número diferente de instancias. El DDS XMLDataReader string reader podrá crear hasta 3 instancias DDS y el denominado como octet reader podrá crear hasta 2 instancias DDS. Este número se habrá fijado en la descripción de cada entidad en el fichero XML. Para crear las entidades DDS contenidas en el subárbol caben dos opciones: 43

58 5. Diseño Figura 5.4: Ejemplo explicativo del funcionamiento de las instancias y parámetros de recursividad 44

59 5.2. Modelo de interacción de objetos a) Explícitamente, crear las entidades una por una realizando 3 operaciones como se muestra en la Figura 5.4, a). Al final de este proceso se habrán creado tres entidades DDS: un DomainParticipant, un Subscriber y un DataReader (indicado con el índice 1 y resaltado en la figura). b) Crear las entidades de manera implícita utilizando la opción de recursividad. En este caso sólo sería necesario ejecutar la acción sobre el primer objeto DDS XML- DomainParticipant. Gracias al parámetro para aplicar la operación recursivamente, todos los objetos DDS XML hijos ejecutarán la misma acción. Como muestra la Figura 5.4, b), al final del proceso se habrán creado siete entidades DDS: un Domain- Participant, un Subscriber y 5 DataReaders (3 del tipo string reader y 2 del tipo octet reader ). Como puede comprobarse, de esta forma se puede interaccionar con el escenario de manera flexible. Granularidad de las operaciones Por último, el diseño de las operaciones a todos los niveles debe hacerse con la granularidad más fina posible. Cuanta más fina sea la granularidad mayor flexibilidad se permitirá en la interacción con el escenario. Para conseguir esto, el proceso de creación y destrucción de las entidades se separará de la activación y parada de la actividad de estas. Además, utilizando el concepto de instancias antes presentado se permitirá seleccionar con precisión entidades DDS concretas del árbol Modelo de interacción de objetos Para explicar el funcionamiento y operaciones del sistema, se opta por una descripción formal basada en diagramas de secuencia. Un diagrama de secuencia es una forma de diagrama de interacción que muestra los objetos como líneas de vida a lo largo de la página y con sus interacciones en el tiempo. Las interacciones se represetentan como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino. Con esta notación, se pretende mostrar qué objetos se comunican con qué otros objetos. Esta representación sigue siendo una representación de alto nivel ya que no se considera la ubicación de cada objeto en el sistema distribuido, puesto que a este nivel no es relevante. Tampoco se consideran las operaciones que no implican la comunicación entre objetos, y que, por tanto, carecen de interés en esta sección. Por último, aclarar que no se mostrarán todos los diagramas de secuencia posibles, 45

60 5. Diseño sino los más representativos, ya que el flujo de muchas acciones es prácticamente idéntico. Así, la lista de diagramas de secuencia considerados como representativos es: Operación cargar escenario. Operación crear entidad DDS. Esta operación es equivalente a destruir entidad DDS. Se representará la secuencia crear entidad DDS cuando la entidad es un DomainParticipant DDS. Las simplificaciones de esta operación que no repetiremos son: crear o destruir una entidad DDS cuando la entidad es un Topic DDS crear o destruir una entidad DDS cuando la entidad es un Publisher DDS crear o destruir una entidad DDS cuando la entidad es un Subscriber DDS crear o destruir una entidad DDS cuando la entidad es un DataWriter DDS crear o destruir una entidad DDS cuando la entidad es un DataReader DDS Operación iniciar comportamiento. Esta operación es equivalente a parar comportamiento. Se representará la secuencia iniciar comportamiento cuando la entidad es un DomainParticipant DDS. Las simplificaciones de esta operación que no repetiremos son: iniciar o parar una entidad DDS cuando la entidad es un Topic DDS iniciar o parar una entidad DDS cuando la entidad es un Publisher DDS iniciar o parar una entidad DDS cuando la entidad es un Subscriber DDS iniciar o parar una entidad DDS cuando la entidad es un DataWriter DDS iniciar o parar una entidad DDS cuando la entidad es un DataReader DDS Acción cargar escenario La Figura 5.5 muestra el diagrama de secuencia de la acción cargar escenario. Esta operación es la responsable de leer un fichero XML proporcionado por el usuario y distribuirlo a los nodos del escenario que lo utilizarán para desarrollar sus aplicaciones DDS. Como resultado de estas acciones, cada nodo seleccionará automáticamente una aplicación DDS descrita en el fichero. Se identifican las siguientes operaciones relevantes: readfile: leer un fichero XML proporcionado por el usuario. loadscenario: se produce en dos objetos: 46 En CommandPublisher se refiere al la publicación de una orden cargar escenario que contiene el fichero XML.

61 5.2. Modelo de interacción de objetos En CommandSubscriber se refiere a la recepción del fichero del escenario. Esto incluye la reconstrucción del fichero, que puede haberse recibido en distintos trozos. parsescenario: es el proceso de análisis del fichero del escenario, llevado a cabo por el parser, que aquí consideramos el actor DDS XMLParser (ver Sección 4.1.1). El resultado de esta operación es un árbol que contiene la representación en memoria del escenario compuesta de entidades DDS XML. createapplicacions: DDS XMLParser creará un conjunto de aplicaciones DDS XML que cada CommandSubscriber (un nodo en la prueba) podrá seleccionar. lookupandselectapplication: sobre el árbol compuesto de DDS XMLApplications generado por DDS XMLParser se debe seleccionar una aplicación. Figura 5.5: Diagrama de secuencia cargar escenario Acción crear entidad DDS La acción crear entidad DDS es compleja debido a la cantidad de objetos de distinto tipo que intervienen. Además, se debe dar soporte tanto para la aplicación recursiva de las operaciones como para la existencia de múltiples instancias DDS, tal y como se explicó en 47

62 5. Diseño la Sección Las siguientes figuras describen un único diagrama de secuencia que se ha dividido en varias figuras para poder mostrarlo correctamente. La Figura 5.6 muestra el inicio de la acción desde CommandPublisher. La secuencia continúa en la Figura 5.7. Las operaciones identificadas en esta secuencia son: createddsentity: esta operación tiene como objetivo la creación de una o varias entidades DDS. Se propaga y efectúa en tres objetos: CommandPublisher: inicia la acción crear entidad DDS con los siguientes atributos que se propagarán entre el resto de objetos: id: identificador de la entidad DDS XML a la que se hará llegar la operación en última instancia. index: índice de la instancia DDS dentro de la entidad DDS XML a la que se aplicará la operación. recursive: parámetro lógico para controlar si la operación se aplicará sólo a la instancia afectada o si también se aplicará a las instancias hijas de ésta en el árbol de entidades. CommandSubscriber: recibe el mensaje createddsentity y a su vez se lo envía a la DDS XMLApplication que tiene asociada. La DDS XMLApplication asociada al objeto CommandSubscriber. lookupentity: la aplicación buscará entre el conjunto de entidades DDS XML que la componen para ver si contiene a la entidad identificada por id. Si no es así, la operación termina aquí. La Figura 5.7 continúa la secuencia de la Figura 5.6 para el caso en que la entidad encontrada en la operación lookupentity sea una entidad del tipo DDS XMLDomainParticipant. Se ha elegido este ejemplo por ser el caso más complejo posible, ya que DDS XMLDomainParticipant es la entidad que puede estar compuesta de más entidades a su vez. El diagrama de secuencia para otras entidades DDS XML será siempre una simplificación del explicado aquí. En el diagrama de secuencia crear entidad DDS concerniente al objeto DDS XMLDomainParticipant (Figura 5.7) se identifican las siguientes operaciones: createddsentity: sobre el objeto DDS XMLDomainParticipant provoca la creación de un DomainParticipant DDS con los parámetros de configuración de la entidad DDS XML sobre la que se está aplicando la operación. Esta operación puede propagarse a las entidades hijas del DDS XMLDomainParticipant. createddsentitychilds: es una operación condicionada a que el parámetro recursive esté activado para propagar la operación createddsentity a las entidades hijas de la actual. 48

63 5.2. Modelo de interacción de objetos Figura 5.6: Diagrama de secuencia crear entidad DDS, parte genérica. Continúa en Figura 5.7 getchildstopic: obtiene los DDS XMLTopic hijos del DDS XMLDomainParticipant. Sobre cada hijo obtenido se propagará la acción createddsentity. getchildspublisher: obtiene los DDS XMLPublisher hijos del DDS XMLDomainParticipant. Sobre cada hijo obtenido se propagará la acción createddsentity. getchildssubscriber: obtiene los DDS XMLSubscriber hijos del DDS XMLDomainParticipant. Sobre cada hijo obtenido se propagará la acción createddsentity. createddsdomainparticipant: es la operación que realiza el middleware DDS para crear un DomainParticipant DDS. createddstopic: es la operación que realiza el middleware DDS para crear un Topic DDS. createddspublisher: es la operación que realiza el middleware DDS para crear un Publisher DDS. createddssubscriber: es la operación que realiza el middleware DDS para crear un Subscriber DDS. La Figura 5.8 representa la encadenación de operaciones a las entidades hijas de un objeto DDS XMLPublisher. En ella se identifican las operaciones no descritas anterioremente: createddsentitychilds: si el parámetro recursive está activo, la operación createdd- SEntity se propaga a las entidades hijas. getchildsdatawriter: obtiene los DDS XMLDataWriter hijos del DDS XMLPublisher. Sobre cada hijo obtenido se propagará la acción createddsentity. 49

64 5. Diseño Figura 5.7: Diagrama de secuencia crear entidad DDS, detalle respecto a DDS XMLDomainParticipant. Continúa en Figuras 5.8 y

65 5.2. Modelo de interacción de objetos createddsdatawriter: es la operación que realiza el middleware DDS para crear un DataWriter DDS. La Figura 5.9 es análoga a la Figura 5.8 y representa la encadenación de operaciones a las entidades hijas de un objeto DDS XMLSubscriber. En ella se identifican las operaciones no descritas anterioremente: createddsentitychilds: es una operación condicionada a que el parámetro recursive esté activado para propagar la operación createddsentity a las entidades hijas de la actual. getchildsdatareader: obtiene los DDS XMLDataReader hijos del DDS XMLSubscriber. Sobre cada hijo obtenido se propagará la acción createddsentity. createddsdatareader: es la operación que realiza el middleware DDS para crear un DataReader DDS Acción iniciar comportamiento La acción iniciar comportamiento es similar a crear comportamiento y por ello compleja. Las siguientes figuras describen un único diagrama de secuencia que se ha dividido en varias figuras para poder mostrarlo correctamente. La Figura 5.10 muestra el inicio de la acción desde CommandPublisher. La secuencia continúa en la Figura Las operaciones identificadas en esta secuencia son: startbehaviour: esta operación tiene como objetivo iniciar la actividad de una o varias entidades DDS. Se propaga y efectúa en tres objetos: CommandPublisher: inicia la acción iniciar comportamiento con los siguientes atributos que se propagarán entre el resto de objetos: id: identificador de la entidad DDS XML a la que se hará llegar la operación en última instancia. index: índice de la instancia DDS dentro de la entidad DDS XML a la que se aplicará la operación. recursive: parámetro lógico para controlar si la operación se aplicará sólo a la instancia afectada o si también se aplicará a las instancias hijas de ésta en el árbol de entidades. CommandSubscriber: recibe el mensaje startbehaviour y a su vez se lo envía a la DDS XMLApplication que tiene asociada. La DDS XMLApplication asociada al objeto CommandSubscriber. 51

66 5. Diseño Figura 5.8: Diagrama de secuencia crear entidad DDS, detalle respecto a DDS XMLDomainPublisher. 52 Figura 5.9: Diagrama de secuencia crear entidad DDS, detalle respecto a DDS XMLDomainSubscriber.

67 5.2. Modelo de interacción de objetos Figura 5.10: Diagrama de secuencia iniciar comportamiento, parte genérica. Continúa en Figura 5.11 lookupentity: la aplicación buscará entre el conjunto de entidades DDS XML que la componen para ver si contiene a la entidad identificada por id. Si no es así, la operación termina aquí. La Figura 5.11 continúa la secuencia de la Figura 5.10 para el caso en que la entidad encontrada en la operación lookupentity sea una entidad del tipo DDS XMLDomainParticipant. Se ha elegido este ejemplo por las mismas razones que en la acción crear entidad DDS. En el diagrama de secuencia iniciar comportamiento concerniente al objeto DDS XML- DomainParticipant (Figura 5.11) se identifican las siguientes operaciones: startbehaviour: sobre el objeto DDS XMLDomainParticipant provoca el una serie de acciones para ejecutar la actividad de este. Esta operación puede propagarse a las entidades hijas del DDS XMLDomainParticipant. lookupmethod: sobre el conjunto de modelos dinámicos del sistema, se busca el método que especifica el comportamiento y es asocia a la entidad DDS XML. Este método corresponde al especificado previamente en el fichero XML. startbehaviourmethod: una vez obtenido un método válido, se inicia el comportamiento en si de la entidad DDS adecuada, indicada con el parámetro index. Se debe permitir la ejecución concurrente de la actividad de las entidades, de modo que la ejecución del comportamiento debe lanzarse en una hebra nueva. startbehaviourchilds: es una operación condicionada a que el parámetro recursive esté activado para propagar la operación startbehaviour a las entidades hijas de la actual. 53

68 5. Diseño getchildstopic: obtiene los DDS XMLTopic hijos del DDS XMLDomainParticipant. Sobre cada hijo obtenido se propagará la acción startbehaviour. getchildspublisher: obtiene los DDS XMLPublisher hijos del DDS XMLDomainParticipant. Sobre cada hijo obtenido se propagará la acción startbehaviour. getchildssubscriber: obtiene los DDS XMLSubscriber hijos del DDS XMLDomainParticipant. Sobre cada hijo obtenido se propagará la acción startbehaviour. La Figura 5.12 representa la encadenación de operaciones a las entidades hijas de un objeto DDS XMLPublisher. En ella se identifican las operaciones no descritas anterioremente: startbehaviourchilds: si el parámetro recursive está activo, la operación startbehaviour se propaga a las entidades hijas. getchildsdatawriter: obtiene los DDS XMLDataWriter hijos del DDS XMLPublisher. Sobre cada hijo obtenido se propagará la acción startbehaviour. La Figura 5.13 es análoga a la Figura 5.12 y representa la encadenación de operaciones a las entidades hijas de un objeto DDS XMLSubscriber. En ella se identifican las operaciones no descritas anterioremente: startbehaviourchilds: es una operación condicionada a que el parámetro recursive esté activado para propagar la operación startbehaviour a las entidades hijas de la actual. getchildsdatareader: obtiene los DDS XMLDataReader hijos del DDS XMLSubscriber. Sobre cada hijo obtenido se propagará la acción startbehaviour. 54

69 5.2. Modelo de interacción de objetos Figura 5.11: Diagrama de secuencia iniciar comportamiento, detalle respecto a DDS XMLDomainParticipant. Continúa en Figuras 5.12 y

70 5. Diseño Figura 5.12: Diagrama de secuencia iniciar comportamiento, detalle respecto a DDS XMLDomainPublisher. 56

71 5.2. Modelo de interacción de objetos Figura 5.13: Diagrama de secuencia iniciar comportamiento, detalle respecto a DDS XMLDomainSubscriber. 57

72 5. Diseño 5.3. Diagrama de clases Esta sección presenta el diagrama de clases del sistema. La representación se ha dividido en una vista general de las clases (Figura 5.14) por un lado y, por otro, la representación de cada clase por separado para poder mostrar sus detalles. Figura 5.14: Vista general del diagrama de clases El diagrama de clases general muestra las relaciones entre las clases del tipo DDS XML. Cada una de estas clases equivale a su correspondiente clase DDS. Este diagrama respeta las relaciones conceptuales de las clases tal y como se especifica en el estándar DDS[6]. Como puede verse en la Figura 5.14, queda claro cómo una aplicación DDS, representada por DDS XMLApplication, está compuesta de un conjunto de entidades DDS, representadas por clases del tipo DDS XMLEntity. Otra relación que cabe destacar es la asociación de una DDS XMLApplication a un CommandSubscriber. Como se introducía en capítulos anteriores, cada nodo que ejecuta un 58

73 5.3. Diagrama de clases CommandSubscriber selecciona una sola aplicación DDS para desarrollar el escenario. La relacción de la clase CommandSubscriber con un único CommandPublisher también queda reflejada. Figura 5.15: Detalle del diagrama de clases: DDS XMLApplication Figura 5.16: Detalle del diagrama de clases: DDS XMLParticipant 59

74 5. Diseño Figura 5.17: Detalle del diagrama de clases: DDS XMLPublisher Figura 5.18: Detalle del diagrama de clases: DDS XMLSubscriber Figura 5.19: Detalle del diagrama de clases: DDS XMLTopic 60

75 5.3. Diagrama de clases Figura 5.20: Detalle del diagrama de clases: DDS XMLDataWriter Figura 5.21: Detalle del diagrama de clases: DDS XMLDataReader 61

76 5. Diseño Figura 5.22: Detalle del diagrama de clases: CommandPublisher Figura 5.23: Detalle del diagrama de clases: CommandSubscriber 62

77 CAPÍTULO 6 IMPLEMENTACIÓN En este capítulo se describen algunos detalles de la implementación que es interesante remarcar. En particular se hace hincapié en: Cómo se ha implementado un modelo de orientación a objetos con el lenguaje C. La implementación del analizador del lenguaje de interacción con el escenario. Los módulos que componen el sistema Implementación de la orientación a objetos en C En esta sección se explica la metodología y reglas de codificación que han permitido utilizar este paradigma de programación con un lenguaje no orientado a objetos. La lectura de este apartado permitirá poder interpretar el código fuente de una forma más clara. Hasta ahora se han utilizado constantemente tanto conceptos de orientación a objetos como notación y diagramas relacionados con la orientación objetos. Esto ha sido así por varias razones: Pensando en el futuro del proyecto, la posible integración de este proyecto dentro de un middleware DDS incluirá que se porte el código actual a lenguajes como C++ o Java. Normalmente estos productos presentan un interfaz de programación que admite varios lenguajes, estando escrita la base casi siempre en C. Así pues, la existencia de diagramas de clases, diagramas de secuencia y demás ayudarán a esta tarea. 63

78 6. Implementación Las técnicas de desarrollo de software modernas como el proceso unificado de desarrollo[45] están pensadas para trabajar con lenguajes orientados a objetos. Las metodologías de orientación a objetos ayudan a estructurar el código de manera funcional, algo esencial conforme la complejidad del problema aumenta. A continuación se describe cómo se organiza el código en C para poder aplicar conceptos de la orientación a objetos: Representación de clases. Cada clase del diagrama de clases se corresponde con una estructura de datos en C. Así, tendremos una estructura con una serie de campos que representarán los atributos de la clase. Por ejemplo: DomainParticipant Espacio de nombres. Para evitar conflictos en la definición de estructuras y métodos, se antepone al nombre de cada uno lo que se conoce como espacio de nombres. Esto es un prefijo que se añade al nombre de la estructura o método para indicar a qué biblioteca o módulo pertenece. Por ejemplo el prefijo DDS indica que lo que sigue a continuación pertenece a la biblioteca que ofrece el API del estándar DDS. En este proyecto, se añade el prefijo DDS XML para indicar las clases XML que envuelven a entidades DDS. El nombre de la estructura anterior, una vez añadido el espacio de nombres DDS XML quedaría: DDS_XMLDomainParticipant Asociación de métodos a clases. Para reflejar la asociación de un método de una clase, se antepone el nombre de la clase, es decir, el nombre de la estructura con el espacio de nombres, al nombre del método. Por ejemplo, el método create dds entity de la clase anterior se nombraría en C así: DDS_XMLDomainParticipant_create_dds_entity Parámetros de las funciones. El primer parámetro de un método asociado a una clase será siempre un puntero a una estructura del tipo de la clase. A continuación se incluirán los parámetros de entrada y al final de la lista los parámetros de salida. De esta manera se consigue poder llamar a una serie de métodos sobre un mismo objeto (estructura en C). Por ejemplo, en el método anterior existirá el siguiente parámetro: DDS_XMLDomainParticipant_create_dds_entity( struct DDS_XMLDomainParticipant *self, <parámetros de entrada>, <parámetros de salida>) 64

79 6.2. Implementación del analizador de gramática semi-natural Métodos new y delete. A cada clase se le añaden métodos para la creación y destrucción de estos. En este caso estos métodos reservan o liberan memoria para los campos necesarios, e inicializan sus valores si es necesario Implementación del analizador de gramática semi-natural En el Apartado 4.2 de la fase de análisis se definió, mediante notación BNF, la gramática generativa del lenguaje semi-natural de interacción con el escenario. Por otro lado, en el Apartado se mencionó como decisión estratégica el uso de las herramientas automatizadas para la generación de analizadores sintácticos, lo que incluye también la generación de analizadores léxicos. Partiendo de la gramática BNF estos generadores construyen analizadores sintácticos. Añadiendo código fuente a las reglas de análisis sintáctico se pueden realizar acciones cuando se reconoce una frase introducida por el usuario. La manera en que están diseñados estos generadores facilita posteriores ampliaciones o modificaciones de la gramática y/o acciones. Las gramáticas BNF se pueden implementar con el uso de un analizador sintáctico de los llamados LookAhead Left-Right (LALR). Una herramienta libre generadora de analizadores sintácticos LALR es bison, [46] la implementación GNU del popular generador de analizadores YACC. Además, será necesario integrar bison con el generador de analizadores léxicos Flex[47]. El proceso de implementación, por tanto, consiste en traducir la gramática definida en la sección 4.2 a bison y definir las acciones pertinentes para cada tipo de sentencia Estructuración modular del código Modelo Estático: clases DDS XML y parser XML La fase de diseño concluyó con la definición del diagrama de clases del sistema (Apartado 5.3). En esta sección se explicarán algunos detalles de su implementación. Procesado de ficheros XML con las clases DDS XML. El diagrama de clases muestra un conjunto de clases DDS XML, clases que envuelven a entidades DDS. El parser para el procesado de los ficheros XML se ha construido utilizando estas clases. Según el tipo de etiqueta que se encuentre al procesar el fichero, se utilizará unas u otras clases para procesar el contenido almacenado dentro de la etiqueta. Así, como resultado del proceso de análisis se obtiene un árbol de objetos DDS XML. La Tabla 6.1 muestra la relación entre entidades DDS, entidades DDS XML y etiquetas. 65

80 6. Implementación Entidad DDS Entidad DDS XML etiqueta DomainParticipant DDS XMLDomainParticipant <participant> Topic DDS XMLTopic <topic> Publisher DDS XMLPublisher <publisher> Subscriber DDS XMLSubscriber <subscriber> DataWriter DDS XMLDataWriter <writer> DataReader DDS XMLDataReader <reader> Tabla 6.1: Relación entidades DDS, entidades DDS XML y etiquetas El soporte para la herencia entre las entidades se im- Implementación de la herencia plementa de la siguiente manera: 1. Como se comentó en la Sección 4.3, existe un atributo opcional llamado base name que indica al parser que la clase que está procesando hereda de otra. Cuando el parser encuentra este atributo busca una entidad en el árbol construído con el nombre name que coincida con base name. Esta entidad denomina clase base. 2. Antes de procesar la información contenida en la etiqueta de la clase que hereda, se copian a ésta todos los atributos de la clase base. 3. Si se encuentran valores nuevos para los atributos encontrados se sobreescriben éstos con el valor nuevo. En la implementación actual la herencia sólo afecta a los atributos de las clases que sean datos inmediatos, no se heredan las clases hijas de la clase base. Podemos explicar el funcionamiento de la herencia con el siguiente código XML: <datareader name="reader1"> <d a t a r e a d e r t o p i c>h e l l o w o r l d t o p i c</ d a t a r e a d e r t o p i c> <i n s t a n c e s>5</ i n s t a n c e s> </ datareader> <datareader name="reader_as_reader1" base name="reader1"> </ datareader> Listado 6.1: Código XML para mostrar el funcionamiento de la herencia El DataReader reader as reader1 tendrá como Topic hello world topic y se crearán 5 instancias DDS si se llama al método create all dds entities() del objeto DDS XML que lo envuelve. Se puede sobreescribir cualquier parámetro de la siguiente manera: <datareader name="reader1"> <d a t a r e a d e r t o p i c>h e l l o w o r l d t o p i c</ d a t a r e a d e r t o p i c> <i n s t a n c e s>5</ i n s t a n c e s> </ datareader> <datareader name="reader_as_reader1" base name="reader1"> <d a t a r e a d e r t o p i c>f o o t o p i c</ d a t a r e a d e r t o p i c> </ datareader> 66

81 6.3. Estructuración modular del código Listado 6.2: Código XML para mostrar el funcionamiento de la herencia En este caso, el DataReader reader as reader1 tendrá como Topic foo topic, pero el número de instancias seguirá siendo 5. Estructuras de datos para la representación de las clases DDS XML A continuación se muestra el código de ejemplo de la la estructura DDS XMLDataReader. El resto de clases no difiere demasiado de esta salvo por la inclusión de atributos para datos específicos. s t r u c t DDS XMLDataReader{ s t r u c t DDS XMLObject base ; / S e t o f DDS DataReader i n s t a n c e s / DDS DataReader dds datareader ; / P o i n t e r t o t h e DDS XMLTopic in t h e DOM. This p o i n t e r i s s e t up during t h e p a r s i n g p r o c e s by l o o k i n g f o r t h e d a t a w r i t e r t o p i c t a g c o n t e n t. The s e a r c h p r o c e s s s t a r t s in t h e DDS XMLDomainParticipant o f t h e p a r e n t DDS XMLSubscriber / s t r u c t DDS XMLTopic xml topic ; / Content o f t h e <i n s t a n c e s > t a g / short i n s t a n c e s t a g ; / T o t a l number o f i n s t a n c e s c o n s i d e r i n g t h e number o f p a r e n t i n s t a n c e s / short instances number ; / L i s t e n e r f o r a t t a c h i n g t o t h e DDS E n t i t y. This l i s t e n e r w i l l be NULL or i t w i l l be r e t r i e v e d from t h e DataReader l i s t e n e r s t a b l e / s t r u c t DDS DataReaderListener l i s t e n e r ; / S t a t u s mask t h a t w i l l be a p p l i e d t o t h e l i s t e n e r / DDS StatusMask l i s t e n e r m a s k ; / S e t o f t h r e a d s IDs / pthread t thread ; / B e h a v i o u r method. This method w i l l be e x e c u t e d when t h e s t a r t b e h a v i o u r ( ) method i s c a l l e d / void ( behaviour ) ( void ) ; } ; Listado 6.3: Estructura DDS XMLDataReader El significado y uso de los campos de datos es: struct DDS_XMLObject base: objeto base del que hereda la clase. DDS_DataReader **dds_datareader: conjunto de en entidades DDS que maneja la clase. struct DDS_XMLTopic *xml_topic: referencia al DDS XMLTopic en el árbol de la aplicación. Esta referencia se fija durante el procesamiento del fichero XML 67

82 6. Implementación buscando el tema indicado por la etiqueta datawriter_topic. El tema correspondiente se busca comenzando desde el DDS XMLDomainParticipant padre de la entidad. short instances_tag: contenido de la etiqueta <instances>. short instances_number: número de instancias DDS que se podrán crear. Considerando que la entidad padre de esta clase puede, a su vez tener más instancias, el total de instancias que se pueden crear será el número de instancias de la entidad padre por el número indicado en la etiqueta XML, almacenado en el atributo instances_tag. Este atributo se modifica durante el procesamiento del fichero XML. struct DDS_DataReaderListener *listener: listener que se asociará a la entidad DDS que se cree. DDS_StatusMask listener_mask: configuración de las callbacks que monitorizará el listener. pthread_t *thread: identificadores de las hebras lanzadas para ejecutar comportamiento paralelo. void *(*behaviour)(void *): puntero a un método de descripción del comportamiento. Los dos últimos atributos se refieren al comportamiento dinámico que se quiere utilizar para la entidad. Cuando se invoca al método start behaviour() en una clase DDS XML, este crea una nueva hebra para llamar al método que describe el comportamiento. Para poder detener la ejecución del comportamiento es necesario almacenar una referencia a la hebra, y esto se almacena en el vector thread. Como pueden existir varias entidades DDS en una entidad DDS XML actuando a la vez, se creará una hebra para cada entidad DDS que inicie su actividad. Así, para un una posición del vector de entidades DDS existirá una en el vector de hebras para identificar la hebra que utiliza una entidad DDS Modelo Dinámico El Modelo Dinámico describe el comportamiento de entidades del Modelo Estático. La descripción se hace programando un método y configurando los listeners apropiados mediante el API de DDS para el lenguaje C. El módulo del Modelo Dinámico actuará como una base de datos que almacena métodos y listeners. Esta base de datos está compuesta de una serie de tablas que gestionan información para poder acceder a los elementos dinámicos que almacenan. El módulo proporciona métodos para inicialiar estas tablas y hacer búsquedas sobre ellas. 68

83 6.3. Estructuración modular del código Si el usuario quiere que un conjunto de métodos y listeners puedan ser utilizados debe incluirlos en estas tablas. A continuación se muestran extractos de código de las tablas del Modelo Dinámico. s t a t i c s t r u c t BehaviourMethodEntry DM models table [ DM models table elements ] ; s t a t i c s t r u c t DataReaderListenerEntry D M d a t a r e a d e r s l i s t e n e r s t a b l e [ D M d a t a r e a d e r l i s t e n e r s t a b l e e l e m e n t s ] ;... Listado 6.4: Tablas del Modelo Dinámico Estas tablas estás compuestas de entradas como la del Listado 6.5. typedef s t r u c t BehaviourMethodEntry { / I d e n t i f i e r / key o f t h e method / char name ; / Type Name f o r t h e b e h a v i o u r method / char type name ; / P o i n t e r t o t h e b e h a v i o u r method / void ( behaviour ) ( void ) ; } BehaviourMethodEntry ; typedef s t r u c t DataReaderListenerEntry { / I d e n t i f i e r / key o f t h e L i s t e n e r / char name ; / Type Name f o r t h e l i s t e n e r / char type name ; / The l i s t e n e r t h a t i s going t o be r e t r i e v e d / s t r u c t DDS DataReaderListener l i s t e n e r ; / D e f a u l t mask t o a p p l y t o t h e L i s t e n e r. Maybe i t s u n n e c e s a r y / DDS StatusMask l i s t e n e r m a s k ; / User d e f i n e d method f o r i n i t i a l i z i n g t h e l i s t e n e r. This method w i l l be c a l l e d by t h e l o o k u p method b e f o r e r e t u r n i n g t h e l i s t e n e r t o t h e u s e r / void ( i n i t i a l i z e m e t h o d ) ( ) ; / User d e f i n e d method f o r r e l a s e l i s t e n e r r e s o u r c e s / void ( delete method ) ( ) ; } DataReaderListenerEntry ; Listado 6.5: Entradas de las tablas del Modelo Dinámico Un ejemplo de tablas es el del Listado 6.3.2, que muestra la inicialización de una tabla de listeners para entidades DataReader. void D y n a m i c M o d e l d a t a r e a d e r i n i t i a l i z e l i s t e n e r s t a b l e ( void ) { D M d a t a r e a d e r s l i s t e n e r s t a b l e [ 0 ]. name = DDS String dup ( "DDS_StringX_listener" ) ; D M d a t a r e a d e r s l i s t e n e r s t a b l e [ 0 ]. type name = DDS String dup ( DDS StringXTypeSupport get type name ( ) ) ; D M d a t a r e a d e r s l i s t e n e r s t a b l e [ 0 ]. l i s t e n e r = NULL; D M d a t a r e a d e r s l i s t e n e r s t a b l e [ 0 ]. l i s t e n e r m a s k = DDS STATUS MASK ALL ; 69

84 6. Implementación } D M d a t a r e a d e r s l i s t e n e r s t a b l e [ 0 ]. i n i t i a l i z e m e t h o d = &D D S S t r i n g X d a t a r e a d e r l i s t e n e r i n i t i a l i z e ; Módulo de coordinación El módulo de coordinación, como su nombre indica, coordina todos los nodos del escenario utilizando un tema de control o Control Topic. El tipo de datos de este tema, Command, se describió en el capítulo de análisis, Sección Las clases CommandPublisher y CommandSubcriber implementan la comunicación de instrucciones entre los nodos del escenario. Estas clases no son aplicaciones en si, sino que se utilizan dentro de dos aplicaciones: cmdmaster es una aplicación DDS que se ejecuta en un nodo Command Master. cmdmaster es una aplicación que integra a un analizador sintáctico generado por Yacc. El resultado del análisis sintáctico se utiliza para rellenar los campos de instancias de datos de la estructura Command. Estas instancias se publicarán a la red utilizando la clase CommandPublisher. La aplicación cmdslave es la única que el usuario necesita ejecutar en un nodo para desplegar el escenario. Esta, utiliza la clase CommandSubscriber para recibir y procesar instancias de datos de control que recibe de la red. Recibidas las órdenes, la clase CommandSubscriber utiliza el API de los módulos estático y dinámico para crear y destruir entidades DDS y controlar su comportamiento. Para ilustrar cómo integrar el analizador sintáctico con la clase CommandPublisher, el Listado 6.6 muestra dos reglas que ilustran la integración de CommandPublisher con las reglas de análisis sintáctico de Yacc. CREATEALL { / CREATEALL / # i f d e f DEBUG PARSER PrintDebug ( "CREATEALL\n" ) # endif } i f ( CommandPublisher set command all ( globalcommandpublisher, CMD CREATE ENTITIES ALL ) ) { / Write t h e Command / CommandPublisher write command ( globalcommandpublisher ) ; CommandPublisher clear command ( globalcommandpublisher ) ; } CREATE STRING NUMBER { / CREATE ENTITY NAME INSTANCE ID / # i f d e f DEBUG PARSER PrintDebug ( "CREATE %s, %d\n", $2, $3 ) 70

85 6.3. Estructuración modular del código # endif i f ( CommandPublisher set command ( globalcommandpublisher, CMD CREATE ENTITIES, $2, $3 ) ) { / Write t h e Command / CommandPublisher write command ( globalcommandpublisher ) ; CommandPublisher clear command ( globalcommandpublisher ) ; } Listado 6.6: Integración de CommandPublisher con las reglas de análisis sintáctico de Yacc 71

86 6. Implementación 72

87 CAPÍTULO 7 PRUEBAS Las pruebas pretenden verificar el correcto funcionamiento del sistema y comprobar que los requisitos funcionales y no funcionales de la especificación se cumplen. Las pruebas a las que se ha sometido el sistema son: Pruebas unitarias: consiste en realizar pruebas a nivel de módulo de forma independiente. Pruebas de integración: los módulos probados en la etapa anterior se integran para comprobar sus interfaces (flujo de datos) en el trabajo conjunto. Pruebas del sistema: para comprobar que el software esté totalmente ensamblado y cumpla tanto los requisitos funcionales y no funcionales como los objetivos indicados para el sistema. Para la realización de las pruebas se ha utilizado un mismo fichero XML (scenario-.xml) que hace uso de todas las funcionalidades implementadas respecto al la descripción de entidades. El fichero puede consultarse en el Apéndice C. Este fichero describe ejemplos de: Especificación de varias aplicaciones con participantes pertenecientes a dominios distintos. La herencia entre entidades. El soporte para múltiples instancias. La conexión del Modelo Estático con el Modelo Dinámico. 73

88 7. Pruebas 7.1. Herramientas para la realización de pruebas Durante las pruebas se han utilizado una serie de herramientas externas, son las siguientes: Valgrind[21] es un software de depuración que permite identificar recursos no liberados al finalizar la ejecución de un programa. Se utilizó con la interfaz gráfica Alleyoop. El depurador GBD, integrado con el entorno de desarrollo Eclipse[19], se utilizó para comprobar la correcta creación y destrucción de hebras internas para el control del los métodos de comportamiento. La herramienta nddsspy, incluida en el producto NDDS[8][23]. Esta herramienta permite monitorizar las los DataWriters, DataReaders y las muestras de datos que aparecen en una red. De esta forma se controla la correcta creación y destrucción de entidades remotas, así como de los datos que se publican Pruebas unitarias Se han realizado las siguiente pruebas unitarias respecto a los siguientes módulos. Modelo Estático. Se han probado dos aspectos de este módulo: 1. El parser o analizador sintáctico para los ficheros XML. Se ha comprobado que el parser reconoce todas las etiquetas necesarias y extrae la información de manera correcta. 2. La funcionalidad ofrecida por las clases DDS XML. Para ello se ha escrito un programa de pruebas que, para el fichero scenario.xml comprobaba el correcto funcionamiento del API ofrecida por estas clases. Esto incluye: Verificación de los métodos de navegación por el árbol del escenario. Búsqueda de entidades en el árbol. Comprobación de los métodos de búsqueda y asignación de modelos dinámicos. Modelo Dinámico. Se escribió un modelo dinámico de prueba para probar la funcionalidad de búsqueda de modelos dinámicos y asignación a entidades DDS XML. Módulo de coordinación. Se han verificado las siguientes funcionalidades: 74 El analizador sintáctico para el lenguaje de interacción con el escenario recoge correctamente las instrucciones del usuario.

89 7.3. Pruebas de integración Las instrucciones del usuario son publicadas mediante DDS y recibidas correctamente en subscriptor de órdenes (CommandSubscriber). La transferencia del fichero XML del escenario utilizando DDS para ficheros que debían ser transmitidos en varios mensajes debido a su tamaño Pruebas de integración Las pruebas de integración consistieron en la verificación de la conexión entre los tres módulos: 1. Verificación de la conexión entre el Modelo Estático y el Modelo Dinámico. Para ello se escribió un programa que iniciaba varias entidades DDS descritas y ejecutaba su comportamiento asociado. 2. Verificación de la conexión entre el módulo de coordinación y el Modelo Estático. Se comprobó la correcta traducción de órdenes del usuario recogidas en el módulos de coordinación en llamadas al API de las clases DDS XML Pruebas de sistema Las pruebas de sistema consistieron en el despliegue de un escenario DDS descrito por el fichero scenario.xml. Se utilizaron, para ello, dos ordenadores conectados mediante una red de área local. Las acciones que se realizaron las siguientes acciones: 1. Carga y distribución del escenario. 2. Creación de todas las entidades DDS. 3. Inicio y parada del comportamiento. 4. Destrucción de las entidades. 5. Finalización de los CommandSubscriber de los nodos. Además, se utilizó una aplicación DDS implementada de forma tradicional para comprobar la recepción correcta de datos publicados desde el escenario. 75

90 7. Pruebas 76

91 CAPÍTULO 8 RESULTADOS Y TRABAJO FUTURO 8.1. Principales contribuciones de este trabajo Los resultados del desarrollo de este proyecto han sido presentados en julio de 2008 en el IX Workshop on Distributed Object Computing for Real-time and Embedded Systems celebrado en Washington (DC, USA) bajo el título An XML-Based Approach to the Configuration and Deployment of DDS Applications [48] Este encuentro, organizado por la OMG, constituye un foro para ingenieros de software e investigadores en el campo de los sistemas distribuidos y de tiempo real. El trabajo actual ha conseguido cumplir los objetivos propuestos con las siguientes conclusiones: 1. La división entre Modelo Estático y Modelo Dinámico para la descripción de aplicaciones minimiza la tarea de programación del sistema. 2. La flexibilidad de las interfaces de programación de estos módulos y el diseño del repertorio de órdenes permite: Evaluar el tiempo de creación y descubrimiento entre entidades DDS. Desarrollar de manera gradual el número y actividad de las entidades que participan en el escenario. 3. La descripción del escenario mediante ficheros XML permite diseñar pruebas distribuidas diferentes tan solo cambiando una líneas en estos ficheros. 4. La implementación sobre DDS de la coordinación y distribución del escenario presenta las siguientes ventajas: 77

92 8. Resultados y Trabajo Futuro El desarrollador no necesita preocuparse sobre la sincronización de ficheros XML. Por un lado, no se necesitan mecanismo externos como SSH o NFS para sincronizar ficheros y órdenes, y, por otro, se puede desplegar el escenario en redes de área amplia. Se puede portar fácilmente el sistema desarrollado a cualquier plataforma soportada por un middleware DDS, incluso si la plataforma no cuenta con sistema de ficheros como ocurre con algunos sistemas de tiempo real Trabajo futuro Existen una serie de funcionalidades que podrían mejorar notablemente el sistema desarrollado: Inclusión de un sistema de auto-validación del escenario. Aprovechando que cada nodo obtiene una copia del fichero XML que describe el escenario, así como la secuencia de órdenes que se distribuyen, cada nodo puede construir localmente un esquema de qué entidades deberían haberse creado en el sistema. Relacionado este esquema con la información de descubrimiento que el middleware DDS genera, podría detectar de manera automática si el escenario se ha desplegado de manera adecuada o, en cambio, hay nodos no accesibles. Inclusión de un sistema de gestión de la seguridad. En la implementación actual, no existen medidas de seguridad que impidan a un potencial atacante publicar información a través del tema de control Extensión del Modelo Estático para soportar perfiles de QoS. En la actualidad varias implementaciones de DDS están incorporando perfiles de QoS que se describen bien a través de ficheros XML o se incluyen de manera nativa en el producto. Estos perfiles agrupan parámetros de configuración de calidad de servicio que en su conjunto permiten configurar grupos de entidades DDS para realizar comunicaciones de baja latencia, máximo rendimiento, etc. La integración con estos proyectos permitiría describir con mayor potencia los escenarios DDS. 78

93 BIBLIOGRAFÍA [1] W3C. Web services architecture, w3c working group note, feb Disponible en la Web: [2] Erik Christensen et al. Web services description language (wsdl) 1.1, w3c note, mar Disponible en la Web: [3] Inc. Sun Microsystems. Java message service (jms), Disponible en la Web: [4] Object Management Group. Common object request broker architecture (corba/iiop), version 3.0.3, Disponible en la Web: docs/formal/ pdf. [5] Message Passing Interface Forum. Mpi: A message-passing interface standard, version 2.1. Technical report, Message Passing Interface Forum, Disponible en la Web: [6] Object Management Group. Data distribution service for real-time systems specification, version 1.2, Disponible en la Web: technology/documents/formal/data_distribution.htm. [7] Object Management Group (OMG). The object management group (omg), Disponible en la Web: [8] Inc. Real-Time Innovations. Rti data distribution service, Disponible en la Web: [9] Inc. Real-Time Innovations. Disponible en la Web: [10] PrismTech Ltd. Opensplice dds, Disponible en la Web: prismtech.com/opensplice-dds. 79

94 [11] PrismTech Ltd. Prismtech ltd. Disponible en la Web: com. [12] Inc. Object Computing. Opendds, Disponible en la Web: opendds.org. [13] Object Computing Inc. Object computing inc., Disponible en la Web: http: // [14] Object Management Group (OMG). Dds vendors page, Disponible en la Web: [15] Javier Sánchez-Monedero, J.M. López-Soler, and J. Povedano-Molina. Scalable dds discovery protocols based on bloom filters. In Real-time and Embedded Systems Workshop, Arlington VA, USA, Disponible en la Web: Sanchez-Moder_etal-revised.pdf. [16] RedIris. Plataforma de analisis de servicios de telecomunicaciones (pasito), versión 7.0. Technical report, [17] Leslie Lamport. LaTeX: A Document Preparation System: User s Guide and Reference Manual. Addison-Wesley, [18] Michel Ludwig et. al. Kile - an integrated latex environment, Disponible en la Web: [19] The Eclipse Foundation. Eclipse, Disponible en la Web: eclipse.org/. [20] Free Software Foundation. The gnu project debugger, Disponible en la Web: [21] Cerion Armour-Brown et. al. Valgrind, Disponible en la Web: www. valgrind.org/. [22] Jeffrey Stedfast. Alleyoop, Disponible en la Web: sourceforge.net/. [23] Inc. Real-Time Innovations. RTI Data Distribution Service User s Manual, Version 4.3e, [24] James Clark. The expat xml parser, Disponible en la Web: sourceforge.net/. [25] IEEE. IEEE Std Standard for Information Technology Portable Operating System Interface (POSIX) System Interfaces, Issue 6. IEEE, New York, NY, USA, Revision of IEEE Std and IEEE Std ) Open Group Technical Standard Base Specifications, Issue 6. 80

95 [26] Sun Microsystems. RPC: remote procedure call protocol specification: Version 2. RFC 1057, Internet Engineering Task Force, June Disponible en la Web: http: // [27] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners- Lee. Hypertext transfer protocol HTTP/1.1. RFC 2616, Internet Engineering Task Force, June Disponible en la Web: rfc2616.txt. [28] Nilo Mitra. Soap version 1.2 part 0: Primer. W3C working draft, World Wide Web Consortium (W3C), December Disponible en la Web: TR/soap12-part0/. [29] Sun Developer Network. RMI remote method invocation. [30] Object Management Group. Omg idl syntax and semantics - common object request broker architecture (corba), v3.0. Technical report, Disponible en la Web: [31] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen. Extensible markup language (xml) 1.0 (fourth edition). W3C Recommendation REC-xml , World Wide Web Consortium (W3C), October Disponible en la Web: org/tr/2006/rec-xml /. [32] David C. Fallside and Priscilla Walmsley. XML schema part 0: Primer second edition. W3C recommendation, W3C, October [33] Xml (extensible markup language). Wikimedia Foundation, Inc., Disponible en la Web: [34] D. Crockford. Introducing json, Disponible en la Web: org/. [35] D. Crockford. The application/json media type for javascript object notation (json). RFC 4627, Internet Engineering Task Force, Disponible en la Web: http: // [36] Henry Story. The limitations of json, Disponible en la Web: http: //blogs.sun.com/bblfish/entry/the_limitations_of_json. [37] Sparx Systems. Sparx systems, Disponible en la Web: sparxsystems.com. [38] Sparx Systems Pty Ltd. Mdg technology for dds, Disponible en la Web: index.html. 81

96 [39] Jishnu Mukerji and Joaquin Miller. Mda guide version Technical report, Object Management Group, Disponible en la Web: cgi-bin/doc?omg/ [40] Douglas C. Schmidt. Distributed object computing (doc) group for distributed realtime and embedded (dre) systems, Disponible en la Web: dre.vanderbilt.edu/. [41] Douglas C. Schmidt. Dds benchmark project, Disponible en la Web: http: // [42] Jeff Parsons, Ming Xiong, Dr. Douglas C. Schmidt, Hieu Nguyen, Ming Xiong,, James Edmondson, and Olabode Ajiboye. Evaluating the performance of pub/- sub platforms for tactical information management. In Real-time and Embedded Systems Workshop, Arlington, VA USA - July 10-13, 2006, Disponible en la Web: [43] The GNOME Project. Planner, Disponible en la Web: gnome.org/planner. [44] Bert Farabaugh Gerardo Pardo-Castellote. Introduction to DDS and Data Centric Communications, Disponible en la Web: whitepapers/intro_to_dds.pdf. [45] Ivar Jacobson, Grady Booch, and James Rumbaugh. El Proceso Unificado de Desarrollo de Software [46] GNU Project, Disponible en la Web: bison/. [47] The Flex Project. Flex (the fast lexical analyzer), Disponible en la Web: [48] Javier Sánchez-Monedero, J.M. López-Soler, J. Povedano-Molina, and J.M. López- Vega. An xml-based approach to the configuration and deployment of dds applications. In Workshop on Distributed Object Computing for Real-time and Embedded Systems, Washington, DC, USA, Disponible en la Web: http: // Presentations_2008/Session%202/02-03_Monedero_et_al.pdf. [49] Real-Time Innovations Inc. RTI Data Distribution Service. Users Manual (version 4.1), [50] S. Shepler, Brent Callaghan, David Robinson, R. Thurlow, C. Beame, M. Eisler, and D. Noveck. Network file system (NFS) version 4 protocol. RFC 3530, Internet Engineering Task Force, April Disponible en la Web: org/rfc/rfc3530.txt. 82

97 BIBLIOGRAFÍA [51] Sun Microsystems, Inc. RFC 1014: XDR: External Data Representation standard. Technical report, June Disponible en la Web: ftp://ftp.internic.net/ rfc/rfc1014.txt, Status: UNKNOWN. [52] Reinier Torenbeek. Benchmarking omg dds for large scale distributed systems. In Real-time and Embedded Systems Workshop, Washington, DC, USA, Disponible en la Web: WS_Final_Presentations_2008/Session%207/07-02_Torenbeek.pdf. 83

98 84 BIBLIOGRAFÍA

99 APÉNDICE A INTRODUCCIÓN A DDS Hoy en día cada vez es más usual el uso de aplicaciones distribuidas. No es raro encontrarse con una serie de aplicaciones que se ejecutan en distintas máquinas de forma cooperativa dando la sensación de ser todo un mismo sistema. Dentro de estos sistemas de computación distribuida, se pueden encontrar los denominados servicios de distribución de datos. En este caso, lo que se encuentra disperso no son las aplicaciones, sino los datos de interés. Un ejemplo claro de ello puede ser la monitorización de sensores. Cada sensor puede encontrarse en un lugar distinto, los cuales se comunican con la entidad monitorizadora por medio de alguna red de conexión. Las Figuras A.1 y A.2 muestran cómo DDS crea una capa entre la aplicación y el sistema operativo y la red. En casos de datos distribuidos como los mencionados anteriormente, los requisitos de tiempo real, fiabilidad, falla ante errores suelen ser muy importantes. Una arquitectura que mantenga todas estas cualidades de una manera adecuada es muy compleja de construir. No sería razonable tener que diseñar para cada nueva aplicación que requiera de distribución de datos una arquitectura que la soporte. Para paliar este problema, algunas empresas han dedicado esfuerzos en diseñar una infraestructura de distribución de datos de una manera común y razonable. Este esfuerzo se ha materializado en lo que hoy se conoce como Data Distribution Service (DDS)[6][44]. DDS proporciona un middleware que abstrae al programador de aplicaciones que necesiten de datos distribuidos de las tareas necesarias para la recogida de los mismos, con máximas prestaciones. DDS deja de lado el clásico paradigma cliente/servidor, para usar un nuevo paradigma mucho más adecuado para distribución de datos: publicación/suscripción. DDS es por tanto un esfuerzo que normaliza el mecanismo de publicación/suscripción, de manera que puede ser añadido a cualquier aplicación de una manera sencilla. 85

100 Figura A.1: Arquitectura de un sistema de distribución de datos sin DDS Figura A.2: Arquitectura de un sistema de distribución de datos con DDS 86

101 A. Introducción a DDS Figura A.3: Infraestructura de DDS Las ventajas de usar DDS son: 1. Está basado en un paradigma conceptualmente sencillo como es publicación/suscripción 2. Es escalable dinámicamente 3. Está diseñado de modo que la sobrecarga del sistema sea mínima 4. Soporta comunicaciones de uno a uno, de uno a muchos o de muchos a muchos 5. Facilita al desarrollador enormemente la tarea de desarrollo de aplicaciones para distribución de datos La utilización de un nuevo paradigma supone cambiar la manera de trabajar de las aplicaciones en muchos aspectos. El paradigma de publicación/suscripción no se basa en la existencia de un servidor central, que es el que se encarga de satisfacer las solicitudes del cliente. En lugar de ello, lo que se hace es que cada entidad (es decir, un computador o sistema embebido que soporte DDS) que posea un dato susceptible de ser de interés para otra entidad, informa al middleware de la disponibilidad del dato y publica dicho dato (de ahí el término publicación). Por otro lado, existen entidades con interés hacia ciertos datos. En este caso, cuando una entidad está interesada en un dato, lo que se hace es que se informa al middleware de dicho interés, y éste se encargara de proporcionarlo. En este caso, se dice que la entidad se ha suscrito a un tipo de dato. 87

102 Figura A.4: Entidades DDS participantes en un Dominio (Domain) Además de estos conceptos de publicación/suscripción, para facilitar la explicación del trabajo realizado y de la arquitectura de DDS, se hace necesaria la explicación de nuevos conceptos: Descubrimiento (Discovery): Es el proceso que se realiza para identificar las entidades que están publicando datos en DDS. Este proceso se inicia de forma casi instantánea por DDS, y sólo requiere que el usuario proporcione un punto de partida donde comenzar la búsqueda. Tema (Topic) : Se define como tema cada uno de los distintos tipos de datos que son publicados en DDS. Cada tema tiene sus propias características, y sus tipos de datos asociados. Instancia (Instance): Un mismo tema (tipo de datos) puede ser publicado por muchas entidades. Para que cada tema publicado se diferencie de los demás se usa un mecanismo de claves únicas. Por ejemplo, si tenemos datos de posición de diversos radares (algo muy común en triangulación), para identificar de dónde proviene cada dato añadimos un campo de clave, para que cada dato de posición se utilice correctamente en los cálculos de determinación de la posición exacta de un objeto. El empleo de claves está gestionado por el middleware de DDS. Muestra (Sample): Una vez definido el concepto de instancia es conveniente definir el concepto de muestra. Éste se refiere a cada uno de los valores que toma una instancia a lo largo del tiempo. En el ejemplo de los radares empleado en la definición de instancia, una muestra sería cada uno de las sucesivas tomas de datos de cada radar que determinan la distancia del mismo en un instante determinado. 88