Universidad de Granada - Una metodología basada en XML ...dtstc.ugr.es/tl/pdf/pf/PFC_jsanchez.pdf · mitido el desarrollo de soluciones que han supuesto un salto en cuanto al aumento

Escuela Tecnica Superior de Ingenierıas Informatica y deTelecomunicacion

Una metodologıa basada en XML para laconfiguracion y despliegue de aplicaciones

DDS

Javier Sanchez Monedero

Dirigido por: Juan Manuel Lopez Soler

Departamento de Teorıa de la Senal, Telematica y ComunicacionesUniversidad de Granada

Granada, 22 de septiembre de 2008

Resumen

En las ultimas decadas, las redes de ordenadores han mejorado en prestacionesy calidad. Estos avances tecnologicos han permitido, y permiten, nuevos para-digmas en el desarrollo de programas, como son las aplicaciones distribuidas. Entreotras tecnologıas, para facilitar el desarrollo de estas aplicaciones han aparecidolos denominados middlewares: una capa software que facilita al programador laconstruccion del sistema distribuido abstrayendole de las tareas de comunica-cion.

Este es el caso de la tecnologıa DDS (Data Distribution Service), un middlewareorientado a la difusion de mensajes en entornos distribuidos con restricciones detiempo-real. DDS se utiliza con exito en redes relativamente pequenas en las queintervienen unas decenas o centenares de nodos sobre los que ejecutan aplicacio-nes distribuidas. Actualmente se plantea conocer si DDS puede implantarse enentornos mayores y si mejorara las tecnologıas existentes en este campo.

El presente proyecto afronta algunos de los retos que aparecen en el desarrollode grandes escenarios DDS mediante la propuesta de una nueva metodologıa enel desarrollo de aplicaciones DDS.

La metodologıa planteada minimiza el esfuerzo de programacion permitien-do especificar gran parte del escenario DDS mediante XML. En consecuencia, eltiempo de desarrollo de sistemas distribuıdos y la probabilidad de que aparezcanerrores de programacion se reducen. Especialmente para el campo de la experi-mentacion, en el que deben lanzarse muchas pruebas variando las aplicacionesdistribuıdas, este proyecto resulta de gran interes.

La metodologıa se complementa con el desarrollo de aplicaciones para la coor-dinacion de nodos de la red sobre la que se ejecuta el escenario. Estas herramien-tas presentan al desarrollador una vista global y de alto nivel para el control delescenario distribuido.

Agradecimientos

En primer lugar quiero agradecer a mi familia, Luis, Maria Jesus y Amaya, el apo-yo, el animo y la comprension que me han dado durante mis anos de estudios enCordoba y Granada.

En segundo lugar, agradecer los animos de mis amigos, en especial el de Car-men. Gracias a ella por aguantar mis dos proyectos y por ayudarme con la docu-mentacion. 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 intencion deaprender, ensenar, debatir y participar activamente en todos sus ambitos. Graciasa los representantes de alumnos que han compartido su tiempo conmigo en elConsejo de Estudiantes de la Escuela Politecnica de la Universidad de Cordoba,la Delegacion de Alumnos de la E.T.S. de Ingenierıas Informatica y de Teleco-municacion de la Universidad de Granada y de la sectorial de estudiantes deInformatica (RITSI). No todo tiene que ser lucrativo en esta vida.

Dar las gracias mi tutor, Juanma, por el tiempo e interes que ha dedicado aeste proyecto.

Por ultimo, me gustarıa agradecer a Gerardo y Fernando de RTI la resolucionde dudas, aportacion de ideas y la revision continua del proyecto. Resulta unverdadero lujo contar con el soporte de personas con gran conocimiento tecnicoy experiencia.

Sinceramente, gracias.

INDICE GENERAL

1. Introduccion 11.1. Presentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Contextualizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1. La empresa Real-Time Innovations . . . . . . . . . . . . . . . . . . . 31.2.2. La plataforma PASITO . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.3. Experimentacion con DDS sobre PASITO . . . . . . . . . . . . . . . 4

1.3. Definicion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5.1. Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.6. Fases de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.7. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.7.1. Factores dato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.7.2. Factores estrategicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.8. Antecedentes y estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . 111.8.1. Antecedentes en distribucion de datos . . . . . . . . . . . . . . . . . 111.8.2. El lenguaje XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.8.3. Herramientas para el desarrollo de aplicaciones DDS . . . . . . . . 14

1.9. Aproximacion a la solucion propuesta . . . . . . . . . . . . . . . . . . . . . 16

2. Especificacion de Requisitos 192.1. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2. Requisitos no Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3. Planificacion 23

I

4. Analisis de Requisitos 274.1. Casos de uso del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1. Identificacion de los actores del sistema . . . . . . . . . . . . . . . . 274.1.2. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 284.1.3. Listado de los casos de uso . . . . . . . . . . . . . . . . . . . . . . . 29

4.2. Gramatica de interaccion con el escenario . . . . . . . . . . . . . . . . . . . 304.2.1. Definicion de la gramatica . . . . . . . . . . . . . . . . . . . . . . . . 314.2.2. Estructura de datos de ordenes . . . . . . . . . . . . . . . . . . . . . 32

4.3. Lenguaje de descripcion de aplicaciones . . . . . . . . . . . . . . . . . . . . 33

5. Diseno 375.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1. ¿Como describir un escenario DDS? . . . . . . . . . . . . . . . . . . 375.1.2. La interaccion y coordinacion del escenario . . . . . . . . . . . . . . 415.1.3. Funcionalidades para mejorar la flexibilidad del sistema . . . . . . 42

5.2. Modelo de interaccion de objetos . . . . . . . . . . . . . . . . . . . . . . . . 455.2.1. Accion cargar escenario . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2.2. Accion crear entidad DDS . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.3. Accion iniciar comportamiento . . . . . . . . . . . . . . . . . . . . . . 51

5.3. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6. Implementacion 636.1. Implementacion de la orientacion a objetos en C . . . . . . . . . . . . . . . 636.2. Implementacion del analizador de gramatica semi-natural . . . . . . . . . 656.3. Estructuracion modular del codigo . . . . . . . . . . . . . . . . . . . . . . . 65

6.3.1. Modelo Estatico: clases DDS XML y parser XML . . . . . . . . . . . 656.3.2. Modelo Dinamico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.3.3. Modulo de coordinacion . . . . . . . . . . . . . . . . . . . . . . . . . 70

7. Pruebas 737.1. Herramientas para la realizacion de pruebas . . . . . . . . . . . . . . . . . 747.2. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.3. Pruebas de integracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.4. Pruebas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8. Resultados y Trabajo Futuro 778.1. Principales contribuciones de este trabajo . . . . . . . . . . . . . . . . . . . 778.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A. Introduccion a DDS 85

B. Despliegue y desarrollo de un escenario incrementalmente 93

II

C. Ficheros utilizados en las pruebas 103C.1. Fichero de definicion de tipo de documento (DTD) . . . . . . . . . . . . . . 103C.2. Fichero de prueba scenario.xml . . . . . . . . . . . . . . . . . . . . . . . 104

Glosario 109

III

IV

INDICE DE FIGURAS

1.1. Mapa de la plataforma PASITO . . . . . . . . . . . . . . . . . . . . . . . . . 41.2. Especificacion de entidades DDS con Enterprise Architect . . . . . . . . . . 151.3. Descripcion de escenarios DDS mediante los modelos Estatico y Dinamico . 18

3.1. Detalle del diagrama de Gantt de la planificacion inicial del proyecto . . . 243.2. Planificacion inicial del proyecto en formato tabular . . . . . . . . . . . . . 25

4.1. Diagrama de casos de uso del sistema . . . . . . . . . . . . . . . . . . . . . 28

5.1. Descripcion de aplicaciones DDS mediante los modelos Estatico y Dinamico 395.2. Arbol del el Modelo Estatico para una aplicacion DDS . . . . . . . . . . . . 405.3. Coordinacion del escenario distribuidos utilizando DDS . . . . . . . . . . 425.4. Ejemplo explicativo del funcionamiento de las instancias y parametros de

recursividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.5. Diagrama de secuencia cargar escenario . . . . . . . . . . . . . . . . . . . . . 475.6. Diagrama de secuencia crear entidad DDS, parte generica. . . . . . . . . . . 495.7. Diagrama de secuencia crear entidad DDS, DDS XMLDomainParticipant . 505.8. Diagrama de secuencia crear entidad DDS, DDS XMLDomainPublisher . . 525.9. Diagrama de secuencia crear entidad DDS, DDS XMLDomainSubscriber . 525.10. Diagrama de secuencia iniciar comportamiento, parte generica. . . . . . . . . 535.11. Diagrama de secuencia iniciar comportamiento, DDS XMLDomainParticipant 555.12. Diagrama de secuencia iniciar comportamiento, DDS XMLDomainPublisher 565.13. Diagrama de secuencia iniciar comportamiento, DDS XMLDomainSubscriber 575.14. Vista general del diagrama de clases . . . . . . . . . . . . . . . . . . . . . . 585.15. Detalle del diagrama de clases: DDS XMLApplication . . . . . . . . . . . . 595.16. Detalle del diagrama de clases: DDS XMLParticipant . . . . . . . . . . . . 595.17. Detalle del diagrama de clases: DDS XMLPublisher . . . . . . . . . . . . . 605.18. Detalle del diagrama de clases: DDS XMLSubscriber . . . . . . . . . . . . 605.19. Detalle del diagrama de clases: DDS XMLTopic . . . . . . . . . . . . . . . . 605.20. Detalle del diagrama de clases: DDS XMLDataWriter . . . . . . . . . . . . 61

V

5.21. Detalle del diagrama de clases: DDS XMLDataReader . . . . . . . . . . . . 615.22. Detalle del diagrama de clases: CommandPublisher . . . . . . . . . . . . . 625.23. Detalle del diagrama de clases: CommandSubscriber . . . . . . . . . . . . 62

A.1. Arquitectura de un sistema de distribucion de datos sin DDS . . . . . . . . 86A.2. Arquitectura de un sistema de distribucion de datos con DDS . . . . . . . 86A.3. Infraestructura de DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87A.4. Entidades DDS participantes en un Dominio (Domain) . . . . . . . . . . . . 88A.5. Modelo conceptual de las entidades DDS . . . . . . . . . . . . . . . . . . . 90

B.1. Representacion de despliegue de un escenario: estado inicial . . . . . . . . 94B.2. Representacion de despliegue de un escenario: distribucion del escenario

y asignacion de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 95B.3. Representacion de despliegue de un escenario: creacion varias entidades

DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97B.4. Representacion de despliegue de un escenario: creacion de dos DataWriters 98B.5. Representacion de despliegue de un escenario: inicio de la actividad de

algunas entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99B.6. Representacion de despliegue de un escenario: incremento del numero de

entidades y actividad en el escenario . . . . . . . . . . . . . . . . . . . . . . 100B.7. Representacion de despliegue de un escenario: destruccion de las entida-

des DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101B.8. Representacion de despliegue de un escenario: finalizacion de la ejecucion

de los CommandSubscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

VI

INDICE DE CODIGO

4.1. Gramatica BNF definida para interaccion con el escenario . . . . . . . . . . 314.2. Fichero IDL correspondiente al tema de control . . . . . . . . . . . . . . . . . 324.3. Descripcion de una aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4. Descripcion de un participante de dominio (Domain Participant) . . . . . . . . 344.5. Descripcion de un tema (Topic) . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6. Descripcion de un publicador (Publisher) . . . . . . . . . . . . . . . . . . . . 354.7. Descripcion de un subscriptor (Subscriber) . . . . . . . . . . . . . . . . . . . 366.1. Codigo XML para mostrar el funcionamiento de la herencia . . . . . . . . 666.2. Codigo XML para mostrar el funcionamiento de la herencia . . . . . . . . 666.3. Estructura DDS XMLDataReader . . . . . . . . . . . . . . . . . . . . . . . . 676.4. Tablas del Modelo Dinamico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.5. Entradas de las tablas del Modelo Dinamico . . . . . . . . . . . . . . . . . . . 696.6. Integracion de CommandPublisher con las reglas de analisis sintactico de Yacc 70C.1. Fichero de definicion de tipo de documento (DTD) . . . . . . . . . . . . . . 103C.2. Fichero de prueba scenario.xml . . . . . . . . . . . . . . . . . . . . . . . 105

VII

VIII

CAPITULO 1

INTRODUCCION

1.1. Presentacion

En las ultimas decadas, las redes de ordenadores han mejorado en prestaciones y ca-lidad. Estos avances tecnologicos han permitido, y permiten, nuevos paradigmas en eldesarrollo de aplicaciones. Este es el caso de las aplicaciones distribuidas: aplicaciones quese ejecutan en plataformas diferentes y que tıpicamente estan conectadas a traves de unared, sistemas de ficheros o memoria compartida. Las aplicaciones distribuidas han per-mitido el desarrollo de soluciones que han supuesto un salto en cuanto al aumento de lacapacidad de computo y a la conexion entre gran cantidad de productores y consumido-res de informacion.

Ejemplos de aplicaciones distribuidas son el correo electronico, la navegacion web,los servicios de mensajerıa instantanea, la trazabilidad de mercancıas, las aplicacionesde calculo cientıfico distribuidas o el control de trafico aereo entre otras. Dependiendodel objeto de la aplicacion que se distribuye, la tecnologıa subyacente en la que se apoyavarıa sustancialmente. Por ejemplo, un servicio de mensajerıa instantanea no tiene losmismos requerimientos que una sistema para coordinar vehıculos aereos.

Ası, han ido surgiendo diferentes tecnologıas para dar soporte a distintos sistemascon diferentes requerimientos. Estas tecnologıas proporcionan funcionalidades orienta-das a satisfacer problemas generales de aplicaciones distribuidas, liberando al desarro-llador de las tareas comunes en este tipo de software, de manera que el desarrollo puedecentrarse en lo especıfico del proyecto. Por lo general, estas tecnologıas entran dentro delconcepto de middleware.

Este proyecto se centra en el middleware orientado a mensajes, cuyo objetivo es la dis-tribucion de datos a las distintas entidades, productores y consumidores de informacion,que componen la aplicacion distribuida. Al delegarse la comunicacion entre aplicaciones

1

1. Introduccion

al middleware, el disenador de software puede centrarse en la resolucion del problema ensi.

Ejemplos de tecnologıas de distribucion de datos son los servicios web[1] [2], los ser-vicios de mensajerıa de Java (JMS, Java Message Service)[3], CORBA (Common Object RequestBroker Architecture)[4], MPI (Message Passing Interface, interfaz de paso de mensajes)[5] oDDS (Data Distribution Service)[6].

Muchas aplicaciones con restricciones de tiempo real (RT, Real-Time) utilizan un midd-leware para resolver las cuestiones de comunicacion. Para estas aplicaciones no solo esimportante la capacidad de distribucion de datos, sino tambien la manera en que se dis-tribuyen estos en cuanto a eficiencia, determinismo, seguridad, fiabilidad y notificaciony gestion de errores. En este campo se han disenado soluciones para satisfacer tales res-tricciones, y este es el caso de la tecnologıa DDS.

DDS son las siglas del estandar Data Distribution Service for Real-Time Systems o servi-cio de distribucion de datos para sistemas de tiempo real[6], estandar mantenido por la OMG(Object Management Group)[7]. DDS es el primer estandar internacional abierto que tratalas comunicaciones de publicacion–subscripcion para sistemas de tiempo real y siste-mas empotrados. Las implementaciones mas conocidas son NDDS[8] de Real–Time In-novations[9], OpenSplice DDS[10] de PrismTech[11] y OpenDDS[12] de la empresa ObjectComputing[13]. Puede consultarse informacion sobre estas y otras implementaciones enel portal web sobre DDS[14] que mantiene la OMG.

RTI Data Distribution Service, tambien conocido como NDDS, es un middleware de redque implementa un modelo de comunicaciones en tiempo real basado en el paradigmapublicacion-suscripcion que permite a un proceso en un entorno distribuido compartirdatos independientemente de la localizacion 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 multidifusion (multicast), ası co-mo tambien soporte para comunicaciones cliente-servidor. Una explicacion detallada deDDS se proporciona en el Apendice A.

DDS se ha utilizado con exito en redes relativamente pequenas en las que intervie-nen unas decenas o centenares de nodos sobre los que ejecutan aplicaciones distribuidas.Conforme los sistemas distribuidos aumentan en numero de nodos participantes, redesque unen estos nodos, y cantidad de entidades DDS que se encargan de la distribucionde los datos, aparecen una serie de retos que deben superarse. Aspectos como la con-figuracion de la capa de transporte, la gestion de la seguridad, la definicion interfacesde interaccion y monitorizacion de cientos o miles de aplicaciones, la especificacion for-mal del sistema, la escalabilidad, los protocolos de descubrimiento[15] y mas constituyendesafıos para las plataformas DDS. A dıa de hoy, no existen estudios sobre los problemasy lımites que DDS puede encontrar en grandes escenarios.

Independientemente de los nuevos retos para los fabricantes de productos DDS, elpaso a grandes escenarios distribuidos necesita de metodologıas y herramientas de proto-tipado rapido de aplicaciones que permitan hacer uso de todas las funcionalidades ofre-

2

1.2. Contextualizacion

cidas por un middleware DDS. Gracias a estas tecnicas, el despliegue y gestion de escenariosDDS permitira identificar cuellos de botella de las implementaciones concretas o de di-versas configuraciones posibles en cuanto a dominios, particiones, parametros de calidadde servicio, temas, etc. El presente proyecto trata de dar solucion al despliegue masivode entidades DDS en redes de gran escala. El objetivo es proporcionar una metodologıa yherramientas que permitan el desarrollo rapido y libre de errores de aplicaciones distri-buidas con la intencion de realizar pruebas empıricas con plataformas DDS en redes degrandes dimensiones.

1.2. Contextualizacion

1.2.1. La empresa Real-Time Innovations

El proyecto se enmarca dentro del convenio de colaboracion del Departamento deTeorıa de la Senal, Telematica y Comunicaciones (TSTC en adelante) de la Universidadde Granada con la empresa Real-Time Innovations, inc (tambien conocida como RTI)1 si-tuada en Sunnyvale, en el estado de California de los Estados Unidos de America. ElDepartamento forma parte del programa de universidades de RTI (Real-Time InnovationsUniversity Program)2, por lo que se dispone de licencias de desarrollo gratuitas del midd-leware RTI Data Distribution Service (o NDDS).

1.2.2. La plataforma PASITO

Profesores del Departamento TSTC forman parte del proyecto PASITO (plataformade experimentacion de servicios de telecomunicaciones)[16]. PASITO es un laboratoriode pruebas distribuido, que ofrece a los ingenieros la posibilidad de construir, depurar yevaluar escenarios de prueba de servicios de telecomunicaciones.

PASITO es una infraestructura publica construida sobre la red academica espanolaRedIRIS3, utilizando tecnologıas variadas para poder probar gran variedad de serviciosde telecomunicaciones y, al mismo tiempo, garantizar que su actividad esta aislada delresto de los servicios dela red academica, para evitar interferencias con otras actividadesque esten en operacion para la comunidad cientıfica espanola. La Figura 1.1 muestra losnodos que componen en la actualidad PASITO.

El proposito como laboratorio de servicios de telecomunicaciones es permitir investi-gaciones sobre:

Arquitecturas para Internet.

1http://www.rti.com/2http://www.rti.com/corporate/university.html3http://www.rediris.es/

3

http://www.rti.com/

http://www.rti.com/corporate/university.html

http://www.rediris.es/

1. Introduccion

Figura 1.1: Mapa de la plataforma PASITO

Protocolos de comunicaciones.

Tecnologıas de transporte con calidad de servicio.

Virtualizacion y autoconfiguracion de redes y servicios.

Tecnologıas y herramientas de monitorizacion de redes y servicios.

Servicios opticos para proyectos intensivos en datos.

Tecnologıas de distribucion de grandes cantidades de informacion.

Sistemas peer-to-peer.

Servicios de movilidad.

Tecnologıas para mejorar la seguridad en redes.

Estandares para servicios de colaboracion de nueva generacion.

1.2.3. Experimentacion con DDS sobre PASITO

PASITO ofrece un laboratorio de telecomunicaciones que brinda oportunidades deexperimentacion difıciles de conseguir si en la investigacion solo participa un centro. Siretomamos las ideas expuestas en la Seccion de “Introduccion” sobre la necesidad de

4

1.3. Definicion del problema

probar y experimentar con DDS en grandes escenarios de aplicaciones distribuidas, parecenatural relacionar esto con la oportunidad que nos ofrece la plataforma PASITO.

PASITO puede constituir, pues, la infrastructura necesaria para experimentar conDDS en un escenario situado sobre una red de area amplia. No obstante, tal y comose presenta en la Seccion 1.1 y se concretara mas adelante, el despliegue de grandes es-cenarios DDS en general, y para realizar experimentaciones en particular, requiere deherramientas de apoyo y metodologıas de prototipado rapido de aplicaciones que libe-ren al experimentador de tareas tediosas y propensas a errores para dejar que se centreen el diseno del experimento.

Ası pues, contextualizamos el desarrollo del proyecto dentro del marco de investiga-cion del despliegue de escenarios DDS sobre redes de area amplia y grandes redes decomputadores.

1.3. Definicion del problema

El desarrollo de aplicaciones DDS, en general, conlleva una serie de tareas que de-ben realizarse programando, mediante el API proporcionada por la plataforma DDS, laaplicacion que se ejecutara en cada nodo. Llamaremos despliegue y desarrollo de un esce-nario a una serie de tareas necesarias para la construccion, distribucion y ejecucion de unescenario DDS. Esta tareas incluyen:

La creacion de aplicaciones con un gran numero de entidades DDS asociadas anodos concretos de la red sobre la que se situa al sistema distribuido.

La descripcion de los parametros de configuracion (dominio, nombres de temas ytipos de tatos, parametros de QoS. . . ) para cada una de las entidades DDS que seejecutaran en cada nodo.

El establecimiento de relaciones entre las entidades DDS a nivel intranodo e inter-nodo.

La descripcion de cada entidad DDS del sistema y la definicion de su comportamien-to. Se entiende por comportamiento a la actividad que desarrollara la entidad. Porejemplo, un DataWriter se dedicara a escribir datos en la red.

La coordinacion y sincronizado del ciclo de vida de de entidades DDS.

Ademas, deben realizarse las tareas habituales en la construccion de una aplicaciongenerica (escritura del codigo fuente, compilacion y enlazado, etc.) cada vez que se quie-ra modificar el comportamiento de la misma o los parametros de uso de las bibliotecasutilizadas. Tras este proceso, se necesita distribuir el resultado de la construccion a losnodos correctos y ejecutar cada aplicacion en el nodo adecuado y momento adecuado.

5

1. Introduccion

Este procedimiento a pequena escala puede realizarse de forma manual. Sin embargo,cuando se trata de escenarios “masivos” en entornos de area amplia, como el que sepropone en la Seccion 1.2.2, aparecen problemas que este proyecto trata de resolver. Estosproblemas son:

1. Aumento del tiempo de desarrollo con el tamano del escenario.

2. Garantıa de la consistencia relacionada con la probabilidad de cometer errores deprogramacion en si, por un lado, y, por otro, en la correcta asignacion de entidadesDDS a nodos.

3. Dificultad para reproducir pruebas.

El presente proyecto tratara de dar solucion a los problemas que se han descrito.Ası pues, como resultado final se debera proporcionar al usuario, el desarrollador deun escenario distribuido de gran tamano, un conjunto de herramientas que le permita:

Automatizar la mayor parte posible de las tareas anteriormente enumeradas.

Minimizar la tarea de programacion del disenador de pruebas y liberarle, en lamedida de lo posible, del conocimiento profundo del API de DDS. De esta forma sepretende que el usuario se centre en el diseno del sistema y las pruebas, y no en laslabores de desarrollo.

Coordinar la realizacion y dar consistencia a las pruebas sobre escenarios en entor-nos reales.

1.4. Objetivos

Descrito ya el problema, en este apartado se detallaran los objetivos que persigue elproyecto:

Proporcionar una manera flexible de describir escenarios DDS. Se trata de proporcio-nar al usuario un conjunto de herramientas que permitan describir un escenario distri-buido compuesto por aplicaciones que se comunican utilizando un middleware DDS. Esteobjetivo se divide en tres subobjetivos:

Disenar un lenguaje de descripcion de aplicaciones, esto es, especificar un lengua-je que permita al usuario describir los elementos que conforman el escenario y susparametros de configuracion. Como resultado, se espera facilitar la descripcion deaplicaciones minimizando al mismo tiempo los conocimientos necesarios del APIde DDS.

6

1.5. Recursos

Proporcionar una interfaz de descripcion del comportamiento de las aplicacio-nes. Este objetivo complementa el anterior, puesto que anade a la descripcion deentidades DDS en si, la descripcion del comportamiento que estas tendran en elescenario.

Proporcionar al usuario una metodologıa de desarrollo rapido de aplicacionesDDS. El proyecto ofrece una alternativa al desarrollo tradicional de aplicaciones4,ası pues, debera proponerse una nueva metodologıa de desarrollo de aplicacionesDDS. Dicha metodologıa establecera los pasos necesarios para la construccion ydespliegue de un escenario distribuido utilizando el sistema desarrollado.

Proporcionar mecanismos de control sobre un escenario DDS. El sistema debe pro-porcionar interfaces de interaccion con el escenario de forma que el usuario sea capazde:

Distribuir la descripcion del escenario entre los nodos y asignar las aplicacionesDDS adecuadas a los nodos adecuados.

Controlar de manera conjunta los procesos de creacion o destruccion de las entida-des DDS que componen el escenario, esto es, el ciclo de vida de las entidades DDS.

Controlar de manera global el comportamiento que tendran las diferentes entidadesDDS del escenario.

1.5. Recursos

Definido el problema, en esta seccion se describen los recursos humanos, de hardwarey de software que se emplearan en el desarrollo del proyecto.

1.5.1. Humanos

Prof D. Juan Manuel Lopez Soler , profesor del Departamento de Teorıa de la Senal,Telematica y Comunicaciones de la Universidad de Granada, como tutor del pro-yecto.

D. Javier Sanchez Monedero , alumno de la Escuela Tecnica Superior de IngenierıasInformatica y de Telecomunicacion de la Universidad de Granada, que sera el en-cargado de realizar dicho proyecto siguiendo las directrices definidas por el tutordel mismo.

4Entendemos como desarrollo tradicional al que se realiza programando, compilando y distribuyendo apli-caciones.

7

1. Introduccion

1.5.2. Hardware

Para el desarrollo del proyecto se dispone de:

Ordenador portatil.

Impresora laser.

Conexion a Internet.

1.5.3. Software

Sistema Operativo GNU/Linux Ubuntu 8.04 Hardy Heron

Paquete de utilidades GNU (GNU Binutils)

Paquete procesador de textos LATEX[17].

Entorno de trabajo Kile[18] para documentos escritos con LATEX.

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 depuracion de problemas de memoria y rendimiento de programasValgrind[21].

Alleyoop[22], interfaz grafica para Valgrind.

Biblioteca de distribucion de datos RTI DDS 4.3b y 4.3e[23].

1.6. Fases de Desarrollo

Para el desarrollo de este proyecto se han considerado una serie de fases bien diferen-ciadas:

1. Revision del estado del arte: en esta fase se realizara un estudio del campo de middle-ware y tecnologıas relacionadas con DDS, se estudiaran alternativas en la descrip-cion no programatica de aplicaciones, ası como de los alternativas en despliegue deaplicaciones distribuidas. Para esto se utilizaran todos los recursos bibliograficos yelectronicos disponibles.

8

1.7. Restricciones

2. Especificacion: del proyecto para delimitar su ambito. Para esto se identificaran ob-jetivos y se capturaran los requerimientos funcionales y no funcionales del sistema.Tras esta fase se procedera a la estimacion de la planificacion temporal.

3. Analisis: de los requerimientos para sentar las bases de una solucion al problema.Esta fase incluye la identificacion a alto nivel de las necesidades del sistema. Estoincluye la especificacion el lenguaje de descripcion de escenarios.

4. Diseno: del sistema. Esta etapa incluye el diseno arquitectonico del sistema, la espe-cificacion de operaciones, el diagrama de clases del sistema, etc.

5. Implementacion: esta etapa consiste en la implementacion de los modelos descritosen las fases anteriores.

6. Evaluacion: durante esta fase se evaluaran las prestaciones de las herramientas desa-rrolladas en entornos reales, valorando especialmente su flexibilidad.

7. Documentacion: coincidente en el tiempo con las etapas anteriores, se procedera a lageneracion de la documentacion de los resultados pertinentes.

1.7. Restricciones

Las restricciones inherentes al proyecto se clasifican en factores dato y factores estrategi-cos. Ambos factores influyen a la hora de tomar decisiones y delimitan el desarrollo delproyecto.

1.7.1. Factores dato

Se expondran en esta seccion una serie de factores limitativos que condicionan la rea-lizacion del proyecto. Estas restricciones (tambien conocidas como factores dato) son limi-taciones impuestas que no pueden ser modificadas a lo largo del desarrollo del proyecto,y cuya imposicion no tiene por que estar justificada. Para el presente proyecto son:

Economicos: economizar el coste del sistema, tanto hardware como software.

Tiempo: el proyecto debera estar finalizado para septiembre de 2008.

Hardware: para el desarrollo y simulacion del sistema se dispondra 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

1. Introduccion

• Plataforma de desarrollo. El desarrollo del proyecto debera realizarse sobre unade las plataformas (combinacion de arquitectura, sistema operativo y versionesde compilador soportadas por NDDS). Considerando el hardware y softwarehabitual en un ordenador personal, una combinacion de plataforma de desa-rrollo aceptable es i86Linux2.6gcc3.4.3, que se traduce en arquitectura Intel 86,sistema operativo Linux 2.6 y la version 3.4.3 del compilador GCC.

• Lenguaje de descripcion de aplicaciones. NDDS ya utiliza XML para la confi-guracion de algunas de sus funcionalidades. Es un requerimiento que la des-cripcion de aplicaciones DDS se realice mediante el lenguaje XML para posi-bilitar la integracion de funcionalidades actuales y futuras.

• Implementacion del parser. En la actualidad, el procesado de ficheros XML quese hace en el producto NDDS utiliza la biblioteca EXPAT[24] para construir elreconocedor. Es un requerimiento utilizar esta biblioteca para implementar elprocesador de ficheros XML dada su portabilidad a arquitecturas utilizadaspor NDDS, entre otras caracterısticas.

• Lenguaje de programacion de la aplicacion. El lenguaje de programacion delprototipo sera el lenguaje C, ya que es el lenguaje que debe utilizarse con labiblioteca EXPAT. Ademas, dada la manera en que integran las interfaces paradiferentes lenguajes de programacion en NDDS, el desarrollo base debe hacer-se siempre en C.

Humanos: en el desarrollo del proyecto participaran un alumno y el director delproyecto.

1.7.2. Factores estrategicos

Los Factores estrategicos son factores que no dependen de la naturaleza del problemay, por tanto, permiten tomar decisiones entre varias alternativas, lo que abre la posibili-dad de mejorar aspectos como por ejemplo los costes, la calidad o la extensibilidad delproyecto.

Para este proyecto, consideramos como decisiones estrategicas:

Plataforma de desarrollo. Se ha elegido Ubuntu GNU/Linux como plataforma de desa-rrollo por ser un entorno libre e ideal para el desarrollo de aplicaciones. Muchasherramientas y bibliotecas son compatibles con este sistema operativo, entre ellasNDDS.

Entorno de programacion. Se ha elegido el entorno de desarrollo libre para C/C++Eclipse C/C++ Development Tooling - CDT. Eclipse es un entorno de desarrollo ex-celente, ademas de por sus funcionalidades como editor y gestor de codigo, porintegrarse a la perfeccion con otras herramientas libres como el depurador GDB, laherramienta GNU make y el compilador GCC. Ademas, Eclipse puede extender sufuncionalidad para el tratamiento de ficheros XML.

10

1.8. Antecedentes y estado del arte

Depuracion de errores y rendimiento. Se incluiran opciones de compilacion condicionalpara activar mensajes de depuracion en el codigo, a fin de facilitar la deteccionde errores durante el desarrollo. Ademas, se utilizara la herramienta Valgrind paracomprobar la correcta liberacion de recursos en los momentos adecuados.

Portabilidad del desarrollo. Para asegurar la portabilidad de desarrollo a otras plata-formas a las que no tenemos acceso, como sistemas operativos de tiempo–real, seutilizara de manera estricta el estandar del lenguaje C. El uso de algunas opcionesde activacion de advertencias del compilador puede ayudar a esto.

Construccion del analizador sintactico. Como se explicara durante el presente docu-mento, se implementara un analizador de lenguaje semi-natural para facilitar lainteraccion del desarrollador con el escenario. Este analizador sintactico se cons-truira utilizando las herramientas Lex y Yacc ya que, no solo facilitaran la tarea, sinoque generaran un analizador optimo, robusto y facilmente extensible.


El problema abordado se centra inicialmente en el prototipado rapido de aplicacionesy reutilizacion de componentes software. Desde este punto de vista, se pueden encontrarideas de interes en algunas herramientas de automatizacion de pruebas distribuidas paraDDS. Estas herramientas pueden configurarse, en mayor o menor medida, para adaptar-se al tipo de prueba que el usuario quiere realizar.

Para situar adecuadamente el trabajo realizado, en el apartado siguiente se examinanlos antecedentes en sistemas de distribucion de datos. A continuacion se presentara bre-vemente el lenguaje XML y, en ultimo lugar, se examinaran los trabajos mas recientes enla configuracion y prototipado de aplicaciones DDS.

1.8.1. Antecedentes en distribucion de datos

El desarrollo de aplicaciones distribuidas ha merecido grandes esfuerzos de inves-tigacion durante ya varias decadas. Entre las herramientas desarrolladas es de especialmencion la API Berkeley Socket Distribution[25]. A partir de este punto, se han propuestonumerosos middleware, especificados para verificar los objetivos de simplificar los costesde desarrollo, optimizar las prestaciones y la utilizacion de los recursos de la red, ofrecermayor escalabilidad, fiabilidad y disponibilidad, ası como potencial interoperatividadentre diferentes plataformas.

Mencionar especıficamente la librerıa RPC (Remote Procedure Call[26]), desarrolladapara facilitar la ejecucion de procedimientos remotos. Recientemente, RPC ha evolucio-nado para aprovechar la extensibilidad de XML, dando lugar a XML-RPC, middlewareque tıpicamente hace uso del protocolo HTTP para transportar las transacciones. El in-tercambio de mensajes basados en XML sobre HTTP[27] ha dado lugar al protocolo SOAP

11

1. Introduccion

(Simple Object Access Protocol)[28], el cual es parte fundamental de la pila de protocolosque da soporte a los ası denominados Web Services[1], definidos por el consorcio W3C.En esta aproximacion, se utiliza WSDL (Web Services Description Language)[2] para des-cribir la interfaz a los objetos remotos. Es tambien destacable la API RMI (Remote MethodInvocation)[29] para Java, la cual proporciona una funcionalidad parecida a RPC. Final-mente, no puede faltar mencion a la arquitectura CORBA (Common Object Request BrokerArchitecture)[4] definida por el consorcio OMG. CORBA proporciona una aproximacionbasada en objetos, accesibles de forma remota a traves de la interfaz IDL (Interface Defini-tion Language)[30].

Todas las tecnologıas anteriormente citadas tienen en comun la adopcion del ası de-nominado paradigma cliente-servidor. Alternativamente, y especialmente disenado parasu utilizacion en aplicaciones con requisitos de tiempo-real, se ha propuesto middlewareque adopta un paradigma distinto al anterior basado en una metodologıa publicacion-subscripcion. Este modelo se fundamenta en el intercambio asıncrono de mensajes. Aquı,las entidades generadoras declaran los temas que estan dispuestas a publicar, y las consu-midoras se subscriben a los temas que les sean de interes. Cuando un productor publicaun dato en un topico dado, todos los subscriptores lo recibiran de forma transparente a laaplicacion. De esta forma, este paradigma adopta una aproximacion denominada data-centric, ya que desacopla (en el tiempo y el espacio) la interaccion entre los participantes(consumidores o generadores de informacion), y se enfoca en la distribucion de los datos,con independencia de la localizacion y el instante del origen o del destino de los mismos.Para la distribucion de datos de acuerdo con un paradigma publicacion–subscripcion, laOMG ha especificado recientemente el estandar DDS (Data Distribution Service for Real-Time Systems)[6] lo que, dada la solvencia y reconocimiento de esta institucion, ha venidoa consolidar definitivamente este nuevo paradigma o modelo de interaccion alternativo.

1.8.2. El lenguaje XML

Antecedentes y relevancia de XML

XML son las siglas en ingles de Extensible Markup Language (“lenguaje de marcasampliable”)[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 anossetenta, llamado GML (General Markup Language), que surgio por la necesidad que tenıala empresa de almacenar grandes cantidades de informacion. XML se propone como unestandar para el intercambio de informacion estructurada entre diferentes plataformas.Se puede usar en bases de datos, editores de texto, hojas de calculo, etc.

XML es una simplificacion y adaptacion del SGML que permite definir la gramaticade lenguajes especıficos. Por lo tanto XML no es realmente un lenguaje en particular, sinouna manera de definir lenguajes para diferentes necesidades. Ejemplos de estos lenguajesque usan XML para su definicion son XHTML, SVG o MathML.

Una manera de describir la gramatica de un lenguaje especıfico basado en XML es

12


la definicion de tipo de documento (DTD, Document Type Definition), que es una descripcionde estructura y sintaxis de un documento XML. DTD se incluye dentro del estandar deXML inicial, aunque el propio W3C ha propuesto XSD (XML Schema Definition)[32] comoalternativa que supera las limitaciones de DTD.

XML presenta varias ventajas como tecnologıa:

Se basa en estandares internacionales y como tal es un estandar abierto.

Puede representar estructuras de datos comunes en el campo de la informatica:registros, listas y arboles.

Los algoritmos de analisis sintactico son simples, eficientes y consistentes dadas susrestricciones de sintaxis y analisis.

XML se utiliza se utiliza masivamente para el almacenamiento y procesamiento dedocumentos.

La adopcion de XML en la industria e campos de investigacion es alta, y es porello que existen multitud de herramientas libres para trabajar con XML desde lageneracion de documentos hasta el procesado de la informacion almacenada enXML.

Un lenguaje basado en XML puede ser facilmente modificado de manera incremen-tal y sin perder compatibilidad hacia atras.

La validacion de documentos mediante lenguajes de esquema como DTD o XSDfacilita, entre otras tareas, las relacionadas con la especificacion y construccion desoftware.

La estructura jerarquica de XML se utiliza con exito para representar conocimientoen multitud de campos de trabajo, si bien esta estructura jerarquica no siempre esvalida para un dominio de conocimiento.

Desventajas de XML y alternativas

Existen multitud de debates sobre las ventajas de XML que ponen en relieve circuns-tancias ante las cuales el uso de XML presenta mas desventajas que ventajas[33]. Algunasde estas son:

La sintaxis de XML es redundante o grande, en terminos de tamano, en compa-racion con representaciones de datos alternativos, especialmente si se utiliza pararepresentar datos tabulares. Esta redundancia afecta al rendimiento de las aplica-ciones al aumentar el tamano de almacenamiento y transferencia, ası como al costede procesamiento.

13

1. Introduccion

La sintaxis presenta sobrecarga de informacion para un lector humano en compa-racion con otros formatos de transferencia de datos.

El modelo jerarquico de representacion del conocimiento es limitado en compara-cion con otras alternativas, como por ejemplo, las orientadas a grafos.

La expresion de solapamientos entre relaciones de los nodos requiere un esfuerzoextra.

Promueve el uso de estructuras de datos no relacionales (datos no normalizados).

XML introduce un fuerte acoplo entre la representacion elegida y el procesamientode la informacion, a diferencia de las alternativas de almacenamiento relacional ySQL.

La mayor parte de las desventajas, como podemos ver, estan relacionadas con la va-lidez de XML para representar datos completos y relaciones entre estos datos. Especial-mente para representar grandes cantidades de datos que deben procesarse y/o trans-ferirse a traves de una red, XML presenta una sobrecarga en el tamano que ocupa lainformacion al serializarse. En este sentido, han aparecido alternativas como JSON (Ja-vaScript Object Notation, notacion de objetos de JavaScript)[34][35]. JSON es un formatoligero para el intercambio de datos que puede sustituir a XML para la representacion ytransferencia de datos. JSON mejora notablemente el espacio de almacenamiento y anchode banda durante la transferencia de informacion, aunque, a cambio, presenta limitacio-nes respecto a XML[36].

1.8.3. Herramientas para el desarrollo de aplicaciones DDS

Soporte para DDS de la aplicacion Enterprise Architect

La empresa Sparx Systems[37] ha desarrollado un complemento de soporte de DDSpara su programa de diseno software Enterprise Architect llamado MDG technology forDDS [38].

Esta herramienta es capaz de generar codigo valido para su compilacion mediante laespecificacion de la aplicacion 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 diseno y desarrollo desistemas software propuesto por la OMG. MDA es una arquitectura que proporciona unconjunto de guıas para estructurar especificaciones expresadas como modelos.

Bajo este enfoque, la funcionalidad del sistema se define mediante los modelos indepen-dientes de plataforma (PIM, Platform-Independent Model) utilizando un lenguaje especıficopara un dominio o de proposito general. Para diversas plataformas como CORBA, entor-nos Web o DDS se define un modelo de definicion de plataforma (PDM, Platform Definition

14


Figura 1.2: Especificacion de entidades DDS con Enterprise Architect

Model). Un modelo PDM es capaz de traducir los modelos PIM en modelos especıficos deplataforma (PSM, Platform-Specific Models). Los PSM pueden ser ejecutados directamenteen un ordenador.

Enterprise Architect permite especificar los modelos a partir de una serie de formu-larios y diagramas UML (ver Figura 1.2). A partir de esta representacion genera codigoDDS listo para compilarse en la plataforma NDDS.

Enterprise Architect es interesante como forma de especificacion de parametros paralas entidades DDS sin especificar el comportamiento de estas. Al fin y al cabo, lo que ge-nera esta herramienta es el esqueleto de una aplicacion distribuida sobre la que empezarel desarrollo.

DDS Benchmark Project

El grupo de investigacion Distributed Object Computing (DOC) Group for DistributedReal-time and Embedded (DRE) Systems[40] es un grupo compuesto por las universidades

15

1. Introduccion

estadounidenses de Vanderbilt, Washington y California. Este grupo ha desarrollado unaherramienta para comparar el rendimiento de diferentes implementaciones del estandarDDS llamada DDS Benchmark Project[41].

DDS Benchmark Project tiene como objetivo evaluar las siguientes caracterısticas de unproducto DDS:

El rendimiento respecto a la latencia (latency) y tasa de transferencia (throughput).

La facilidad de programacion de las interfaces ofrecidas.

Las diferencias de rendimiento respecto a otros sistemas de publicacion–subscripcion.

Este conjunto de herramientas permiten al usuario configurar la ejecucion de prue-bas distribuidas. Este sistema cuenta con varias aplicaciones DDS y cada aplicacion tieneuna serie de entidades DDS predefinidas. Estas entidades admiten una serie de parame-tros que se especifican mediante ficheros XML, aunque estos parametros solo incluyenla frecuencia de publicacion de datos, el tamano de los datos y algunos parametros deconfiguracion QoS para DDS. No se puede especificar, por ejemplo, el tipo de datos quese publica, ni combinar varios de estos tipos en un mismo escenario.

La distribucion del escenario se realiza ubicando una serie de ficheros ejecutables enun sistema de ficheros de red (NFS en concreto) al que todos los nodos tienen acceso.Por otro lado, la creacion de entidades DDS y su actividad se controlan mediante unaserie de guiones que se ejecutan en cada nodo que participa en la prueba para ejecutar elprograma 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 adap-ta los algoritmos genericos de cada prueba a la interfaz de programacion de cada pro-ducto DDS, lo que permite desarrollar pruebas identicas para comparar el rendimientode diferentes implementaciones de DDS. En la actualidad el proyecto funciona con losproductos NDDS[8], OpenSplice[10] y OpenDDS[12] y los resultados experimentales sonpublicos[42].

1.9. Aproximacion a la solucion propuesta

Antes de entrar en el desarrollo del proyecto, a modo de resumen, se ofrece una visiongeneral de la solucion propuesta.

La motivacion del proyecto se puede resumir como la busqueda de una solucion alprototipado rapido y masivo de aplicaciones DDS. Esta solucion plantea una serie deretos.

El primer reto corresponde a la descripcion de aplicaciones que componen el escenario.Para ello, se propone dividir la descripcion del escenario en dos modelos:

16

1.9. Aproximacion a la solucion propuesta

El Modelo Estatico describe las entidades DDS mediante un lenguaje basado en XMLque especificara tanto las entidades en sı, como las relaciones entre estas.

El Modelo Dinamico describe el comportamiento de las entidades DDS mediante unlenguaje de programacion.

Los Modelo Estatico y Dinamico son independientes. Esto es, el Modelo Estatico deuna entidad podra asociarse a un Modelo Dinamico distinto en momentos diferentes. Estopermitira cambiar por completo el comportamiento de una aplicacion distribuida cam-biando el Modelo Dinamico de sus entidades.

La Figura 1.3 representa los conceptos de Modelo Estatico, Modelo Dinamico y como unescenario puede cambiar su comportamiento reemplazando el Modelo Dinamico de susentidades.

El segundo reto corresponde al despliegue y ejecucion del escenario. Para ello se divi-den los nodos de la red en dos tipos: el nodo “Command Master” se encarga de publicarinstrucciones para el despliegue del escenario, mientras que los nodos que del tipo “Com-mand Slaves” estaran subscritos a las instrucciones que distribuya este nodo. El problemade la distribucion de instrucciones se resuelve utilizando el propio middleware DDS.

Los nodos “Command Slaves” desarrollaran aplicaciones ejecutando las ordenes quereciban los modelos estaticos y dinamicos que se les asocien.

El ultimo problema a resolver se refiere a la interaccion del desarrollador con el es-cenario mediante una gramatica semi-natural. Esta gramatica permitira especificar lasordenes que se quiere hacer llegar a los nodos del escenario. De esta forma se ofrece unainterfaz para controlar el despliegue y permite una vision global del escenario.

En resumen, se pretende simplificar la tarea del despliegue de uno o varios escenariosDDS de grandes dimensiones a:

La descripcion del escenario o escenarios mediante modelos estaticos y dinamicos.

El uso los nodos “Command Master” y “Command Slaves” para desarrollar estosescenarios.

El Apartado 5.1, de arquitectura del sistema, profundiza mas en las ideas aquı expues-tas.

17

1. Introduccion

Figura 1.3: Descripcion de escenarios DDS mediante los modelos Estatico y Dinamico18

CAPITULO 2

ESPECIFICACION DE REQUISITOS

Este capıtulo tiene como objetivo identificar el conjunto de requerimientos que el sis-tema debe de cumplir, diferenciandose en dos tipos:

Requisitos funcionales, que son los que se encuentran orientados a la funcionalidadque debe desempenar la aplicacion de cara al usuario final.

Requisitos no funcionales, orientados al funcionamiento final de la aplicacion. Son re-quisitos que no tienen que ver con la funcionalidad de la aplicacion, sino como severa mas adelante, estan mas orientados a caracterısticas que debe cumplir el fun-cionamiento de la aplicacion.

El sistema en desarrollo consiste en la creacion de un conjunto de herramientas parael desarrollador de aplicaciones que utilicen DDS. El usuario sera, pues, un investigadoro un desarrollador que pretenda comprobar la adecuacion del middleware DDS a la redsobre la que experimenta o sobre el que planea implantar un sistema en produccion.

2.1. Requisitos Funcionales

Descripcion de los parametros de todas las entidades DDS existentes mediante XML.El punto de partida del proyecto lo constituye la descripcion de entidades DDS. Esto sehara mediante la especificacion de todos los parametros que el API de DDS admite parala creacion de entidades. Estos parametros pueden ser datos simples u otras entidadesDDS de manera que implıcitamente quede definida la relacion de jerarquıa entre entida-des necesaria para que el sistema funcione. Debe tener mencion especial la especificacionde los parametros de calidad de servicio (QoS) que se quieran aplicar a las entidades.Es un requerimiento que la descripcion de todo este conocimiento se haga mediante un

19

2. Especificacion de Requisitos

documento XML. Este requerimiento implica la definicion de tipo de documento (DTD, Do-cument Type Definition) para validar los ficheros XML que el usuario cree.

Creacion de un parser o analizador sintactico para los documentos XML definidos.Puesto que se va a trabajar con XML, debera crearse un analizador sintactico que permitavalidar el documento y crear una representacion en memoria del mismo que contenga lainformacion del fichero XML de forma estructurada. Esta estructura en memoria sera elresultado del proceso de analisis sintactico del fichero. Es un requerimiento que el ana-lizador sintactico se implemente extendiendo el actual analizador construido sobre labiblioteca EXPAT (ver 1.7.1 Factores Dato).

Creacion de un API de interaccion con el documento XML. Debera proporcionarseuna API que permita al usuario consultar o modificar la informacion resultante del pro-ceso de analisis sintactico. Puesto que esta informacion se almacenara en una estructurade tipo arbol el API debe permitir operaciones comunes que permitan, partiendo de unnodo, acceder a nodos padres, hermanos o hijos. Esto incluye ofrecer al usuario metodosespecializados de recorrido del arbol, esto es, dado, por ejemplo, un Tema, debe poder rea-lizarse una operacion de acceso directo al nodo del Participante del que es hijo. Comple-mentando a las operaciones de navegacion por el arbol, deben proporcionarse metodosde acceso a los datos almacenados en cada nodo.

Creacion un API que permita integrar metodos escritos por el usuario en el sistema.Como ya se argumento en la redaccion de los Objetivos (1.4), para la especificacion delcomportamiento sera necesario el uso de metodos que describan programaticamente laactividad de cada entidad DDS. Sera necesario crear una interfaz de integracion de estosmetodos del usuario en el sistema, ası como definir los lımites que el usuario tendra paraescribir este codigo.

Interfaces de programacion para la creacion y destruccion de entidades DDS. Se debeproporcionar una interfaz de programacion que permita la creacion y destruccion de lasentidades DDS descritas en el documento XML dado un identificador de la entidad o deentidades padres a las que pertenece.

Interfaces de programacion para la asignacion y control del comportamiento de unaentidad DDS. Se debe proporcionar una interfaz de programacion que permita la asig-nacion de metodos y listeners a entidades DDS descritas en el documento XML dado unidentificador 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 DDSdel escenario. Puesto que una de las aplicaciones directa del proyecto es la experimen-

20

2.2. Requisitos no Funcionales

tacion escenarios DDS compuestos de muchas entidades, sera necesario proporcionar alusuario una interfaz de interaccion con el escenario. Esto es decidir en que momento secrean todas o algunas de las entidades DDS, ası como el momento en el que se destruyeno el momento en el que inician su actividad. Podemos adelantar que esta interfaz se en-cargara de producir ordenes que los nodos del escenario deberan procesar correctamente.

2.2. Requisitos no Funcionales

Ejecucion de tareas concurrentes. La programacion de aplicaciones que procesan flujosde datos diferentes, tanto para leerlos desde la red como para enviarlos a traves de la red,de manera simultanea implica el diseno, programacion y prueba del software para laejecucion de tareas concurrentes de manera correcta.

Rendimiento y consumo de recursos. El uso del proyecto al crear y destruir entidadesDDS, hebras de tareas, etc. conllevara la asignacion y liberacion constante de recursos.Esta debera hacerse de forma eficaz y eficiente para no degradar las prestaciones de lamaquina donde se ejecuta el proceso y afectar a posteriores usos de la propia aplicacion.

Flexibilidad. El conjunto de herramientas desarrolladas y la biblioteca de funcionesdeberan ser flexibles para permitir la descripcion de la mayor diversidad de escenariosposibles.

Portabilidad. Se deberan cuidar los aspectos de portabilidad respecto de sistemas ope-rativos, compiladores, versiones del compilador y respecto del estandar DDS.

Facil instalacion. Puesto que las herramientas deberan distribuirse a muchos nodosde red, el procedimiento de instalacion de las herramientas debera ser lo mas sencilloposible.

Transparencia y abstraccion. Debera abstraerse al usuario al maximo respecto a las ta-reas de programacion y la especificacion de parametros de las entidades DDS, ası comode la difusion de ordenes.

21

2. Especificacion de Requisitos

22

CAPITULO 3

PLANIFICACION

Una vez obtenidos los requisitos del sistema, se presenta una estimacion inicial de lastareas en que se descompone el desarrollo del proyecto.

La planificacion del proyecto se gestiona con ayuda de la aplicacion Planner[43]. Laplanificacion se hizo mediante un diagrama de Gantt. Debido a el tamano de este tipode diagramas solo se mostrara un detalle del mismo a modo de ejemplo (Ver Figura 3.1),mientras que la planificacion completa se muestra en forma de tabla de datos.

La estimacion inicial de tareas y duracion de las mismas se muestra en la Figura 3.2.

23

3. Planificacion

Figura 3.1: Detalle del diagrama de Gantt de la planificacion inicial del proyecto

24

Figura 3.2: Planificacion inicial del proyecto en formato tabular

25

3. Planificacion

26

CAPITULO 4

ANALISIS DE REQUISITOS

Una vez descrito el problema mediante la identificacion de requisitos, funcionales yno funcionales, el siguiente paso es realizar un analisis mas detallado de estos. En estecapıtulo se analizan los requerimientos de la aplicacion mediante la identificacion y des-cripcion grafica y textual de casos de uso. De esta forma obtendremos una descripcion aalto nivel de las operaciones que debe realizar el sistema.

Ademas, se abordan las necesidades de la gramatica de interaccion con el escenario,ası como la definicion de formato de ficheros XML.

4.1. Casos de uso del sistema

Cada caso de uso proporciona uno o mas escenarios que indican como deberıa inter-actuar el sistema con el usuario o con otro sistema para conseguir un objetivo especıfico.

4.1.1. Identificacion de los actores del sistema

Usuario Se identifica con el usuario de la aplicacion, que en este caso es el desarrolladorde aplicaciones distribuidas que quiere desplegar e interaccionar con el servicio dedistribucion de datos. El usuario interactua con el sistema para distribuir la des-cripcion del escenario y controlar el ciclo de vida y actividad de las entidades DDSque componen el escenario.

Nodo El rol de este actor se identifica con un nodo que participa en el sistema distribui-do. Un actor del tipo Nodo interactua con el Usuario, del que obtiene las acciones arealizar, y mantiene contacto con el actor DDS Middleware para desarrollar las tareasque le asigne el usuario.

27

4. Analisis 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 procesarlos ficheros XML que describen el escenario. Como resultado de este procesamientoel DDS XMLParser devolvera el arbol que representa el escenario.

DDS Middleware El rol de este actor se identifica con el software encargado de gestio-nar la funcionalidad relacionada con un servicio de distribucion de datos. Concep-tualmente, cada Nodo mantendra contacto con el actor DDS Middleware para realizarlas gestiones pertinentes.

4.1.2. 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 abstraccion, la interaccion entre los tres actores del sistema y enque casos participa cada uno.

28

4.1. Casos de uso del sistema

4.1.3. Listado de los casos de uso

A continuacion se describen brevemente los casos de usos identificados en la Figura4.1. Notese que la descripcion se hace a muy alto nivel. La descripcion de estas operacio-nes se refinara en capıtulos posteriores.

Cargar escenario. Es un caso de uso base. El objetivo de este caso de uso es hacer llegarla descripcion del escenario a todos los nodos que participan en la aplicacion distri-buida, y que estos seleccionen la aplicacion que les corresponda. Este caso de usose compone de los casos de uso distribuir escenario e interpretar escenario, descritos acontinuacion.

Distribuir escenario. Este caso de uso esta incluido en el caso anterior. Hace referencia ala distribucion del escenario que el usuario quiere asignar a los nodos participantes.

Interpretar escenario. Este caso de uso esta incluido en el caso Cargar escenario. Repre-senta las acciones que deben desarrollarse en cada nodo ante la recepcion del es-cenario que se esta distribuyendo. Tıpicamente un nodo que recibe la descripcionde un escenario seleccionara una aplicacion de entre las descritas en el escenario,dicha seleccion se hara en base a la informacion de asignacion de aplicaciones anodos que se etiquete en el fichero.

Gestion entidades DDS. Caso de uso base. Abarca todas las operaciones relacionadascon la gestion de la creacion y destruccion de las entidades DDS. En el partici-pan todos los actores ya que las entidades se crean y destruyen ante peticiones delUsuario que cada Nodo interpreta. El Nodo se comunicara con el actor DDS parala realizar las operaciones de gestion pertinentes.

Crear entidad DDS. Este caso de uso extiende al caso de uso Gestion entidades DDS. Laoperacion consiste en la orden de creacion de una entidad DDS dado el identifica-dor de la entidad DDS XML que la envuelve. El Usuario proporciona un identifi-cador de la entidad DDS XML que sera utilizado por cada Nodo para buscar esaentidad dentro de la aplicacion que tiene asignada. Los Nodos cuya aplicacion con-tengan la entidad DDS XML buscada crearan la entidad DDS que se describe en lamisma.

Destruir entidad DDS. Este caso de uso extiende al caso de uso Gestion entidades DDS.El objetivo del caso es destruir las entidades DDS a partir de un identificador queproporciona el Usuario. La localizacion de la entidad se hace de manera similar alcaso de uso Crear entidad DDS. La destruccion de una entidad implica el cese de suactividad.

Gestion del comportamiento. Es un caso de uso base cuyo objetivo es el control del com-portamiento que las entidades tienen en la red.

29


Iniciar comportamiento. Este caso de uso extiende al caso Gestion del comportamiento pa-ra controlar el inicio del comportamiento de las entidades. La localizacion de laentidad sobre la que aplicar la operacion se realiza como en Crear entidad DDS. Ca-da Nodo debera gestionar correctamente la ejecucion paralela de tareas de cadaentidad DDS que pertenezca a la aplicacion que esta desarrollando.

Parar comportamiento. Este caso de uso extiende al caso Gestion del comportamiento paracontrolar el fin de la actividad de una entidad. El funcionamiento es el contrario aIniciar comportamiento.

4.2. Gramatica de interaccion con el escenario

Una de las partes esenciales del proyecto es la interaccion que el desarrollador debetener con el escenario. Como se comento en la Seccion 1.9, se ha optado por un metodo deinteraccion con el escenario basado un lenguaje semi-natural. Este lenguaje de interacciondebe ser disenado considerando los casos de uso presentados y las ideas aportadas en elApartado 1.9.

La gramatica debe proporcionar mecanismos que hagan que el acceso al escenarioDDS por parte del usuario sea lo mas sencillo posible. Ademas de sencilla, debe de serintuitiva, para que la curva de aprendizaje sea mınima. Es por ello que las palabras quese reconoceran estaran escritas en ingles y trataran de coincidir con las palabras repre-sentativas de acciones similares en otros sistemas como “load” para indicar la carga deun fichero o “create” para indicar una accion de creacion.

Tras estas consideraciones, la gramatica debe soportar las siguientes operaciones:

Carga, distribucion y asignacion de aplicaciones. Esta operacion debera distribuir elfichero XML que describe el escenario. La participacion en esta operacion dependedel actor:

• La aplicacion de interaccion con el usuario debera leer el fichero que se le pro-porciona y distribuirlo, mediante el uso de DDS, al resto de nodos de la red. Sies necesario, el fichero debera ser dividido en fragmentos para su transmisiondadas las limitaciones de NDDS en este sentido[23].

• Los nodos de la red deberan leer, reconstruir y procesar la descripcion delescenario para seleccionar una aplicacion.

Creacion y destruccion de entidades DDS dado un identificador de una entidad.

Creacion y destruccion de todas las entidades DDS del escenario. En este caso es obvioque no se necesita identificador alguno.

Inicio y parada de la actividad de entidades DDS dado un identificador de una entidad.

30

4.2. Gramatica de interaccion con el escenario

Inicio y parada de la actividad de todas las entidades DDS del escenario. En este caso esobvio que no se necesita identificador alguno.

Liberacion de recursos y finalizacion de la ejecucion. El sistema debe proveer de unamanera de terminar todas las aplicaciones remotas. Las aplicaciones deberan liberartodos los recursos en uso antes de finalizar la ejecucion.

Aclarar que una instancia DDS sobre la que aplicar una orden queda identificada porel nombre del objeto DDS XML que la envuelve mas un numero que indica a que instan-cia, de entre las descritas por el objeto DDS XML, se aplica la operacion.

4.2.1. Definicion de la gramatica

Una vez que descritas las operaciones que debe soportar la gramatica estamos endisposicion de especificarla para dar soporte a estas operaciones. La definicion de lagramatica se realizara mediante la notacion BNF (Backus-Naur form) por ser la forma deespecificacion mas conocida. El Listado 4.1 muestra esta gramatica 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: Gramatica BNF definida para interaccion con el escenario

El siguiente paso es identificar cada tipo de orden o comando con cada una de lasoperaciones que debe soportar nuestra aplicacion:

<commands> Es el sımbolo inicial de la gramatica. Cada lınea de texto escrita en elterminal de entrada a la aplicacion se considerara como una nueva orden.

<command> Aglutina al conjunto de ordenes que son reconocidas. Estas son:

LOAD <string>: cargar y distribuir el escenario cuyo fichero se indica co-mo parametro. Los siguientes parametros se aplican bajo la premisa de habercargado un escenario.

CREATE <xml_entity_id> <dds_instance_number>: crear la entidadcon el primer parametro como identificador y segundo parametro como nume-ro de instancia DDS.

31


DESTROY <xml_entity_id> <dds_instance_number>: destruir la enti-dad con el primer parametro como identificador y segundo parametro comonumero de instancia DDS.

START <xml_entity_id> <dds_instance_number>: iniciar el compor-tamiento de la entidad con identificador <xml entity id> y numero de ins-tancia DDS <dds_instance_number>.

STOP <xml_entity_id> <dds_instance_number>: detener el compor-tamiento de la entidad con identificador <xml entity id> y numero de ins-tancia 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 ejecu-cion en todos los nodos del escenario.

4.2.2. Estructura de datos de ordenes

Para poder transmitir datos en DDS, estos deben definirse previamente mediante elformato IDL[30]. Como se ha mencionado, las ordenes se transfieren a todos los nodosparticipantes utilizando un tema de control creado para el middleware NDDS, ası que debe-mos 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 variableconst 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 falseenum 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

4.3. Lenguaje de descripcion de aplicaciones

struct Command {// Tipo de orden que contiene la instancia de// datos transferidaCommandKind command;// ID de la entidad XML e ID de la instancia DDS a// la que aplicar la ordenstring <CMD_ENTITY_NAME_SIZE_MAX> entity_name;short instance_id;// Variables para la transferencia de datos auxiliares// como el contenido de un fichero XMLstring <CMD_DATA_NAME_SIZE_MAX>data_id;string <CMD_DATA_MAX_SIZE> data;

};

Listado 4.2: Fichero IDL correspondiente al tema de control


El lenguaje de descripcion de escenarios sera un lenguaje basado en XML, tal y comose indico en el Apartado de Factores Dato, y lo describiremos mediante un documentoDTD. En esta seccion analizaremos la informacion necesaria que deben manejar los fi-cheros XML y que debe quedar reflejada en el DTD, junto con las restricciones en lasrelaciones entre entidades DDS.

Comenzaremos introduciendo los atributos comunes a los elementos XML que defi-niremos mas 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 dela que este objeto hereda. Los atributos y etiquetas de la clase base se utilizaran en laclase que hereda de ella, aunque podran sobreescribirse.

Los siguientes elementos podran estar presentes en todas las entidades:

listener: identifica a un listener del Modelo Dinamico que se utilizara con la en-tidad.

behaviour: dentifica a un metodo del Modelo Dinamico que define el comporta-miento de la entidad.

instances: numero maximo de instancias DDS que se pueden crear para el objetoXML definido.

33


El elemento raız del escenario sera dds. Este estara compuesto por una o varias apli-caciones DDS tal y como se muestra en el Listado 4.3. A su vez, estas aplicaciones estarancompuestas por uno o varios participantes de dominio. En el mismo listado tambien semuestran los elementos comunes enumerados antes.

<!ELEMENT dds (application)*>

<!ELEMENT application (participant+)><!ATTLIST application name CDATA #IMPLIED><!ATTLIST application base_name CDATA #IMPLIED>

<!ELEMENT listener (#PCDATA)><!ELEMENT behaviour (#PCDATA)>

<!ELEMENT instances (#PCDATA)>

Listado 4.3: Descripcion de una aplicacion

El Listado 4.4 muestra como un participante de dominio esta compuesto de varias enti-dades hijas que pueden ser temas, publicadores o subscriptores.

<!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: Descripcion de un participante de dominio (Domain Participant)

El Listado 4.5 ilustra la estructura de un tema. No se ha considerado que un tema pue-da tener varias instancias puesto que no tiene sentido que haya mas de un tema por parti-

34


cipante de dominio[44]. Ademas de los datos comunes a todas las entidades, la descripcionde un tema incluye:

topic name: el nombre del tema.

type: el tipo de datos asociado al tema.

<!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: Descripcion de un tema (Topic)

El Listado 4.6 muestra, ademas de los elementos comunes a otras entidades, como unpublicador estara compuesto de varias entidades hijas escritoras. El mismo listado incluyela definicion de un escritor o DataWriter. Destacar que el elemento datawriter topic corres-pondara a un tema previamente definido. Este tema sera el que el DataWriter utilice parapublicar datos.

El Listado 4.7 es el equivalente al Listado 4.6, pero aplicado a los subscriptores y loslectores de datos.

<!ELEMENT publisher

(datawriter*,listener?,behaviour?,instances?)>

<!ATTLIST publisher name CDATA #IMPLIED><!ATTLIST publisher base_name CDATA #IMPLIED>

<!ELEMENT datawriter (

datawriter_topic,listener?,behaviour?,instances?)>

<!ATTLIST datawriter name CDATA #IMPLIED><!ATTLIST datawriter base_name CDATA #IMPLIED>

35


<!ELEMENT datawriter_topic (#PCDATA)>

Listado 4.6: Descripcion de un publicador (Publisher)

<!ELEMENT subscriber

(datareader*,listener?,behaviour?,instances?)>

<!ATTLIST subscriber name CDATA #IMPLIED><!ATTLIST subscriber base_name CDATA #IMPLIED>

<!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: Descripcion de un subscriptor (Subscriber)

36

CAPITULO 5

DISENO

Tras la fase de analisis, en la que se identifica que se quiere hacer, el siguiente paso escomo se debe hacer. Durante este capıtulo se proporcionan los detalles mas relevantes deldiseno de nuestro sistema.

5.1. Arquitectura del sistema

El proposito de esta seccion es describir, desde un punto de vista de alto nivel, lasolucion al problema que este proyecto propone. Esta seccion de arquitectura del sistemaconstituye la parte central del diseno propuesto, y la mas importante. En ella se apoyatodo el desarrollo realizado.

5.1.1. ¿Como describir un escenario DDS?

El primer reto es encontrar la manera de describir un escenario DDS. Si consideramosque un escenario DDS es una gran aplicacion distribuida que a su vez se compone devarias aplicaciones, se puede considerar como un primer nivel de descripcion a la divi-sion del escenario en aplicaciones DDS. Estas aplicaciones DDS podran ejecutarse en unoo muchos nodos, y a su vez, en un nodo podran ejecutarse una o varias aplicaciones DDSdistintas.

Una aplicacion DDS estara compuesta por un conjunto de entidades DDS de las iden-tificadas en la Figura A.4 (Apendice A), estas son: participante de dominio o participante(Domain Participant o Participant), tema (Topic), publicador (Publisher), subscriptor (Subscri-ber), escritor (DataWriter) y lector (DataReader).

Las entidades se crean mediante llamadas al API de DDS ofrecida por el middleware.

37

5. Diseno

En esta API, salvo algunos parametros de calidad de servicio, los parametros son estaticos,es decir, una vez que se crea una entidad con unos parametros estos no pueden modifi-carse a no ser que la entidad se destruya y se cree de nuevo. La configuracion y creacionde entidades DDS constituye la preparacion de la infraestructura de comunicacion entreaplicaciones que se va a utilizar.

Por otro lado, las entidades presentan metodos para realizar acciones en el sistema.Los mas utilizados son los metodos para escribir datos en la red, utilizando un DataWriter,y los metodos para leer datos de la red mediante un DataReader. El uso de estos metodos,es decir, los datos que se escriben y se leen, representan la actividad del sistema distri-buido y constituyen el punto de conexion entre el middleware DDS y el sistema que sedistribuye en si. Por ejemplo, un publicador de informacion de sensores de temperaturacomprobara los sensores de la plataforma en la que se ejecuta y utilizara los metodos depublicacion para enviar los datos que recogen de los sensores.

Esta division funcional nos lleva a identificar dos modelos necesarios para la descrip-cion de una aplicacion DDS: el Modelo Estatico y el Modelo Dinamico. El Modelo Estaticose corresponde con la especificacion de todas las entidades DDS que serviran de soportea la comunicacion entre las aplicaciones distribuidas. El Modelo Dinamico define como secomporta cada una de las entidades DDS del escenario.

Nuestra propuesta es describir las aplicaciones DDS mediante sus modelos estatico ydinamico. Ası, el escenario DDS global lo constituiran un conjunto de aplicaciones descri-tas con estos dos modelos.

La Figura 5.1 presenta un escenario DDS compuesto de un conjunto de aplicacionesDDS. Como se puede observar, cada aplicacion puede especificarse con los dos modelospropuestos.

A continuacion se describiran las responsabilidades que se asocian a cada modelodentro del desarrollo global del escenario.

El Modelo Estatico

El Modelo Estatico de una aplicacion tiene como objetivo describir la arquitectura decomunicacion DDS que utilizara la aplicacion distribuida. Esta descripcion se hara me-diante un fichero XML que especificara los parametros necesarios de las entidades perte-necientes a la aplicacion.

Se definira, pues, un lenguaje de descripcion de aplicaciones basado en XML. Esto in-cluye la definicion del tipo de documento (DTD) y la creacion de un analizador sintacticoque extraiga informacion del fichero XML para construir el Modelo Estatico de la aplica-cion.

En terminos de estructuras de datos, el Modelo Estatico de la aplicacion es una estruc-tura jerarquica en forma de arbol en la que el nodo raız es una aplicacion DDS. De estaaplicacion parten los nodos que representan a las entidades DDS que componen la apli-

38


Figura 5.1: Descripcion de aplicaciones DDS mediante los modelos Estatico y Dinamico

39

5. Diseno

cacion. La estructura jerarquica del arbol, definida en el DTD, respeta las relaciones entreentidades definidas en el estandar de DDS[6] (ver Apendice A).

El Modelo Estatico se compone de una serie de clases que van a envolver a las enti-dades DDS. El procesamiento de un fichero XML que describa una aplicacion dara lu-gar a la creacion de un arbol cuyos objetos van a ser instancias estas clases. Estas cla-ses reciben el nombre de Entidades DDS XML y existira una por cada entidad DDS:DDS XMLDomainParticipant para el participante de dominio, DDS XMLPublisher para elpublicador, etc. La Figura 5.2 muestra un ejemplo de un arbol que representa una aplica-cion DDS.

Figura 5.2: Arbol del el Modelo Estatico para una aplicacion DDS

Como puede observarse en la Figura 5.2, el Modelo Estatico presenta una interfaz denavegacion por esta estructura en arbol que facilita el recorrido del mismo y el acceso a lainformacion contenida. Por ejemplo, la clase DDS XMLDataReader tendra un metodo lla-mado get xml subscriber() que permite obtener el nodo del tipo DDS XMLSubscriberdel que cuelga.

Cada entidad DDS XML es capaz de controlar tanto el ciclo de vida (crear y destruiruna entidad) y como el comportamiento de un tipo de entidad DDS (iniciar o detener lasacciones que realiza la entidad). Para ello, gestiona informacion diversa que agrupamosde la siguiente manera:

Datos de configuracion para la creacion de la entidad DDS (identificador de dominio,nombre del tema. . . ).

Parametros de conexion de la entidad con el Modelo Dinamico correspondiente.

40


Otros datos, como los relacionados con la gestion de hebras en la ejecucion concu-rrente de tareas.

El Modelo Dinamico

El Modelo Dinamico de una aplicacion DDS describe el comportamiento que tendranlas entidades que forman la aplicacion. El comportamiento se define como la actividadque realiza una entidad. Esto abarca no solo a la ejecucion de tareas programadas sinotambien la reaccion de la entidad a eventos que se produzcan en el sistema.

En el caso de la programacion de tareas de una entidad, la especificacion puede ha-cerse programando un metodo que podra ser utilizado por una o varias entidades. Enel caso de la reaccion ante eventos se hara utilizando la interfaz de DDS para configurarque eventos atiende un listener y como los gestiona. Un evento puede ser, por ejemplo,la llegada de datos a una cola de recepcion o la perdida de muestras de datos entre losrecibidos.

El sistema dispondra de un Modelo Dinamico global que almacene todos los mode-los dinamicos que se quieran utilizar. El conjunto de modelos dinamicos definidos for-mara una tabla sobre la que se podran realizar busquedas y obtener elementos que aso-ciar a las Entidades DDS XML para su posterior uso. Mediante esta asociacion el ModeloEstatico y el Modelo Dinamico quedan conectados.

5.1.2. La interaccion y coordinacion del escenario

Presentadas las cuestiones relativas a la descripcion del escenario, esta seccion presentacomo abordar la coordinacion entre las aplicaciones que componen el escenario, ası comola interfaz de interaccion que el desarrollador tendra con el.

Dicho problema puede ser dividido en dos subproblemas:

La distribucion de ordenes o comandos a todos los nodos para indicar que accionesrealizar. Para ello se propone delegar esta tarea en el propio middleware DDS. Deesta forma se define un tema de control sobre el cual se publicaran datos para lacoordinacion del escenario. Todos los nodos participantes se subscribiran a estetema de control de forma que recibiran las ordenes publicadas.

La interpretacion y desarrollo de estas ordenes, que se realizara mediante los nodosCommand Slave explicados mas adelante.

Para desplegar la infraestructura de coordinacion necesaria, los nodos de la red par-ticipantes en el futuro escenario DDS lo haran con dos roles bien definidos. El papel de“Command Master” se encarga de publicar ordenes utilizando el tema de control. El restode nodos participaran como “Command Slaves” y estaran subscritos al tema de control.Como puede deducirse, solo puede haber un “Command Master” para un escenario.

41

5. Diseno

Figura 5.3: Coordinacion del escenario distribuidos utilizando DDS

La aplicacion que actue como Command Master tiene dos funciones: interpretar orde-nes del usuario y distribuirlas. Para implementar la primera, se propone la creacion deuna gramatica de lenguaje semi-natural que permita al usuario interaccionar con el siste-ma. Respecto a la distribucion de ordenes, se delegara esta funcion en el propio DDS.

El rol de Command Slave implica la subscripcion al tema de control para recibir ordenesde la red. El nodo debera interpretar estas ordenes para desarrollar la parte del escenarioque le corresponda. Para ello utilizara la funcionalidad ofrecida por Modelos Estaticos yDinamicos.

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 corres-pondientes:

cmdmaster, que se ejecutara en el nodo que juega el papel de Command Master.cmdslave, que se ejecutara en los nodos que actuan como Command Slaves.

5.1.3. Funcionalidades para mejorar la flexibilidad del sistema

Para finalizar este capıtulo se introducen algunas ideas de diseno que mejoran la fle-xibilidad y potencia descriptiva del sistema.

42


Distribucion del escenario y asignacion automatica de aplicaciones a nodos

La distribucion del fichero XML que describe un escenario se hara utilizando tambienDDS para la transferencia. De esta forma se evitan dependencias de mecanismo externos,tal y como ocurre con algunas alternativas estudiadas en la Seccion 1.8.

Por otro lado, la asignacion de aplicaciones DDS a nodos se realiza de forma au-tomatica. Cuando un nodo recibe un fichero XML que contiene la lista de aplicacionesde un escenario selecciona una de ellas para desarrollarla. Sobre esta aplicara, a partir deentonces, los ordenes recibidas.

La asignacion se especifica incluyendo una lista de atributos en las etiquetas XML querepresentan una aplicacion. Estos atributos forman una lista de direcciones IP y nombresde maquina. Cuando un nodo recibe el fichero XML, comprueba si su nombre o direccionIP esta en la lista de cada aplicacion y ası selecciona la aplicacion adecuada.

Creacion de varias instancias, recursividad y herencia

Una manera de aumentar la capacidad expresiva del Modelo Estatico, y en conse-cuencia de las acciones que se pueden ejecutar con la interfaz que ofrece, es el soportepara:

La especificacion de un numero maximo de instancias DDS que se pueden crear apartir de un objeto DDS XML. Esto significa que se podran especificar descripcio-nes del tipo “crear 5 DataWriter como ’writer a’ en la aplicacion ’a”’. Este numerose especificara como una etiqueta mas en el fichero XML.

La aplicacion recursiva de acciones en las entidades. Esto es, incluir un parametroque permita especificar si una accion se aplica sobre una sola entidad o tambiensobre todos sus descendientes en el arbol.

Herencia entre objetos DDS XML. A partir de un objeto DDS XML se podran de-finir otros objetos como el, que heredaran sus atributos. De esta forma se consigueminimizar el codigo necesario para describir aplicaciones al permitir la reutiliza-cion de componentes anteriormente descritos..

La Figura 5.4 a modo de ejemplo ilustra de manera conjunta los conceptos de instan-cias y recursividad.

Siguiendo la Figura 5.4, se presenta el siguiente subarbol dentro de una aplicacion.Aparecen las siguientes entidades DDS XML: un DomainParticipant que tiene un Subs-criber que a su vez tiene 2 DataReaders, cada uno de estos con un numero diferente deinstancias. El DDS XMLDataReader “string reader” podra crear hasta 3 instancias DDS yel denominado como “octet reader” podra crear hasta 2 instancias DDS. Este numero sehabra fijado en la descripcion de cada entidad en el fichero XML.

Para crear las entidades DDS contenidas en el subarbol caben dos opciones:

43

5. Diseno

Figura 5.4: Ejemplo explicativo del funcionamiento de las instancias y parametros derecursividad

44

5.2. Modelo de interaccion de objetos

a) Explıcitamente, crear las entidades una por una realizando 3 operaciones como semuestra en la Figura 5.4, a). Al final de este proceso se habran creado tres entidadesDDS: 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 opcion de recursividad. Eneste caso solo serıa necesario ejecutar la accion sobre el primer objeto DDS XML-DomainParticipant. Gracias al parametro para aplicar la operacion recursivamente,todos los objetos DDS XML hijos ejecutaran la misma accion. Como muestra la Fi-gura 5.4, b), al final del proceso se habran 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 demanera flexible.

Granularidad de las operaciones

Por ultimo, el diseno de las operaciones a todos los niveles debe hacerse con la gra-nularidad mas fina posible. Cuanta mas fina sea la granularidad mayor flexibilidad sepermitira en la interaccion con el escenario.

Para conseguir esto, el proceso de creacion y destruccion de las entidades se sepa-rara de la activacion y parada de la actividad de estas. Ademas, utilizando el concepto deinstancias antes presentado se permitira seleccionar con precision entidades DDS concre-tas del arbol.


Para explicar el funcionamiento y operaciones del sistema, se opta por una descrip-cion formal basada en diagramas de secuencia.

Un diagrama de secuencia es una forma de diagrama de interaccion que muestra losobjetos como lıneas de vida a lo largo de la pagina y con sus interacciones en el tiempo.Las interacciones se represetentan como mensajes dibujados como flechas desde la lıneade vida origen hasta la lınea de vida destino.

Con esta notacion, se pretende mostrar que objetos se comunican con que otros obje-tos. Esta representacion sigue siendo una representacion de alto nivel ya que no se con-sidera la ubicacion de cada objeto en el sistema distribuido, puesto que a este nivel no esrelevante. Tampoco se consideran las operaciones que no implican la comunicacion entreobjetos, y que, por tanto, carecen de interes en esta seccion.

Por ultimo, aclarar que no se mostraran todos los diagramas de secuencia posibles,

45

5. Diseno

sino los mas representativos, ya que el flujo de muchas acciones es practicamente identi-co.

Ası, la lista de diagramas de secuencia considerados como representativos es:

Operacion cargar escenario.

Operacion crear entidad DDS. Esta operacion es equivalente a destruir entidad DDS.Se representara la secuencia crear entidad DDS cuando la entidad es un DomainPartici-pant DDS. Las simplificaciones de esta operacion 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

Operacion iniciar comportamiento. Esta operacion es equivalente a parar comporta-miento. Se representara la secuencia iniciar comportamiento cuando la entidad es unDomainParticipant DDS. Las simplificaciones de esta operacion que no repetiremosson:

• 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

5.2.1. Accion cargar escenario

La Figura 5.5 muestra el diagrama de secuencia de la accion cargar escenario. Esta ope-racion es la responsable de leer un fichero XML proporcionado por el usuario y distri-buirlo a los nodos del escenario que lo utilizaran para desarrollar sus aplicaciones DDS.Como resultado de estas acciones, cada nodo seleccionara automaticamente una aplica-cion 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:

En CommandPublisher se refiere al la publicacion de una orden “cargar escena-rio” que contiene el fichero XML.

46


En CommandSubscriber se refiere a la recepcion del fichero del escenario. Estoincluye la reconstruccion del fichero, que puede haberse recibido en distintostrozos.

parseScenario: es el proceso de analisis del fichero del escenario, llevado a cabo porel parser, que aquı consideramos el actor DDS XMLParser (ver Seccion 4.1.1). Elresultado de esta operacion es un arbol que contiene la representacion en memoriadel escenario compuesta de entidades DDS XML.

createApplicacions: DDS XMLParser creara un conjunto de aplicaciones DDS XML quecada CommandSubscriber (un nodo en la prueba) podra seleccionar.

lookupAndSelectApplication: sobre el arbol compuesto de DDS XMLApplications ge-nerado por DDS XMLParser se debe seleccionar una aplicacion.

Figura 5.5: Diagrama de secuencia cargar escenario

5.2.2. Accion crear entidad DDS

La accion crear entidad DDS es compleja debido a la cantidad de objetos de distinto ti-po que intervienen. Ademas, se debe dar soporte tanto para la aplicacion recursiva de lasoperaciones como para la existencia de multiples instancias DDS, tal y como se explico en

47

5. Diseno

la Seccion 5.1.3. Las siguientes figuras describen un unico diagrama de secuencia que seha dividido en varias figuras para poder mostrarlo correctamente.

La Figura 5.6 muestra el inicio de la accion desde CommandPublisher. La secuenciacontinua en la Figura 5.7. Las operaciones identificadas en esta secuencia son:

createDDSEntity: esta operacion tiene como objetivo la creacion de una o varias entida-des DDS. Se propaga y efectua en tres objetos:

CommandPublisher: inicia la accion crear entidad DDS con los siguientes atribu-tos que se propagaran entre el resto de objetos:

• id: identificador de la entidad DDS XML a la que se hara llegar la opera-cion en ultima instancia.

• index: ındice de la instancia DDS dentro de la entidad DDS XML a la quese aplicara la operacion.

• recursive: parametro logico para controlar si la operacion se aplicara soloa la instancia afectada o si tambien se aplicara a las instancias hijas de estaen el arbol de entidades.

CommandSubscriber: recibe el mensaje createDDSEntity y a su vez se lo envıa ala DDS XMLApplication que tiene asociada.

La DDS XMLApplication asociada al objeto CommandSubscriber.

lookupEntity: la aplicacion buscara entre el conjunto de entidades DDS XML que la com-ponen para ver si contiene a la entidad identificada por id. Si no es ası, la operaciontermina aquı.

La Figura 5.7 continua la secuencia de la Figura 5.6 para el caso en que la entidad en-contrada en la operacion lookupEntity sea una entidad del tipo DDS XMLDomainParticipant.Se ha elegido este ejemplo por ser el caso mas complejo posible, ya que DDS XMLDomainParticipantes la entidad que puede estar compuesta de mas entidades a su vez. El diagrama de se-cuencia para otras entidades DDS XML sera siempre una simplificacion del explicadoaquı.

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 creacion de unDomainParticipant DDS con los parametros de configuracion de la entidad DDS XMLsobre la que se esta aplicando la operacion. Esta operacion puede propagarse a lasentidades hijas del DDS XMLDomainParticipant.

createDDSEntityChilds: es una operacion condicionada a que el parametro “recursive”este activado para propagar la operacion createDDSEntity a las entidades hijas de laactual.

48


Figura 5.6: Diagrama de secuencia crear entidad DDS, parte generica. Continua en Figura5.7

getChildsTopic: obtiene los DDS XMLTopic hijos del DDS XMLDomainParticipant. Sobrecada hijo obtenido se propagara la accion createDDSEntity.

getChildsPublisher: obtiene los DDS XMLPublisher hijos del DDS XMLDomainParticipant.Sobre cada hijo obtenido se propagara la accion createDDSEntity.

getChildsSubscriber: obtiene los DDS XMLSubscriber hijos del DDS XMLDomainParticipant.Sobre cada hijo obtenido se propagara la accion createDDSEntity.

createDDSDomainParticipant: es la operacion que realiza el middleware DDS para crearun DomainParticipant DDS.

createDDSTopic: es la operacion que realiza el middleware DDS para crear un Topic DDS.

createDDSPublisher: es la operacion que realiza el middleware DDS para crear un Publis-her DDS.

createDDSSubscriber: es la operacion que realiza el middleware DDS para crear un Subs-criber DDS.

La Figura 5.8 representa la encadenacion de operaciones a las entidades hijas de unobjeto DDS XMLPublisher. En ella se identifican las operaciones no descritas anteriore-mente:

createDDSEntityChilds: si el parametro “recursive” esta activo, la operacion createDD-SEntity se propaga a las entidades hijas.

getChildsDataWriter: obtiene los DDS XMLDataWriter hijos del DDS XMLPublisher. So-bre cada hijo obtenido se propagara la accion createDDSEntity.

49

5. Diseno

Figura 5.7: Diagrama de secuencia crear entidad DDS, detalle respecto aDDS XMLDomainParticipant. Continua en Figuras 5.8 y 5.9

50


createDDSDataWriter: es la operacion que realiza el middleware DDS para crear un Da-taWriter DDS.

La Figura 5.9 es analoga a la Figura 5.8 y representa la encadenacion de operaciones alas entidades hijas de un objeto DDS XMLSubscriber. En ella se identifican las operacionesno descritas anterioremente:

createDDSEntityChilds: es una operacion condicionada a que el parametro “recursive”este activado para propagar la operacion createDDSEntity a las entidades hijas de laactual.

getChildsDataReader: obtiene los DDS XMLDataReader hijos del DDS XMLSubscriber.Sobre cada hijo obtenido se propagara la accion createDDSEntity.

createDDSDataReader: es la operacion que realiza el middleware DDS para crear un Da-taReader DDS.

5.2.3. Accion iniciar comportamiento

La accion iniciar comportamiento es similar a crear comportamiento y por ello compleja.Las siguientes figuras describen un unico diagrama de secuencia que se ha dividido envarias figuras para poder mostrarlo correctamente.

La Figura 5.10 muestra el inicio de la accion desde CommandPublisher. La secuenciacontinua en la Figura 5.11. Las operaciones identificadas en esta secuencia son:

startBehaviour: esta operacion tiene como objetivo iniciar la actividad de una o variasentidades DDS. Se propaga y efectua en tres objetos:

CommandPublisher: inicia la accion iniciar comportamiento con los siguientes atri-butos que se propagaran entre el resto de objetos:

• id: identificador de la entidad DDS XML a la que se hara llegar la opera-cion en ultima instancia.

• index: ındice de la instancia DDS dentro de la entidad DDS XML a la quese aplicara la operacion.

• recursive: parametro logico para controlar si la operacion se aplicara soloa la instancia afectada o si tambien se aplicara a las instancias hijas de estaen el arbol de entidades.

CommandSubscriber: recibe el mensaje startBehaviour y a su vez se lo envıa a laDDS XMLApplication que tiene asociada.

La DDS XMLApplication asociada al objeto CommandSubscriber.

51

5. Diseno

Figura 5.8: Diagrama de secuencia crear entidad DDS, detalle respecto aDDS XMLDomainPublisher.

Figura 5.9: Diagrama de secuencia crear entidad DDS, detalle respecto aDDS XMLDomainSubscriber.

52


Figura 5.10: Diagrama de secuencia iniciar comportamiento, parte generica. Continua enFigura 5.11

lookupEntity: la aplicacion buscara entre el conjunto de entidades DDS XML que la com-ponen para ver si contiene a la entidad identificada por id. Si no es ası, la operaciontermina aquı.

La Figura 5.11 continua la secuencia de la Figura 5.10 para el caso en que la entidad en-contrada en la operacion lookupEntity sea una entidad del tipo DDS XMLDomainParticipant.Se ha elegido este ejemplo por las mismas razones que en la accion 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 ac-ciones para ejecutar la actividad de este. Esta operacion puede propagarse a lasentidades hijas del DDS XMLDomainParticipant.

lookupMethod: sobre el conjunto de modelos dinamicos del sistema, se busca el metodoque especifica el comportamiento y es asocia a la entidad DDS XML. Este metodocorresponde al especificado previamente en el fichero XML.

startBehaviourMethod: una vez obtenido un metodo valido, se inicia el comportamien-to en si de la entidad DDS adecuada, indicada con el parametro index. Se debepermitir la ejecucion concurrente de la actividad de las entidades, de modo que laejecucion del comportamiento debe lanzarse en una hebra nueva.

startBehaviourChilds: es una operacion condicionada a que el parametro “recursive”este activado para propagar la operacion startBehaviour a las entidades hijas de laactual.

53

5. Diseno

getChildsTopic: obtiene los DDS XMLTopic hijos del DDS XMLDomainParticipant. Sobrecada hijo obtenido se propagara la accion startBehaviour.

getChildsPublisher: obtiene los DDS XMLPublisher hijos del DDS XMLDomainParticipant.Sobre cada hijo obtenido se propagara la accion startBehaviour.

getChildsSubscriber: obtiene los DDS XMLSubscriber hijos del DDS XMLDomainParticipant.Sobre cada hijo obtenido se propagara la accion startBehaviour.

La Figura 5.12 representa la encadenacion de operaciones a las entidades hijas de unobjeto DDS XMLPublisher. En ella se identifican las operaciones no descritas anteriore-mente:

startBehaviourChilds: si el parametro “recursive” esta activo, la operacion startBeha-viour se propaga a las entidades hijas.

getChildsDataWriter: obtiene los DDS XMLDataWriter hijos del DDS XMLPublisher. So-bre cada hijo obtenido se propagara la accion startBehaviour.

La Figura 5.13 es analoga a la Figura 5.12 y representa la encadenacion de operacionesa las entidades hijas de un objeto DDS XMLSubscriber. En ella se identifican las operacio-nes no descritas anterioremente:

startBehaviourChilds: es una operacion condicionada a que el parametro “recursive”este activado para propagar la operacion startBehaviour a las entidades hijas de laactual.

getChildsDataReader: obtiene los DDS XMLDataReader hijos del DDS XMLSubscriber.Sobre cada hijo obtenido se propagara la accion startBehaviour.

54


Figura 5.11: Diagrama de secuencia iniciar comportamiento, detalle respecto aDDS XMLDomainParticipant. Continua en Figuras 5.12 y 5.13

55

5. Diseno

Figura 5.12: Diagrama de secuencia iniciar comportamiento, detalle respecto aDDS XMLDomainPublisher.

56


Figura 5.13: Diagrama de secuencia iniciar comportamiento, detalle respecto aDDS XMLDomainSubscriber.

57

5. Diseno

5.3. Diagrama de clases

Esta seccion presenta el diagrama de clases del sistema. La representacion se ha divi-dido en una vista general de las clases (Figura 5.14) por un lado y, por otro, la represen-tacion 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 respetalas relaciones conceptuales de las clases tal y como se especifica en el estandar DDS[6].

Como puede verse en la Figura 5.14, queda claro como una aplicacion DDS, repre-sentada por DDS XMLApplication, esta compuesta de un conjunto de entidades DDS,representadas por clases del tipo DDS XMLEntity.

Otra relacion que cabe destacar es la asociacion de una DDS XMLApplication a unCommandSubscriber. Como se introducıa en capıtulos anteriores, cada nodo que ejecuta un

58


CommandSubscriber selecciona una sola aplicacion DDS para desarrollar el escenario. Larelaccion de la clase CommandSubscriber con un unico CommandPublisher tambien quedareflejada.

Figura 5.15: Detalle del diagrama de clases: DDS XMLApplication

Figura 5.16: Detalle del diagrama de clases: DDS XMLParticipant

59

5. Diseno

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


Figura 5.20: Detalle del diagrama de clases: DDS XMLDataWriter

Figura 5.21: Detalle del diagrama de clases: DDS XMLDataReader

61

5. Diseno

Figura 5.22: Detalle del diagrama de clases: CommandPublisher

Figura 5.23: Detalle del diagrama de clases: CommandSubscriber

62

CAPITULO 6

IMPLEMENTACION

En este capıtulo se describen algunos detalles de la implementacion que es interesanteremarcar. En particular se hace hincapie en:

Como se ha implementado un modelo de orientacion a objetos con el lenguaje C.

La implementacion del analizador del lenguaje de interaccion con el escenario.

Los modulos que componen el sistema.

6.1. Implementacion de la orientacion a objetos en C

En esta seccion se explica la metodologıa y reglas de codificacion que han permiti-do utilizar este paradigma de programacion con un lenguaje no orientado a objetos. Lalectura de este apartado permitira poder interpretar el codigo fuente de una forma masclara.

Hasta ahora se han utilizado constantemente tanto conceptos de orientacion a objetoscomo notacion y diagramas relacionados con la orientacion objetos. Esto ha sido ası porvarias razones:

Pensando en el futuro del proyecto, la posible integracion de este proyecto dentrode un middleware DDS incluira que se porte el codigo actual a lenguajes como C++o Java. Normalmente estos productos presentan un interfaz de programacion queadmite varios lenguajes, estando escrita la base casi siempre en C. Ası pues, la exis-tencia de diagramas de clases, diagramas de secuencia y demas ayudaran a estatarea.

63

6. Implementacion

Las tecnicas de desarrollo de software modernas como el proceso unificado de desa-rrollo[45] estan pensadas para trabajar con lenguajes orientados a objetos.

Las metodologıas de orientacion a objetos ayudan a estructurar el codigo de manerafuncional, algo esencial conforme la complejidad del problema aumenta.

A continuacion se describe como se organiza el codigo en C para poder aplicar con-ceptos de la orientacion a objetos:

Representacion de clases. Cada clase del diagrama de clases se corresponde con unaestructura de datos en C. Ası, tendremos una estructura con una serie de campos querepresentaran los atributos de la clase. Por ejemplo:

DomainParticipant

Espacio de nombres. Para evitar conflictos en la definicion de estructuras y metodos,se antepone al nombre de cada uno lo que se conoce como “espacio de nombres”.Esto es un prefijo que se anade al nombre de la estructura o metodo para indicar aque biblioteca o modulo pertenece. Por ejemplo el prefijo “DDS” indica que lo quesigue a continuacion pertenece a la biblioteca que ofrece el API del estandar DDS.En este proyecto, se anade el prefijo “DDS XML” para indicar las clases XML queenvuelven a entidades DDS. El nombre de la estructura anterior, una vez anadidoel espacio de nombres “DDS XML” quedarıa:

DDS_XMLDomainParticipant

Asociacion de metodos a clases. Para reflejar la asociacion de un metodo de una clase,se antepone el nombre de la clase, es decir, el nombre de la estructura con el espaciode nombres, al nombre del metodo. Por ejemplo, el metodo “create dds entity” dela clase anterior se nombrarıa en C ası:

DDS_XMLDomainParticipant_create_dds_entity

Parametros de las funciones. El primer parametro de un metodo asociado a una clasesera siempre un puntero a una estructura del tipo de la clase. A continuacion seincluiran los parametros de entrada y al final de la lista los parametros de salida.De esta manera se consigue poder llamar a una serie de metodos sobre un mismoobjeto (estructura en C). Por ejemplo, en el metodo anterior existira el siguienteparametro:

DDS_XMLDomainParticipant_create_dds_entity(struct DDS_XMLDomainParticipant *self,<parametros de entrada>,<parametros de salida>)

64

6.2. Implementacion del analizador de gramatica semi-natural

Metodos new y delete. A cada clase se le anaden metodos para la creacion y destruccionde estos. En este caso estos metodos reservan o liberan memoria para los camposnecesarios, e inicializan sus valores si es necesario.

6.2. Implementacion del analizador de gramatica semi-natural

En el Apartado 4.2 de la fase de analisis se definio, mediante notacion BNF, la gramati-ca generativa del lenguaje semi-natural de interaccion con el escenario.

Por otro lado, en el Apartado 1.7.2 se menciono como decision estrategica el uso delas herramientas automatizadas para la generacion de analizadores sintacticos, lo queincluye tambien la generacion de analizadores lexicos.

Partiendo de la gramatica BNF estos generadores construyen analizadores sintacti-cos. Anadiendo codigo fuente a las reglas de analisis sintactico se pueden realizar accio-nes cuando se reconoce una frase introducida por el usuario. La manera en que estan di-senados estos generadores facilita posteriores ampliaciones o modificaciones de la gramati-ca y/o acciones.

Las gramaticas BNF se pueden implementar con el uso de un analizador sintactico delos llamados LookAhead Left-Right (LALR). Una herramienta libre generadora de analiza-dores sintacticos LALR es bison, [46] la implementacion GNU del popular generador deanalizadores YACC. Ademas, sera necesario integrar bison con el generador de analiza-dores lexicos Flex[47].

El proceso de implementacion, por tanto, consiste en traducir la gramatica definidaen la seccion 4.2 a bison y definir las acciones pertinentes para cada tipo de sentencia.

6.3. Estructuracion modular del codigo

6.3.1. Modelo Estatico: clases DDS XML y parser XML

La fase de diseno concluyo con la definicion del diagrama de clases del sistema (Aparta-do 5.3). En esta seccion se explicaran algunos detalles de su implementacion.

Procesado de ficheros XML con las clases DDS XML. El diagrama de clases muestraun conjunto de clases DDS XML, clases que envuelven a entidades DDS. El parser parael procesado de los ficheros XML se ha construido utilizando estas clases. Segun el tipode etiqueta que se encuentre al procesar el fichero, se utilizara unas u otras clases paraprocesar el contenido almacenado dentro de la etiqueta. Ası, como resultado del procesode analisis se obtiene un arbol de objetos DDS XML. La Tabla 6.1 muestra la relacionentre entidades DDS, entidades DDS XML y etiquetas.

65

6. Implementacion

Entidad DDS Entidad DDS XML etiquetaDomainParticipant 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: Relacion entidades DDS, entidades DDS XML y etiquetas

Implementacion de la herencia El soporte para la herencia entre las entidades se im-plementa de la siguiente manera:

1. Como se comento en la Seccion 4.3, existe un atributo opcional llamado base nameque indica al parser que la clase que esta procesando hereda de otra. Cuando el parserencuentra este atributo busca una entidad en el arbol construıdo con el nombrename que coincida con base name. Esta entidad denomina clase base.

2. Antes de procesar la informacion contenida en la etiqueta de la clase que hereda, secopian a esta todos los atributos de la clase base.

3. Si se encuentran valores nuevos para los atributos encontrados se sobreescribenestos con el valor nuevo.

En la implementacion actual la herencia solo afecta a los atributos de las clases quesean datos inmediatos, no se heredan las clases hijas de la clase base.

Podemos explicar el funcionamiento de la herencia con el siguiente codigo 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>5

</datareader><datareader name="reader_as_reader1" base name="reader1"></datareader>

Listado 6.1: Codigo XML para mostrar el funcionamiento de la herencia

El DataReader “reader as reader1” tendra como Topic “hello world topic” y se crearan5 instancias DDS si se llama al metodo create all dds entities() del objeto DDS XMLque lo envuelve. Se puede sobreescribir cualquier parametro 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>5

</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


Listado 6.2: Codigo XML para mostrar el funcionamiento de la herencia

En este caso, el DataReader “reader as reader1” tendra como Topic “foo topic”, pero elnumero de instancias seguira siendo 5.

Estructuras de datos para la representacion de las clases DDS XML A continuacionse muestra el codigo de ejemplo de la la estructura DDS XMLDataReader. El resto de cla-ses no difiere demasiado de esta salvo por la inclusion 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.∗ Thi s p o i n t e r i s s e t up dur ing 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 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 .∗ Thi s 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 . Th i s 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 ma-neja la clase.

struct DDS_XMLTopic *xml_topic: referencia al DDS XMLTopic en el arbolde la aplicacion. Esta referencia se fija durante el procesamiento del fichero XML

67

6. Implementacion

buscando el tema indicado por la etiqueta datawriter_topic. El tema correspon-diente se busca comenzando desde el DDS XMLDomainParticipant padre de la en-tidad.

short instances_tag: contenido de la etiqueta <instances>.

short instances_number: numero de instancias DDS que se podran crear. Con-siderando que la entidad padre de esta clase puede, a su vez tener mas instancias,el total de instancias que se pueden crear sera el numero de instancias de la enti-dad padre por el numero indicado en la etiqueta XML, almacenado en el atributoinstances_tag. Este atributo se modifica durante el procesamiento del ficheroXML.

struct DDS_DataReaderListener *listener: listener que se asociara a laentidad DDS que se cree.

DDS_StatusMask listener_mask: configuracion de las callbacks que monitori-zara el listener.

pthread_t *thread: identificadores de las hebras lanzadas para ejecutar com-portamiento paralelo.

void *(*behaviour)(void *): puntero a un metodo de descripcion del com-portamiento.

Los dos ultimos atributos se refieren al comportamiento dinamico que se quiere uti-lizar para la entidad. Cuando se invoca al metodo start behaviour() en una claseDDS XML, este crea una nueva hebra para llamar al metodo que describe el comporta-miento. Para poder detener la ejecucion del comportamiento es necesario almacenar unareferencia a la hebra, y esto se almacena en el vector thread. Como pueden existir variasentidades DDS en una entidad DDS XML actuando a la vez, se creara una hebra paracada entidad DDS que inicie su actividad. Ası, para un una posicion del vector de enti-dades DDS existira una en el vector de hebras para identificar la hebra que utiliza unaentidad DDS.

6.3.2. Modelo Dinamico

El Modelo Dinamico describe el comportamiento de entidades del Modelo Estatico. Ladescripcion se hace programando un metodo y configurando los listeners apropiados me-diante el API de DDS para el lenguaje C.

El modulo del Modelo Dinamico actuara como una base de datos que almacena meto-dos y listeners. Esta base de datos esta compuesta de una serie de tablas que gestionaninformacion para poder acceder a los elementos dinamicos que almacenan. El moduloproporciona metodos para inicialiar estas tablas y hacer busquedas sobre ellas.

68


Si el usuario quiere que un conjunto de metodos y listeners puedan ser utilizados debeincluirlos en estas tablas. A continuacion se muestran extractos de codigo de las tablasdel Modelo Dinamico.

s t a t i c s t r u c t BehaviourMethodEntryDM models table [ DM models table elements ] ;

s t a t i c s t r u c t DataReaderListenerEntryD 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 Dinamico

Estas tablas estas 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 / k ey 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 / k ey 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 go ing 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 .∗ Thi s 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 Dinamico

Un ejemplo de tablas es el del Listado 6.3.2, que muestra la inicializacion de una tablade 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

6. Implementacion

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 ;

}

6.3.3. Modulo de coordinacion

El modulo de coordinacion, como su nombre indica, coordina todos los nodos del esce-nario utilizando un tema de control o Control Topic. El tipo de datos de este tema, Command,se describio en el capıtulo de analisis, Seccion 4.2.2.

Las clases CommandPublisher y CommandSubcriber implementan la comunicacion deinstrucciones entre los nodos del escenario. Estas clases no son aplicaciones en si, sinoque se utilizan dentro de dos aplicaciones:

cmdmaster es una aplicacion DDS que se ejecuta en un nodo “Command Master”.cmdmaster es una aplicacion que integra a un analizador sintactico generado porYacc. El resultado del analisis sintactico se utiliza para rellenar los campos de ins-tancias de datos de la estructura Command. Estas instancias se publicaran a la redutilizando la clase CommandPublisher.

La aplicacion cmdslave es la unica que el usuario necesita ejecutar en un nodopara desplegar el escenario. Esta, utiliza la clase CommandSubscriber para recibir yprocesar instancias de datos de control que recibe de la red. Recibidas las ordenes,la clase CommandSubscriber utiliza el API de los modulos estatico y dinamico paracrear y destruir entidades DDS y controlar su comportamiento.

Para ilustrar como integrar el analizador sintactico con la clase CommandPublisher, elListado 6.6 muestra dos reglas que ilustran la integracion de CommandPublisher con lasreglas de analisis sintactico de Yacc.

| CREATEALL {/∗ CREATEALL ∗ /# i f d e f DEBUG PARSERPrintDebug ("CREATEALL\n" )# endi f

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 PARSERPrintDebug ("CREATE %s, %d\n" , $2 , $3 )

70


# endi f

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: Integracion de CommandPublisher con las reglas de analisis sintactico de Yacc

71

6. Implementacion

72

CAPITULO 7

PRUEBAS

Las pruebas pretenden verificar el correcto funcionamiento del sistema y comprobarque los requisitos funcionales y no funcionales de la especificacion se cumplen. Las prue-bas a las que se ha sometido el sistema son:

Pruebas unitarias: consiste en realizar pruebas a nivel de modulo de forma indepen-diente.

Pruebas de integracion: los modulos probados en la etapa anterior se integran paracomprobar sus interfaces (flujo de datos) en el trabajo conjunto.

Pruebas del sistema: para comprobar que el software este totalmente ensamblado ycumpla tanto los requisitos funcionales y no funcionales como los objetivos indica-dos para el sistema.

Para la realizacion de las pruebas se ha utilizado un mismo fichero XML (scenario-.xml) que hace uso de todas las funcionalidades implementadas respecto al la descrip-cion de entidades. El fichero puede consultarse en el Apendice C. Este fichero describeejemplos de:

Especificacion de varias aplicaciones con participantes pertenecientes a dominiosdistintos.

La herencia entre entidades.

El soporte para multiples instancias.

La conexion del Modelo Estatico con el Modelo Dinamico.

73

7. Pruebas

7.1. Herramientas para la realizacion de pruebas

Durante las pruebas se han utilizado una serie de herramientas externas, son las si-guientes:

Valgrind[21] es un software de depuracion que permite identificar recursos no li-berados al finalizar la ejecucion de un programa. Se utilizo con la interfaz graficaAlleyoop.

El depurador GBD, integrado con el entorno de desarrollo Eclipse[19], se utilizo paracomprobar la correcta creacion y destruccion de hebras internas para el control dellos metodos de comportamiento.

La herramienta nddsspy, incluida en el producto NDDS[8][23]. Esta herramientapermite monitorizar las los DataWriters, DataReaders y las muestras de datos queaparecen en una red. De esta forma se controla la correcta creacion y destruccion deentidades remotas, ası como de los datos que se publican.

7.2. Pruebas unitarias

Se han realizado las siguiente pruebas unitarias respecto a los siguientes modulos.

Modelo Estatico. Se han probado dos aspectos de este modulo:

1. El parser o analizador sintactico para los ficheros XML. Se ha comprobado queel parser reconoce todas las etiquetas necesarias y extrae la informacion de ma-nera correcta.

2. La funcionalidad ofrecida por las clases DDS XML. Para ello se ha escrito unprograma de pruebas que, para el fichero scenario.xml comprobaba el co-rrecto funcionamiento del API ofrecida por estas clases. Esto incluye:

Verificacion de los metodos de navegacion por el arbol del escenario.Busqueda de entidades en el arbol.Comprobacion de los metodos de busqueda y asignacion de modelos dinami-cos.

Modelo Dinamico. Se escribio un modelo dinamico de prueba para probar la funciona-lidad de busqueda de modelos dinamicos y asignacion a entidades DDS XML.

Modulo de coordinacion. Se han verificado las siguientes funcionalidades:

El analizador sintactico para el lenguaje de interaccion con el escenario recogecorrectamente las instrucciones del usuario.

74

7.3. Pruebas de integracion

Las instrucciones del usuario son publicadas mediante DDS y recibidas correc-tamente en subscriptor de ordenes (CommandSubscriber).

La transferencia del fichero XML del escenario utilizando DDS para ficherosque debıan ser transmitidos en varios mensajes debido a su tamano.

7.3. Pruebas de integracion

Las pruebas de integracion consistieron en la verificacion de la conexion entre los tresmodulos:

1. Verificacion de la conexion entre el Modelo Estatico y el Modelo Dinamico. Para ellose escribio un programa que iniciaba varias entidades DDS descritas y ejecutaba sucomportamiento asociado.

2. Verificacion de la conexion entre el modulo de coordinacion y el Modelo Estatico.Se comprobo la correcta traduccion de ordenes del usuario recogidas en el modulosde coordinacion en llamadas al API de las clases DDS XML.

7.4. Pruebas de sistema

Las pruebas de sistema consistieron en el despliegue de un escenario DDS descritopor el fichero scenario.xml. Se utilizaron, para ello, dos ordenadores conectados me-diante una red de area local. Las acciones que se realizaron las siguientes acciones:

1. Carga y distribucion del escenario.

2. Creacion de todas las entidades DDS.

3. Inicio y parada del comportamiento.

4. Destruccion de las entidades.

5. Finalizacion de los CommandSubscriber de los nodos.

Ademas, se utilizo una aplicacion DDS implementada de forma tradicional para com-probar la recepcion correcta de datos publicados desde el escenario.

75

7. Pruebas

76

CAPITULO 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 2008en el IX Workshop on Distributed Object Computing for Real-time and Embedded Systems ce-lebrado en Washington (DC, USA) bajo el tıtulo “An XML-Based Approach to the Confi-guration and Deployment of DDS Applications”[48]

Este encuentro, organizado por la OMG, constituye un foro para ingenieros de soft-ware e investigadores en el campo de los sistemas distribuidos y de tiempo–real.

El trabajo actual ha conseguido cumplir los objetivos propuestos con las siguientesconclusiones:

1. La division entre Modelo Estatico y Modelo Dinamico para la descripcion de aplica-ciones minimiza la tarea de programacion del sistema.

2. La flexibilidad de las interfaces de programacion de estos modulos y el diseno delrepertorio de ordenes permite:

Evaluar el tiempo de creacion y descubrimiento entre entidades DDS.

Desarrollar de manera gradual el numero y actividad de las entidades queparticipan en el escenario.

3. La descripcion del escenario mediante ficheros XML permite disenar pruebas dis-tribuidas diferentes tan solo cambiando una lıneas en estos ficheros.

4. La implementacion sobre DDS de la coordinacion y distribucion del escenario pre-senta las siguientes ventajas:

77

8. Resultados y Trabajo Futuro

El desarrollador no necesita preocuparse sobre la sincronizacion de ficherosXML. Por un lado, no se necesitan mecanismo externos como SSH o NFS parasincronizar ficheros y ordenes, y, por otro, se puede desplegar el escenario enredes de area amplia.

Se puede portar facilmente el sistema desarrollado a cualquier plataforma so-portada por un middleware DDS, incluso si la plataforma no cuenta con sistemade ficheros como ocurre con algunos sistemas de tiempo–real.

8.2. Trabajo futuro

Existen una serie de funcionalidades que podrıan mejorar notablemente el sistemadesarrollado:

Inclusion de un sistema de auto-validacion del escenario. Aprovechando que cada nodoobtiene una copia del fichero XML que describe el escenario, ası como la secuenciade ordenes que se distribuyen, cada nodo puede construir localmente un esquemade que entidades deberıan haberse creado en el sistema. Relacionado este esquemacon la informacion de descubrimiento que el middleware DDS genera, podrıa detec-tar de manera automatica si el escenario se ha desplegado de manera adecuada o,en cambio, hay nodos no accesibles.

Inclusion de un sistema de gestion de la seguridad. En la implementacion actual, noexisten medidas de seguridad que impidan a un potencial atacante publicar infor-macion a traves del tema de control

Extension del Modelo Estatico para soportar perfiles de QoS. En la actualidad varias im-plementaciones de DDS estan incorporando perfiles de QoS que se describen bien atraves de ficheros XML o se incluyen de manera nativa en el producto. Estos perfi-les agrupan parametros de configuracion de calidad de servicio que en su conjuntopermiten configurar grupos de entidades DDS para realizar comunicaciones de ba-ja latencia, maximo rendimiento, etc. La integracion con estos proyectos permitirıadescribir con mayor potencia los escenarios DDS.

78

BIBLIOGRAFIA

[1] W3C. Web services architecture, w3c working group note, feb 2004. Disponible enla Web: http://www.w3.org/TR/wsdl.

[2] Erik Christensen et al. Web services description language (wsdl) 1.1, w3c note, mar2001. Disponible en la Web: http://www.w3.org/TR/wsdl.

[3] Inc. Sun Microsystems. Java message service (jms), 2008. Disponible en la Web:http://java.sun.com/products/jms/.

[4] Object Management Group. Common object request broker architecture (cor-ba/iiop), version 3.0.3, 03 2004. Disponible en la Web: http://www.omg.org/docs/formal/04-03-12.pdf.

[5] Message Passing Interface Forum. Mpi: A message-passing interface standard, ver-sion 2.1. Technical report, Message Passing Interface Forum, 06 2008. Disponible enla Web: http://www.mpi-forum.org/docs/mpi21-report.pdf.

[6] Object Management Group. Data distribution service for real-time systems spe-cification, version 1.2, 01 2007. Disponible en la Web: http://www.omg.org/technology/documents/formal/data_distribution.htm.

[7] Object Management Group (OMG). The object management group (omg), 09 2008.Disponible en la Web: http://www.omg.org/.

[8] Inc. Real-Time Innovations. Rti data distribution service, 09 2008. Disponible en laWeb: http://www.rti.com/products/data_distribution/index.html.

[9] Inc. Real-Time Innovations. Disponible en la Web: http://www.rti.com.

[10] PrismTech Ltd. Opensplice dds, 09 2008. Disponible en la Web: http://www.prismtech.com/opensplice-dds.

79

http://www.w3.org/TR/wsdl

http://www.w3.org/TR/wsdl

http://java.sun.com/products/jms/

http://www.omg.org/docs/formal/04-03-12.pdf

http://www.omg.org/docs/formal/04-03-12.pdf

http://www.mpi-forum.org/docs/mpi21-report.pdf

http://www.omg.org/technology/documents/formal/data_distribution.htm

http://www.omg.org/technology/documents/formal/data_distribution.htm

http://www.omg.org/

http://www.rti.com/products/data_distribution/index.html

http://www.rti.com

http://www.prismtech.com/opensplice-dds

http://www.prismtech.com/opensplice-dds

[11] PrismTech Ltd. Prismtech ltd. Disponible en la Web: http://www.prismtech.com.

[12] Inc. Object Computing. Opendds, 09 2008. Disponible en la Web: http://www.opendds.org.

[13] Object Computing Inc. Object computing inc., 09 2008. Disponible en la Web: http://www.ociweb.com.

[14] Object Management Group (OMG). Dds vendors page, 09 2008. Disponible en laWeb: http://portals.omg.org/dds/VendorsPage.

[15] Javier Sanchez-Monedero, J.M. Lopez-Soler, and J. Povedano-Molina. Sca-lable dds discovery protocols based on bloom filters. In Real-time and Em-bedded Systems Workshop, Arlington VA, USA, 2007. Disponible en la Web:http://www.omg.org/news/meetings/workshops/RT-2007/04-2_Sanchez-Moder_etal-revised.pdf.

[16] RedIris. Plataforma de analisis de servicios de telecomunicaciones (pasito), version7.0. Technical report, 2008.

[17] Leslie Lamport. LaTeX: A Document Preparation System: User’s Guide and ReferenceManual. Addison-Wesley, 1985.

[18] Michel Ludwig et. al. Kile - an integrated latex environment, 09 2008. Disponible enla Web: http://kile.sourceforge.net/.

[19] The Eclipse Foundation. Eclipse, 09 2008. Disponible en la Web: http://www.eclipse.org/.

[20] Free Software Foundation. The gnu project debugger, 09 2008. Disponible en la Web:http://www.gnu.org/software/gdb/.

[21] Cerion Armour-Brown et. al. Valgrind, 09 2008. Disponible en la Web: www.valgrind.org/.

[22] Jeffrey Stedfast. Alleyoop, 09 2008. Disponible en la Web: http://alleyoop.sourceforge.net/.

[23] Inc. Real-Time Innovations. RTI Data Distribution Service User’s Manual, Version 4.3e,2008.

[24] James Clark. The expat xml parser, 09 2008. Disponible en la Web: http://expat.sourceforge.net/.

[25] IEEE. IEEE Std 1003.1-2001 Standard for Information Technology — Portable OperatingSystem Interface (POSIX) System Interfaces, Issue 6. IEEE, New York, NY, USA, 2001.Revision of IEEE Std 1003.1-1996 and IEEE Std 1003.2-1992) Open Group TechnicalStandard Base Specifications, Issue 6.

80

http://www.prismtech.com

http://www.prismtech.com

http://www.opendds.org

http://www.opendds.org

http://www.ociweb.com

http://www.ociweb.com

http://portals.omg.org/dds/VendorsPage

http://www.omg.org/news/meetings/workshops/RT-2007/04-2_Sanchez-Moder_etal-revised.pdf

http://www.omg.org/news/meetings/workshops/RT-2007/04-2_Sanchez-Moder_etal-revised.pdf

http://kile.sourceforge.net/

http://www.eclipse.org/

http://www.eclipse.org/

http://www.gnu.org/software/gdb/

www.valgrind.org/

www.valgrind.org/

http://alleyoop.sourceforge.net/

http://alleyoop.sourceforge.net/

http://expat.sourceforge.net/

http://expat.sourceforge.net/

[26] Sun Microsystems. RPC: remote procedure call protocol specification: Version 2.RFC 1057, Internet Engineering Task Force, June 1988. Disponible en la Web: http://www.rfc-editor.org/rfc/rfc1057.txt.

[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 TaskForce, June 1999. Disponible en la Web: http://www.rfc-editor.org/rfc/rfc2616.txt.

[28] Nilo Mitra. Soap version 1.2 part 0: Primer. W3C working draft, World Wide WebConsortium (W3C), December 2001. Disponible en la Web: http://www.w3.org/TR/soap12-part0/.

[29] Sun Developer Network. RMI remote method invocation.

[30] Object Management Group. Omg idl syntax and semantics - common object re-quest broker architecture (corba), v3.0. Technical report, 2002. Disponible en la Web:http://www.omg.org/cgi-bin/doc?formal/02-06-39.

[31] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen. Extensible markup language(xml) 1.0 (fourth edition). W3C Recommendation REC-xml-20001006, World WideWeb Consortium (W3C), October 2006. Disponible en la Web: http://www.w3.org/TR/2006/REC-xml-20060816/.

[32] David C. Fallside and Priscilla Walmsley. XML schema part 0: Primer second edition.W3C recommendation, W3C, October 2004. http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/.

[33] Xml (extensible markup language). Wikimedia Foundation, Inc., 09 2008. Disponibleen la Web: http://en.wikipedia.org/wiki/XML#Critique_of_XML.

[34] D. Crockford. Introducing json, 09 2008. Disponible en la Web: http://json.org/.

[35] D. Crockford. The application/json media type for javascript object notation (json).RFC 4627, Internet Engineering Task Force, 07 2006. Disponible en la Web: http://www.rfc-editor.org/rfc/rfc4627.txt.

[36] Henry Story. The limitations of json, 07 2007. Disponible en la Web: http://blogs.sun.com/bblfish/entry/the_limitations_of_json.

[37] Sparx Systems. Sparx systems, 09 2008. Disponible en la Web: http://www.sparxsystems.com.

[38] Sparx Systems Pty Ltd. Mdg technology for dds, 09 2008. Disponibleen la Web: http://www.sparxsystems.com.au/products/mdg/tech/dds/index.html.

81

http://www.rfc-editor.org/rfc/rfc1057.txt




http://www.w3.org/TR/soap12-part0/

http://www.w3.org/TR/soap12-part0/

http://www.omg.org/cgi-bin/doc?formal/02-06-39

http://www.w3.org/TR/2006/REC-xml-20060816/

http://www.w3.org/TR/2006/REC-xml-20060816/

http://en.wikipedia.org/wiki/XML#Critique_of_XML

http://json.org/

http://json.org/



http://blogs.sun.com/bblfish/entry/the_limitations_of_json

http://blogs.sun.com/bblfish/entry/the_limitations_of_json

http://www.sparxsystems.com

http://www.sparxsystems.com

http://www.sparxsystems.com.au/products/mdg/tech/dds/index.html

http://www.sparxsystems.com.au/products/mdg/tech/dds/index.html

[39] Jishnu Mukerji and Joaquin Miller. Mda guide version 1.0.1. Technical report, Ob-ject Management Group, 06 2003. Disponible en la Web: http://www.omg.org/cgi-bin/doc?omg/03-06-01.

[40] Douglas C. Schmidt. Distributed object computing (doc) group for distributed real-time and embedded (dre) systems, 09 2008. Disponible en la Web: http://www.dre.vanderbilt.edu/.

[41] Douglas C. Schmidt. Dds benchmark project, 2008. Disponible en la Web: http://www.dre.vanderbilt.edu/DDS/.

[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 Sys-tems Workshop, Arlington, VA USA - July 10-13, 2006, 2006. Disponible en la Web:http://www.dre.vanderbilt.edu/DDS/DDS_RTWS06.pdf.

[43] The GNOME Project. Planner, 09 2008. Disponible en la Web: http://live.gnome.org/Planner.

[44] Bert Farabaugh Gerardo Pardo-Castellote. Introduction to DDS and DataCentric Communications, 2005. Disponible en la Web: www.omg.org/news/whitepapers/Intro_To_DDS.pdf.

[45] Ivar Jacobson, Grady Booch, and James Rumbaugh. El Proceso Unificado de Desarrollode Software. 2000.

[46] GNU Project, 09 2008. Disponible en la Web: http://www.gnu.org/software/bison/.

[47] The Flex Project. Flex (the fast lexical analyzer), 09 2008. Disponible en la Web:http://flex.sourceforge.net/.

[48] Javier Sanchez-Monedero, J.M. Lopez-Soler, J. Povedano-Molina, and J.M. Lopez-Vega. An xml-based approach to the configuration and deployment of ddsapplications. In Workshop on Distributed Object Computing for Real-time andEmbedded Systems, Washington, DC, USA, 2008. Disponible en la Web: http://www.omg.org/news/meetings/workshops/Real-time_WS_Final_Presentations_2008/Session%202/02-03_Monedero_et_al.pdf.

[49] Real-Time Innovations Inc. RTI Data Distribution Service. Users’ Manual (version 4.1),2007.

[50] S. Shepler, Brent Callaghan, David Robinson, R. Thurlow, C. Beame, M. Eisler, andD. Noveck. Network file system (NFS) version 4 protocol. RFC 3530, Internet Engi-neering Task Force, April 2003. Disponible en la Web: http://www.rfc-editor.org/rfc/rfc3530.txt.

82

http://www.omg.org/cgi-bin/doc?omg/03-06-01

http://www.omg.org/cgi-bin/doc?omg/03-06-01

http://www.dre.vanderbilt.edu/

http://www.dre.vanderbilt.edu/

http://www.dre.vanderbilt.edu/DDS/

http://www.dre.vanderbilt.edu/DDS/

http://www.dre.vanderbilt.edu/DDS/DDS_RTWS06.pdf

http://live.gnome.org/Planner

http://live.gnome.org/Planner

www.omg.org/news/whitepapers/Intro_To_DDS.pdf

www.omg.org/news/whitepapers/Intro_To_DDS.pdf

http://www.gnu.org/software/bison/

http://www.gnu.org/software/bison/

http://flex.sourceforge.net/

http://www.omg.org/news/meetings/workshops/Real-time_WS_Final_Presentations_2008/Session%202/02-03_Monedero_et_al.pdf





BIBLIOGRAFIA

[51] Sun Microsystems, Inc. RFC 1014: XDR: External Data Representation standard.Technical report, June 1987. Disponible en la Web: ftp://ftp.internic.net/rfc/rfc1014.txt,http://www.rfc-editor.org/rfc/rfc1014.txt. Sta-tus: UNKNOWN.

[52] Reinier Torenbeek. Benchmarking omg dds for large–scale distributed systems. InReal-time and Embedded Systems Workshop, Washington, DC, USA, 2008. Disponibleen la Web: http://www.omg.org/news/meetings/workshops/Real-time_WS_Final_Presentations_2008/Session%207/07-02_Torenbeek.pdf.

83

ftp://ftp.internic.net/rfc/rfc1014.txt, http://www.rfc-editor.org/rfc/rfc1014.txt

ftp://ftp.internic.net/rfc/rfc1014.txt, http://www.rfc-editor.org/rfc/rfc1014.txt

http://www.omg.org/news/meetings/workshops/Real-time_WS_Final_Presentations_2008/Session%207/07-02_Torenbeek.pdf

http://www.omg.org/news/meetings/workshops/Real-time_WS_Final_Presentations_2008/Session%207/07-02_Torenbeek.pdf

BIBLIOGRAFIA

84

APENDICE A

INTRODUCCION A DDS

Hoy en dıa cada vez es mas usual el uso de aplicaciones distribuidas. No es raroencontrarse con una serie de aplicaciones que se ejecutan en distintas maquinas de formacooperativa dando la sensacion de ser todo un mismo sistema.

Dentro de estos sistemas de computacion distribuida, se pueden encontrar los deno-minados servicios de distribucion de datos. En este caso, lo que se encuentra disperso noson las aplicaciones, sino los datos de interes. Un ejemplo claro de ello puede ser la mo-nitorizacion de sensores. Cada sensor puede encontrarse en un lugar distinto, los cualesse comunican con la entidad monitorizadora por medio de alguna red de conexion. LasFiguras A.1 y A.2 muestran como DDS crea una capa entre la aplicacion y el sistemaoperativo y la red.

En casos de datos distribuidos como los mencionados anteriormente, los requisitosde tiempo real, fiabilidad, falla ante errores suelen ser muy importantes. Una arquitec-tura que mantenga todas estas cualidades de una manera adecuada es muy compleja deconstruir. No serıa razonable tener que disenar para cada nueva aplicacion que requierade distribucion de datos una arquitectura que la soporte. Para paliar este problema, al-gunas empresas han dedicado esfuerzos en disenar una infraestructura de distribucionde datos de una manera comun y razonable. Este esfuerzo se ha materializado en lo quehoy se conoce como Data Distribution Service (DDS)[6][44].

DDS proporciona un middleware que abstrae al programador de aplicaciones que ne-cesiten de datos distribuidos de las tareas necesarias para la recogida de los mismos, conmaximas prestaciones. DDS deja de lado el clasico paradigma cliente/servidor , para usarun nuevo paradigma mucho mas adecuado para distribucion de datos: publicacion/sus-cripcion.

DDS es por tanto un esfuerzo que normaliza el mecanismo de publicacion/suscrip-cion, de manera que puede ser anadido a cualquier aplicacion de una manera sencilla.

85

Figura A.1: Arquitectura de un sistema de distribucion de datos sin DDS

Figura A.2: Arquitectura de un sistema de distribucion de datos con DDS

86

A. Introduccion a DDS

Figura A.3: Infraestructura de DDS

Las ventajas de usar DDS son:

1. Esta basado en un paradigma conceptualmente sencillo como es publicacion/sus-cripcion

2. Es escalable dinamicamente

3. Esta disenado 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 paradistribucion de datos

La utilizacion de un nuevo paradigma supone cambiar la manera de trabajar de lasaplicaciones en muchos aspectos. El paradigma de publicacion/suscripcion no se basa enla existencia de un servidor central, que es el que se encarga de satisfacer las solicitudesdel cliente. En lugar de ello, lo que se hace es que cada entidad (es decir, un computadoro sistema embebido que soporte DDS) que posea un dato susceptible de ser de interespara otra entidad, informa al middleware de la disponibilidad del dato y publica dichodato (de ahı el termino publicacion). Por otro lado, existen entidades con interes haciaciertos datos. En este caso, cuando una entidad esta interesada en un dato, lo que se hacees que se informa al middleware de dicho interes, y este se encargara de proporcionarlo.En este caso, se dice que la entidad se ha suscrito a un tipo de dato.

87

Figura A.4: Entidades DDS participantes en un Dominio (Domain)

Ademas de estos conceptos de publicacion/suscripcion, para facilitar la explicacion deltrabajo realizado y de la arquitectura de DDS, se hace necesaria la explicacion de nuevosconceptos:

Descubrimiento (Discovery): Es el proceso que se realiza para identificar las entidadesque estan publicando datos en DDS. Este proceso se inicia de forma casi instantaneapor DDS, y solo requiere que el usuario proporcione un punto de partida dondecomenzar la busqueda.

Tema (Topic) : Se define como tema cada uno de los distintos tipos de datos que sonpublicados en DDS. Cada tema tiene sus propias caracterısticas, y sus tipos de datosasociados.

Instancia (Instance): Un mismo tema (tipo de datos) puede ser publicado por muchasentidades. Para que cada tema publicado se diferencie de los demas se usa un me-canismo de claves unicas. Por ejemplo, si tenemos datos de posicion de diversosradares (algo muy comun en triangulacion), para identificar de donde proviene ca-da dato anadimos un campo de clave, para que cada dato de posicion se utilicecorrectamente en los calculos de determinacion de la posicion exacta de un objeto.El empleo de claves esta gestionado por el middleware de DDS.

Muestra (Sample): Una vez definido el concepto de instancia es conveniente definir elconcepto de muestra. Este se refiere a cada uno de los valores que toma una ins-tancia a lo largo del tiempo. En el ejemplo de los radares empleado en la definicionde instancia, una muestra serıa cada uno de las sucesivas tomas de datos de cadaradar que determinan la distancia del mismo en un instante determinado.

88


Dominio (Domain): Mecanismo de agrupamiento de entidades en DDS. Cada entidadse encuentra situada dentro de un dominio por medio de un participante de do-minio. Todas las aplicaciones que dispongan de participantes en un dominio, pue-den descubrir e interaccionar con otras aplicaciones remotas con participantes enel mismo dominio.Mediante este mecanismo se consigue aumentar la escalabilidadası como aislamiento de trafico.

Una vez definidos estos conceptos, el siguiente paso es identificar las entidades pre-sentes en DDS para ver como se relacionan. Esto se pone de manifiesto en la Figura A.4,donde aparecen una serie de entidades relacionadas que se identifican a continuacion:

Suscriber: Es el punto de comunicacion entre los DataReader y la aplicacion. Se encargade gestionar las suscripciones (temas en los que se haya declarado interes).

Publisher: Es el encargado de publicar temas en un dominio, que seran recogidos porlos suscriptores situados en otro participante de dominio.

DataWriter: Es el punto de acceso de una aplicacion a DDS para publicar datos que seranpublicados por un publisher

DataReader: Es el punto de acceso de una aplicacion a DDS para recibir datos que fueronrecogidos por un suscriber

La Figura A.5 muestra el modelo conceptual DCPS (Data-Centric Publish–Subscribe,publicacion–subscripcion centrada en los datos) que agrupa a las entidades descritas an-tes.

Ademas de lo anteriormente comentado, es conveniente mencionar una caracterısticaventajosa de DDS: internamente, todas las entidades presentes en DDS, disponen de unaserie de polıticas de calidad de servicio (QoS). Estas polıticas son modificables de modoque pueden afinarse en funcion del entorno de explotacion final.

Polıticas de calidad de servicio (QoS) Las polıticas de calidad de servicio (QoS) sonuno de los atractivos de utilizar DDS. Mediante ellas se pueden gestionar aspectos muyvariados del funcionamiento de DDS, desde el descubrimiento de entidades remotas dis-tribuidas, hasta parametros de tiempo de recogida de datos o de usuario. Las polıticas decalidad de servicio disponibles son:

Destination Order

Deadline

Durability

Entity Factory

Group Data

History

Latency Budget

Lifespan

Liveliness

Ownership

Ownership Strength

Partition

89

Figura A.5: Modelo conceptual de las entidades DDS

90


Presentation

Reader Data Lifecycle

Reliability

Resource Limits

Time-Based Filter

Topic Data

Transport Priority

User Data

Writer Data Lifecycle

De todas las polıticas mostradas, algunas solo estan disponibles para ciertos tipos deentidades. Por otro lado solo algunas de ellas pueden ser modificadas dinamicamente.De todas estas polıticas de calidad de servicio, se destacan algunas de ellas, por ser demayor interes por sus caracterısticas:

Deadline Este parametro se refiere al tiempo o intervalo mınimo de envıo de datos porparte de un DataWriter. Es util para aplicaciones que publican los datos periodi-camente. Si se supera el tiempo de Deadline entre muestras, la aplicacion es noti-ficada, quedando a decision del desarrollador las acciones a llevar a cabo en estesupuesto.

Lifespan Se refiere al tiempo en el que un mensaje o muestra es valido. Si se supera eltiempo para este mensaje, es eliminado de DDS.

Transport Priority Se refiere a la prioridad que recibe una muestra de datos en la capade transporte subyacente. Dicho valor es valido solo si la capa de transporte subya-cente soporta prioridad de mensajes.

Para una descripcion mas detallada de estas y otras polıticas de calidad de servicio,vease [44] o [49].

91

92

APENDICE B

DESPLIEGUE Y DESARROLLO DE UN ESCENARIOINCREMENTALMENTE

El objetivo de este ejemplo es mostrar la secuencia de ordenes necesaria para realizarun despliegue y ejecucion incremental de un escenario.

Supongase que se quiere desarrollar el siguiente escenario en el que se tienen dosaplicaciones distribuidas descritas mediantes sus modelos estaticos y dinamicos:

Una aplicacion publicadora de datos, Application radar o Radar.

Una aplicacion subscriptora Application traffic control o Control Trafico que trabajacon los datos que recibe de entidades Application radar.

El primer paso consiste en la preparacion del escenario. Se supone que las herra-mientas cmdmaster (rol de CommandPublisher) y cmdslave (rol de CommandSubscriber)se estan ejecutando en los nodos adecuados, tal y como muestra la Figura B.1. En todomomento se indicara la secuencia de ordenes en el recuadro “Control Topic” y la figuracorrespondiente mostrara los efectos de la ejecucion de ordenes. Las flechas rojas indicancomo el nodo CommandPublisher publica ordenes a traves de tema de control, ordenes quereciben los nodos CommandSubscriber.

El segundo paso (Figura B.2) consiste en la distribucion de la descripcion del escenarioa los nodos que participan en el mediante el la orden:

> load "scenario.xml"

Esta orden lee el fichero que el usuario le proporciona y lo distribuye a todos los no-dos. Cada nodo seleccionara la aplicacion adecuada consultando la etiqueta <deployment>de cada aplicacion. Ası, las aplicaciones Radar se asignaran a los Nodos 1 y 2, y la aplica-cion Control Trafico se asignara al Nodo 3.

93

Figura B.1: Representacion de despliegue de un escenario: estado inicial

94

B. Despliegue y desarrollo de un escenario incrementalmente

Figura B.2: Representacion de despliegue de un escenario: distribucion del escenario yasignacion de aplicaciones

95

Asignadas las aplicaciones a nodos, puede empezar la creacion de algunas entidades.Por ejemplo pueden crearse todos los Participants, Topics, Publishers y Subscribers mediantela siguiente secuencia de ordenes:

> create "radar_participant"> create "radar_topic"> create "radar_publisher"> create "tcontrol_participant"> create "tcontrol_subscriber"

Tras la ejecucion de esta orden los nodos correspondientes crearan este conjunto deentidades.

Si el usuario quiere realizar una carga incremental del sistema creando poco a pocolas entidades y decide crear la primera instancia de los DataReader llamados “reader a”:

> create "reader_a" 1

La distribucion de esta orden a los CommandSubscriber produce que cada uno de ellosbusque en su aplicacion una entidad llamada “reader a”. Los que la tengan crearan lainstancia DDS de ındice 1. Este es el caso del Nodo 3, que crea este DataReader (ver FiguraB.3) para subscribirse a la futura informacion que publiquen los radares.

El mismo proceso puede repetirse para crear otras entidades:

> create "writer_a" 1

El comando anterior produce que los nodos cuya aplicacion tenga una entidad llama“writer a” creen una entidad DDS, en este caso un DataWriter, como puede observarseen la Figura B.4. Este tipo de creacion gradual de entidades es interesante, por ejemplo,para medir el tiempo de descubrimiento de las entidades de la red.

Pasemos ahora a iniciar el comportamiento de algunas de las entidades. La ordensiguiente inicia la actividad de los DataWriters creados en el paso anterior:

> start "writer_a" 1

La Figura B.5 muestra el inicio de actividad de los DataWriters creados en los nodos 1y 2. Las flechas negras indican el trafico de datos DDS que generan estas entidades comoresultado de la su actividad. El nodo 3 comienza a recibir los datos de los nodos 1 y 2.

Se puede incrementar el numero de entidades con el fin de comprobar como reaccio-na el escenario ante el incremento de carga. Para ilustrar esto, se utilizan los siguientescomandos para crear una segunda entidad del tipo “writer a”. Ademas se activa el com-portamiento de estas entidades:

96


Figura B.3: Representacion de despliegue de un escenario: creacion varias entidades DDS

97

Figura B.4: Representacion de despliegue de un escenario: creacion de dos DataWriters

98


Figura B.5: Representacion de despliegue de un escenario: inicio de la actividad de algu-nas entidades

> create "writer_a" 2> start "writer_a" 2

La Figura B.6 muestra este incremento de la carga del sistema tras la aplicacion deestas ordenes.

Por ultimo, se puede detener el comportamiento de todas las entidades de la red almismo tiempo con una orden que se aplica a todas las entidades. La Figura B.7 muestrael efecto de los comandos listados a continuacion, que producen el cese de actividad ydestruccion de todas las entidades DDS de la red (salvo las relativas a la coordinacion delescenario):

> stopall> destroy

Por ultimo, se puede finalizar la ejecucion de la aplicacion cmdslave mediante elcomando siguiente:

> terminate

99

Figura B.6: Representacion de despliegue de un escenario: incremento del numero deentidades y actividad en el escenario

100


Figura B.7: Representacion de despliegue de un escenario: destruccion de las entidadesDDS

La Figura B.8 ilustra el efecto de esta orden.

101

Figura B.8: Representacion de despliegue de un escenario: finalizacion de la ejecucion delos CommandSubscribers

102

APENDICE C

FICHEROS UTILIZADOS EN LAS PRUEBAS

C.1. Fichero de definicion de tipo de documento (DTD)

El Listado C.1 muestra el fichero DTD que define el formato de los ficheros XMLvalidos.

< !−− dds −−>< !ELEMENT dds ( a p p l i c a t i o n )∗>

< !−− S c e n a r i o d e s c r i p t i o n : an a p p l i c a t i o n −−>< !−− A p p l i c a t i o n ( c o n t a i n s DDS E n t i t i e s ) −−>< !ELEMENT a p p l i c a t i o n ( p a r t i c i p a n t +)>< ! ATTLIST a p p l i c a t i o n name CDATA #IMPLIED>< ! ATTLIST a p p l i c a t i o n base name CDATA #IMPLIED>

< !−− DDS ENTITIES −−>< !−− p a r t i c i p a n t −−>< !ELEMENT p a r t i c i p a n t

( domain id ,p a r t i c i p a n t e n t i t i e s ,l i s t e n e r ? ,behaviour ? ,i n s t a n c e s ? )>

< ! ATTLIST p a r t i c i p a n t name CDATA #IMPLIED>< ! ATTLIST p a r t i c i p a n t base name CDATA #IMPLIED>

< !ELEMENT domain id (#PCDATA)>

< !ELEMENT p a r t i c i p a n t e n t i t i e s ( t o p i c | publ i sher | s u b s c r i b e r )∗>< !−− t o p i c −−>< !ELEMENT t o p i c

( topic name ? ,type ? ,l i s t e n e r ? ,behaviour ? )>

< ! ATTLIST t o p i c name CDATA #IMPLIED>

103

C.2. Fichero de prueba scenario.xml

< ! ATTLIST t o p i c base name CDATA #IMPLIED>

< !ELEMENT topic name (#PCDATA)>< !ELEMENT type (#PCDATA)>

< !−− p u b l i s h e r −−>< !ELEMENT publ i sher

( datawr i ter ∗ ,l i s t e n e r ? ,behaviour ? ,i n s t a n c e s ? )>

< ! ATTLIST publ i sher name CDATA #IMPLIED>< ! ATTLIST publ i sher base name CDATA #IMPLIED>

< !−− w r i t e r −−>< !ELEMENT datawri ter (

d a t a w r i t e r t o p i c ,l i s t e n e r ? ,behaviour ? ,i n s t a n c e s ? )>

< ! ATTLIST datawri ter name CDATA #IMPLIED>< ! ATTLIST datawri ter base name CDATA #IMPLIED>

< !ELEMENT d a t a w r i t e r t o p i c (#PCDATA)>

< !−− s u b s c r i b e r −−>< !ELEMENT s u b s c r i b e r

( datareader ∗ ,l i s t e n e r ? ,behaviour ? ,i n s t a n c e s ? )>

< ! ATTLIST s u b s c r i b e r name CDATA #IMPLIED>< ! ATTLIST s u b s c r i b e r base name CDATA #IMPLIED>

< !−− r e a d e r −−>< !ELEMENT datareader

( d a t a r e a d e r t o p i c ? ,l i s t e n e r ? ,behaviour ? ,i n s t a n c e s ? )>

< ! ATTLIST datareader name CDATA #IMPLIED>< ! ATTLIST datareader base name CDATA #IMPLIED>

< !ELEMENT d a t a r e a d e r t o p i c (#PCDATA)>

< !ELEMENT l i s t e n e r (#PCDATA)>< !ELEMENT behaviour (#PCDATA)>< !−− Number o f i n s t a n c e s which a r e go ing t o be c r e a t e d o f an e n t i t y .

Th i s i s not mandatory so t h e default v a l u e i f no t p r e s e n t i s 1 −−>< !ELEMENT i n s t a n c e s (#PCDATA)>

Listado C.1: Fichero de definicion de tipo de documento (DTD)


El Listado C.2 muestra el fichero XML utilizado en las pruebas del sistema.

104

C. Ficheros utilizados en las pruebas

<?xml version="1.0" encoding="UTF-8"?><dds>

<a p p l i c a t i o n name="application1">

<domain id>21</domain id>

<t o p i c name="hello_world_topic"><topic name>Hello world !</topic name><type>DDS StringX</type>

</ t o p i c><publ i sher name="publisher1">

<datawri ter name="writer1a"><d a t a w r i t 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 w r i t e r t o p i c><behaviour>DDS StringX behaviour<behaviour>

</datawri ter><datawri ter name="writer1b">

<d a t a w r i t 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 w r i t e r t o p i c></datawri ter>

</publ i sher><s u b s c r i b e r name="subscriber1">

1<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>< l i s t e n e r>DDS Str ingX l i s tener< l i s t e n e r>1

</datareader></ s u b s c r i b e r>



<domain id>2</domain id>

<t o p i c name="hello_world_topic2"><topic name>Hello world2</topic name><type>DDS StringX</type>

</ t o p i c><publ i sher name="publisher11">

<datawri ter name="writer1"><d a t a w r i t e r t o p i c>h e l l o w o r l d t o p i c 2</ d a t a w r i t e r t o p i c>

</datawri ter></publ i sher><s u b s c r i b e r name="subscriber11">

<datareader name="reader11"><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 2</ d a t a r e a d e r t o p i c>5

</datareader><datareader name="reader_as_reader11" base name="reader11"></datareader>

</ s u b s c r i b e r>

</ a p p l i c a t i o n><a p p l i c a t i o n name="application2">

<domain id>3</domain id>

<t o p i c name="hello_world_topic3"><topic name>Hello world3</topic name><type>DDS Octets</type>

</ t o p i c><s u b s c r i b e r name="subscriber2">

105


2<datareader name="reader2">

2<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 3</ d a t a r e a d e r t o p i c>

</datareader><datareader name="reader2a" base name="reader2">

3</datareader><datareader name="reader2b" base name="reader2">

1</datareader>

</ s u b s c r i b e r><s u b s c r i b e r name="subscriber2a" base name="subscriber2"></ s u b s c r i b e r>



</ a p p l i c a t i o n></dds>

Listado C.2: Fichero de prueba scenario.xml

106

INDEX

bison, 70parser generator, 65

BNF, 31

cliente, 85

DataReader, 89DataWriter, 89DDS, 2, 85

middleware, 2, 85discovery process, 88DTD, 33

herencia, 33, 43, 66

IDL, 32instance, 88instancia, 88

listener, 20, 68

middleware, 1, 11, 85Modelo Dinamico, 17, 41, 68Modelo Estatico, 17, 38, 58, 65muestra, 88

parser, 20proceso de descubrimiento, 88publicacion, 85publicacion/suscripcion

Paradigma, 85publisher, 89

sample, 88servidor, 85suscriber, 89suscripcion, 85

Tema, 88Topic, 88

instance, 88sample, 88

XML, 20, 33, 65

107

INDEX

108

GLOSARIO

LATEX Sistema de composicion de textos.

DDS Data Distribution Service. Servicio de distribucion dedatos

DTD Document Type Definition. Definicion de tipo de do-cumento, es una descripcion de estructura y sintaxisde un documento XML.

GNU Gnu is Not Unix.

IDE Entorno de desarrollo integrado o Integrated Develop-ment Environment en ingles

IDL Interface Definition Language. Lenguaje de especi-ficacion de interfaces que se utiliza en software decomputacion distribuida.

LALR Look-Ahead LR parser. Este tipo de analizadorsintactico que toma un sımbolo por delante para de-terminar que regla de derivacion aplicar

listener Significa oyente en ingles. En programacion se refierea objetos que se subscriben a eventos o notificacionesde un sistema.

LR Left to right, Rightmost derivation. Este tipo de anali-zador sintactico lee caracteres de izquierda a derecha,para producir derivaciones por la derecha

Middleware Software encargado de abstraer la aplicacion de laexistencia de un entorno distribuido

109

Glosario

Modelo Dinamico Descripcion del comportamiento de entidades DDS.Modelo Estatico Descripcion de los parametros y relaciones entre en-

tidades DDS.

parser Analizador sintactico. Convierte el texto de entradaen otras estructuras (comunmente arboles).

UML Unified Modelling Language. Lenguaje formal em-pleado para el modelado en el proceso de desarrollode software.

XML Extensible Markup Language. Metalenguaje de eti-quetado ampliable capaz de definir a su vez otros len-guajes.

XML eXtensible Markup Language

YACC Yet Another Compiler Compiler. Traducido significaotro compilador de compiladores mas

110

Documents

Universidad de Granada - Una metodología basada en XML ...dtstc.ugr.es/tl/pdf/pf/PFC_jsanchez.pdf · mitido el desarrollo de soluciones que han supuesto un salto en cuanto al aumento