Una metodología basada en XML para la configuración y

Transcripción

Escuela Técnica Superior de Ingenierı́as Informática y de
Telecomunicación
Una metodologı́a basada en XML para la
configuración y despliegue de aplicaciones
DDS
Javier Sánchez Monedero
Dirigido por: Juan Manuel López Soler
Departamento de Teorı́a de la Señal, Telemática y Comunicaciones
Universidad de Granada
Granada, 22 de septiembre de 2008
Resumen
En las últimas décadas, las redes de ordenadores han mejorado en prestaciones
y calidad. Estos avances tecnológicos han permitido, y permiten, nuevos paradigmas en el desarrollo de programas, como son las aplicaciones distribuidas. Entre
otras tecnologı́as, para facilitar el desarrollo de estas aplicaciones han aparecido
los denominados middlewares: una capa software que facilita al programador la
construcción del sistema distribuido abstrayéndole de las tareas de comunicación.
Este es el caso de la tecnologı́a DDS (Data Distribution Service), un middleware
orientado a la difusión de mensajes en entornos distribuidos con restricciónes de
tiempo-real. DDS se utiliza con éxito en redes relativamente pequeñas en las que
intervienen unas decenas o centenares de nodos sobre los que ejecutan aplicaciones distribuidas. Actualmente se plantea conocer si DDS puede implantarse en
entornos mayores y si mejorará las tecnologı́as existentes en este campo.
El presente proyecto afronta algunos de los retos que aparecen en el desarrollo
de grandes escenarios DDS mediante la propuesta de una nueva metodologı́a en
el desarrollo de aplicaciones DDS.
La metodologı́a planteada minimiza el esfuerzo de programación permitiendo especificar gran parte del escenario DDS mediante XML. En consecuencia, el
tiempo de desarrollo de sistemas distribuı́dos y la probabilidad de que aparezcan
errores de programación se reducen. Especialmente para el campo de la experimentación, en el que deben lanzarse muchas pruebas variando las aplicaciones
distribuı́das, este proyecto resulta de gran interés.
La metodologı́a se complementa con el desarrollo de aplicaciones para la coordinación de nodos de la red sobre la que se ejecuta el escenario. Estas herramientas presentan al desarrollador una vista global y de alto nivel para el control del
escenario distribuido.
Agradecimientos
En primer lugar quiero agradecer a mi familia, Luis, Maria Jesús y Amaya, el apoyo, el ánimo y la comprensión que me han dado durante mis años de estudios en
Córdoba y Granada.
En segundo lugar, agradecer los ánimos de mis amigos, en especial el de Carmen. Gracias a ella por aguantar mis dos proyectos y por ayudarme con la documentación. Gracias a todos por asistir a los ensayos de mis presentaciones.
Gracias a la gente que hoy en dı́a pasa por la universidad con la intención de
aprender, enseñar, debatir y participar activamente en todos sus ámbitos. Gracias
a los representantes de alumnos que han compartido su tiempo conmigo en el
Consejo de Estudiantes de la Escuela Politécnica de la Universidad de Córdoba,
la Delegación de Alumnos de la E.T.S. de Ingenierı́as Informática y de Telecomunicación de la Universidad de Granada y de la sectorial de estudiantes de
Informática (RITSI). No todo tiene que ser lucrativo en esta vida.
Dar las gracias mi tutor, Juanma, por el tiempo e interés que ha dedicado a
este proyecto.
Por último, me gustarı́a agradecer a Gerardo y Fernando de RTI la resolución
de dudas, aportación de ideas y la revisión continua del proyecto. Resulta un
verdadero lujo contar con el soporte de personas con gran conocimiento técnico
y experiencia.
Sinceramente, gracias.
ÍNDICE GENERAL
1. Introducción
1.1. Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Contextualización . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1. La empresa Real-Time Innovations . . . . . . . . . . .
1.2.2. La plataforma PASITO . . . . . . . . . . . . . . . . . .
1.2.3. Experimentación con DDS sobre PASITO . . . . . . .
1.3. Definición del problema . . . . . . . . . . . . . . . . . . . . .
1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1. Humanos . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6. Fases de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . .
1.7. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1. Factores dato . . . . . . . . . . . . . . . . . . . . . . .
1.7.2. Factores estratégicos . . . . . . . . . . . . . . . . . . .
1.8. Antecedentes y estado del arte . . . . . . . . . . . . . . . . .
1.8.1. Antecedentes en distribución de datos . . . . . . . . .
1.8.2. El lenguaje XML . . . . . . . . . . . . . . . . . . . . .
1.8.3. Herramientas para el desarrollo de aplicaciones DDS
1.9. Aproximación a la solución propuesta . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
3
3
4
5
6
7
7
8
8
8
9
9
10
11
11
12
14
16
2. Especificación de Requisitos
2.1. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Requisitos no Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
21
3. Planificación
23
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Análisis de Requisitos
4.1. Casos de uso del sistema . . . . . . . . . . . . .
4.1.1. Identificación de los actores del sistema
4.1.2. Diagrama de casos de uso . . . . . . . .
4.1.3. Listado de los casos de uso . . . . . . .
4.2. Gramática de interacción con el escenario . . .
4.2.1. Definición de la gramática . . . . . . . .
4.2.2. Estructura de datos de órdenes . . . . .
4.3. Lenguaje de descripción de aplicaciones . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5. Diseño
5.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . .
5.1.1. ¿Cómo describir un escenario DDS? . . . . . . . . . . . .
5.1.2. La interacción y coordinación del escenario . . . . . . . .
5.1.3. Funcionalidades para mejorar la flexibilidad del sistema
5.2. Modelo de interacción de objetos . . . . . . . . . . . . . . . . . .
5.2.1. Acción cargar escenario . . . . . . . . . . . . . . . . . . . .
5.2.2. Acción crear entidad DDS . . . . . . . . . . . . . . . . . . .
5.2.3. Acción iniciar comportamiento . . . . . . . . . . . . . . . .
5.3. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
27
28
29
30
31
32
33
.
.
.
.
.
.
.
.
.
37
37
37
41
42
45
46
47
51
58
6. Implementación
6.1. Implementación de la orientación a objetos en C . . . . . .
6.2. Implementación del analizador de gramática semi-natural
6.3. Estructuración modular del código . . . . . . . . . . . . . .
6.3.1. Modelo Estático: clases DDS XML y parser XML . .
6.3.2. Modelo Dinámico . . . . . . . . . . . . . . . . . . . .
6.3.3. Módulo de coordinación . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
63
65
65
65
68
70
7. Pruebas
7.1. Herramientas para la realización de pruebas
7.2. Pruebas unitarias . . . . . . . . . . . . . . . .
7.3. Pruebas de integración . . . . . . . . . . . . .
7.4. Pruebas de sistema . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
74
74
75
75
8. Resultados y Trabajo Futuro
8.1. Principales contribuciones de este trabajo . . . . . . . . . . . . . . . . . . .
8.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
77
78
A. Introducción a DDS
85
B. Despliegue y desarrollo de un escenario incrementalmente
93
II
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
C. Ficheros utilizados en las pruebas
103
C.1. Fichero de definición de tipo de documento (DTD) . . . . . . . . . . . . . . 103
C.2. Fichero de prueba scenario.xml . . . . . . . . . . . . . . . . . . . . . . . 104
Glosario
109
III
IV
ÍNDICE DE FIGURAS
1.1. Mapa de la plataforma PASITO . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Especificación de entidades DDS con Enterprise Architect . . . . . . . . . .
1.3. Descripción de escenarios DDS mediante los modelos Estático y Dinámico .
4
15
18
3.1. Detalle del diagrama de Gantt de la planificación inicial del proyecto . . .
3.2. Planificación inicial del proyecto en formato tabular . . . . . . . . . . . . .
24
25
4.1. Diagrama de casos de uso del sistema . . . . . . . . . . . . . . . . . . . . .
28
Descripción de aplicaciones DDS mediante los modelos Estático y Dinámico
Árbol del el Modelo Estático para una aplicación DDS . . . . . . . . . . . .
Coordinación del escenario distribuidos utilizando DDS . . . . . . . . . .
Ejemplo explicativo del funcionamiento de las instancias y parámetros de
recursividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5. Diagrama de secuencia cargar escenario . . . . . . . . . . . . . . . . . . . . .
5.6. Diagrama de secuencia crear entidad DDS, parte genérica. . . . . . . . . . .
5.7. Diagrama de secuencia crear entidad DDS, DDS XMLDomainParticipant .
5.8. Diagrama de secuencia crear entidad DDS, DDS XMLDomainPublisher . .
5.9. Diagrama de secuencia crear entidad DDS, DDS XMLDomainSubscriber .
5.10. Diagrama de secuencia iniciar comportamiento, parte genérica. . . . . . . . .
5.11. Diagrama de secuencia iniciar comportamiento, DDS XMLDomainParticipant
5.12. Diagrama de secuencia iniciar comportamiento, DDS XMLDomainPublisher
5.13. Diagrama de secuencia iniciar comportamiento, DDS XMLDomainSubscriber
5.14. Vista general del diagrama de clases . . . . . . . . . . . . . . . . . . . . . .
5.15. Detalle del diagrama de clases: DDS XMLApplication . . . . . . . . . . . .
5.16. Detalle del diagrama de clases: DDS XMLParticipant . . . . . . . . . . . .
5.17. Detalle del diagrama de clases: DDS XMLPublisher . . . . . . . . . . . . .
5.18. Detalle del diagrama de clases: DDS XMLSubscriber . . . . . . . . . . . .
5.19. Detalle del diagrama de clases: DDS XMLTopic . . . . . . . . . . . . . . . .
5.20. Detalle del diagrama de clases: DDS XMLDataWriter . . . . . . . . . . . .
39
40
42
5.1.
5.2.
5.3.
5.4.
V
44
47
49
50
52
52
53
55
56
57
58
59
59
60
60
60
61
5.21. Detalle del diagrama de clases: DDS XMLDataReader . . . . . . . . . . . .
5.22. Detalle del diagrama de clases: CommandPublisher . . . . . . . . . . . . .
5.23. Detalle del diagrama de clases: CommandSubscriber . . . . . . . . . . . .
61
62
62
A.1.
A.2.
A.3.
A.4.
A.5.
86
86
87
88
90
Arquitectura de un sistema de distribución de datos sin DDS .
Arquitectura de un sistema de distribución de datos con DDS
Infraestructura de DDS . . . . . . . . . . . . . . . . . . . . . . .
Entidades DDS participantes en un Dominio (Domain) . . . . .
Modelo conceptual de las entidades DDS . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B.1. Representación de despliegue de un escenario: estado inicial . . . . . . . . 94
B.2. Representación de despliegue de un escenario: distribución del escenario
y asignación de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
B.3. Representación de despliegue de un escenario: creación varias entidades
DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
B.4. Representación de despliegue de un escenario: creación de dos DataWriters 98
B.5. Representación de despliegue de un escenario: inicio de la actividad de
algunas entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
B.6. Representación de despliegue de un escenario: incremento del número de
entidades y actividad en el escenario . . . . . . . . . . . . . . . . . . . . . . 100
B.7. Representación de despliegue de un escenario: destrucción de las entidades DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B.8. Representación de despliegue de un escenario: finalización de la ejecución
de los CommandSubscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
VI
ÍNDICE DE CÓDIGO
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
C.1.
C.2.
Gramática BNF definida para interacción con el escenario . . . . . . . . . . 31
Fichero IDL correspondiente al tema de control . . . . . . . . . . . . . . . . . 32
Descripción de una aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Descripción de un participante de dominio (Domain Participant) . . . . . . . . 34
Descripción de un tema (Topic) . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Descripción de un publicador (Publisher) . . . . . . . . . . . . . . . . . . . . 35
Descripción de un subscriptor (Subscriber) . . . . . . . . . . . . . . . . . . . 36
Código XML para mostrar el funcionamiento de la herencia . . . . . . . . 66
Código XML para mostrar el funcionamiento de la herencia . . . . . . . . 66
Estructura DDS XMLDataReader . . . . . . . . . . . . . . . . . . . . . . . . 67
Tablas del Modelo Dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Entradas de las tablas del Modelo Dinámico . . . . . . . . . . . . . . . . . . . 69
Integración de CommandPublisher con las reglas de análisis sintáctico de Yacc 70
Fichero de definición de tipo de documento (DTD) . . . . . . . . . . . . . . 103
Fichero de prueba scenario.xml . . . . . . . . . . . . . . . . . . . . . . . 105
VII
VIII
CAPÍTULO
1
INTRODUCCIÓN
1.1.
Presentación
En las últimas décadas, las redes de ordenadores han mejorado en prestaciones y calidad. Estos avances tecnológicos han permitido, y permiten, nuevos paradigmas en el
desarrollo de aplicaciones. Este es el caso de las aplicaciones distribuidas: aplicaciones que
se ejecutan en plataformas diferentes y que tı́picamente están conectadas a través de una
red, sistemas de ficheros o memoria compartida. Las aplicaciones distribuidas han permitido el desarrollo de soluciones que han supuesto un salto en cuanto al aumento de la
capacidad de cómputo y a la conexión entre gran cantidad de productores y consumidores de información.
Ejemplos de aplicaciones distribuidas son el correo electrónico, la navegación web,
los servicios de mensajerı́a instantánea, la trazabilidad de mercancı́as, las aplicaciones
de cálculo cientı́fico distribuidas o el control de tráfico aéreo entre otras. Dependiendo
del objeto de la aplicación que se distribuye, la tecnologı́a subyacente en la que se apoya
varı́a sustancialmente. Por ejemplo, un servicio de mensajerı́a instantánea no tiene los
mismos requerimientos que una sistema para coordinar vehı́culos aéreos.
Ası́, han ido surgiendo diferentes tecnologı́as para dar soporte a distintos sistemas
con diferentes requerimientos. Estas tecnologı́as proporcionan funcionalidades orientadas a satisfacer problemas generales de aplicaciones distribuidas, liberando al desarrollador de las tareas comunes en este tipo de software, de manera que el desarrollo puede
centrarse en lo especı́fico del proyecto. Por lo general, estas tecnologı́as entran dentro del
concepto de middleware.
Este proyecto se centra en el middleware orientado a mensajes, cuyo objetivo es la distribución de datos a las distintas entidades, productores y consumidores de información,
que componen la aplicación distribuida. Al delegarse la comunicación entre aplicaciones
1
1. Introducción
al middleware, el diseñador de software puede centrarse en la resolución del problema en
si.
Ejemplos de tecnologı́as de distribución de datos son los servicios web[1] [2], los servicios de mensajerı́a de Java (JMS, Java Message Service)[3], CORBA (Common Object Request
Broker Architecture)[4], MPI (Message Passing Interface, interfaz de paso de mensajes)[5] o
DDS (Data Distribution Service)[6].
Muchas aplicaciones con restricciones de tiempo real (RT, Real-Time) utilizan un middleware para resolver las cuestiones de comunicación. Para estas aplicaciones no sólo es
importante la capacidad de distribución de datos, sino también la manera en que se distribuyen estos en cuanto a eficiencia, determinismo, seguridad, fiabilidad y notificación
y gestión de errores. En este campo se han diseñado soluciones para satisfacer tales restricciones, y este es el caso de la tecnologı́a DDS.
DDS son las siglas del estándar Data Distribution Service for Real-Time Systems o servicio de distribución de datos para sistemas de tiempo real[6], estándar mantenido por la OMG
(Object Management Group)[7]. DDS es el primer estándar internacional abierto que trata
las comunicaciones de publicación–subscripción para sistemas de tiempo real y sistemas empotrados. Las implementaciones más conocidas son NDDS[8] de Real–Time Innovations[9], OpenSplice DDS[10] de PrismTech[11] y OpenDDS[12] de la empresa Object
Computing[13]. Puede consultarse información sobre estas y otras implementaciones en
el portal web sobre DDS[14] que mantiene la OMG.
RTI Data Distribution Service, también conocido como NDDS, es un middleware de red
que implementa un modelo de comunicaciones en tiempo real basado en el paradigma
publicación-suscripción que permite a un proceso en un entorno distribuido compartir
datos independientemente de la localización fı́sica o la arquitectura del resto de procesos.
Incluye soporte para comunicaciones deterministas (best-effort) y comunicaciones fiables
(reliable), incluyendo comunicaciones fiables basadas en multidifusión (multicast), ası́ como también soporte para comunicaciones cliente-servidor. Una explicación detallada de
DDS se proporciona en el Apéndice A.
DDS se ha utilizado con éxito en redes relativamente pequeñas en las que intervienen unas decenas o centenares de nodos sobre los que ejecutan aplicaciones distribuidas.
Conforme los sistemas distribuidos aumentan en número de nodos participantes, redes
que unen estos nodos, y cantidad de entidades DDS que se encargan de la distribución
de los datos, aparecen una serie de retos que deben superarse. Aspectos como la configuración de la capa de transporte, la gestión de la seguridad, la definición interfaces
de interacción y monitorización de cientos o miles de aplicaciones, la especificación formal del sistema, la escalabilidad, los protocolos de descubrimiento[15] y más constituyen
desafı́os para las plataformas DDS. A dı́a de hoy, no existen estudios sobre los problemas
y lı́mites que DDS puede encontrar en grandes escenarios.
Independientemente de los nuevos retos para los fabricantes de productos DDS, el
paso a grandes escenarios distribuidos necesita de metodologı́as y herramientas de prototipado rápido de aplicaciones que permitan hacer uso de todas las funcionalidades ofre2
1.2. Contextualización
cidas por un middleware DDS. Gracias a estas técnicas, el despliegue y gestión de escenarios
DDS permitirá identificar cuellos de botella de las implementaciones concretas o de diversas configuraciones posibles en cuanto a dominios, particiones, parámetros de calidad
de servicio, temas, etc. El presente proyecto trata de dar solución al despliegue masivo
de entidades DDS en redes de gran escala. El objetivo es proporcionar una metodologı́a y
herramientas que permitan el desarrollo rápido y libre de errores de aplicaciones distribuidas con la intención de realizar pruebas empı́ricas con plataformas DDS en redes de
grandes dimensiones.
1.2.
Contextualización
1.2.1.
La empresa Real-Time Innovations
El proyecto se enmarca dentro del convenio de colaboración del Departamento de
Teorı́a de la Señal, Telemática y Comunicaciones (TSTC en adelante) de la Universidad
de Granada con la empresa Real-Time Innovations, inc (también conocida como RTI)1 situada en Sunnyvale, en el estado de California de los Estados Unidos de América. El
Departamento forma parte del programa de universidades de RTI (Real-Time Innovations
University Program)2 , por lo que se dispone de licencias de desarrollo gratuitas del middleware RTI Data Distribution Service (o NDDS).
1.2.2.
La plataforma PASITO
Profesores del Departamento TSTC forman parte del proyecto PASITO (plataforma
de experimentación de servicios de telecomunicaciones)[16]. PASITO es un laboratorio
de pruebas distribuido, que ofrece a los ingenieros la posibilidad de construir, depurar y
evaluar escenarios de prueba de servicios de telecomunicaciones.
PASITO es una infraestructura pública construida sobre la red académica española
RedIRIS3 , utilizando tecnologı́as variadas para poder probar gran variedad de servicios
de telecomunicaciones y, al mismo tiempo, garantizar que su actividad está aislada del
resto de los servicios dela red académica, para evitar interferencias con otras actividades
que estén en operación para la comunidad cientı́fica española. La Figura 1.1 muestra los
nodos que componen en la actualidad PASITO.
El propósito como laboratorio de servicios de telecomunicaciones es permitir investigaciones sobre:
Arquitecturas para Internet.
1
http://www.rti.com/
http://www.rti.com/corporate/university.html
3
http://www.rediris.es/
2
3
1. Introducción
Figura 1.1: Mapa de la plataforma PASITO
Protocolos de comunicaciones.
Tecnologı́as de transporte con calidad de servicio.
Virtualización y autoconfiguración de redes y servicios.
Tecnologı́as y herramientas de monitorización de redes y servicios.
Servicios ópticos para proyectos intensivos en datos.
Tecnologı́as de distribución de grandes cantidades de información.
Sistemas peer-to-peer.
Servicios de movilidad.
Tecnologı́as para mejorar la seguridad en redes.
Estándares para servicios de colaboración de nueva generación.
1.2.3.
Experimentación con DDS sobre PASITO
PASITO ofrece un laboratorio de telecomunicaciones que brinda oportunidades de
experimentación difı́ciles de conseguir si en la investigación sólo participa un centro. Si
retomamos las ideas expuestas en la Sección de “Introducción” sobre la necesidad de
4
1.3. Definición del problema
probar y experimentar con DDS en grandes escenarios de aplicaciones distribuidas, parece
natural relacionar esto con la oportunidad que nos ofrece la plataforma PASITO.
PASITO puede constituir, pues, la infrastructura necesaria para experimentar con
DDS en un escenario situado sobre una red de área amplia. No obstante, tal y cómo
se presenta en la Sección 1.1 y se concretará más adelante, el despliegue de grandes escenarios DDS en general, y para realizar experimentaciones en particular, requiere de
herramientas de apoyo y metodologı́as de prototipado rápido de aplicaciones que liberen al experimentador de tareas tediosas y propensas a errores para dejar que se centre
en el diseño del experimento.
Ası́ pues, contextualizamos el desarrollo del proyecto dentro del marco de investigación del despliegue de escenarios DDS sobre redes de área amplia y grandes redes de
computadores.
1.3.
Definición del problema
El desarrollo de aplicaciones DDS, en general, conlleva una serie de tareas que deben realizarse programando, mediante el API proporcionada por la plataforma DDS, la
aplicación que se ejecutará en cada nodo. Llamaremos despliegue y desarrollo de un escenario a una serie de tareas necesarias para la construcción, distribución y ejecución de un
escenario DDS. Esta tareas incluyen:
La creación de aplicaciones con un gran número de entidades DDS asociadas a
nodos concretos de la red sobre la que se sitúa al sistema distribuido.
La descripción de los parámetros de configuración (dominio, nombres de temas y
tipos de tatos, parámetros de QoS. . . ) para cada una de las entidades DDS que se
ejecutarán en cada nodo.
El establecimiento de relaciones entre las entidades DDS a nivel intranodo e internodo.
La descripción de cada entidad DDS del sistema y la definición de su comportamiento. Se entiende por comportamiento a la actividad que desarrollará la entidad. Por
ejemplo, un DataWriter se dedicará a escribir datos en la red.
La coordinación y sincronizado del ciclo de vida de de entidades DDS.
Además, deben realizarse las tareas habituales en la construcción de una aplicación
genérica (escritura del código fuente, compilación y enlazado, etc.) cada vez que se quiera modificar el comportamiento de la misma o los parámetros de uso de las bibliotecas
utilizadas. Tras este proceso, se necesita distribuir el resultado de la construcción a los
nodos correctos y ejecutar cada aplicación en el nodo adecuado y momento adecuado.
5
1. Introducción
Este procedimiento a pequeña escala puede realizarse de forma manual. Sin embargo,
cuando se trata de escenarios “masivos” en entornos de área amplia, como el que se
propone en la Sección 1.2.2, aparecen problemas que este proyecto trata de resolver. Estos
problemas son:
1. Aumento del tiempo de desarrollo con el tamaño del escenario.
2. Garantı́a de la consistencia relacionada con la probabilidad de cometer errores de
programación en si, por un lado, y, por otro, en la correcta asignación de entidades
DDS a nodos.
3. Dificultad para reproducir pruebas.
El presente proyecto tratará de dar solución a los problemas que se han descrito.
Ası́ pues, como resultado final se deberá proporcionar al usuario, el desarrollador de
un escenario distribuido de gran tamaño, un conjunto de herramientas que le permita:
Automatizar la mayor parte posible de las tareas anteriormente enumeradas.
Minimizar la tarea de programación del diseñador de pruebas y liberarle, en la
medida de lo posible, del conocimiento profundo del API de DDS. De esta forma se
pretende que el usuario se centre en el diseño del sistema y las pruebas, y no en las
labores de desarrollo.
Coordinar la realización y dar consistencia a las pruebas sobre escenarios en entornos reales.
1.4.
Objetivos
Descrito ya el problema, en este apartado se detallarán los objetivos que persigue el
proyecto:
Proporcionar una manera flexible de describir escenarios DDS. Se trata de proporcionar al usuario un conjunto de herramientas que permitan describir un escenario distribuido compuesto por aplicaciones que se comunican utilizando un middleware DDS. Este
objetivo se divide en tres subobjetivos:
Diseñar un lenguaje de descripción de aplicaciones, esto es, especificar un lenguaje que permita al usuario describir los elementos que conforman el escenario y sus
parámetros de configuración. Como resultado, se espera facilitar la descripción de
aplicaciones minimizando al mismo tiempo los conocimientos necesarios del API
de DDS.
6
1.5. Recursos
Proporcionar una interfaz de descripción del comportamiento de las aplicaciones. Este objetivo complementa el anterior, puesto que añade a la descripción de
entidades DDS en si, la descripción del comportamiento que éstas tendrán en el
escenario.
Proporcionar al usuario una metodologı́a de desarrollo rápido de aplicaciones
DDS. El proyecto ofrece una alternativa al desarrollo tradicional de aplicaciones4 ,
ası́ pues, deberá proponerse una nueva metodologı́a de desarrollo de aplicaciones
DDS. Dicha metodologı́a establecerá los pasos necesarios para la construcción y
despliegue de un escenario distribuido utilizando el sistema desarrollado.
Proporcionar mecanismos de control sobre un escenario DDS. El sistema debe proporcionar interfaces de interacción con el escenario de forma que el usuario sea capaz
de:
Distribuir la descripción del escenario entre los nodos y asignar las aplicaciones
DDS adecuadas a los nodos adecuados.
Controlar de manera conjunta los procesos de creación o destrucción de las entidades DDS que componen el escenario, esto es, el ciclo de vida de las entidades DDS.
Controlar de manera global el comportamiento que tendrán las diferentes entidades
DDS del escenario.
1.5.
Recursos
Definido el problema, en esta sección se describen los recursos humanos, de hardware
y de software que se emplearán en el desarrollo del proyecto.
1.5.1.
Humanos
Prof D. Juan Manuel López Soler , profesor del Departamento de Teorı́a de la Señal,
Telemática y Comunicaciones de la Universidad de Granada, como tutor del proyecto.
D. Javier Sánchez Monedero , alumno de la Escuela Técnica Superior de Ingenierı́as
Informática y de Telecomunicación de la Universidad de Granada, que será el encargado de realizar dicho proyecto siguiendo las directrices definidas por el tutor
del mismo.
4
Entendemos como desarrollo tradicional al que se realiza programando, compilando y distribuyendo aplicaciones.
7
1. Introducción
1.5.2.
Hardware
Para el desarrollo del proyecto se dispone de:
Ordenador portátil.
Impresora láser.
Conexión 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 depuración de problemas de memoria y rendimiento de programas
Valgrind[21].
Alleyoop[22], interfaz gráfica para Valgrind.
Biblioteca de distribución 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 diferenciadas:
1. Revisión del estado del arte: en esta fase se realizará un estudio del campo de middleware y tecnologı́as relacionadas con DDS, se estudiarán alternativas en la descripción no programática de aplicaciones, ası́ como de los alternativas en despliegue de
aplicaciones distribuidas. Para esto se utilizarán todos los recursos bibliográficos y
electrónicos disponibles.
8
1.7. Restricciones
2. Especificación: del proyecto para delimitar su ámbito. Para esto se identificarán objetivos y se capturarán los requerimientos funcionales y no funcionales del sistema.
Tras esta fase se procederá a la estimación de la planificación temporal.
3. Análisis: de los requerimientos para sentar las bases de una solución al problema.
Esta fase incluye la identificación a alto nivel de las necesidades del sistema. Esto
incluye la especificación el lenguaje de descripción de escenarios.
4. Diseño: del sistema. Esta etapa incluye el diseño arquitectónico del sistema, la especificación de operaciones, el diagrama de clases del sistema, etc.
5. Implementación: esta etapa consiste en la implementación de los modelos descritos
en las fases anteriores.
6. Evaluación: durante esta fase se evaluarán las prestaciones de las herramientas desarrolladas en entornos reales, valorando especialmente su flexibilidad.
7. Documentación: coincidente en el tiempo con las etapas anteriores, se procederá a la
generación de la documentación de los resultados pertinentes.
1.7.
Restricciones
Las restricciones inherentes al proyecto se clasifican en factores dato y factores estratégicos. Ambos factores influyen a la hora de tomar decisiones y delimitan el desarrollo del
proyecto.
1.7.1.
Factores dato
Se expondrán en esta sección una serie de factores limitativos que condicionan la realización del proyecto. Estas restricciones (también conocidas como factores dato) son limitaciones impuestas que no pueden ser modificadas a lo largo del desarrollo del proyecto,
y cuya imposición no tiene por qué estar justificada. Para el presente proyecto son:
Económicos: economizar el coste del sistema, tanto hardware como software.
Tiempo: el proyecto deberá estar finalizado para septiembre de 2008.
Hardware: para el desarrollo y simulación 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. Introducción
• Plataforma de desarrollo. El desarrollo del proyecto deberá realizarse sobre una
de las plataformas (combinación de arquitectura, sistema operativo y versiones
de compilador soportadas por NDDS). Considerando el hardware y software
habitual en un ordenador personal, una combinación de plataforma de desarrollo aceptable es i86Linux2.6gcc3.4.3, que se traduce en arquitectura Intel 86,
sistema operativo Linux 2.6 y la versión 3.4.3 del compilador GCC.
• Lenguaje de descripción de aplicaciones. NDDS ya utiliza XML para la configuración de algunas de sus funcionalidades. Es un requerimiento que la descripción de aplicaciones DDS se realice mediante el lenguaje XML para posibilitar la integración de funcionalidades actuales y futuras.
• Implementación del parser. En la actualidad, el procesado de ficheros XML que
se hace en el producto NDDS utiliza la biblioteca EXPAT[24] para construir el
reconocedor. Es un requerimiento utilizar esta biblioteca para implementar el
procesador de ficheros XML dada su portabilidad a arquitecturas utilizadas
por NDDS, entre otras caracterı́sticas.
• Lenguaje de programación de la aplicación. El lenguaje de programación del
prototipo será el lenguaje C, ya que es el lenguaje que debe utilizarse con la
biblioteca EXPAT. Además, dada la manera en que integran las interfaces para
diferentes lenguajes de programación en NDDS, el desarrollo base debe hacerse siempre en C.
Humanos: en el desarrollo del proyecto participarán un alumno y el director del
proyecto.
1.7.2.
Factores estratégicos
Los Factores estratégicos son factores que no dependen de la naturaleza del problema
y, por tanto, permiten tomar decisiones entre varias alternativas, lo que abre la posibilidad de mejorar aspectos como por ejemplo los costes, la calidad o la extensibilidad del
proyecto.
Para este proyecto, consideramos como decisiones estratégicas:
Plataforma de desarrollo. Se ha elegido Ubuntu GNU/Linux como plataforma de desarrollo por ser un entorno libre e ideal para el desarrollo de aplicaciones. Muchas
herramientas y bibliotecas son compatibles con este sistema operativo, entre ellas
NDDS.
Entorno de programación. Se ha elegido el entorno de desarrollo libre para C/C++
Eclipse C/C++ Development Tooling - CDT. Eclipse es un entorno de desarrollo excelente, además de por sus funcionalidades como editor y gestor de código, por
integrarse a la perfección con otras herramientas libres como el depurador GDB, la
herramienta GNU make y el compilador GCC. Además, Eclipse puede extender su
funcionalidad para el tratamiento de ficheros XML.
10
1.8. Antecedentes y estado del arte
Depuración de errores y rendimiento. Se incluirán opciones de compilación condicional
para activar mensajes de depuración en el código, a fin de facilitar la detección
de errores durante el desarrollo. Además, se utilizará la herramienta Valgrind para
comprobar la correcta liberación de recursos en los momentos adecuados.
Portabilidad del desarrollo. Para asegurar la portabilidad de desarrollo a otras plataformas a las que no tenemos acceso, como sistemas operativos de tiempo–real, se
utilizará de manera estricta el estándar del lenguaje C. El uso de algunas opciones
de activación de advertencias del compilador puede ayudar a esto.
Construcción del analizador sintáctico. Como se explicará durante el presente documento, se implementará un analizador de lenguaje semi-natural para facilitar la
interacción del desarrollador con el escenario. Este analizador sintáctico se construirá utilizando las herramientas Lex y Yacc ya que, no sólo facilitarán la tarea, sino
que generarán un analizador óptimo, robusto y fácilmente extensible.
1.8.
Antecedentes y estado del arte
El problema abordado se centra inicialmente en el prototipado rápido de aplicaciones
y reutilización de componentes software. Desde este punto de vista, se pueden encontrar
ideas de interés en algunas herramientas de automatización de pruebas distribuidas para
DDS. Estas herramientas pueden configurarse, en mayor o menor medida, para adaptarse al tipo de prueba que el usuario quiere realizar.
Para situar adecuadamente el trabajo realizado, en el apartado siguiente se examinan
los antecedentes en sistemas de distribución de datos. A continuación se presentará brevemente el lenguaje XML y, en último lugar, se examinarán los trabajos más recientes en
la configuración y prototipado de aplicaciones DDS.
1.8.1.
Antecedentes en distribución de datos
El desarrollo de aplicaciones distribuidas ha merecido grandes esfuerzos de investigación durante ya varias décadas. Entre las herramientas desarrolladas es de especial
mención la API Berkeley Socket Distribution[25]. A partir de este punto, se han propuesto
numerosos middleware, especificados para verificar los objetivos de simplificar los costes
de desarrollo, optimizar las prestaciones y la utilización de los recursos de la red, ofrecer
mayor escalabilidad, fiabilidad y disponibilidad, ası́ como potencial interoperatividad
entre diferentes plataformas.
Mencionar especı́ficamente la librerı́a RPC (Remote Procedure Call[26]), desarrollada
para facilitar la ejecución de procedimientos remotos. Recientemente, RPC ha evolucionado para aprovechar la extensibilidad de XML, dando lugar a XML-RPC, middleware
que tı́picamente hace uso del protocolo HTTP para transportar las transacciones. El intercambio de mensajes basados en XML sobre HTTP[27] ha dado lugar al protocolo SOAP
11
1. Introducción
(Simple Object Access Protocol)[28], el cual es parte fundamental de la pila de protocolos
que da soporte a los ası́ denominados Web Services[1], definidos por el consorcio W3C.
En esta aproximación, se utiliza WSDL (Web Services Description Language)[2] para describir la interfaz a los objetos remotos. Es también destacable la API RMI (Remote Method
Invocation)[29] para Java, la cual proporciona una funcionalidad parecida a RPC. Finalmente, no puede faltar mención a la arquitectura CORBA (Common Object Request Broker
Architecture)[4] definida por el consorcio OMG. CORBA proporciona una aproximación
basada en objetos, accesibles de forma remota a través de la interfaz IDL (Interface Definition Language)[30].
Todas las tecnologı́as anteriormente citadas tienen en común la adopción del ası́ denominado paradigma cliente-servidor. Alternativamente, y especialmente diseñado para
su utilización en aplicaciones con requisitos de tiempo-real, se ha propuesto middleware
que adopta un paradigma distinto al anterior basado en una metodologı́a publicaciónsubscripción. Este modelo se fundamenta en el intercambio ası́ncrono de mensajes. Aquı́,
las entidades generadoras declaran los temas que están dispuestas a publicar, y las consumidoras se subscriben a los temas que les sean de interés. Cuando un productor publica
un dato en un tópico dado, todos los subscriptores lo recibirán de forma transparente a la
aplicación. De esta forma, este paradigma adopta una aproximación denominada datacentric, ya que desacopla (en el tiempo y el espacio) la interacción entre los participantes
(consumidores o generadores de información), y se enfoca en la distribución de los datos,
con independencia de la localización y el instante del origen o del destino de los mismos.
Para la distribución de datos de acuerdo con un paradigma publicación–subscripción, la
OMG ha especificado recientemente el estándar DDS (Data Distribution Service for RealTime Systems)[6] lo que, dada la solvencia y reconocimiento de esta institución, ha venido
a consolidar definitivamente este nuevo paradigma o modelo de interacción alternativo.
1.8.2.
El lenguaje XML
Antecedentes y relevancia de XML
XML son las siglas en inglés de Extensible Markup Language (“lenguaje de marcas
ampliable”)[31]. Es un metalenguaje extensible de etiquetas desarrollado por el W3C
(World Wide Web Consortium) y proviene de un lenguaje, inventado por IBM en los años
setenta, llamado GML (General Markup Language), que surgió por la necesidad que tenı́a
la empresa de almacenar grandes cantidades de información. XML se propone como un
estándar para el intercambio de información estructurada entre diferentes plataformas.
Se puede usar en bases de datos, editores de texto, hojas de cálculo, etc.
XML es una simplificación y adaptación del SGML que permite definir la gramática
de lenguajes especı́ficos. Por lo tanto XML no es realmente un lenguaje en particular, sino
una manera de definir lenguajes para diferentes necesidades. Ejemplos de estos lenguajes
que usan XML para su definición son XHTML, SVG o MathML.
Una manera de describir la gramática de un lenguaje especı́fico basado en XML es
12
la definición de tipo de documento (DTD, Document Type Definition), que es una descripción
de estructura y sintaxis de un documento XML. DTD se incluye dentro del estándar de
XML inicial, aunque el propio W3C ha propuesto XSD (XML Schema Definition)[32] como
alternativa que supera las limitaciones de DTD.
XML presenta varias ventajas como tecnologı́a:
Se basa en estándares internacionales y como tal es un estándar abierto.
Puede representar estructuras de datos comunes en el campo de la informática:
registros, listas y árboles.
Los algoritmos de análisis sintáctico son simples, eficientes y consistentes dadas sus
restricciones de sintaxis y análisis.
XML se utiliza se utiliza masivamente para el almacenamiento y procesamiento de
documentos.
La adopción de XML en la industria e campos de investigación es alta, y es por
ello que existen multitud de herramientas libres para trabajar con XML desde la
generación de documentos hasta el procesado de la información almacenada en
XML.
Un lenguaje basado en XML puede ser fácilmente modificado de manera incremental y sin perder compatibilidad hacia atrás.
La validación de documentos mediante lenguajes de esquema como DTD o XSD
facilita, entre otras tareas, las relacionadas con la especificación y construcción de
software.
La estructura jerárquica de XML se utiliza con éxito para representar conocimiento
en multitud de campos de trabajo, si bien esta estructura jerárquica no siempre es
válida para un dominio de conocimiento.
Desventajas de XML y alternativas
Existen multitud de debates sobre las ventajas de XML que ponen en relieve circunstancias ante las cuales el uso de XML presenta más desventajas que ventajas[33]. Algunas
de estas son:
La sintaxis de XML es redundante o grande, en términos de tamaño, en comparación con representaciones de datos alternativos, especialmente si se utiliza para
representar datos tabulares. Esta redundancia afecta al rendimiento de las aplicaciones al aumentar el tamaño de almacenamiento y transferencia, ası́ como al coste
de procesamiento.
13
1. Introducción
La sintaxis presenta sobrecarga de información para un lector humano en comparación con otros formatos de transferencia de datos.
El modelo jerárquico de representación del conocimiento es limitado en comparación con otras alternativas, como por ejemplo, las orientadas a grafos.
La expresión de solapamientos entre relaciones de los nodos requiere un esfuerzo
extra.
Promueve el uso de estructuras de datos no relacionales (datos no normalizados).
XML introduce un fuerte acoplo entre la representación elegida y el procesamiento
de la información, a diferencia de las alternativas de almacenamiento relacional y
SQL.
La mayor parte de las desventajas, como podemos ver, están relacionadas con la validez de XML para representar datos completos y relaciones entre estos datos. Especialmente para representar grandes cantidades de datos que deben procesarse y/o transferirse a través de una red, XML presenta una sobrecarga en el tamaño que ocupa la
información al serializarse. En este sentido, han aparecido alternativas como JSON (JavaScript Object Notation, notación de objetos de JavaScript)[34][35]. JSON es un formato
ligero para el intercambio de datos que puede sustituir a XML para la representación y
transferencia de datos. JSON mejora notablemente el espacio de almacenamiento y ancho
de banda durante la transferencia de información, aunque, a cambio, presenta limitaciones respecto a XML[36].
1.8.3.
Herramientas para el desarrollo de aplicaciones DDS
Soporte para DDS de la aplicación Enterprise Architect
La empresa Sparx Systems[37] ha desarrollado un complemento de soporte de DDS
para su programa de diseño software Enterprise Architect llamado MDG technology for
DDS [38].
Esta herramienta es capaz de generar código válido para su compilación mediante la
especificación de la aplicación utilizando de la tecnologı́a MDA (Model-driven architecture,
arquitectura dirigida por modelos)[39].
La arquitectura dirigida por modelos es un nuevo enfoque para el diseño y desarrollo de
sistemas software propuesto por la OMG. MDA es una arquitectura que proporciona un
conjunto de guı́as para estructurar especificaciones expresadas como modelos.
Bajo este enfoque, la funcionalidad del sistema se define mediante los modelos independientes de plataforma (PIM, Platform-Independent Model) utilizando un lenguaje especı́fico
para un dominio o de propósito general. Para diversas plataformas como CORBA, entornos Web o DDS se define un modelo de definición de plataforma (PDM, Platform Definition
14
Figura 1.2: Especificación de entidades DDS con Enterprise Architect
Model). Un modelo PDM es capaz de traducir los modelos PIM en modelos especı́ficos de
plataforma (PSM, Platform-Specific Models). Los PSM pueden ser ejecutados directamente
en un ordenador.
Enterprise Architect permite especificar los modelos a partir de una serie de formularios y diagramas UML (ver Figura 1.2). A partir de esta representación genera código
DDS listo para compilarse en la plataforma NDDS.
Enterprise Architect es interesante como forma de especificación de parámetros para
las entidades DDS sin especificar el comportamiento de estas. Al fin y al cabo, lo que genera esta herramienta es el esqueleto de una aplicación distribuida sobre la que empezar
el desarrollo.
DDS Benchmark Project
El grupo de investigación Distributed Object Computing (DOC) Group for Distributed
Real-time and Embedded (DRE) Systems[40] es un grupo compuesto por las universidades
15
1. Introducción
estadounidenses de Vanderbilt, Washington y California. Este grupo ha desarrollado una
herramienta para comparar el rendimiento de diferentes implementaciones del estándar
DDS llamada DDS Benchmark Project[41].
DDS Benchmark Project tiene como objetivo evaluar las siguientes caracterı́sticas de un
producto DDS:
El rendimiento respecto a la latencia (latency) y tasa de transferencia (throughput).
La facilidad de programación de las interfaces ofrecidas.
Las diferencias de rendimiento respecto a otros sistemas de publicación–subscripción.
Este conjunto de herramientas permiten al usuario configurar la ejecución de pruebas distribuidas. Este sistema cuenta con varias aplicaciones DDS y cada aplicación tiene
una serie de entidades DDS predefinidas. Estas entidades admiten una serie de parámetros que se especifican mediante ficheros XML, aunque estos parámetros sólo incluyen
la frecuencia de publicación de datos, el tamaño de los datos y algunos parámetros de
configuración QoS para DDS. No se puede especificar, por ejemplo, el tipo de datos que
se publica, ni combinar varios de estos tipos en un mismo escenario.
La distribución del escenario se realiza ubicando una serie de ficheros ejecutables en
un sistema de ficheros de red (NFS en concreto) al que todos los nodos tienen acceso.
Por otro lado, la creación de entidades DDS y su actividad se controlan mediante una
serie de guiones que se ejecutan en cada nodo que participa en la prueba para ejecutar el
programa adecuado. El acceso a los nodos se realiza mediante conexiones SSH.
El punto fuerte de DDS Benchmark Project es que crea una capa software que adapta los algoritmos genéricos de cada prueba a la interfaz de programación de cada producto DDS, lo que permite desarrollar pruebas idénticas para comparar el rendimiento
de diferentes implementaciones de DDS. En la actualidad el proyecto funciona con los
productos NDDS[8], OpenSplice[10] y OpenDDS[12] y los resultados experimentales son
públicos[42].
1.9.
Aproximación a la solución propuesta
Antes de entrar en el desarrollo del proyecto, a modo de resumen, se ofrece una visión
general de la solución propuesta.
La motivación del proyecto se puede resumir como la búsqueda de una solución al
prototipado rápido y masivo de aplicaciones DDS. Ésta solución plantea una serie de
retos.
El primer reto corresponde a la descripción de aplicaciones que componen el escenario.
Para ello, se propone dividir la descripción del escenario en dos modelos:
16
1.9. Aproximación a la solución propuesta
El Modelo Estático describe las entidades DDS mediante un lenguaje basado en XML
que especificará tanto las entidades en sı́, como las relaciones entre éstas.
El Modelo Dinámico describe el comportamiento de las entidades DDS mediante un
lenguaje de programación.
Los Modelo Estático y Dinámico son independientes. Esto es, el Modelo Estático de
una entidad podrá asociarse a un Modelo Dinámico distinto en momentos diferentes. Esto
permitirá cambiar por completo el comportamiento de una aplicación distribuida cambiando el Modelo Dinámico de sus entidades.
La Figura 1.3 representa los conceptos de Modelo Estático, Modelo Dinámico y cómo un
escenario puede cambiar su comportamiento reemplazando el Modelo Dinámico de sus
entidades.
El segundo reto corresponde al despliegue y ejecución del escenario. Para ello se dividen los nodos de la red en dos tipos: el nodo “Command Master” se encarga de publicar
instrucciones para el despliegue del escenario, mientras que los nodos que del tipo “Command Slaves” estarán subscritos a las instrucciones que distribuya este nodo. El problema
de la distribución de instrucciones se resuelve utilizando el propio middleware DDS.
Los nodos “Command Slaves” desarrollarán aplicaciones ejecutando las órdenes que
reciban los modelos estáticos y dinámicos que se les asocien.
El último problema a resolver se refiere a la interacción del desarrollador con el escenario mediante una gramática semi-natural. Esta gramática permitirá especificar las
órdenes que se quiere hacer llegar a los nodos del escenario. De esta forma se ofrece una
interfaz para controlar el despliegue y permite una visión global del escenario.
En resumen, se pretende simplificar la tarea del despliegue de uno o varios escenarios
DDS de grandes dimensiones a:
La descripción del escenario o escenarios mediante modelos estáticos y dinámicos.
El uso los nodos “Command Master” y “Command Slaves” para desarrollar estos
escenarios.
El Apartado 5.1, de arquitectura del sistema, profundiza más en las ideas aquı́ expuestas.
17
1. Introducción
18Figura 1.3: Descripción de escenarios DDS mediante los modelos Estático y Dinámico
CAPÍTULO
2
ESPECIFICACIÓN DE REQUISITOS
Este capı́tulo tiene como objetivo identificar el conjunto de requerimientos que el sistema debe de cumplir, diferenciándose en dos tipos:
Requisitos funcionales, que son los que se encuentran orientados a la funcionalidad
que debe desempeñar la aplicación de cara al usuario final.
Requisitos no funcionales, orientados al funcionamiento final de la aplicación. Son requisitos que no tienen que ver con la funcionalidad de la aplicación, sino como se
verá más adelante, están más orientados a caracterı́sticas que debe cumplir el funcionamiento de la aplicación.
El sistema en desarrollo consiste en la creación de un conjunto de herramientas para
el desarrollador de aplicaciones que utilicen DDS. El usuario será, pues, un investigador
o un desarrollador que pretenda comprobar la adecuación del middleware DDS a la red
sobre la que experimenta o sobre el que planea implantar un sistema en producción.
2.1.
Requisitos Funcionales
Descripción de los parámetros de todas las entidades DDS existentes mediante XML.
El punto de partida del proyecto lo constituye la descripción de entidades DDS. Esto se
hará mediante la especificación de todos los parámetros que el API de DDS admite para
la creación de entidades. Estos parámetros pueden ser datos simples u otras entidades
DDS de manera que implı́citamente quede definida la relación de jerarquı́a entre entidades necesaria para que el sistema funcione. Debe tener mención especial la especificación
de los parámetros de calidad de servicio (QoS) que se quieran aplicar a las entidades.
Es un requerimiento que la descripción de todo este conocimiento se haga mediante un
19
documento XML. Este requerimiento implica la definición de tipo de documento (DTD, Document Type Definition) para validar los ficheros XML que el usuario cree.
Creación de un parser o analizador sintáctico para los documentos XML definidos.
Puesto que se va a trabajar con XML, deberá crearse un analizador sintáctico que permita
validar el documento y crear una representación en memoria del mismo que contenga la
información del fichero XML de forma estructurada. Esta estructura en memoria será el
resultado del proceso de análisis sintáctico del fichero. Es un requerimiento que el analizador sintáctico se implemente extendiendo el actual analizador construido sobre la
biblioteca EXPAT (ver 1.7.1 Factores Dato).
Creación de un API de interacción con el documento XML. Deberá proporcionarse
una API que permita al usuario consultar o modificar la información resultante del proceso de análisis sintáctico. Puesto que esta información se almacenará en una estructura
de tipo árbol el API debe permitir operaciones comunes que permitan, partiendo de un
nodo, acceder a nodos padres, hermanos o hijos. Esto incluye ofrecer al usuario métodos
especializados de recorrido del árbol, esto es, dado, por ejemplo, un Tema, debe poder realizarse una operación de acceso directo al nodo del Participante del que es hijo. Complementando a las operaciones de navegación por el árbol, deben proporcionarse métodos
de acceso a los datos almacenados en cada nodo.
Creación un API que permita integrar métodos escritos por el usuario en el sistema.
Como ya se argumentó en la redacción de los Objetivos (1.4), para la especificación del
comportamiento será necesario el uso de métodos que describan programáticamente la
actividad de cada entidad DDS. Será necesario crear una interfaz de integración de estos
métodos del usuario en el sistema, ası́ como definir los lı́mites que el usuario tendrá para
escribir este código.
Interfaces de programación para la creación y destrucción de entidades DDS. Se debe
proporcionar una interfaz de programación que permita la creación y destrucción de las
entidades DDS descritas en el documento XML dado un identificador de la entidad o de
entidades padres a las que pertenece.
Interfaces de programación para la asignación y control del comportamiento de una
entidad DDS. Se debe proporcionar una interfaz de programación que permita la asignación de métodos y listeners a entidades DDS descritas en el documento XML dado un
identificador de la entidad o de entidades padres a las que pertenece.
Interfaz de usuario para coordinar el ciclo de vida y actividad de las entidades DDS
del escenario. Puesto que una de las aplicaciones directa del proyecto es la experimen20
2.2. Requisitos no Funcionales
tación escenarios DDS compuestos de muchas entidades, será necesario proporcionar al
usuario una interfaz de interacción con el escenario. Esto es decidir en qué momento se
crean todas o algunas de las entidades DDS, ası́ como el momento en el que se destruyen
o el momento en el que inician su actividad. Podemos adelantar que esta interfaz se encargará de producir órdenes que los nodos del escenario deberán procesar correctamente.
2.2.
Requisitos no Funcionales
Ejecución de tareas concurrentes. La programación de aplicaciones que procesan flujos
de datos diferentes, tanto para leerlos desde la red como para enviarlos a través de la red,
de manera simultánea implica el diseño, programación y prueba del software para la
ejecución de tareas concurrentes de manera correcta.
Rendimiento y consumo de recursos. El uso del proyecto al crear y destruir entidades
DDS, hebras de tareas, etc. conllevará la asignación y liberación constante de recursos.
Ésta deberá hacerse de forma eficaz y eficiente para no degradar las prestaciones de la
máquina donde se ejecuta el proceso y afectar a posteriores usos de la propia aplicación.
Flexibilidad. El conjunto de herramientas desarrolladas y la biblioteca de funciones
deberán ser flexibles para permitir la descripción de la mayor diversidad de escenarios
posibles.
Portabilidad. Se deberán cuidar los aspectos de portabilidad respecto de sistemas operativos, compiladores, versiones del compilador y respecto del estándar DDS.
Fácil instalación. Puesto que las herramientas deberán distribuirse a muchos nodos
de red, el procedimiento de instalación de las herramientas deberá ser lo más sencillo
posible.
Transparencia y abstracción. Deberá abstraerse al usuario al máximo respecto a las tareas de programación y la especificación de parámetros de las entidades DDS, ası́ como
de la difusión de órdenes.
21
22
CAPÍTULO
3
PLANIFICACIÓN
Una vez obtenidos los requisitos del sistema, se presenta una estimación inicial de las
tareas en que se descompone el desarrollo del proyecto.
La planificación del proyecto se gestiona con ayuda de la aplicación Planner[43]. La
planificación se hizo mediante un diagrama de Gantt. Debido a el tamaño de este tipo
de diagramas sólo se mostrará un detalle del mismo a modo de ejemplo (Ver Figura 3.1),
mientras que la planificación completa se muestra en forma de tabla de datos.
La estimación inicial de tareas y duración de las mismas se muestra en la Figura 3.2.
23
3. Planificación
Figura 3.1: Detalle del diagrama de Gantt de la planificación inicial del proyecto
24
Figura 3.2: Planificación inicial del proyecto en formato tabular
25
3. Planificación
26
CAPÍTULO
4
ANÁLISIS DE REQUISITOS
Una vez descrito el problema mediante la identificación de requisitos, funcionales y
no funcionales, el siguiente paso es realizar un análisis más detallado de estos. En este
capı́tulo se analizan los requerimientos de la aplicación mediante la identificación y descripción gráfica y textual de casos de uso. De esta forma obtendremos una descripción a
alto nivel de las operaciones que debe realizar el sistema.
Además, se abordan las necesidades de la gramática de interacción con el escenario,
ası́ como la definición de formato de ficheros XML.
4.1.
Casos de uso del sistema
Cada caso de uso proporciona uno o más escenarios que indican cómo deberı́a interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo especı́fico.
4.1.1.
Identificación de los actores del sistema
Usuario Se identifica con el usuario de la aplicación, que en este caso es el desarrollador
de aplicaciones distribuidas que quiere desplegar e interaccionar con el servicio de
distribución de datos. El usuario interactúa con el sistema para distribuir la descripción del escenario y controlar el ciclo de vida y actividad de las entidades DDS
que componen el escenario.
Nodo El rol de este actor se identifica con un nodo que participa en el sistema distribuido. Un actor del tipo Nodo interactúa con el Usuario, del que obtiene las acciones a
realizar, y mantiene contacto con el actor DDS Middleware para desarrollar las tareas
que le asigne el usuario.
27
Figura 4.1: Diagrama de casos de uso del sistema
DDS XMLParser El rol de este actor se identifica con el software encargado de procesar
los ficheros XML que describen el escenario. Como resultado de este procesamiento
el DDS XMLParser devolverá el árbol que representa el escenario.
DDS Middleware El rol de este actor se identifica con el software encargado de gestionar la funcionalidad relacionada con un servicio de distribución de datos. Conceptualmente, cada Nodo mantendrá contacto con el actor DDS Middleware para realizar
las 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 abstracción, la interacción entre los tres actores del sistema y en
qué casos participa cada uno.
28
4.1. Casos de uso del sistema
4.1.3.
Listado de los casos de uso
A continuación se describen brevemente los casos de usos identificados en la Figura
4.1. Nótese que la descripción se hace a muy alto nivel. La descripción de estas operaciones se refinará en capı́tulos posteriores.
Cargar escenario. Es un caso de uso base. El objetivo de este caso de uso es hacer llegar
la descripción del escenario a todos los nodos que participan en la aplicación distribuida, y que estos seleccionen la aplicación que les corresponda. Este caso de uso
se compone de los casos de uso distribuir escenario e interpretar escenario, descritos a
continuación.
Distribuir escenario. Este caso de uso está incluido en el caso anterior. Hace referencia a
la distribución del escenario que el usuario quiere asignar a los nodos participantes.
Interpretar escenario. Este caso de uso está incluido en el caso Cargar escenario. Representa las acciones que deben desarrollarse en cada nodo ante la recepción del escenario que se está distribuyendo. Tı́picamente un nodo que recibe la descripción
de un escenario seleccionará una aplicación de entre las descritas en el escenario,
dicha selección se hará en base a la información de asignación de aplicaciones a
nodos que se etiquete en el fichero.
Gestión entidades DDS. Caso de uso base. Abarca todas las operaciones relacionadas
con la gestión de la creación y destrucción de las entidades DDS. En él participan todos los actores ya que las entidades se crean y destruyen ante peticiones del
Usuario que cada Nodo interpreta. El Nodo se comunicará con el actor DDS para
la realizar las operaciones de gestión pertinentes.
Crear entidad DDS. Este caso de uso extiende al caso de uso Gestión entidades DDS. La
operación consiste en la orden de creación de una entidad DDS dado el identificador de la entidad DDS XML que la envuelve. El Usuario proporciona un identificador de la entidad DDS XML que será utilizado por cada Nodo para buscar esa
entidad dentro de la aplicación que tiene asignada. Los Nodos cuya aplicación contengan la entidad DDS XML buscada crearán la entidad DDS que se describe en la
misma.
Destruir entidad DDS. Este caso de uso extiende al caso de uso Gestión entidades DDS.
El objetivo del caso es destruir las entidades DDS a partir de un identificador que
proporciona el Usuario. La localización de la entidad se hace de manera similar al
caso de uso Crear entidad DDS. La destrucción de una entidad implica el cese de su
actividad.
Gestión del comportamiento. Es un caso de uso base cuyo objetivo es el control del comportamiento que las entidades tienen en la red.
29
Iniciar comportamiento. Este caso de uso extiende al caso Gestión del comportamiento para controlar el inicio del comportamiento de las entidades. La localización de la
entidad sobre la que aplicar la operación se realiza como en Crear entidad DDS. Cada Nodo deberá gestionar correctamente la ejecución paralela de tareas de cada
entidad DDS que pertenezca a la aplicación que está desarrollando.
Parar comportamiento. Este caso de uso extiende al caso Gestión del comportamiento para
controlar el fin de la actividad de una entidad. El funcionamiento es el contrario a
Iniciar comportamiento.
4.2.
Gramática de interacción con el escenario
Una de las partes esenciales del proyecto es la interacción que el desarrollador debe
tener con el escenario. Como se comentó en la Sección 1.9, se ha optado por un método de
interacción con el escenario basado un lenguaje semi-natural. Este lenguaje de interacción
debe ser diseñado considerando los casos de uso presentados y las ideas aportadas en el
Apartado 1.9.
La gramática debe proporcionar mecanismos que hagan que el acceso al escenario
DDS por parte del usuario sea lo más sencillo posible. Además de sencilla, debe de ser
intuitiva, para que la curva de aprendizaje sea mı́nima. Es por ello que las palabras que
se reconocerán estarán escritas en inglés y tratarán de coincidir con las palabras representativas de acciones similares en otros sistemas como “load” para indicar la carga de
un fichero o “create” para indicar una acción de creación.
Tras estas consideraciones, la gramática debe soportar las siguientes operaciones:
Carga, distribución y asignación de aplicaciones. Esta operación deberá distribuir el
fichero XML que describe el escenario. La participación en esta operación depende
del actor:
• La aplicación de interacción con el usuario deberá leer el fichero que se le proporciona y distribuirlo, mediante el uso de DDS, al resto de nodos de la red. Si
es necesario, el fichero deberá ser dividido en fragmentos para su transmisión
dadas las limitaciones de NDDS en este sentido[23].
• Los nodos de la red deberán leer, reconstruir y procesar la descripción del
escenario para seleccionar una aplicación.
Creación y destrucción de entidades DDS dado un identificador de una entidad.
Creación y destrucción de todas las entidades DDS del escenario. En este caso es obvio
que no se necesita identificador alguno.
Inicio y parada de la actividad de entidades DDS dado un identificador de una entidad.
30
4.2. Gramática de interacción con el escenario
Inicio y parada de la actividad de todas las entidades DDS del escenario. En este caso es
obvio que no se necesita identificador alguno.
Liberación de recursos y finalización de la ejecución. El sistema debe proveer de una
manera de terminar todas las aplicaciones remotas. Las aplicaciones deberán liberar
todos los recursos en uso antes de finalizar la ejecución.
Aclarar que una instancia DDS sobre la que aplicar una orden queda identificada por
el nombre del objeto DDS XML que la envuelve más un número que indica a qué instancia, de entre las descritas por el objeto DDS XML, se aplica la operación.
4.2.1.
Definición de la gramática
Una vez que descritas las operaciones que debe soportar la gramática estamos en
disposición de especificarla para dar soporte a estas operaciones. La definición de la
gramática se realizará mediante la notación BNF (Backus-Naur form) por ser la forma de
especificación más conocida. El Listado 4.1 muestra esta gramática en BNF.
<commands> ::= <commands> | <command>
<command> ::=
LOAD <string> |
CREATE <xml_entity_id> <dds_instance_number> |
DESTROY <xml_entity_id> <dds_instance_number> |
START <xml_entity_id> <dds_instance_number> |
STOP <xml_entity_id> <dds_instance_number> |
CREATEALL | DESTROYALL | STARTALL | STOPALL |
TERMINATE
<xml_entity_id> ::= <string>
<dds_instance_number> ::= [0-9]*
<string> ::= [a-zA-Z\._ 0-9]*
Listado 4.1: Gramática BNF definida para interacción con el escenario
El siguiente paso es identificar cada tipo de orden o comando con cada una de las
operaciones que debe soportar nuestra aplicación:
<commands> Es el sı́mbolo inicial de la gramática. Cada lı́nea de texto escrita en el
terminal de entrada a la aplicación se considerará como una nueva orden.
<command> Aglutina al conjunto de órdenes que son reconocidas. Estas son:
LOAD <string>: cargar y distribuir el escenario cuyo fichero se indica como parámetro. Los siguientes parámetros se aplican bajo la premisa de haber
cargado un escenario.
CREATE <xml_entity_id> <dds_instance_number>: crear la entidad
con el primer parámetro como identificador y segundo parámetro como número de instancia DDS.
31
DESTROY <xml_entity_id> <dds_instance_number>: destruir la entidad con el primer parámetro como identificador y segundo parámetro como
número de instancia DDS.
START <xml_entity_id> <dds_instance_number>: iniciar el comportamiento de la entidad con identificador <xml entity id> y número de instancia DDS <dds_instance_number>.
STOP <xml_entity_id> <dds_instance_number>: detener el comportamiento de la entidad con identificador <xml entity id> y número de instancia DDS <dds_instance_number>.
CREATEALL: crear todas las entidades del escenario.
DESTROYALL: destruir todas las entidades del escenario.
STARTALL: iniciar el comportamiento de todas las entidades del escenario.
STOPALL: detener el comportamiento de todas las entidades del escenario.
TERMINATE: destruye todas las entidades, libera recursos y finaliza la ejecución en todos los nodos del escenario.
4.2.2.
Estructura de datos de órdenes
Para poder transmitir datos en DDS, estos deben definirse previamente mediante el
formato IDL[30]. Como se ha mencionado, las órdenes se transfieren a todos los nodos
participantes utilizando un tema de control creado para el middleware NDDS, ası́ que debemos definir el tipo de datos asociado al tema de control.
El Listado 4.2 presenta el fichero IDL correspondiente al tema de control.
// Valores maximos para los tipos de datos de tamanno variable
const unsigned long CMD_ENTITY_NAME_SIZE_MAX = 256;
const unsigned long CMD_DATA_NAME_SIZE_MAX = 256;
const unsigned long CMD_DATA_MAX_SIZE = 1024;
//@top-level false
enum CommandKind{
CMD_NOCOMMAND,
CMD_START,
CMD_START_ALL,
CMD_STOP,
CMD_STOP_ALL,
CMD_CREATE_ENTITIES,
CMD_CREATE_ENTITIES_ALL,
CMD_DESTROY_ENTITIES,
CMD_DESTROY_ENTITIES_ALL,
CMD_LOAD_SCENARIO,
CMD_TERMINATE,
CMD_EXIT
};
32
4.3. Lenguaje de descripción de aplicaciones
struct Command {
// Tipo de orden que contiene la instancia de
// datos transferida
CommandKind command;
// ID de la entidad XML e ID de la instancia DDS a
// la que aplicar la orden
string <CMD_ENTITY_NAME_SIZE_MAX> entity_name;
short instance_id;
// Variables para la transferencia de datos auxiliares
// como el contenido de un fichero XML
string <CMD_DATA_NAME_SIZE_MAX>data_id;
string <CMD_DATA_MAX_SIZE> data;
};
Listado 4.2: Fichero IDL correspondiente al tema de control
4.3.
Lenguaje de descripción de aplicaciones
El lenguaje de descripción de escenarios será un lenguaje basado en XML, tal y como
se indicó en el Apartado de Factores Dato, y lo describiremos mediante un documento
DTD. En esta sección analizaremos la información necesaria que deben manejar los ficheros XML y que debe quedar reflejada en el DTD, junto con las restricciones en las
relaciones entre entidades DDS.
Comenzaremos introduciendo los atributos comunes a los elementos XML que definiremos más adelante:
name: es el nombre o identificador del elemento XML.
base name: es el nombre de la clase base para un elemento XML. Esto es, la clase de
la que este objeto hereda. Los atributos y etiquetas de la clase base se utilizarán en la
clase que hereda de ella, aunque podrán sobreescribirse.
Los siguientes elementos podrán estar presentes en todas las entidades:
listener: identifica a un listener del Modelo Dinámico que se utilizará con la entidad.
behaviour: dentifica a un método del Modelo Dinámico que define el comportamiento de la entidad.
instances: número máximo de instancias DDS que se pueden crear para el objeto
XML definido.
33
El elemento raı́z del escenario será dds. Este estará compuesto por una o varias aplicaciones DDS tal y como se muestra en el Listado 4.3. A su vez, estas aplicaciones estarán
compuestas por uno o varios participantes de dominio. En el mismo listado también se
muestran 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: Descripción de una aplicación
El Listado 4.4 muestra cómo un participante de dominio está compuesto de varias entidades 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: Descripción de un participante de dominio (Domain Participant)
El Listado 4.5 ilustra la estructura de un tema. No se ha considerado que un tema pueda tener varias instancias puesto que no tiene sentido que haya más de un tema por parti34
4.3. Lenguaje de descripción de aplicaciones
cipante de dominio[44]. Además de los datos comunes a todas las entidades, la descripción
de 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: Descripción de un tema (Topic)
El Listado 4.6 muestra, además de los elementos comunes a otras entidades, cómo un
publicador estará compuesto de varias entidades hijas escritoras. El mismo listado incluye
la definición de un escritor o DataWriter. Destacar que el elemento datawriter topic correspondará a un tema previamente definido. Este tema será el que el DataWriter utilice para
publicar datos.
El Listado 4.7 es el equivalente al Listado 4.6, pero aplicado a los subscriptores y los
lectores de datos.

<!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: Descripción 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: Descripción de un subscriptor (Subscriber)
36
CAPÍTULO
5
DISEÑO
Tras la fase de análisis, en la que se identifica qué se quiere hacer, el siguiente paso es
cómo se debe hacer. Durante este capı́tulo se proporcionan los detalles más relevantes del
diseño de nuestro sistema.
5.1.
Arquitectura del sistema
El propósito de esta sección es describir, desde un punto de vista de alto nivel, la
solución al problema que este proyecto propone. Esta sección de arquitectura del sistema
constituye la parte central del diseño propuesto, y la más importante. En ella se apoya
todo el desarrollo realizado.
5.1.1.
¿Cómo describir un escenario DDS?
El primer reto es encontrar la manera de describir un escenario DDS. Si consideramos
que un escenario DDS es una gran aplicación distribuida que a su vez se compone de
varias aplicaciones, se puede considerar como un primer nivel de descripción a la división del escenario en aplicaciones DDS. Estas aplicaciones DDS podrán ejecutarse en uno
o muchos nodos, y a su vez, en un nodo podrán ejecutarse una o varias aplicaciones DDS
distintas.
Una aplicación DDS estará compuesta por un conjunto de entidades DDS de las identificadas en la Figura A.4 (Apéndice A), estas son: participante de dominio o participante
(Domain Participant o Participant), tema (Topic), publicador (Publisher), subscriptor (Subscriber), escritor (DataWriter) y lector (DataReader).
Las entidades se crean mediante llamadas al API de DDS ofrecida por el middleware.
37
5. Diseño
En esta API, salvo algunos parámetros de calidad de servicio, los parámetros son estáticos,
es decir, una vez que se crea una entidad con unos parámetros estos no pueden modificarse a no ser que la entidad se destruya y se cree de nuevo. La configuración y creación
de entidades DDS constituye la preparación de la infraestructura de comunicación entre
aplicaciones que se va a utilizar.
Por otro lado, las entidades presentan métodos para realizar acciones en el sistema.
Los más utilizados son los métodos para escribir datos en la red, utilizando un DataWriter,
y los métodos para leer datos de la red mediante un DataReader. El uso de estos métodos,
es decir, los datos que se escriben y se leen, representan la actividad del sistema distribuido y constituyen el punto de conexión entre el middleware DDS y el sistema que se
distribuye en si. Por ejemplo, un publicador de información de sensores de temperatura
comprobará los sensores de la plataforma en la que se ejecuta y utilizará los métodos de
publicación para enviar los datos que recogen de los sensores.
Esta división funcional nos lleva a identificar dos modelos necesarios para la descripción de una aplicación DDS: el Modelo Estático y el Modelo Dinámico. El Modelo Estático
se corresponde con la especificación de todas las entidades DDS que servirán de soporte
a la comunicación entre las aplicaciones distribuidas. El Modelo Dinámico define cómo se
comporta cada una de las entidades DDS del escenario.
Nuestra propuesta es describir las aplicaciones DDS mediante sus modelos estático y
dinámico. Ası́, el escenario DDS global lo constituirán un conjunto de aplicaciones descritas con estos dos modelos.
La Figura 5.1 presenta un escenario DDS compuesto de un conjunto de aplicaciones
DDS. Como se puede observar, cada aplicación puede especificarse con los dos modelos
propuestos.
A continuación se describirán las responsabilidades que se asocian a cada modelo
dentro del desarrollo global del escenario.
El Modelo Estático
El Modelo Estático de una aplicación tiene como objetivo describir la arquitectura de
comunicación DDS que utilizará la aplicación distribuida. Esta descripción se hará mediante un fichero XML que especificará los parámetros necesarios de las entidades pertenecientes a la aplicación.
Se definirá, pues, un lenguaje de descripción de aplicaciones basado en XML. Esto incluye la definición del tipo de documento (DTD) y la creación de un analizador sintáctico
que extraiga información del fichero XML para construir el Modelo Estático de la aplicación.
En términos de estructuras de datos, el Modelo Estático de la aplicación es una estructura jerárquica en forma de árbol en la que el nodo raı́z es una aplicación DDS. De esta
aplicación parten los nodos que representan a las entidades DDS que componen la apli38
5.1. Arquitectura del sistema
Figura 5.1: Descripción de aplicaciones DDS mediante los modelos Estático y Dinámico
39
5. Diseño
cación. La estructura jerárquica del árbol, definida en el DTD, respeta las relaciones entre
entidades definidas en el estándar de DDS[6] (ver Apéndice A).
El Modelo Estático se compone de una serie de clases que van a envolver a las entidades DDS. El procesamiento de un fichero XML que describa una aplicación dará lugar a la creación de un árbol cuyos objetos van a ser instancias estas clases. Estas clases reciben el nombre de Entidades DDS XML y existirá una por cada entidad DDS:
DDS XMLDomainParticipant para el participante de dominio, DDS XMLPublisher para el
publicador, etc. La Figura 5.2 muestra un ejemplo de un árbol que representa una aplicación DDS.
Figura 5.2: Árbol del el Modelo Estático para una aplicación DDS
Como puede observarse en la Figura 5.2, el Modelo Estático presenta una interfaz de
navegación por esta estructura en árbol que facilita el recorrido del mismo y el acceso a la
información contenida. Por ejemplo, la clase DDS XMLDataReader tendrá un método llamado get xml subscriber() que permite obtener el nodo del tipo DDS XMLSubscriber
del que cuelga.
Cada entidad DDS XML es capaz de controlar tanto el ciclo de vida (crear y destruir
una entidad) y como el comportamiento de un tipo de entidad DDS (iniciar o detener las
acciones que realiza la entidad). Para ello, gestiona información diversa que agrupamos
de la siguiente manera:
Datos de configuración para la creación de la entidad DDS (identificador de dominio,
nombre del tema. . . ).
Parámetros de conexión de la entidad con el Modelo Dinámico correspondiente.
40
Otros datos, como los relacionados con la gestión de hebras en la ejecución concurrente de tareas.
El Modelo Dinámico
El Modelo Dinámico de una aplicación DDS describe el comportamiento que tendrán
las entidades que forman la aplicación. El comportamiento se define como la actividad
que realiza una entidad. Esto abarca no sólo a la ejecución de tareas programadas sino
también la reacción de la entidad a eventos que se produzcan en el sistema.
En el caso de la programación de tareas de una entidad, la especificación puede hacerse programando un método que podrá ser utilizado por una o varias entidades. En
el caso de la reacción ante eventos se hará utilizando la interfaz de DDS para configurar
qué eventos atiende un listener y cómo los gestiona. Un evento puede ser, por ejemplo,
la llegada de datos a una cola de recepción o la pérdida de muestras de datos entre los
recibidos.
El sistema dispondrá de un Modelo Dinámico global que almacene todos los modelos dinámicos que se quieran utilizar. El conjunto de modelos dinámicos definidos formará una tabla sobre la que se podrán realizar búsquedas y obtener elementos que asociar a las Entidades DDS XML para su posterior uso. Mediante esta asociación el Modelo
Estático y el Modelo Dinámico quedan conectados.
5.1.2.
La interacción y coordinación del escenario
Presentadas las cuestiones relativas a la descripción del escenario, esta sección presenta
cómo abordar la coordinación entre las aplicaciones que componen el escenario, ası́ como
la interfaz de interacción que el desarrollador tendrá con él.
Dicho problema puede ser dividido en dos subproblemas:
La distribución de órdenes o comandos a todos los nodos para indicar qué acciones
realizar. Para ello se propone delegar esta tarea en el propio middleware DDS. De
esta forma se define un tema de control sobre el cual se publicarán datos para la
coordinación del escenario. Todos los nodos participantes se subscribirán a este
tema de control de forma que recibirán las órdenes publicadas.
La interpretación y desarrollo de estas órdenes, que se realizará mediante los nodos
Command Slave explicados más adelante.
Para desplegar la infraestructura de coordinación necesaria, los nodos de la red participantes en el futuro escenario DDS lo harán con dos roles bien definidos. El papel de
“Command Master” se encarga de publicar órdenes utilizando el tema de control. El resto
de nodos participarán como “Command Slaves” y estarán subscritos al tema de control.
Como puede deducirse, sólo puede haber un “Command Master” para un escenario.
41
5. Diseño
Figura 5.3: Coordinación del escenario distribuidos utilizando DDS
La aplicación que actúe como Command Master tiene dos funciones: interpretar órdenes del usuario y distribuirlas. Para implementar la primera, se propone la creación de
una gramática de lenguaje semi-natural que permita al usuario interaccionar con el sistema. Respecto a la distribución de órdenes, se delegará esta función en el propio DDS.
El rol de Command Slave implica la subscripción al tema de control para recibir órdenes
de la red. El nodo deberá interpretar estas órdenes para desarrollar la parte del escenario
que le corresponda. Para ello utilizará la funcionalidad ofrecida por Modelos Estáticos y
Dinámicos.
La Figura 5.3 ilustra los dos tipos de roles de los nodos participantes en el escenario.
En la figura se introducen dos aplicaciones que deben ser lanzadas en los nodos correspondientes:
cmdmaster, que se ejecutará en el nodo que juega el papel de Command Master.
cmdslave, que se ejecutará en los nodos que actúan como Command Slaves.
5.1.3.
Funcionalidades para mejorar la flexibilidad del sistema
Para finalizar este capı́tulo se introducen algunas ideas de diseño que mejoran la flexibilidad y potencia descriptiva del sistema.
42
Distribución del escenario y asignación automática de aplicaciones a nodos
La distribución del fichero XML que describe un escenario se hará utilizando también
DDS para la transferencia. De esta forma se evitan dependencias de mecanismo externos,
tal y como ocurre con algunas alternativas estudiadas en la Sección 1.8.
Por otro lado, la asignación de aplicaciones DDS a nodos se realiza de forma automática. Cuando un nodo recibe un fichero XML que contiene la lista de aplicaciones
de un escenario selecciona una de ellas para desarrollarla. Sobre esta aplicará, a partir de
entonces, los órdenes recibidas.
La asignación se especifica incluyendo una lista de atributos en las etiquetas XML que
representan una aplicación. Estos atributos forman una lista de direcciones IP y nombres
de máquina. Cuando un nodo recibe el fichero XML, comprueba si su nombre o dirección
IP está en la lista de cada aplicación y ası́ selecciona la aplicación adecuada.
Creación de varias instancias, recursividad y herencia
Una manera de aumentar la capacidad expresiva del Modelo Estático, y en consecuencia de las acciones que se pueden ejecutar con la interfaz que ofrece, es el soporte
para:
La especificación de un número máximo de instancias DDS que se pueden crear a
partir de un objeto DDS XML. Esto significa que se podrán especificar descripciones del tipo “crear 5 DataWriter como ’writer a’ en la aplicación ’a”’. Este número
se especificará como una etiqueta más en el fichero XML.
La aplicación recursiva de acciones en las entidades. Esto es, incluir un parámetro
que permita especificar si una acción se aplica sobre una sola entidad o también
sobre todos sus descendientes en el árbol.
Herencia entre objetos DDS XML. A partir de un objeto DDS XML se podrán definir otros objetos como él, que heredarán sus atributos. De esta forma se consigue
minimizar el código necesario para describir aplicaciones al permitir la reutilización de componentes anteriormente descritos..
La Figura 5.4 a modo de ejemplo ilustra de manera conjunta los conceptos de instancias y recursividad.
Siguiendo la Figura 5.4, se presenta el siguiente subárbol dentro de una aplicación.
Aparecen las siguientes entidades DDS XML: un DomainParticipant que tiene un Subscriber que a su vez tiene 2 DataReaders, cada uno de estos con un número diferente de
instancias. El DDS XMLDataReader “string reader” podrá crear hasta 3 instancias DDS y
el denominado como “octet reader” podrá crear hasta 2 instancias DDS. Este número se
habrá fijado en la descripción de cada entidad en el fichero XML.
Para crear las entidades DDS contenidas en el subárbol caben dos opciones:
43
5. Diseño
Figura 5.4: Ejemplo explicativo del funcionamiento de las instancias y parámetros de
recursividad
44
5.2. Modelo de interacción de objetos
a) Explı́citamente, crear las entidades una por una realizando 3 operaciones como se
muestra en la Figura 5.4, a). Al final de este proceso se habrán creado tres entidades
DDS: un DomainParticipant, un Subscriber y un DataReader (indicado con el ı́ndice
“1” y resaltado en la figura).
b) Crear las entidades de manera implı́cita utilizando la opción de recursividad. En
este caso sólo serı́a necesario ejecutar la acción sobre el primer objeto DDS XMLDomainParticipant. Gracias al parámetro para aplicar la operación recursivamente,
todos los objetos DDS XML hijos ejecutarán la misma acción. Como muestra la Figura 5.4, b), al final del proceso se habrán creado siete entidades DDS: un DomainParticipant, un Subscriber y 5 DataReaders (3 del tipo “string reader” y 2 del tipo
“octet reader”).
Como puede comprobarse, de esta forma se puede interaccionar con el escenario de
manera flexible.
Granularidad de las operaciones
Por último, el diseño de las operaciones a todos los niveles debe hacerse con la granularidad más fina posible. Cuanta más fina sea la granularidad mayor flexibilidad se
permitirá en la interacción con el escenario.
Para conseguir esto, el proceso de creación y destrucción de las entidades se separará de la activación y parada de la actividad de estas. Además, utilizando el concepto de
instancias antes presentado se permitirá seleccionar con precisión entidades DDS concretas del árbol.
5.2.
Modelo de interacción de objetos
Para explicar el funcionamiento y operaciones del sistema, se opta por una descripción formal basada en diagramas de secuencia.
Un diagrama de secuencia es una forma de diagrama de interacción que muestra los
objetos como lı́neas de vida a lo largo de la página y con sus interacciones en el tiempo.
Las interacciones se represetentan como mensajes dibujados como flechas desde la lı́nea
de vida origen hasta la lı́nea de vida destino.
Con esta notación, se pretende mostrar qué objetos se comunican con qué otros objetos. Esta representación sigue siendo una representación de alto nivel ya que no se considera la ubicación de cada objeto en el sistema distribuido, puesto que a este nivel no es
relevante. Tampoco se consideran las operaciones que no implican la comunicación entre
objetos, y que, por tanto, carecen de interés en esta sección.
Por último, aclarar que no se mostrarán todos los diagramas de secuencia posibles,
45
5. Diseño
sino los más representativos, ya que el flujo de muchas acciones es prácticamente idéntico.
Ası́, la lista de diagramas de secuencia considerados como representativos es:
Operación cargar escenario.
Operación crear entidad DDS. Esta operación es equivalente a destruir entidad DDS.
Se representará la secuencia crear entidad DDS cuando la entidad es un DomainParticipant DDS. Las simplificaciones de esta operación que no repetiremos son:
• crear o destruir una entidad DDS cuando la entidad es un Topic DDS
• crear o destruir una entidad DDS cuando la entidad es un Publisher DDS
• crear o destruir una entidad DDS cuando la entidad es un Subscriber DDS
• crear o destruir una entidad DDS cuando la entidad es un DataWriter DDS
• crear o destruir una entidad DDS cuando la entidad es un DataReader DDS
Operación iniciar comportamiento. Esta operación es equivalente a parar comportamiento. Se representará la secuencia iniciar comportamiento cuando la entidad es un
DomainParticipant DDS. Las simplificaciones de esta operación que no repetiremos
son:
• iniciar o parar una entidad DDS cuando la entidad es un Topic DDS
• iniciar o parar una entidad DDS cuando la entidad es un Publisher DDS
• iniciar o parar una entidad DDS cuando la entidad es un Subscriber DDS
• iniciar o parar una entidad DDS cuando la entidad es un DataWriter DDS
• iniciar o parar una entidad DDS cuando la entidad es un DataReader DDS
5.2.1.
Acción cargar escenario
La Figura 5.5 muestra el diagrama de secuencia de la acción cargar escenario. Esta operación es la responsable de leer un fichero XML proporcionado por el usuario y distribuirlo a los nodos del escenario que lo utilizarán para desarrollar sus aplicaciones DDS.
Como resultado de estas acciones, cada nodo seleccionará automáticamente una aplicación DDS descrita en el fichero. Se identifican las siguientes operaciones relevantes:
readfile: leer un fichero XML proporcionado por el usuario.
loadScenario: se produce en dos objetos:
En CommandPublisher se refiere al la publicación de una orden “cargar escenario” que contiene el fichero XML.
46
En CommandSubscriber se refiere a la recepción del fichero del escenario. Esto
incluye la reconstrucción del fichero, que puede haberse recibido en distintos
trozos.
parseScenario: es el proceso de análisis del fichero del escenario, llevado a cabo por
el parser, que aquı́ consideramos el actor DDS XMLParser (ver Sección 4.1.1). El
resultado de esta operación es un árbol que contiene la representación en memoria
del escenario compuesta de entidades DDS XML.
createApplicacions: DDS XMLParser creará un conjunto de aplicaciones DDS XML que
cada CommandSubscriber (un nodo en la prueba) podrá seleccionar.
lookupAndSelectApplication: sobre el árbol compuesto de DDS XMLApplications generado por DDS XMLParser se debe seleccionar una aplicación.
Figura 5.5: Diagrama de secuencia cargar escenario
5.2.2.
Acción crear entidad DDS
La acción crear entidad DDS es compleja debido a la cantidad de objetos de distinto tipo que intervienen. Además, se debe dar soporte tanto para la aplicación recursiva de las
operaciones como para la existencia de múltiples instancias DDS, tal y como se explicó en
47
5. Diseño
la Sección 5.1.3. Las siguientes figuras describen un único diagrama de secuencia que se
ha dividido en varias figuras para poder mostrarlo correctamente.
La Figura 5.6 muestra el inicio de la acción desde CommandPublisher. La secuencia
continúa en la Figura 5.7. Las operaciones identificadas en esta secuencia son:
createDDSEntity: esta operación tiene como objetivo la creación de una o varias entidades DDS. Se propaga y efectúa en tres objetos:
CommandPublisher: inicia la acción crear entidad DDS con los siguientes atributos que se propagarán entre el resto de objetos:
• id: identificador de la entidad DDS XML a la que se hará llegar la operación en última instancia.
• index: ı́ndice de la instancia DDS dentro de la entidad DDS XML a la que
se aplicará la operación.
• recursive: parámetro lógico para controlar si la operación se aplicará sólo
a la instancia afectada o si también se aplicará a las instancias hijas de ésta
en el árbol de entidades.
CommandSubscriber: recibe el mensaje createDDSEntity y a su vez se lo envı́a a
la DDS XMLApplication que tiene asociada.
La DDS XMLApplication asociada al objeto CommandSubscriber.
lookupEntity: la aplicación buscará entre el conjunto de entidades DDS XML que la componen para ver si contiene a la entidad identificada por id. Si no es ası́, la operación
termina aquı́.
La Figura 5.7 continúa la secuencia de la Figura 5.6 para el caso en que la entidad encontrada en la operación lookupEntity sea una entidad del tipo DDS XMLDomainParticipant.
Se ha elegido este ejemplo por ser el caso más complejo posible, ya que DDS XMLDomainParticipant
es la entidad que puede estar compuesta de más entidades a su vez. El diagrama de secuencia para otras entidades DDS XML será siempre una simplificación del explicado
aquı́.
En el diagrama de secuencia crear entidad DDS concerniente al objeto DDS XMLDomainParticipant
(Figura 5.7) se identifican las siguientes operaciones:
createDDSEntity: sobre el objeto DDS XMLDomainParticipant provoca la creación de un
DomainParticipant DDS con los parámetros de configuración de la entidad DDS XML
sobre la que se está aplicando la operación. Esta operación puede propagarse a las
entidades hijas del DDS XMLDomainParticipant.
createDDSEntityChilds: es una operación condicionada a que el parámetro “recursive”
esté activado para propagar la operación createDDSEntity a las entidades hijas de la
actual.
48
Figura 5.6: Diagrama de secuencia crear entidad DDS, parte genérica. Continúa en Figura
5.7
getChildsTopic: obtiene los DDS XMLTopic hijos del DDS XMLDomainParticipant. Sobre
cada hijo obtenido se propagará la acción createDDSEntity.
getChildsPublisher: obtiene los DDS XMLPublisher hijos del DDS XMLDomainParticipant.
Sobre cada hijo obtenido se propagará la acción createDDSEntity.
getChildsSubscriber: obtiene los DDS XMLSubscriber hijos del DDS XMLDomainParticipant.
createDDSDomainParticipant: es la operación que realiza el middleware DDS para crear
un DomainParticipant DDS.
createDDSTopic: es la operación que realiza el middleware DDS para crear un Topic DDS.
createDDSPublisher: es la operación que realiza el middleware DDS para crear un Publisher DDS.
createDDSSubscriber: es la operación que realiza el middleware DDS para crear un Subscriber DDS.
La Figura 5.8 representa la encadenación de operaciones a las entidades hijas de un
objeto DDS XMLPublisher. En ella se identifican las operaciones no descritas anterioremente:
createDDSEntityChilds: si el parámetro “recursive” está activo, la operación createDDSEntity se propaga a las entidades hijas.
getChildsDataWriter: obtiene los DDS XMLDataWriter hijos del DDS XMLPublisher. Sobre cada hijo obtenido se propagará la acción createDDSEntity.
49
5. Diseño
Figura 5.7: Diagrama de secuencia crear entidad DDS,
DDS XMLDomainParticipant. Continúa en Figuras 5.8 y 5.9
50
detalle
respecto
a
createDDSDataWriter: es la operación que realiza el middleware DDS para crear un DataWriter DDS.
La Figura 5.9 es análoga a la Figura 5.8 y representa la encadenación de operaciones a
las entidades hijas de un objeto DDS XMLSubscriber. En ella se identifican las operaciones
no descritas anterioremente:
createDDSEntityChilds: es una operación condicionada a que el parámetro “recursive”
esté activado para propagar la operación createDDSEntity a las entidades hijas de la
actual.
getChildsDataReader: obtiene los DDS XMLDataReader hijos del DDS XMLSubscriber.
createDDSDataReader: es la operación que realiza el middleware DDS para crear un DataReader DDS.
5.2.3.
Acción iniciar comportamiento
La acción iniciar comportamiento es similar a crear comportamiento y por ello compleja.
Las siguientes figuras describen un único diagrama de secuencia que se ha dividido en
varias figuras para poder mostrarlo correctamente.
La Figura 5.10 muestra el inicio de la acción desde CommandPublisher. La secuencia
continúa en la Figura 5.11. Las operaciones identificadas en esta secuencia son:
startBehaviour: esta operación tiene como objetivo iniciar la actividad de una o varias
entidades DDS. Se propaga y efectúa en tres objetos:
CommandPublisher: inicia la acción iniciar comportamiento con los siguientes atributos que se propagarán entre el resto de objetos:
• id: identificador de la entidad DDS XML a la que se hará llegar la operación en última instancia.
• index: ı́ndice de la instancia DDS dentro de la entidad DDS XML a la que
se aplicará la operación.
• recursive: parámetro lógico para controlar si la operación se aplicará sólo
a la instancia afectada o si también se aplicará a las instancias hijas de ésta
en el árbol de entidades.
CommandSubscriber: recibe el mensaje startBehaviour y a su vez se lo envı́a a la
DDS XMLApplication que tiene asociada.
La DDS XMLApplication asociada al objeto CommandSubscriber.
51
5. Diseño
secuencia
crear
entidad
DDS,
detalle
respecto
a
Figura 5.9: Diagrama de secuencia
DDS XMLDomainSubscriber.
crear
entidad
DDS,
detalle
respecto
a
Figura 5.8: Diagrama de
DDS XMLDomainPublisher.
52
Figura 5.10: Diagrama de secuencia iniciar comportamiento, parte genérica. Continúa en
Figura 5.11
lookupEntity: la aplicación buscará entre el conjunto de entidades DDS XML que la componen para ver si contiene a la entidad identificada por id. Si no es ası́, la operación
termina aquı́.
La Figura 5.11 continúa la secuencia de la Figura 5.10 para el caso en que la entidad encontrada en la operación lookupEntity sea una entidad del tipo DDS XMLDomainParticipant.
Se ha elegido este ejemplo por las mismas razones que en la acción crear entidad DDS.
En el diagrama de secuencia iniciar comportamiento concerniente al objeto DDS XMLDomainParticipant (Figura 5.11) se identifican las siguientes operaciones:
startBehaviour: sobre el objeto DDS XMLDomainParticipant provoca el una serie de acciones para ejecutar la actividad de este. Esta operación puede propagarse a las
entidades hijas del DDS XMLDomainParticipant.
lookupMethod: sobre el conjunto de modelos dinámicos del sistema, se busca el método
que especifica el comportamiento y es asocia a la entidad DDS XML. Este método
corresponde al especificado previamente en el fichero XML.
startBehaviourMethod: una vez obtenido un método válido, se inicia el comportamiento en si de la entidad DDS adecuada, indicada con el parámetro index. Se debe
permitir la ejecución concurrente de la actividad de las entidades, de modo que la
ejecución del comportamiento debe lanzarse en una hebra nueva.
startBehaviourChilds: es una operación condicionada a que el parámetro “recursive”
esté activado para propagar la operación startBehaviour a las entidades hijas de la
actual.
53
5. Diseño
getChildsTopic: obtiene los DDS XMLTopic hijos del DDS XMLDomainParticipant. Sobre
cada hijo obtenido se propagará la acción startBehaviour.
getChildsPublisher: obtiene los DDS XMLPublisher hijos del DDS XMLDomainParticipant.
Sobre cada hijo obtenido se propagará la acción startBehaviour.
getChildsSubscriber: obtiene los DDS XMLSubscriber hijos del DDS XMLDomainParticipant.
La Figura 5.12 representa la encadenación de operaciones a las entidades hijas de un
objeto DDS XMLPublisher. En ella se identifican las operaciones no descritas anterioremente:
startBehaviourChilds: si el parámetro “recursive” está activo, la operación startBehaviour se propaga a las entidades hijas.
getChildsDataWriter: obtiene los DDS XMLDataWriter hijos del DDS XMLPublisher. Sobre cada hijo obtenido se propagará la acción startBehaviour.
La Figura 5.13 es análoga a la Figura 5.12 y representa la encadenación de operaciones
a las entidades hijas de un objeto DDS XMLSubscriber. En ella se identifican las operaciones no descritas anterioremente:
startBehaviourChilds: es una operación condicionada a que el parámetro “recursive”
esté activado para propagar la operación startBehaviour a las entidades hijas de la
actual.
getChildsDataReader: obtiene los DDS XMLDataReader hijos del DDS XMLSubscriber.
54
Figura 5.11: Diagrama de secuencia iniciar comportamiento, detalle respecto a
DDS XMLDomainParticipant. Continúa en Figuras 5.12 y 5.13
55
5. Diseño
DDS XMLDomainPublisher.
56
DDS XMLDomainSubscriber.
57
5. Diseño
5.3.
Diagrama de clases
Esta sección presenta el diagrama de clases del sistema. La representación se ha dividido en una vista general de las clases (Figura 5.14) por un lado y, por otro, la representación de cada clase por separado para poder mostrar sus detalles.
Figura 5.14: Vista general del diagrama de clases
El diagrama de clases general muestra las relaciones entre las clases del tipo DDS XML.
Cada una de estas clases equivale a su correspondiente clase DDS. Este diagrama respeta
las relaciones conceptuales de las clases tal y como se especifica en el estándar DDS[6].
Como puede verse en la Figura 5.14, queda claro cómo una aplicación DDS, representada por DDS XMLApplication, está compuesta de un conjunto de entidades DDS,
representadas por clases del tipo DDS XMLEntity.
Otra relación que cabe destacar es la asociación de una DDS XMLApplication a un
CommandSubscriber. Como se introducı́a en capı́tulos anteriores, cada nodo que ejecuta un
58
5.3. Diagrama de clases
CommandSubscriber selecciona una sola aplicación DDS para desarrollar el escenario. La
relacción de la clase CommandSubscriber con un único CommandPublisher también queda
reflejada.
Figura 5.15: Detalle del diagrama de clases: DDS XMLApplication
Figura 5.16: Detalle del diagrama de clases: DDS XMLParticipant
59
5. Diseño
Figura 5.17: Detalle del diagrama de clases: DDS XMLPublisher
Figura 5.18: Detalle del diagrama de clases: DDS XMLSubscriber
Figura 5.19: Detalle del diagrama de clases: DDS XMLTopic
60
5.3. Diagrama de clases
Figura 5.20: Detalle del diagrama de clases: DDS XMLDataWriter
Figura 5.21: Detalle del diagrama de clases: DDS XMLDataReader
61
5. Diseño
Figura 5.22: Detalle del diagrama de clases: CommandPublisher
Figura 5.23: Detalle del diagrama de clases: CommandSubscriber
62
CAPÍTULO
6
IMPLEMENTACIÓN
En este capı́tulo se describen algunos detalles de la implementación que es interesante
remarcar. En particular se hace hincapié en:
Cómo se ha implementado un modelo de orientación a objetos con el lenguaje C.
La implementación del analizador del lenguaje de interacción con el escenario.
Los módulos que componen el sistema.
6.1.
Implementación de la orientación a objetos en C
En esta sección se explica la metodologı́a y reglas de codificación que han permitido utilizar este paradigma de programación con un lenguaje no orientado a objetos. La
lectura de este apartado permitirá poder interpretar el código fuente de una forma más
clara.
Hasta ahora se han utilizado constantemente tanto conceptos de orientación a objetos
como notación y diagramas relacionados con la orientación objetos. Esto ha sido ası́ por
varias razones:
Pensando en el futuro del proyecto, la posible integración de este proyecto dentro
de un middleware DDS incluirá que se porte el código actual a lenguajes como C++
o Java. Normalmente estos productos presentan un interfaz de programación que
admite varios lenguajes, estando escrita la base casi siempre en C. Ası́ pues, la existencia de diagramas de clases, diagramas de secuencia y demás ayudarán a esta
tarea.
63
6. Implementación
Las técnicas de desarrollo de software modernas como el proceso unificado de desarrollo[45] están pensadas para trabajar con lenguajes orientados a objetos.
Las metodologı́as de orientación a objetos ayudan a estructurar el código de manera
funcional, algo esencial conforme la complejidad del problema aumenta.
A continuación se describe cómo se organiza el código en C para poder aplicar conceptos de la orientación a objetos:
Representación de clases. Cada clase del diagrama de clases se corresponde con una
estructura de datos en C. Ası́, tendremos una estructura con una serie de campos que
representarán los atributos de la clase. Por ejemplo:
DomainParticipant
Espacio de nombres. Para evitar conflictos en la definición de estructuras y métodos,
se antepone al nombre de cada uno lo que se conoce como “espacio de nombres”.
Esto es un prefijo que se añade al nombre de la estructura o método para indicar a
qué biblioteca o módulo pertenece. Por ejemplo el prefijo “DDS” indica que lo que
sigue a continuación pertenece a la biblioteca que ofrece el API del estándar DDS.
En este proyecto, se añade el prefijo “DDS XML” para indicar las clases XML que
envuelven a entidades DDS. El nombre de la estructura anterior, una vez añadido
el espacio de nombres “DDS XML” quedarı́a:
DDS_XMLDomainParticipant
Asociación de métodos a clases. Para reflejar la asociación de un método de una clase,
se antepone el nombre de la clase, es decir, el nombre de la estructura con el espacio
de nombres, al nombre del método. Por ejemplo, el método “create dds entity” de
la clase anterior se nombrarı́a en C ası́:
DDS_XMLDomainParticipant_create_dds_entity
Parámetros de las funciones. El primer parámetro de un método asociado a una clase
será siempre un puntero a una estructura del tipo de la clase. A continuación se
incluirán los parámetros de entrada y al final de la lista los parámetros de salida.
De esta manera se consigue poder llamar a una serie de métodos sobre un mismo
objeto (estructura en C). Por ejemplo, en el método anterior existirá el siguiente
parámetro:
DDS_XMLDomainParticipant_create_dds_entity(
struct DDS_XMLDomainParticipant *self,
<parámetros de entrada>,
<parámetros de salida>)
64
6.2. Implementación del analizador de gramática semi-natural
Métodos new y delete. A cada clase se le añaden métodos para la creación y destrucción
de estos. En este caso estos métodos reservan o liberan memoria para los campos
necesarios, e inicializan sus valores si es necesario.
6.2.
Implementación del analizador de gramática semi-natural
En el Apartado 4.2 de la fase de análisis se definió, mediante notación BNF, la gramática generativa del lenguaje semi-natural de interacción con el escenario.
Por otro lado, en el Apartado 1.7.2 se mencionó como decisión estratégica el uso de
las herramientas automatizadas para la generación de analizadores sintácticos, lo que
incluye también la generación de analizadores léxicos.
Partiendo de la gramática BNF estos generadores construyen analizadores sintácticos. Añadiendo código fuente a las reglas de análisis sintáctico se pueden realizar acciones cuando se reconoce una frase introducida por el usuario. La manera en que están diseñados estos generadores facilita posteriores ampliaciones o modificaciones de la gramática y/o acciones.
Las gramáticas BNF se pueden implementar con el uso de un analizador sintáctico de
los llamados LookAhead Left-Right (LALR). Una herramienta libre generadora de analizadores sintácticos LALR es bison, [46] la implementación GNU del popular generador de
analizadores YACC. Además, será necesario integrar bison con el generador de analizadores léxicos Flex[47].
El proceso de implementación, por tanto, consiste en traducir la gramática definida
en la sección 4.2 a bison y definir las acciones pertinentes para cada tipo de sentencia.
6.3.
Estructuración modular del código
6.3.1.
Modelo Estático: clases DDS XML y parser XML
La fase de diseño concluyó con la definición del diagrama de clases del sistema (Apartado 5.3). En esta sección se explicarán algunos detalles de su implementación.
Procesado de ficheros XML con las clases DDS XML. El diagrama de clases muestra
un conjunto de clases DDS XML, clases que envuelven a entidades DDS. El parser para
el procesado de los ficheros XML se ha construido utilizando estas clases. Según el tipo
de etiqueta que se encuentre al procesar el fichero, se utilizará unas u otras clases para
procesar el contenido almacenado dentro de la etiqueta. Ası́, como resultado del proceso
de análisis se obtiene un árbol de objetos DDS XML. La Tabla 6.1 muestra la relación
entre entidades DDS, entidades DDS XML y etiquetas.
65
6. Implementación
Entidad DDS
DomainParticipant
Topic
Publisher
Subscriber
DataWriter
DataReader
Entidad DDS XML
DDS XMLDomainParticipant
DDS XMLTopic
DDS XMLPublisher
DDS XMLSubscriber
DDS XMLDataWriter
DDS XMLDataReader
etiqueta
<participant>
<topic>
<publisher>
<subscriber>
<writer>
<reader>
Tabla 6.1: Relación entidades DDS, entidades DDS XML y etiquetas
Implementación de la herencia El soporte para la herencia entre las entidades se implementa de la siguiente manera:
1. Como se comentó en la Sección 4.3, existe un atributo opcional llamado base name
que indica al parser que la clase que está procesando hereda de otra. Cuando el parser
encuentra este atributo busca una entidad en el árbol construı́do con el nombre
name que coincida con base name. Esta entidad denomina clase base.
2. Antes de procesar la información contenida en la etiqueta de la clase que hereda, se
copian a ésta todos los atributos de la clase base.
3. Si se encuentran valores nuevos para los atributos encontrados se sobreescriben
éstos con el valor nuevo.
En la implementación actual la herencia sólo afecta a los atributos de las clases que
sean datos inmediatos, no se heredan las clases hijas de la clase base.
Podemos explicar el funcionamiento de la herencia con el siguiente código XML:
<d a t a r e a d e r 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
</ d a t a r e a d e r>
<d a t a r e a d e r name="reader_as_reader1" base name="reader1">
Listado 6.1: Código XML para mostrar el funcionamiento de la herencia
El DataReader “reader as reader1” tendrá como Topic “hello world topic” y se crearán
5 instancias DDS si se llama al método create all dds entities() del objeto DDS XML
que lo envuelve. Se puede sobreescribir cualquier parámetro de la siguiente manera:
<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>
66
6.3. Estructuración modular del código
Listado 6.2: Código XML para mostrar el funcionamiento de la herencia
En este caso, el DataReader “reader as reader1” tendrá como Topic “foo topic”, pero el
número de instancias seguirá siendo 5.
Estructuras de datos para la representación de las clases DDS XML A continuación
se muestra el código de ejemplo de la la estructura DDS XMLDataReader. El resto de clases no difiere demasiado de esta salvo por la inclusión de atributos para datos especı́ficos.
s t r u c t DDS XMLDataReader{
s t r u c t DDS XMLObject base ;
/ ∗ S e t o f DDS DataReader i n s t a n c e s ∗ /
DDS DataReader ∗∗ d d s d a t a r e a d e r ;
/ ∗ P o i n t e r t o t h e DDS XMLTopic i n t h e DOM.
∗ T h i s p o i n t e r i s s e t up d u r i n g 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 i n
∗ 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 ∗ x m l t o p i c ;
/ ∗ C o n t e n t o f t h e t a g ∗ /
short instances tag ;
/ ∗ 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
∗ parent i n s t a n c e s ∗/
s h o r t i ns ta n ce s n um be r ;
/ ∗ L i s t e n e r f o r a t t a c h i n g t o t h e DDS E n t i t y .
∗ This l i s t e n e r
w i l l b e NULL o r i t w i l l b e
∗ 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 b e 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 . T h i s method w i l l b e e x e c u t e d when
∗ t h e s t a r t b e h a v i o u r ( ) method i s c a l l e d ∗ /
void ∗ ( ∗ behaviour ) ( void ∗ ) ;
};
Listado 6.3: Estructura DDS XMLDataReader
El significado y uso de los campos de datos es:
struct DDS_XMLObject base: objeto base del que hereda la clase.
DDS_DataReader **dds_datareader: conjunto de en entidades DDS que maneja la clase.
struct DDS_XMLTopic *xml_topic: referencia al DDS XMLTopic en el árbol
de la aplicación. Esta referencia se fija durante el procesamiento del fichero XML
67
6. Implementación
buscando el tema indicado por la etiqueta datawriter_topic. El tema correspondiente se busca comenzando desde el DDS XMLDomainParticipant padre de la entidad.
short instances_tag: contenido de la etiqueta <instances>.
short instances_number: número de instancias DDS que se podrán crear. Considerando que la entidad padre de esta clase puede, a su vez tener más instancias,
el total de instancias que se pueden crear será el número de instancias de la entidad padre por el número indicado en la etiqueta XML, almacenado en el atributo
instances_tag. Este atributo se modifica durante el procesamiento del fichero
XML.
struct DDS_DataReaderListener *listener: listener que se asociará a la
entidad DDS que se cree.
DDS_StatusMask listener_mask: configuración de las callbacks que monitorizará el listener.
pthread_t *thread: identificadores de las hebras lanzadas para ejecutar comportamiento paralelo.
void *(*behaviour)(void *): puntero a un método de descripción del comportamiento.
Los dos últimos atributos se refieren al comportamiento dinámico que se quiere utilizar para la entidad. Cuando se invoca al método start behaviour() en una clase
DDS XML, este crea una nueva hebra para llamar al método que describe el comportamiento. Para poder detener la ejecución del comportamiento es necesario almacenar una
referencia a la hebra, y esto se almacena en el vector thread. Como pueden existir varias
entidades DDS en una entidad DDS XML actuando a la vez, se creará una hebra para
cada entidad DDS que inicie su actividad. Ası́, para un una posición del vector de entidades DDS existirá una en el vector de hebras para identificar la hebra que utiliza una
entidad DDS.
6.3.2.
Modelo Dinámico
El Modelo Dinámico describe el comportamiento de entidades del Modelo Estático. La
descripción se hace programando un método y configurando los listeners apropiados mediante el API de DDS para el lenguaje C.
El módulo del Modelo Dinámico actuará como una base de datos que almacena métodos y listeners. Esta base de datos está compuesta de una serie de tablas que gestionan
información para poder acceder a los elementos dinámicos que almacenan. El módulo
proporciona métodos para inicialiar estas tablas y hacer búsquedas sobre ellas.
68
Si el usuario quiere que un conjunto de métodos y listeners puedan ser utilizados debe
incluirlos en estas tablas. A continuación se muestran extractos de código de las tablas
del Modelo Dinámico.
s t a t i c s t r u c t BehaviourMethodEntry
DM models table [ DM models table elements ] ;
s t a t i c s t r u c t DataReaderListenerEntry
DM datareaders listeners table [ DM datareader listeners table elements ] ;
...
Listado 6.4: Tablas del Modelo Dinámico
Estas tablas estás compuestas de entradas como la del Listado 6.5.
typedef s t r u c t BehaviourMethodEntry {
/ ∗ I d e n t i f i e r / k e y 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 D a t a R e a d e r L i s t e n e r E n t r y {
/∗ I d e n t i f i e r / key o f the 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 g o i n g t o b e 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 .
∗ T h i s method w i l l b e c a l l e d by t h e l o o k u p method b e f o r e
∗ returning the l i s t e n e r to the user ∗/
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 Dinámico
Un ejemplo de tablas es el del Listado 6.3.2, que muestra la inicialización de una tabla
de listeners para entidades DataReader.
void D y n a m i c M o d e l d a t a r e a d e r i n i t i a l i z e l i s t e n e r s t a b l e ( void )
{
D M d a t a r e a d e r s l i s t e n e r s t a b l e [ 0 ] . name =
DDS String dup ( "DDS_StringX_listener" ) ;
D M d a t a r e a d e r s l i s t e n e r s t a b l e [ 0 ] . type name = DDS String dup (
DDS StringXTypeSupport get type name ( ) ) ;
D M d a t a r e a d e r s l i s t e n e r s t a b l e [ 0 ] . l i s t e n e r = NULL;
D M d a t a r e a d e r s l i s t e n e r s t a b l e [ 0 ] . l i s t e n e r m a s k = DDS STATUS MASK ALL ;
69
6. Implementación
DM datareaders listeners table [ 0 ] . initialize method =
&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.
Módulo de coordinación
El módulo de coordinación, como su nombre indica, coordina todos los nodos del escenario utilizando un tema de control o Control Topic. El tipo de datos de este tema, Command,
se describió en el capı́tulo de análisis, Sección 4.2.2.
Las clases CommandPublisher y CommandSubcriber implementan la comunicación de
instrucciones entre los nodos del escenario. Estas clases no son aplicaciones en si, sino
que se utilizan dentro de dos aplicaciones:
cmdmaster es una aplicación DDS que se ejecuta en un nodo “Command Master”.
cmdmaster es una aplicación que integra a un analizador sintáctico generado por
Yacc. El resultado del análisis sintáctico se utiliza para rellenar los campos de instancias de datos de la estructura Command. Estas instancias se publicarán a la red
utilizando la clase CommandPublisher.
La aplicación cmdslave es la única que el usuario necesita ejecutar en un nodo
para desplegar el escenario. Esta, utiliza la clase CommandSubscriber para recibir y
procesar instancias de datos de control que recibe de la red. Recibidas las órdenes,
la clase CommandSubscriber utiliza el API de los módulos estático y dinámico para
crear y destruir entidades DDS y controlar su comportamiento.
Para ilustrar cómo integrar el analizador sintáctico con la clase CommandPublisher, el
Listado 6.6 muestra dos reglas que ilustran la integración de CommandPublisher con las
reglas de análisis sintáctico de Yacc.
| CREATEALL {
/ ∗ CREATEALL ∗ /
# i f d e f DEBUG PARSER
PrintDebug ( "CREATEALL\n" )
# endif
i f ( CommandPublisher set command all (
globalCommandPublisher , CMD CREATE ENTITIES ALL ) ) {
/ ∗ W r i t e t h e Command ∗ /
CommandPublisher write command ( globalCommandPublisher ) ;
CommandPublisher clear command ( globalCommandPublisher ) ;
}
}
| CREATE STRING NUMBER {
/ ∗ CREATE ENTITY NAME INSTANCE ID ∗ /
# i f d e f DEBUG PARSER
PrintDebug ( "CREATE %s, %d\n" , $2 , $3 )
70
# endif
i f ( CommandPublisher set command (
globalCommandPublisher , CMD CREATE ENTITIES , $2 , $3 ) ) {
/ ∗ W r i t e t h e Command ∗ /
CommandPublisher write command ( globalCommandPublisher ) ;
CommandPublisher clear command ( globalCommandPublisher ) ;
}
Listado 6.6: Integración de CommandPublisher con las reglas de análisis sintáctico de Yacc
71
6. Implementación
72
CAPÍTULO
7
PRUEBAS
Las pruebas pretenden verificar el correcto funcionamiento del sistema y comprobar
que los requisitos funcionales y no funcionales de la especificación se cumplen. Las pruebas a las que se ha sometido el sistema son:
Pruebas unitarias: consiste en realizar pruebas a nivel de módulo de forma independiente.
Pruebas de integración: los módulos probados en la etapa anterior se integran para
comprobar sus interfaces (flujo de datos) en el trabajo conjunto.
Pruebas del sistema: para comprobar que el software esté totalmente ensamblado y
cumpla tanto los requisitos funcionales y no funcionales como los objetivos indicados para el sistema.
Para la realización de las pruebas se ha utilizado un mismo fichero XML (scenario.xml) que hace uso de todas las funcionalidades implementadas respecto al la descripción de entidades. El fichero puede consultarse en el Apéndice C. Este fichero describe
ejemplos de:
Especificación de varias aplicaciones con participantes pertenecientes a dominios
distintos.
La herencia entre entidades.
El soporte para múltiples instancias.
La conexión del Modelo Estático con el Modelo Dinámico.
73
7. Pruebas
7.1.
Herramientas para la realización de pruebas
Durante las pruebas se han utilizado una serie de herramientas externas, son las siguientes:
Valgrind[21] es un software de depuración que permite identificar recursos no liberados al finalizar la ejecución de un programa. Se utilizó con la interfaz gráfica
Alleyoop.
El depurador GBD, integrado con el entorno de desarrollo Eclipse[19], se utilizó para
comprobar la correcta creación y destrucción de hebras internas para el control del
los métodos de comportamiento.
La herramienta nddsspy, incluida en el producto NDDS[8][23]. Esta herramienta
permite monitorizar las los DataWriters, DataReaders y las muestras de datos que
aparecen en una red. De esta forma se controla la correcta creación y destrucción de
entidades remotas, ası́ como de los datos que se publican.
7.2.
Pruebas unitarias
Se han realizado las siguiente pruebas unitarias respecto a los siguientes módulos.
Modelo Estático. Se han probado dos aspectos de este módulo:
1. El parser o analizador sintáctico para los ficheros XML. Se ha comprobado que
el parser reconoce todas las etiquetas necesarias y extrae la información de manera correcta.
2. La funcionalidad ofrecida por las clases DDS XML. Para ello se ha escrito un
programa de pruebas que, para el fichero scenario.xml comprobaba el correcto funcionamiento del API ofrecida por estas clases. Esto incluye:
Verificación de los métodos de navegación por el árbol del escenario.
Búsqueda de entidades en el árbol.
Comprobación de los métodos de búsqueda y asignación de modelos dinámicos.
Modelo Dinámico. Se escribió un modelo dinámico de prueba para probar la funcionalidad de búsqueda de modelos dinámicos y asignación a entidades DDS XML.
Módulo de coordinación. Se han verificado las siguientes funcionalidades:
El analizador sintáctico para el lenguaje de interacción con el escenario recoge
correctamente las instrucciones del usuario.
74
7.3. Pruebas de integración
Las instrucciones del usuario son publicadas mediante DDS y recibidas correctamente en subscriptor de órdenes (CommandSubscriber).
La transferencia del fichero XML del escenario utilizando DDS para ficheros
que debı́an ser transmitidos en varios mensajes debido a su tamaño.
7.3.
Pruebas de integración
Las pruebas de integración consistieron en la verificación de la conexión entre los tres
módulos:
1. Verificación de la conexión entre el Modelo Estático y el Modelo Dinámico. Para ello
se escribió un programa que iniciaba varias entidades DDS descritas y ejecutaba su
comportamiento asociado.
2. Verificación de la conexión entre el módulo de coordinación y el Modelo Estático.
Se comprobó la correcta traducción de órdenes del usuario recogidas en el módulos
de coordinación 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 descrito
por el fichero scenario.xml. Se utilizaron, para ello, dos ordenadores conectados mediante una red de área local. Las acciones que se realizaron las siguientes acciones:
1. Carga y distribución del escenario.
2. Creación de todas las entidades DDS.
3. Inicio y parada del comportamiento.
4. Destrucción de las entidades.
5. Finalización de los CommandSubscriber de los nodos.
Además, se utilizó una aplicación DDS implementada de forma tradicional para comprobar la recepción correcta de datos publicados desde el escenario.
75
7. Pruebas
76
CAPÍTULO
8
RESULTADOS Y TRABAJO FUTURO
8.1.
Principales contribuciones de este trabajo
Los resultados del desarrollo de este proyecto han sido presentados en julio de 2008
en el IX Workshop on Distributed Object Computing for Real-time and Embedded Systems celebrado en Washington (DC, USA) bajo el tı́tulo “An XML-Based Approach to the Configuration and Deployment of DDS Applications”[48]
Este encuentro, organizado por la OMG, constituye un foro para ingenieros de software e investigadores en el campo de los sistemas distribuidos y de tiempo–real.
El trabajo actual ha conseguido cumplir los objetivos propuestos con las siguientes
conclusiones:
1. La división entre Modelo Estático y Modelo Dinámico para la descripción de aplicaciones minimiza la tarea de programación del sistema.
2. La flexibilidad de las interfaces de programación de estos módulos y el diseño del
repertorio de órdenes permite:
Evaluar el tiempo de creación y descubrimiento entre entidades DDS.
Desarrollar de manera gradual el número y actividad de las entidades que
participan en el escenario.
3. La descripción del escenario mediante ficheros XML permite diseñar pruebas distribuidas diferentes tan solo cambiando una lı́neas en estos ficheros.
4. La implementación sobre DDS de la coordinación y distribución del escenario presenta las siguientes ventajas:
77
8. Resultados y Trabajo Futuro
El desarrollador no necesita preocuparse sobre la sincronización de ficheros
XML. Por un lado, no se necesitan mecanismo externos como SSH o NFS para
sincronizar ficheros y órdenes, y, por otro, se puede desplegar el escenario en
redes de área amplia.
Se puede portar fácilmente el sistema desarrollado a cualquier plataforma soportada por un middleware DDS, incluso si la plataforma no cuenta con sistema
de ficheros como ocurre con algunos sistemas de tiempo–real.
8.2.
Trabajo futuro
Existen una serie de funcionalidades que podrı́an mejorar notablemente el sistema
desarrollado:
Inclusión de un sistema de auto-validación del escenario. Aprovechando que cada nodo
obtiene una copia del fichero XML que describe el escenario, ası́ como la secuencia
de órdenes que se distribuyen, cada nodo puede construir localmente un esquema
de qué entidades deberı́an haberse creado en el sistema. Relacionado este esquema
con la información de descubrimiento que el middleware DDS genera, podrı́a detectar de manera automática si el escenario se ha desplegado de manera adecuada o,
en cambio, hay nodos no accesibles.
Inclusión de un sistema de gestión de la seguridad. En la implementación actual, no
existen medidas de seguridad que impidan a un potencial atacante publicar información a través del tema de control
Extensión del Modelo Estático para soportar perfiles de QoS. En la actualidad varias implementaciones de DDS están incorporando perfiles de QoS que se describen bien a
través de ficheros XML o se incluyen de manera nativa en el producto. Estos perfiles agrupan parámetros de configuración de calidad de servicio que en su conjunto
permiten configurar grupos de entidades DDS para realizar comunicaciones de baja latencia, máximo rendimiento, etc. La integración con estos proyectos permitirı́a
describir con mayor potencia los escenarios DDS.
78
BIBLIOGRAFÍA
[1] W3C. Web services architecture, w3c working group note, feb 2004. Disponible en
la Web: http://www.w3.org/TR/wsdl.
[2] Erik Christensen et al. Web services description language (wsdl) 1.1, w3c note, mar
2001. 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 (corba/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, version 2.1. Technical report, Message Passing Interface Forum, 06 2008. Disponible en
la Web: http://www.mpi-forum.org/docs/mpi21-report.pdf.
[6] Object Management Group. Data distribution service for real-time systems specification, 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 la
Web: 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
[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 la
Web: http://portals.omg.org/dds/VendorsPage.
[15] Javier Sánchez-Monedero, J.M. López-Soler, and J. Povedano-Molina.
Scalable dds discovery protocols based on bloom filters. In Real-time and Embedded 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), versión
7.0. Technical report, 2008.
[17] Leslie Lamport. LaTeX: A Document Preparation System: User’s Guide and Reference
Manual. Addison-Wesley, 1985.
[18] Michel Ludwig et. al. Kile - an integrated latex environment, 09 2008. Disponible en
la 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.org/.
Valgrind, 09 2008.
Disponible en la Web: www.
[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 Operating
System 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 Technical
Standard Base Specifications, Issue 6.
80
[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. BernersLee. Hypertext transfer protocol – HTTP/1.1. RFC 2616, Internet Engineering Task
Force, 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 Web
Consortium (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 request 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 Wide
Web 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/RECxmlschema-0-20041028/.
[33] Xml (extensible markup language). Wikimedia Foundation, Inc., 09 2008. Disponible
en 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.
Disponible
en la Web: http://www.sparxsystems.com.au/products/mdg/tech/dds/
index.html.
81
[39] Jishnu Mukerji and Joaquin Miller. Mda guide version 1.0.1. Technical report, Object 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 realtime 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 Systems 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 Data
Centric 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 Desarrollo
de 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 Sánchez-Monedero, J.M. López-Soler, J. Povedano-Molina, and J.M. LópezVega. An xml-based approach to the configuration and deployment of dds
applications.
In Workshop on Distributed Object Computing for Real-time and
Embedded Systems, Washington, DC, USA, 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, and
D. Noveck. Network file system (NFS) version 4 protocol. RFC 3530, Internet Engineering Task Force, April 2003. Disponible en la Web: http://www.rfc-editor.
org/rfc/rfc3530.txt.
82
BIBLIOGRAFÍA
[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. Status: UNKNOWN.
[52] Reinier Torenbeek. Benchmarking omg dds for large–scale distributed systems. In
Real-time and Embedded Systems Workshop, Washington, DC, USA, 2008. Disponible
en la Web: http://www.omg.org/news/meetings/workshops/Real-time_
WS_Final_Presentations_2008/Session%207/07-02_Torenbeek.pdf.
83
BIBLIOGRAFÍA
84
APÉNDICE
A
INTRODUCCIÓN A DDS
Hoy en dı́a cada vez es más usual el uso de aplicaciones distribuidas. No es raro
encontrarse con una serie de aplicaciones que se ejecutan en distintas máquinas de forma
cooperativa dando la sensación de ser todo un mismo sistema.
Dentro de estos sistemas de computación distribuida, se pueden encontrar los denominados servicios de distribución de datos. En este caso, lo que se encuentra disperso no
son las aplicaciones, sino los datos de interés. Un ejemplo claro de ello puede ser la monitorización de sensores. Cada sensor puede encontrarse en un lugar distinto, los cuales
se comunican con la entidad monitorizadora por medio de alguna red de conexión. Las
Figuras A.1 y A.2 muestran cómo DDS crea una capa entre la aplicación y el sistema
operativo y la red.
En casos de datos distribuidos como los mencionados anteriormente, los requisitos
de tiempo real, fiabilidad, falla ante errores suelen ser muy importantes. Una arquitectura que mantenga todas estas cualidades de una manera adecuada es muy compleja de
construir. No serı́a razonable tener que diseñar para cada nueva aplicación que requiera
de distribución de datos una arquitectura que la soporte. Para paliar este problema, algunas empresas han dedicado esfuerzos en diseñar una infraestructura de distribución
de datos de una manera común y razonable. Este esfuerzo se ha materializado en lo que
hoy se conoce como Data Distribution Service (DDS)[6][44].
DDS proporciona un middleware que abstrae al programador de aplicaciones que necesiten de datos distribuidos de las tareas necesarias para la recogida de los mismos, con
máximas prestaciones. DDS deja de lado el clásico paradigma cliente/servidor , para usar
un nuevo paradigma mucho más adecuado para distribución de datos: publicación/suscripción.
DDS es por tanto un esfuerzo que normaliza el mecanismo de publicación/suscripción, de manera que puede ser añadido a cualquier aplicación de una manera sencilla.
85
Figura A.1: Arquitectura de un sistema de distribución de datos sin DDS
Figura A.2: Arquitectura de un sistema de distribución de datos con DDS
86
Figura A.3: Infraestructura de DDS
Las ventajas de usar DDS son:
1. Está basado en un paradigma conceptualmente sencillo como es publicación/suscripción
2. Es escalable dinámicamente
3. Está diseñado de modo que la sobrecarga del sistema sea mı́nima
4. Soporta comunicaciones de uno a uno, de uno a muchos o de muchos a muchos
5. Facilita al desarrollador enormemente la tarea de desarrollo de aplicaciones para
distribución de datos
La utilización de un nuevo paradigma supone cambiar la manera de trabajar de las
aplicaciones en muchos aspectos. El paradigma de publicación/suscripción no se basa en
la existencia de un servidor central, que es el que se encarga de satisfacer las solicitudes
del cliente. En lugar de ello, lo que se hace es que cada entidad (es decir, un computador
o sistema embebido que soporte DDS) que posea un dato susceptible de ser de interés
para otra entidad, informa al middleware de la disponibilidad del dato y publica dicho
dato (de ahı́ el término publicación). Por otro lado, existen entidades con interés hacia
ciertos datos. En este caso, cuando una entidad está interesada en un dato, lo que se hace
es que se informa al middleware de dicho interés, y éste 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)
Además de estos conceptos de publicación/suscripción, para facilitar la explicación del
trabajo realizado y de la arquitectura de DDS, se hace necesaria la explicación de nuevos
conceptos:
Descubrimiento (Discovery): Es el proceso que se realiza para identificar las entidades
que están publicando datos en DDS. Este proceso se inicia de forma casi instantánea
por DDS, y sólo requiere que el usuario proporcione un punto de partida donde
comenzar la búsqueda.
Tema (Topic) : Se define como tema cada uno de los distintos tipos de datos que son
publicados en DDS. Cada tema tiene sus propias caracterı́sticas, y sus tipos de datos
asociados.
Instancia (Instance): Un mismo tema (tipo de datos) puede ser publicado por muchas
entidades. Para que cada tema publicado se diferencie de los demás se usa un mecanismo de claves únicas. Por ejemplo, si tenemos datos de posición de diversos
radares (algo muy común en triangulación), para identificar de dónde proviene cada dato añadimos un campo de clave, para que cada dato de posición se utilice
correctamente en los cálculos de determinación de la posición 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 el
concepto de muestra. Éste se refiere a cada uno de los valores que toma una instancia a lo largo del tiempo. En el ejemplo de los radares empleado en la definición
de instancia, una muestra serı́a cada uno de las sucesivas tomas de datos de cada
radar que determinan la distancia del mismo en un instante determinado.
88
Dominio (Domain): Mecanismo de agrupamiento de entidades en DDS. Cada entidad
se encuentra situada dentro de un dominio por medio de un participante de dominio. Todas las aplicaciones que dispongan de participantes en un dominio, pueden descubrir e interaccionar con otras aplicaciones remotas con participantes en
el mismo dominio.Mediante este mecanismo se consigue aumentar la escalabilidad
ası́ como aislamiento de tráfico.
Una vez definidos estos conceptos, el siguiente paso es identificar las entidades presentes 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 continuación:
Suscriber: Es el punto de comunicación entre los DataReader y la aplicación. Se encarga
de gestionar las suscripciones (temas en los que se haya declarado interés).
Publisher: Es el encargado de publicar temas en un dominio, que serán recogidos por
los suscriptores situados en otro participante de dominio.
DataWriter: Es el punto de acceso de una aplicación a DDS para publicar datos que serán
publicados por un publisher
DataReader: Es el punto de acceso de una aplicación a DDS para recibir datos que fueron
recogidos por un suscriber
La Figura A.5 muestra el modelo conceptual DCPS (Data-Centric Publish–Subscribe,
publicación–subscripción centrada en los datos) que agrupa a las entidades descritas antes.
Además de lo anteriormente comentado, es conveniente mencionar una caracterı́stica
ventajosa de DDS: internamente, todas las entidades presentes en DDS, disponen de una
serie de polı́ticas de calidad de servicio (QoS). Estas polı́ticas son modificables de modo
que pueden afinarse en función del entorno de explotación final.
Polı́ticas de calidad de servicio (QoS) Las polı́ticas de calidad de servicio (QoS) son
uno de los atractivos de utilizar DDS. Mediante ellas se pueden gestionar aspectos muy
variados del funcionamiento de DDS, desde el descubrimiento de entidades remotas distribuidas, hasta parámetros de tiempo de recogida de datos o de usuario. Las polı́ticas de
calidad de servicio disponibles son:
Destination Order
Group Data
Liveliness
Deadline
History
Ownership
Durability
Latency Budget
Ownership Strength
Entity Factory
Lifespan
Partition
89
Figura A.5: Modelo conceptual de las entidades DDS
90
Presentation
Resource Limits
Transport Priority
Reader Data Lifecycle
Time-Based Filter
User Data
Reliability
Topic Data
Writer Data Lifecycle
De todas las polı́ticas mostradas, algunas sólo están disponibles para ciertos tipos de
entidades. Por otro lado sólo algunas de ellas pueden ser modificadas dinámicamente.
De todas estas polı́ticas de calidad de servicio, se destacan algunas de ellas, por ser de
mayor interés por sus caracterı́sticas:
Deadline Este parámetro se refiere al tiempo o intervalo mı́nimo de envı́o de datos por
parte de un DataWriter. Es útil para aplicaciones que publican los datos periódicamente. Si se supera el tiempo de Deadline entre muestras, la aplicación es notificada, quedando a decisión del desarrollador las acciones a llevar a cabo en este
supuesto.
Lifespan Se refiere al tiempo en el que un mensaje o muestra es válido. Si se supera el
tiempo para este mensaje, es eliminado de DDS.
Transport Priority Se refiere a la prioridad que recibe una muestra de datos en la capa
de transporte subyacente. Dicho valor es válido sólo si la capa de transporte subyacente soporta prioridad de mensajes.
Para una descripción más detallada de éstas y otras polı́ticas de calidad de servicio,
véase [44] ó [49].
91
92
APÉNDICE
B
DESPLIEGUE Y DESARROLLO DE UN ESCENARIO
INCREMENTALMENTE
El objetivo de este ejemplo es mostrar la secuencia de órdenes necesaria para realizar
un despliegue y ejecución incremental de un escenario.
Supóngase que se quiere desarrollar el siguiente escenario en el que se tienen dos
aplicaciones distribuidas descritas mediantes sus modelos estáticos y dinámicos:
Una aplicación publicadora de datos, Application radar o Radar.
Una aplicación subscriptora Application traffic control o Control Tráfico que trabaja
con los datos que recibe de entidades Application radar.
El primer paso consiste en la preparación del escenario. Se supone que las herramientas cmdmaster (rol de CommandPublisher) y cmdslave (rol de CommandSubscriber)
se están ejecutando en los nodos adecuados, tal y como muestra la Figura B.1. En todo
momento se indicará la secuencia de órdenes en el recuadro “Control Topic” y la figura
correspondiente mostrará los efectos de la ejecución de órdenes. Las flechas rojas indican
cómo el nodo CommandPublisher publica órdenes a través de tema de control, órdenes que
reciben los nodos CommandSubscriber.
El segundo paso (Figura B.2) consiste en la distribución de la descripción del escenario
a los nodos que participan en él mediante el la orden:
> load "scenario.xml"
Esta orden lee el fichero que el usuario le proporciona y lo distribuye a todos los nodos. Cada nodo seleccionará la aplicación adecuada consultando la etiqueta <deployment>
de cada aplicación. Ası́, las aplicaciones Radar se asignarán a los Nodos 1 y 2, y la aplicación Control Tráfico se asignará al Nodo 3.
93
Figura B.1: Representación de despliegue de un escenario: estado inicial
94
Figura B.2: Representación de despliegue de un escenario: distribución del escenario y
asignación de aplicaciones
95
Asignadas las aplicaciones a nodos, puede empezar la creación de algunas entidades.
Por ejemplo pueden crearse todos los Participants, Topics, Publishers y Subscribers mediante
la siguiente secuencia de órdenes:
>
>
>
>
>
create
create
create
create
create
"radar_participant"
"radar_topic"
"radar_publisher"
"tcontrol_participant"
"tcontrol_subscriber"
Tras la ejecución de esta orden los nodos correspondientes crearán este conjunto de
entidades.
Si el usuario quiere realizar una carga incremental del sistema creando poco a poco
las entidades y decide crear la primera instancia de los DataReader llamados “reader a”:
> create "reader_a" 1
La distribución de esta orden a los CommandSubscriber produce que cada uno de ellos
busque en su aplicación una entidad llamada “reader a”. Los que la tengan crearán la
instancia DDS de ı́ndice 1. Este es el caso del Nodo 3, que crea este DataReader (ver Figura
B.3) para subscribirse a la futura información 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 aplicación tenga una entidad llama
“writer a” creen una entidad DDS, en este caso un DataWriter, como puede observarse
en la Figura B.4. Este tipo de creación 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 orden
siguiente 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 1
y 2. Las flechas negras indican el tráfico de datos DDS que generan estas entidades como
resultado de la su actividad. El nodo 3 comienza a recibir los datos de los nodos 1 y 2.
Se puede incrementar el número de entidades con el fin de comprobar cómo reacciona el escenario ante el incremento de carga. Para ilustrar esto, se utilizan los siguientes
comandos para crear una segunda entidad del tipo “writer a”. Además se activa el comportamiento de estas entidades:
96
Figura B.3: Representación de despliegue de un escenario: creación varias entidades DDS
97
Figura B.4: Representación de despliegue de un escenario: creación de dos DataWriters
98
Figura B.5: Representación de despliegue de un escenario: inicio de la actividad de algunas entidades
> create "writer_a" 2
> start "writer_a" 2
La Figura B.6 muestra este incremento de la carga del sistema tras la aplicación de
estas órdenes.
Por último, se puede detener el comportamiento de todas las entidades de la red al
mismo tiempo con una orden que se aplica a todas las entidades. La Figura B.7 muestra
el efecto de los comandos listados a continuación, que producen el cese de actividad y
destrucción de todas las entidades DDS de la red (salvo las relativas a la coordinación del
escenario):
> stopall
> destroy
Por último, se puede finalizar la ejecución de la aplicación cmdslave mediante el
comando siguiente:
> terminate
99
Figura B.6: Representación de despliegue de un escenario: incremento del número de
entidades y actividad en el escenario
100
Figura B.7: Representación de despliegue de un escenario: destrucción de las entidades
DDS
La Figura B.8 ilustra el efecto de esta orden.
101
Figura B.8: Representación de despliegue de un escenario: finalización de la ejecución de
los CommandSubscribers
102
APÉNDICE
C
FICHEROS UTILIZADOS EN LAS PRUEBAS
C.1.
Fichero de definición de tipo de documento (DTD)
El Listado C.1 muestra el fichero DTD que define el formato de los ficheros XML
válidos.
<!−− d d s −−>
<!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 ,
participant entities ,
listener ? ,
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 | p u b l i s h e r | s u b s c r i b e r ) ∗>
<!−− t o p i c −−>
<!ELEMENT t o p i c
( topic name ? ,
type ? ,
listener ? ,
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 p u b l i s h e r
( datawriter ∗ ,
listener ? ,
behaviour ? ,
<! ATTLIST p u b l i s h e r name CDATA #IMPLIED>
<! ATTLIST p u b l i s h e r base name CDATA #IMPLIED>
<!−− w r i t e r −−>
<!ELEMENT d a t a w r i t e r (
datawriter topic ,
listener ? ,
behaviour ? ,
<! ATTLIST d a t a w r i t e r name CDATA #IMPLIED>
<! ATTLIST d a t a w r i t e r 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 ∗ ,
listener ? ,
behaviour ? ,
<! 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 d a t a r e a d e r
( datareader topic ? ,
listener ? ,
behaviour ? ,
<! ATTLIST d a t a r e a d e r name CDATA #IMPLIED>
<! ATTLIST d a t a r e a d e r 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 g o i n g t o b e c r e a t e d o f an e n t i t y .
T h i s i s n o t m a n d a t o r y s o t h e d e f a u l t v a l u e i f n o 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 definición de tipo de documento (DTD)
C.2.
Fichero de prueba scenario.xml
El Listado C.2 muestra el fichero XML utilizado en las pruebas del sistema.
104
C. Ficheros utilizados en las pruebas
<?xml v e r s i o n="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>

<d a t a w r i t e r 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>
</ d a t a w r i t e r>
<d a t a w r i t e r 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>

<s u b s c r i b e r name="subscriber1">
<l i s t e n e r>D D S S t r i n g X l i s t e n e r<l i s t e n e r>
</ s u b s c r i b e r>


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

<d a t a w r i t e r 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>

<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>
</ a p p l i c a t i o n>
<a p p l i c a t i o n name="application2">
<t o p i c name="hello_world_topic3">
<topic name>Hello world3</topic name>
<type>DDS Octets</type>
</ t o p i c>
105
C.2. Fichero de prueba scenario.xml
<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>
<d a t a r e a d e r name="reader2a" base name="reader2">
<d a t a r e a d e r name="reader2b" base name="reader2">
<s u b s c r i b e r name="subscriber2a" base name="subscriber2">
</ a p p l i c a t i o n>
</dds>
Listado C.2: Fichero de prueba scenario.xml
106
INDEX
bison, 70
parser generator, 65
BNF, 31
sample, 88
servidor, 85
suscriber, 89
suscripción, 85
cliente, 85
Tema, 88
Topic, 88
instance, 88
sample, 88
DataReader, 89
DataWriter, 89
DDS, 2, 85
middleware, 2, 85
discovery process, 88
DTD, 33
XML, 20, 33, 65
herencia, 33, 43, 66
IDL, 32
instance, 88
instancia, 88
listener, 20, 68
middleware, 1, 11, 85
Modelo Dinámico, 17, 41, 68
Modelo Estático, 17, 38, 58, 65
muestra, 88
parser, 20
proceso de descubrimiento, 88
publicación, 85
publicación/suscripción
Paradigma, 85
publisher, 89
107
INDEX
108
GLOSARIO
LATEX
Sistema de composición de textos.
DDS
DTD
Data Distribution Service. Servicio de distribución de
datos
Document Type Definition. Definición de tipo de documento, es una descripción de estructura y sintaxis
de un documento XML.
GNU
Gnu is Not Unix.
IDE
Entorno de desarrollo integrado o Integrated Development Environment en inglés
Interface Definition Language. Lenguaje de especificación de interfaces que se utiliza en software de
computación distribuida.
IDL
LALR
listener
LR
Middleware
Look-Ahead LR parser. Este tipo de analizador
sintáctico que toma un sı́mbolo por delante para determinar que regla de derivación aplicar
Significa oyente en inglés. En programación se refiere
a objetos que se subscriben a eventos o notificaciones
de un sistema.
Left to right, Rightmost derivation. Este tipo de analizador sintáctico lee caracteres de izquierda a derecha,
para producir derivaciones por la derecha
Software encargado de abstraer la aplicación de la
existencia de un entorno distribuido
109
Glosario
Modelo Dinámico
Modelo Estático
Descripción del comportamiento de entidades DDS.
Descripción de los parámetros y relaciones entre entidades DDS.
parser
Analizador sintáctico. Convierte el texto de entrada
en otras estructuras (comúnmente árboles).
UML
Unified Modelling Language. Lenguaje formal empleado para el modelado en el proceso de desarrollo
de software.
XML
Extensible Markup Language. Metalenguaje de etiquetado ampliable capaz de definir a su vez otros lenguajes.
eXtensible Markup Language
XML
YACC
110
Yet Another Compiler Compiler. Traducido significa
otro compilador de compiladores más

Una metodología basada en XML para la configuración y

Transcripción

Documentos relacionados

San Benito Health Foundation Centro Comunitario de Salud 351

We`re in the Business of Children`s Smiles

Coord Des Soc - Puerto Peñasco

Aviso de no Discriminación

La familia de excitadores/transmisores de la serie ADVANCAST