Grupo ARCO - Universidad de Castilla-La Mancha

IMPLEMENTACIÓN DE UNA PLATAFORMA DE PROPAGACIÓN DE
EVENTOS DDS MEDIANTE OBJETOS DISTRIBUIDOS, Y SU APLICACIÓN A
UN CASO DE ESTUDIO

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
INGENIERÍA
EN INFORMÁTICA
PROYECTO FIN DE CARRERA
Implementación de una plataforma de propagación de eventos
DDS mediante objetos distribuidos, y su aplicación a un caso
de estudio
Alicia Serrano Sánchez
Junio, 2012

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
Departamento de Tecnologías y Sistemas de Información
PROYECTO FIN DE CARRERA
Implementación de una plataforma de propagación de eventos
DDS mediante objetos distribuidos, y su aplicación a un caso
de estudio
Autor: Alicia Serrano Sánchez
Director: David Villa Alises
Junio, 2012

Alicia Serrano Sánchez
Ciudad Real – Spain
E-mail: Alicia.Serrano1@alu.uclm.es
Web site:
c○ 2012 Alicia Serrano Sánchez
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.3 or any later version published by the Free Software
Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy
of the license is included in the section entitled "GNU Free Documentation License".
Se permite la copia, distribución y/o modificación de este documento bajo los términos de la
Licencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada por
la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida en
el apéndice titulado «GNU Free Documentation License».
Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios son
reclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, y
cuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos en
mayúsculas o como nombres propios.

TRIBUNAL:
Presidente:
Vocal 1:
Vocal 2:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE VOCAL 1 VOCAL 2 SECRETARIO
Fdo.: Fdo.: Fdo.: Fdo.:

Resumen
Hoy en día, las tecnologías nos ofrecen la posibilidad de gestionar, controlar y manipular
gran cantidad de información. La oportunidad de poder utilizar esta información ha contribuido
a la creación de sistemas que pretenden solventar las dificultades a las que se exponen
ciertas situaciones que conllevan multitud de riesgos impredecibles. Estas sistemas llevan a
cabo tareas que requieren mucha precisión y exactitud, por ello es importante que la información
esté disponible en el momento justo y en el lugar adecuado. Son las tecnologías que
trabajan con comunicación de datos en tiempo real.
En este documento, se realizará un estudio y comprensión del estándar DDS [OMG07]
cuyo contenido es la descripción de un middleware para la comunicación entre publicadores
y suscriptores en sistemas distribuidos de tiempo real. Además, se analizan varias implementaciones
existentes de este estándar.
Como resultado, se realizará la implementación de un modelo de comunicación del tipo
publicador/suscriptor añadiendo al mismo los aspectos de calidad de servicio relativos
al filtrado de eventos especificado en el estándar DDS. Para ello se utilizará el middleware
orientado a objetos ZeroC Ice, que proporciona soporte y servicios avanzados para desarrollar
aplicaciones distribuidas basadas en invocaciones a método remoto.
VI

Índice general
Resumen
Índice general
Índice de cuadros
Índice de figuras
Índice de listados
Listado de acrónimos
Agradecimientos
VI
VII
XII
XIII
XV
XVII
XIX
1. Introducción 1
1.1. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Antecedentes 4
2.1. Middleware orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. ZeroC Ice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3. JAVA RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Data Distribution Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Espacio global de datos . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2. Canales (Topics) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3. Publisher/Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4. Lectura y escritura de datos . . . . . . . . . . . . . . . . . . . . . 15
2.2.5. Mecanismos y técnicas para conseguir información . . . . . . . . . 16
2.2.6. Filtrado de canales . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.7. Query Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.8. Calidad de Servicio (Quality of Service) . . . . . . . . . . . . . . . 17
VII

2.2.9. Control de las propiedades del tiempo real . . . . . . . . . . . . . . 18
2.2.10. Estudio de implementaciones existentes . . . . . . . . . . . . . . . 18
2.3. Proyecto Elcano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4. Proyecto Energos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1. Adquisición de información en tiempo real . . . . . . . . . . . . . 22
3. Objetivos 23
3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4. Método de trabajo y herramientas 25
4.1. Metodología de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1. Prototipado incremental . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2. Desarrollo dirigido por pruebas . . . . . . . . . . . . . . . . . . . 27
4.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1. Lenguajes de programación . . . . . . . . . . . . . . . . . . . . . 27
4.2.2. Aplicaciones de desarrollo . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.4. Gestión de proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.5. Herramientas hardware . . . . . . . . . . . . . . . . . . . . . . . . 28
5. Desarrollo del proyecto 29
5.1. Especificación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4.1. Suscripción y publicación sin filtros . . . . . . . . . . . . . . . . . 35
5.4.2. Filtrado de eventos a nivel de canal . . . . . . . . . . . . . . . . . 36
5.4.3. Filtrado a nivel de publicador . . . . . . . . . . . . . . . . . . . . 39
5.4.4. Filtrado a nivel de suscripción . . . . . . . . . . . . . . . . . . . . 41
5.4.5. Federación de canales . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.6. Modificación de filtros de un suscriptor . . . . . . . . . . . . . . . 46
5.4.7. Operaciones del servicio IceStorm . . . . . . . . . . . . . . . . . . 46
5.5. Aplicación Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6. Resultados 49
6.1. Aplicaciones del modelo a diferentes escenarios . . . . . . . . . . . . . . . 49

6.1.1. Escenario 1: Canales filtrados . . . . . . . . . . . . . . . . . . . . 50
6.1.2. Escenario 2: Subscriptores filtrados . . . . . . . . . . . . . . . . . 51
6.1.3. Escenario 3: Publicadores filtrados . . . . . . . . . . . . . . . . . . 52
6.1.4. Escenario 4: Federación de canales filtrados . . . . . . . . . . . . . 53
6.2. Recursos y costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.1. Repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7. Conclusiones y trabajo futuro 57
7.1. Objectivos alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A. Casos de estudio: OpenSplice y RTI 61
A.1. RTI Context DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.2. OpenSplice DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.2.1. Arquitecture OpenSplice DDS . . . . . . . . . . . . . . . . . . . . 62
A.2.2. Características de OpenSplice DDS . . . . . . . . . . . . . . . . . 63
A.2.3. Estudio de la comunicación de eventos OpenSplice DDS . . . . . . 64
A.2.4. Estudio del filtrado de eventos . . . . . . . . . . . . . . . . . . . . 68
B. Plan de pruebas 72
B.1. Suscripción y publicación sin filtrado . . . . . . . . . . . . . . . . . . . . . 72
B.1.1. Mensaje recibido . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
B.1.2. Mensaje no recibido . . . . . . . . . . . . . . . . . . . . . . . . . 72
B.1.3. Mensaje recibido en varios suscriptores . . . . . . . . . . . . . . . 72
B.1.4. Varios publicadores en un canal . . . . . . . . . . . . . . . . . . . 73
B.1.5. Varios canales y publicadores y un sólo suscriptor . . . . . . . . . . 73
B.2. Filtrado de eventos a nivel de canal . . . . . . . . . . . . . . . . . . . . . . 73
B.2.1. Comprobación de valores en los filtros . . . . . . . . . . . . . . . . 73
B.2.2. Tipos de los datos que circulan por el canal . . . . . . . . . . . . . 74
B.2.3. Filtrado en el canal con un suscriptor . . . . . . . . . . . . . . . . 74
B.2.4. Filtrado en el canal con varios suscriptores . . . . . . . . . . . . . 74
B.2.5. Se envía un dato inválido a un canal con filtro . . . . . . . . . . . . 74
B.2.6. Se indican varios filtros . . . . . . . . . . . . . . . . . . . . . . . . 74
B.3. Filtrado de eventos a nivel de publicador . . . . . . . . . . . . . . . . . . . 75
B.3.1. Correcta definición de las expresiones en los filtros . . . . . . . . . 75
B.3.2. Evento recibido con publicador filtrado . . . . . . . . . . . . . . . 75

B.3.3. Evento recibido con publicador filtrado en un canal filtrado . . . . . 75
B.3.4. Se envía un dato inválido a un canal . . . . . . . . . . . . . . . . . 75
B.3.5. Se envía un dato inválido a un canal con filtros . . . . . . . . . . . 76
B.3.6. Un publicador con filtros y otro sin filtros . . . . . . . . . . . . . . 76
B.3.7. Un publicador con filtros y otro sin filtros en un canal con filtros . . 76
B.3.8. Se indican varios filtros . . . . . . . . . . . . . . . . . . . . . . . . 76
B.4. Filtrado de eventos a nivel de suscripción . . . . . . . . . . . . . . . . . . 77
B.4.1. Subscripción con filtro en un canal . . . . . . . . . . . . . . . . . . 77
B.4.2. Varias suscripciones (con y sin filtro) a un canal . . . . . . . . . . . 77
B.4.3. Subscripción con filtro en un canal con su propio filtro . . . . . . . 77
B.4.4. Varias suscripciones a un canal con un publicador general . . . . . 78
B.4.5. Suscripción con filtro a un canal con publicador, ambos con filtros . 78
B.4.6. Suscripción con filtro a un canal con publicador, ambos con filtros . 78
B.4.7. Se indican varios filtros . . . . . . . . . . . . . . . . . . . . . . . . 79
B.4.8. Eliminar la suscripción a un canal . . . . . . . . . . . . . . . . . . 79
B.4.9. Federación de canales . . . . . . . . . . . . . . . . . . . . . . . . 79
B.4.10. Federación entre canales filtrados . . . . . . . . . . . . . . . . . . 79
B.4.11. Federación entre un canal con filtro y un canal sin filtro . . . . . . . 79
B.4.12. Federación con suscriptores con filtro y sin filtro . . . . . . . . . . 80
B.4.13. Eventos no válidos para el enlace especificado . . . . . . . . . . . 80
B.4.14. Eliminar el enlace entre canales . . . . . . . . . . . . . . . . . . . 80
B.5. Modificación del filtro en un suscriptor . . . . . . . . . . . . . . . . . . . . 81
B.5.1. Cambio de filtro y recepción de eventos . . . . . . . . . . . . . . . 81
B.5.2. Cambio de filtro y no recepción de eventos . . . . . . . . . . . . . 81
B.6. Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
C. Slices 83
C.1. Eventos de localización del proyecto Elcano . . . . . . . . . . . . . . . . . 83
D. Tipos de filtros 85
D.1. EventFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
D.2. EventFilterRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
D.3. EventFilterOver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
D.4. EventFilterBelow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
D.5. Función eval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

E. Estudio IceStorm 89
E.1. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
F. Manual de usuario 92
F.1. Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
F.2. Listar canales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.3. Crear un nuevo canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.4. Suscribirse a un canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
F.4.1. Subscribirse a un canal indicando filtros . . . . . . . . . . . . . . . 95
Bibliografía 96

Índice de cuadros
2.1. Operadores utilizados para filtros en DDS . . . . . . . . . . . . . . . . . . 17
5.1. Tipos de filtros en IceDDS . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1. Operadores comparativos para expresar filtros . . . . . . . . . . . . . . . . 50
6.2. Operadores lógicos para filtros . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3. Líneas de código separado por elementos . . . . . . . . . . . . . . . . . . 55
6.4. Líneas de código por lenguaje de programación . . . . . . . . . . . . . . . 55
6.5. Estimación de costes del proyecto . . . . . . . . . . . . . . . . . . . . . . 56
D.1. Operadores lógicos para expresar un conjunto de filtros . . . . . . . . . . . 87
D.2. Operadores comparativos para expresar filtros . . . . . . . . . . . . . . . . 87
XII

Índice de figuras
2.1. Invocación entre dos objetos . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Estructura de comunicación cliente-servidor en Ice . . . . . . . . . . . . . 5
2.3. Federación de canales IceStorm . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Arquitectura CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Arquitectura Java RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6. Estándar DDS [ucs11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7. Una única cola de lectura asociada a un canal sin clave especificada . . . . 14
2.8. Varias colas de lectura de cada instancia del canal con clave definida . . . . 15
2.9. Arquitectura del sistema Elcano . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Diagrama de flujo del prototipado incremental . . . . . . . . . . . . . . . . 26
5.1. Visión general para el desarrollo de la API con ZeroC Ice . . . . . . . . . . 30
5.2. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3. Arquitectura del modelo de comunicaciones suscriptor/publicador IceDDS . 33
5.4. Diagrama de secuencia de la creación de un canal con filtros . . . . . . . . 39
5.5. Diagrama de secuencia para un publicador filtrado . . . . . . . . . . . . . . 41
5.6. Procedimiento de una suscripción indicando filtros en el modelo de comunicaciones
IceDDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.7. Diagrama de secuencia de una suscripción con filtros . . . . . . . . . . . . 44
5.8. Federación de canales con filtro en IceDDS . . . . . . . . . . . . . . . . . 45
6.1. Vista de las áreas que cubre cada canal en el mapa . . . . . . . . . . . . . . 51
6.2. Ruta del usuario en el escenario 1 . . . . . . . . . . . . . . . . . . . . . . 51
6.3. Ruta del usuario en la aplicación IceDDSAndroid . . . . . . . . . . . . . . 52
6.4. Visión que muestra la pantalla del dispositivo con respecto al mapa completo 52
6.5. Publicadores existentes que limitan el envío de datos a zonas concretas . . . 53
6.6. Federación de canales filtrados . . . . . . . . . . . . . . . . . . . . . . . . 54
A.1. Arquitectura de un nodo de la tecnología OpenSplice DDS . . . . . . . . . 63
XIII

A.2. Puerta de enlace de la tecnología OpenSplice DDS . . . . . . . . . . . . . . 64
A.3. El consumidor se suscribe al canal . . . . . . . . . . . . . . . . . . . . . . 70
A.4. Paquete que contiene los datos de un evento de localización . . . . . . . . . 71
B.1. Escenario para la prueba de integración de IceDDS . . . . . . . . . . . . . 82
F.1. Pantalla principal de la aplicación aAndroid . . . . . . . . . . . . . . . . . 92
F.2. Error lanzado por aplicaciones Android . . . . . . . . . . . . . . . . . . . 93
F.3. Lista de canales en el sistema . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.4. Crear un nuevo canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
F.5. Eliminar filtro cuando se quiere crear un canal . . . . . . . . . . . . . . . . 94
F.6. Diálogo para realizar la suscripción a un canal . . . . . . . . . . . . . . . . 95
F.7. Suscripción añadiendo filtros propios . . . . . . . . . . . . . . . . . . . . . 95

Índice de listados
2.1. Ejemplo de interfaz SLICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Tipo de canal DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Tipos de canal con clave y sin clave . . . . . . . . . . . . . . . . . . . . . 14
2.4. Escritura en un canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Ejemplo de prueba unitaria . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Ejemplo de prueba de integración . . . . . . . . . . . . . . . . . . . . . . 34
5.3. SLICE para el modelo de comunicaciones DDS con ZeroC Ice . . . . . . . . 36
5.4. Definición del tipo para filtros . . . . . . . . . . . . . . . . . . . . . . . . 37
5.5. Tipo de código de los filtros . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6. SLICE para el modelo de comunicaciones DDS con ZeroC Ice . . . . . . . . 38
5.7. SLICE para el modelo de comunicaciones DDS con ZeroC Ice . . . . . . . . 40
5.8. SLICE para el modelo de comunicaciones DDS con ZeroC Ice . . . . . . . . 42
5.9. SLICE para el modelo de comunicaciones DDS con ZeroC Ice . . . . . . . . 45
5.10. Obtención y modificación de los filtros asociados a un canal . . . . . . . . 46
5.11. SLICE para el modelo de comunicaciones DDS con ZeroC Ice . . . . . . . . 47
6.1. Evento de localización de Elcano . . . . . . . . . . . . . . . . . . . . . . . 49
A.1. IDL utilizado para el ejemplo HelloWorld de OpenSplice DDS . . . . . . . 64
A.2. Suscriptor de OpenSplice DDS . . . . . . . . . . . . . . . . . . . . . . . . 65
A.3. Publicador de OpenSplice DDS . . . . . . . . . . . . . . . . . . . . . . . . 66
A.4. IDL que especifica el tipo de canal con una estructura de datos semejante a
la utilizada en los eventos del proyecto Elcano . . . . . . . . . . . . . . . . 68
A.5. Operaciones realizadas para la creación de un canal filtrado en OpenSplice
DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
C.1. Posibles eventos de localización del proyecto Elcano . . . . . . . . . . . . 83
D.1. Clase EventFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
D.2. Clase EventFilterRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
D.3. Clase EventFilterOver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
D.4. Clase EventFilterBelow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
E.1. Interfaces utilizadas para establecer un determinado tipo de suscriptor) . . . 89
XV

E.2. Canal encargado de la comunicación con los servicios IceStorm . . . . . . 90
E.3. Implementación de un suscriptor para el canal delegado . . . . . . . . . . . 91
E.4. Implementación de un publicador para el canal delegado . . . . . . . . . . 91

Listado de acrónimos
API
Arco
BDD
CEP
CORBA
DCPS
DDS
DDSI
ESI
ESP
GCC
GDS
GIOP
GPL
GPS
Ice
IDL
IIOP
OMG
OpenLS
ORB
MLP
QoS
RFID
RMI
RTI
Application Programming Interface
Arquitectura y Redes de Computadores
Behavior Driven Development
Complex Event Processing
Common Object Request Broker Architecture
Data-Centric Publish-Subscribe
Data Distribution Service
DDS Interoperability Wire Protocol
Escuela Superior de Informática
Event Stream Processing
GNU Compiler Collection
Global Data Space
General Inter-ORB Protocol
GNU General Public License
Global Positioning System
Internet Communications Engine
Interface Definition Language
Internet Inter-ORB Protocol
Object Management Group
Open Geospatial Consortium452
Object Request Broker
Mobile Location Protocol
Quality of Service
Radio Frequency IDentification
Java Remote Method Invocation
Real-Time Innovations
XVII

RTPS
SCADA
Slice
TCP
TDD
WiFi
Real-Time Publish-Subscribe
Supervisory Control And Data Acquisition
Specification Language for Ice
Transmission Control Protocol
Test Driven Development
Wireless Fidelity

Agradecimientos
«Creer es primo hermano de la mentira»
Mi padre
...pero parece ser que ya no es una creencia, sino una realidad, ha llegado el final. Todos
estos años han servido para formarme tanto académica como personalmente y, la verdad, me
da un poquito de pena abandonar el barco. Pero es la hora de empezar otra nueva etapa y
antes de ello, me gustaría agradecer a todas las personas que han estado a mi lado en este
trayecto de mi vida.
En primer lugar, me gustaría darle las gracias a mis padres. Ellos siempre me han dado
su cariño incondicional y me han enseñado a valorar y a disfrutar las buenas cosas de la
vida. También tengo que agradecer a mi hermana, que a pesar de ser la más pequeña, le debo
mucho, gracias por tu apoyo.
A mis compañeros de la universidad: Alicia, Luis, Miguel, Sergio, Pirri... con los que
he compartido inquietudes, desvelos, alegrías y entusiasmo, gracias por convertiros en unos
amigos admirables y espero que conservemos nuestra amistad durante mucho tiempo.
Gracias a mis compañeros del laboratorio por hacer del trabajo algo más que una simple
ocupación. Me alegro de haber entrado a formar parte de ellos, ya que está siendo una
experiencia muy satisfactoria tanto a nivel personal como profesional.
Agradezco el tiempo dedicado a mi director David Villa, sin el cual este proyecto no
hubiese llegado a su fin. Gracias por aumentar mis ganas de aprender y enriquecer mi formación.
Tampoco puedo olvidarme de mis amigos “no informáticos”: mis compañeras de piso y
amigas Selene y Chiqui, y mis amigos del pueblo Cristina (Poten), Jose, Silvia, M a José
(Patata), Ana y Consuelo. A ellos quiero agradecerles aguantar todas mis locuras y estar ahí
siempre, en los buenos y en los malos momentos.
Por último, agradecer a mi banda de música, ella me ha dado momentos inolvidables que
han hecho que mi vida sea más apasionante cada día que paso tocando entre sus músicos.
Gracias a todos.
XIX

A mis padres, por su paciencia y comprensión

Introducción
1
En la actualidad existen cada vez más sistemas centrados en la comunicación de datos
haciendo uso de la red. La eficiencia, escalabilidad y la calidad de servicio constituyen los
pilares básicos que representan a las tecnologías en sistemas de este tipo.
Estos sistemas suelen comprender despliegues de tecnología a gran escala en los cuales los
diferentes componentes que forman parte del mismo necesitan la recogida de la información
que circula entre ellos en tiempo real. Además, se caracterizan por ser sistemas distribuidos
que utilizan middlewares que hacen que las distintas partes que los constituyen esten
integradas de manera transparente para el resto del sistema. De esta manera se consigue independencia
tanto de arquitectura hardware, sistema operativo y lenguajes de programación
utilizados para el desarrollo de los diferentes módulos que lo forman. Simuladores, sistemas
de defensa naval y aéreo, control y gestión del tráfico aéreo, sistemas Supervisory Control
And Data Acquisition (SCADA) de gran escala,... son algunos ejemplos de tecnologías donde
la adquisición de la información en tiempo real es lo más importante.
Desde el año 2003, el grupo Object Management Group (OMG) [OMG97] publica la primera
versión del estándar Data Distribution Service (DDS) [OMG07], una especificación de
un middleware de tipo publicador/suscriptor con grandes ventajas prácticas para el transporte
de eventos complejos en tiempo real que, actualmente, se está utilizando en muchos de los
sistemas anteriormente mencionados.
A menor escala, también existen tecnologías que necesitan obtener información en tiempo
real. Es el caso de la localización de dispositivos en determinados espacios ya sean exteriores
o interiores. La tecnología GPS, ampliamente utilizada, hace posible el posicionamiento y el
guiado en lugares exteriores (calles, carreteras, autovías, etc.), pero el desarrollo de tecnologías
para el posicionamiento de personas en el interior de edificios está menos solventado.
En este ámbito se enmarca el proyecto Elcano que está siendo desarrollado en el grupo de
investigación ARCO. En este proyecto se combinan las tecnologías WIFI, Bluetooth y RFID
para posicionar al usuario dentro de un espacio limitado.
En Elcano es notable la importancia que adquiere la recepción de datos en tiempo real, ya
que la posición de los diferentes usuarios en el sistema tiene que ser lo más afín posible a
la posición real que mantienen los mismos. La enorme variedad de información a incluir en
1

1. INTRODUCCIÓN 2
los eventos de localización hacen aconsejable el uso de middlewares más escalables como el
especificado en el estándar DDS.
Teniendo en cuenta los problemas que existen en el Elcano, el presente proyecto persigue
dar una solución implementado un modelo de comunicaciones orientado a objetos, basado
en software libre, que utilice los servicios ofrecidos por el middleware ZeroC Ice introduciendo
parámetros de calidad de servicio atendiendo al estándar DDS de OMG. Aunque el
desarrollo del proyecto esté envuelvo dentro del proyecto Elcano, sirviendo éste como ayuda
o escenario real para ir construyendo el modelo de comunicaciones requerido, el producto
final será perfectamente aplicable a otras tecnologías.
1.1. Estructura del documento
A continuación se detallan los capítulos que componen este documento con una breve
descripción del contenido de cada uno de ellos.
Capítulo 2: «Antecedentes»
En este capítulo se realiza un breve repaso de los middleware de comunicaciones orientados
a objetos, el estándar Data Distribution Service (DDS) para sistemas en tiempo
real creado por OMG y los diferentes implementaciones existentes en el mercado.
Además, se describe las características de los proyectos Elcano, desarrollado en el
grupo ARCO, y Energos, que hacen a los mismos candidatos para implantar el modelo
de comunicaciones a desarrollar en este proyecto.
Capítulo 3: «Objetivos»
El objetivo principal del proyecto es la implementación de una API atendiendo a los
parámetros de calidad de servicio (QOS) del estándar OMG DDS [OMG07] utilizando
el middleware ZeroC Ice [ICEb].
En este capítulo se detallarán los objetivos específicos que se pretenden alcanzar a lo
largo del ciclo de vida del proyecto.
Capítulo 4: «Método de trabajo y herramientas»
La metodología que se sigue para el desarrollo de este proyecto es el prototipado
incremental junto con la técnica Test Driven Development (TDD) para la implementación
del mismo.
En este capítulo se describe la metodología y técnica anteriores, así como las herramientas
que se han utilizado durante la realización del proyecto.
Capítulo 5: «Desarrollo del proyecto»
En este capítulo se exponen el trabajo realizado en las diferentes iteraciones en las que
se ha dividido el proyecto, así como los requisitos iniciales y el diseño que tiene que
cumplir el modelo de comunicaciones a implementar.

1. INTRODUCCIÓN 3
Capítulo 6: «Resultados»
Se describen diversos escenarios reales en los cuales la utilidad de producto realizado
es claramente beneficiosa. También se describirán el esfuerzo realizado, las líneas de
código, la estimación de los costes del proyecto, ...
Capítulo 7: «Conclusiones y trabajo futuro»
El proyecto solo se centra en algunos aspectos concretos del estándar DDS, por ello,
permite la continuación del desarrollo añadiendo el resto de las funcionalidades que
proporciona dicho estándar.
En este capítulo se muestran los trabajos futuros y las diferentes opciones cuyo desarrollo
dotará al proyecto de mejoras beneficiosas en el ámbito de sistemas en tiempo
real.

Antecedentes
2
En este capítulo se realiza una presentación de los conceptos y herramientas que se han
utilizado para la elaboración del proyecto, así como una descripción y valoración de la especificación
DDS para un middleware del tipo publicador-suscriptor en sistemas distribuidos y
un estudio de algunos de los modelos existentes en el mercado. Este aprendizaje enriquecerá
el desarrollo del proyecto.
2.1. Middleware orientado a objetos
Un middleware de comunicaciones orientado a objetos es una plataforma utilizada para el
desarrollo de aplicaciones de sistemas distribuidos. Este tipo de plataforma permite al programador
abstraerse de la tecnología de red que se utiliza para establecer las comunicaciones
entre las distintas aplicaciones. La comunicación entre objetos se realiza mediante invocaciones.
En la figura 2.1 se muestra un ejemplo de una llamada de un objeto Cliente a otro
objeto Servidor que está en otro nodo de la red. La invocación a esta llamada es traducida
por el middleware para permitir que el mensaje sea enviado de un nodo a otro. En este tipo
de plataformas, el cliente es el que efectúa las peticiones y el servidor es la entidad que las
atiende, aunque las dos entidades pueden actuar de servidor o de cliente indistintamente.
Figura 2.1: Invocación entre dos objetos
En la actualidad existen diferentes alternativas que se ajustan a este comportamiento. A
continuación se explicarán algunas de las más importantes, aunque se hace más hincapié en
ZeroC Ice ya que es una parte importante del presente proyecto.
2.1.1. ZeroC Ice
Internet Communications Engine (ICE) es un middleware de comunicación orientado a
objetos con licencia GPL y desarrollado por la empresa ZeroC. Soporta varios lenguajes, lo
4

2. ANTECEDENTES 5
que permite una mayor adaptabilidad según las necesidades.
Al ser un middleware de comunicaciones orientado a objetos, ICE está basado en una
arquitectura cliente-servidor. Para establecer la comunicación entre estas dos entidades el
cliente necesita un proxy al objeto para poder solicitar sus servicios y el servidor tiene que
ser añadido a un adaptador de objetos para que el cliente pueda acceder a él a través del
middleware. En la figura 2.2 se muestra una visión general de esta arquitectura.
Figura 2.2: Estructura de comunicación cliente-servidor en Ice
A continuación se describen los conceptos básicos de la arquitectura ICE así como una
breve explicación de los servicios que ofrece.
Adaptador de objetos
El adaptador de objetos es un mecanismo que actúa como contenedor de los objetos del
servidor que son accedidos mediante invocaciones remotas. Cada adaptador de objetos tiene
una o varias direcciones asignadas que son conocidas como endpoints. Cada endpoint se
identifica mediante una cadena que contiene el protocolo de transporte utilizado, la dirección
IP y el puerto. Un ejemplo de endpoint es el siguiente:
tcp -h 127.0.0.1 -p 10000
donde tcp indica que se utilizará un protocolo de transporte TCP, se escuchará por la
interfaz con dirección 127.0.0.1 y en el puerto 10000.
Sirviente
El sirviente es un instancia del objeto remoto que recibe las invocaciones. Los sirvientes
son los objetos que se añaden a los adaptadores de objetos para que puedan recibir solicitudes

2. ANTECEDENTES 6
del exterior. El cliente realizará las llamadas remotas mediante un objeto proxy proporcionado
por el middleware.
Identidad de un objeto
Los sirvientes que son añadidos al adaptador de objetos se registran con una identidad
que los identifica de manera única en el sistema distribuido. Esta característica puede ser
añadida por el programador o de manera automática mediante los diferentes métodos que
proporciona el adaptador de objetos de ICE.
Proxy
El proxy se representa como una cadena de caracteres que contiene la identidad del objeto
unida al endpoint del adaptador donde se ha añadido. Por ejemplo:
Identity -t : tcp -h 127.0.0.1 -p 10000
La opción -t es el modo de acceso al objeto. Significa twoway, es decir, el sirviente recibe
peticiones y se espera una respuesta. Hay otras posibles opciones, como por ejemplo -o
(oneway) donde el sirviente recibe peticiones y no hay respuesta.
Communicator
El Communicator es el elemento más importante del middleware. Proporciona la comunicación
entre los clientes y los servidores en el sistema distribuido. Se encarga de crear los
adaptadores de objetos, proxys, identidades de objetos, ...
Slice
Specification Language for Ice (SLICE) es un lenguaje que se utiliza para describir las operaciones
sobre las que los clientes pueden hacer invocaciones. Aquí se define la interfaz y las
operaciones que serán accesibles mediante un proxy a un sirviente determinado y se establecen
independientemente del lenguaje de programación que se vaya a utilizar. ICE proporciona
herramientas para traducir la interfaz SLICE en diferentes lenguajes. Los lenguajes a los que
ICE da soporte son C++, Python, Java, .NET, PHP, Objective-C, Ruby y ActionScript. En el
listado 2.1 se muestra un ejemplo sencillo de SLICE.
module UCLM {
interface Hello {
void puts(string str);
};
};
Listado 2.1: Ejemplo de interfaz SLICE

2. ANTECEDENTES 7
Tanto el cliente como el servidor pueden estar implementados en diferentes lenguajes de
programación, lo que ofrece una ventaja bastante importante, ya que se puede implementar
clientes en diferentes lenguajes sin necesidad de cambiar nada en el servidor.
Servicios
ICE ofrece una serie de servicios que gestionan otras características para propósitos más
concretos:
IceStorm
IceStorm [icea] es un servicio que proporciona comunicaciones entre clientes y servidores
mediante la creación de canales de eventos. En este ámbito se habla de publicador
y suscriptor en vez de cliente y servidor. Los publicadores envían datos al canal
mediante invocaciones remotas que serán enviadas a los suscriptores de dicho canal.
De este modo, un único evento de un publicador puede ser enviado a múltiples suscriptores.
Cada canal está identificado unívocamente por un nombre y puede tener a su
vez múltiples publicadores y múltiples suscriptores.
IceStorm también soporta manejo de excepciones causadas por un comportamiento
inadecuado de la red o por la pérdida de suscriptores.
Los eventos IceStorm son unidireccionales, es decir, el publicador no recibe respuestas
desde los suscriptores.
Una de las características de este servicio es la federación. La federación permite realizar
enlaces entre canales. Cada enlace es una asociación unidireccional desde un canal
o otro y tiene asociado un coste que puede limitar la entrega en ese canal.
Estos enlaces hacen que los eventos publicados en un canal también sean publicados
en todos los canales que estén enlazados a él con coste que no exceda del indicado en
el momento de la creación del enlace.
La figura 2.3 representa un ejemplo de federación de canales. El canal T1 tiene enlaces
a T2 y T3. Los suscriptores S1 y S2 reciben todos los eventos publicados en T2 así como
los publicados en T1. El suscriptor S3 sólo recibe los eventos de T1 y el suscriptor
S4 recibe los eventos de T1 y T3.
Este servicio es el más relevante ya que será utilizado en el desarrollo de este proyecto.
IceGrid
IceGrid es un servicio de localización y activación para las aplicaciones ICE. Esto
permite que un cliente se comunique con un objeto remoto sin saber en qué máquina
y en qué puerto está (proxies indirectos).
Una de las características de IceGrid es la activación de los servidores bajo demanda,
es decir, cuando un cliente realiza una solicitud a un objeto en el servidor.

2. ANTECEDENTES 8
Figura 2.3: Federación de canales IceStorm
IceGrid permite la replicación mediante la agrupación de los adaptadores de objetos
de varios servidores en un único adaptador de objetos virtual y el balanceo de carga.
Además, soporta interfaces que proporcionan a las aplicaciones un control sobre su
actividad y notificaciones acerca de eventos significativos, lo que permite el desarrollo
de herramientas personalizadas.
IceBox
IceBox es un servidor de aplicaciones que gestiona el arranque y detención de distintos
componentes de una aplicación.
El servidor IceBox se configura a través de las propiedades de los servicios de la aplicación.
Estos servicios se pueden administrar de forma remota y compartir una interfaz
común que permite una administración centralizada.
IcePatch
IcePatch es un servicio que permite la distribución de actualizaciones de software a los
nodos que componen el grid. El servicio comprueba automáticamente la versión que
tiene cada nodo y envía las actualizaciones disponibles. Esta comunicación se puede
realizar de forma segura utilizando el servicio Glacier2 mencionado más adelante.
Glacier2
Glacier2 es un servicio de firewall 1 que permite una comunicación segura entre clientes
y servidores. Los datos que se transportan entre clientes y servidores están encriptados.
1 Sistema que permite bloquear los accesos no autorizados, así como permitir los autorizados.

2. ANTECEDENTES 9
Freeze
Freeze ofrece un servicio de persistencia que le permite guardar el estado de los objetos
ICE en una base de datos Berkeley 2 con muy poco esfuerzo. Freeze puede recuperar
automáticamente bajo demanda los objetos de una base de datos y actualizarla cuando
cambia el estado de un objeto.
2.1.2. CORBA
Common Object Request Broker Architecture (CORBA) [COR] es un estándar definido
por Object Management Group (OMG) para la programación de aplicaciones distribuidas.
CORBA es una de las arquitecturas actualmente más extendida. Permite que los componentes
puedan estar escritos en diferentes lenguajes y ejecutarse en diferentes máquinas. El modelo
cliente-servidor de CORBA (figura 2.4) es muy parecido al de ICE. Se utilizan interfaces IDL
para la comunicación entre dos o más aplicaciones.
Figura 2.4: Arquitectura CORBA
Una parte esencial de la arquitectura CORBA es el Object Request Broker (ORB) que se
encarga de facilitar la comunicación entre objetos, es decir, es el encargado de enviar las
invocaciones realizadas por los clientes y de retornar las repuestas a los mismos.
El estándar CORBA especifica un protocolo de transporte llamado General Inter-ORB Protocol
(GIOP) para las comunicaciones entre varios componentes ORBs e Internet Inter-ORB
Protocol (IIOP) es el protocolo utilizado para redes TCP/IP.
Existen muchas implementaciones del estándar CORBA tanto privativas como libres. Algunos
ejemplos son TAO [TCO10], OpenFusion CORBA [OPC] y ORBit2 de GNOME [GNO04].
2.1.3. JAVA RMI
Java Remote Method Invocation (RMI) [Inc06] es un middleware creado por Sun Microsystems
para aplicaciones desarrolladas en Java. La interfaz entre el cliente y el servidor
2 Biblioteca de software que proporciona una base de datos integrada de alto rendimiento para los datos con
formato clave/valor.

2. ANTECEDENTES 10
se especifica mediante clases abstractas definidas en java. Esto implica que los clientes y los
servidores tienen que estar desarrollados en java.
En la figura 2.5 se muestra el funcionamiento de la arquitectura cliente-servidor de RMI.
El servidor utiliza RMIRegistry para registrar los objetos que serán accesibles remotamente.
Cada objeto se asocia con un único nombre utilizando el sistema RMI’s simple naming
facility. Los clientes obtendrán una referencia a un objeto al cual hacer invocaciones remotas.
Cada objeto registrado debe implementar al menos la interfaz Remote definida en el
middleware RMI.
Figura 2.5: Arquitectura Java RMI
El inconveniente de tener que desarrollar los clientes y servidores en java hizo que no
se tuviera en cuenta esta alternativa, ya que uno de los intereses de este proyecto es poder
aplicar el modelo cliente-servidor independientemente de los lenguajes de programación en
los que se desarrollen.
2.2. Data Distribution Service
El estándar Data Distribution Service (DDS) de OMG fue introducido en 2004 para dirigir
las estrategias de los sistemas de defensa y aplicaciones aeroespaciales de manera distribuida.
El objetivo principal para la utilización del estándar fue el alto rendimiento y escalabilidad
en sistemas integrados de gran escala.
Actualmente, DDS está recomendado como clave para la administración y utilizado más
allá del aeroespacio y de la defensa como puede ser el comercio automatizado, simulaciones,
telemetría, etc.

2. ANTECEDENTES 11
DDS es una especificación de un API y un protocolo de interoperabilidad que define una arquitectura
basada en el modelo publicador-subscriptor para la comunicación de información
anónima entre proveedores y consumidores. Un proveedor de datos (publicador) publica flujos
de datos identificados por nombres llamados topics (canales) a los que los consumidores
pueden suscribirse. Además, una aplicación puede desempeñar al mismo tiempo el rol de
proveedor y el de consumidor.
Las características de DDS son:
Desacoplamiento: los publicadores y los suscriptores pueden estar en diferentes lugares.
Independencia de plataformas: los publicadores y suscriptores pueden estar implementados
en plataformas diferentes y escritos en diferentes lenguajes de programación.
Multiplicidad: pueden existir múltiples publicadores y suscriptores en el mismo canal.
Tiempo real: la información se entrega en el lugar y tiempo correctos. No entregar una
información necesaria en el momento preciso puede llevar a situaciones que entren en
conflicto con los objetivos deseados.
Fiable: se asegura la fiabilidad, seguridad e integridad a pesar de fallos de hardware y
software.
Alto rendimiento: permite distribuir grandes volúmenes de datos con una baja latencia.
Actualmente, el estándar DDS de la OMG está compuesto por DDS v1.2 API y DDS Interoperability
Wire Protocol (DDSI) v2.1 (figura 2.6). El estándar DDS API garantiza la portabilidad
del código fuente a pesar de que los proveedores tengan diferentes implementaciones,
mientras que el estándar DDSI asegura la interoperabilidad a través de implementaciones
DDS de diferentes proveedores.
Data-Centric Publish-Subscribe (DCPS) es la capa de DDS que proporciona la funcionalidad
requerida para que una aplicación pueda publicar y suscribirse a los datos específicos de
los objetos y consta de 5 módulos:
Modelo de la infraestructura – define las clases abstractas y las interfaces que son refinadas
en otros módulos.
Modelo del dominio – contiene la clase DomainParticipant que actúa como un contenedor
para otros objetos que componen la aplicación.
Modelo del canal – contiene las clases Topic, ContentFilteredTopic y MultiTopic. Estas clases
definen los diferentes canales. La clase ContentFilteredTopic define un canal al que
se le aplica un filtro y la clase MultiTopic se utiliza para suscribirse a múltiples canales
y combinar y/o filtrar los datos recibidos obteniendo como resultado un tipo.

2. ANTECEDENTES 12
Figura 2.6: Estándar DDS [ucs11]
Modelo de publicación – define las clases Publisher y DataWriter que son necesarias
para publicar los datos.
Modelo de suscripción – define las clases Subscriber y DataReader que son necesarios
para poder recibir los datos publicados.
2.2.1. Espacio global de datos
DDS está basado en un espacio global de datos (GDS) totalmente distribuido para evitar
puntos de ruptura o cuellos de botella. Los publicadores y los subscriptores pueden unirse
o abandonar un GDS en cualquier momento. Además, las aplicaciones pueden automáticamente
escribir y/o leer datos asíncronamente en/del GDS.
2.2.2. Canales (Topics)
Los canales proporcionan el punto de conexión base entre los publicadores y los suscriptores.
Para que la información viaje de manera correcta, el canal de un publicador en un nodo
debe coincidir con el canal de un suscriptor asociado en cualquier otro nodo.
Un canal está compuesto por un nombre, un tipo de datos y un conjunto de parámetros
de Calidad de Servicio(QOS) que son usados para controlar las propiedades no funcionales
del canal. Estos parámetros permiten a los diseñadores del sistema construir una aplicación
distribuida basada en requerimientos para cada parte específica de los datos.
El nombre del canal es una cadena que identifica unívocamente al canal en un dominio y

2. ANTECEDENTES 13
el tipo es la definición del contenido de los datos en el canal.
Se utiliza IDL como la forma para describir los datos de representación comunes en el
canal. IDL es una sintaxis estándar para expresar varios tipos manteniendo la independencia
de un lenguaje de programación específico.
Un tipo de canal está compuesto por una estructura IDL y una clave o un conjunto de
claves asociadas. La clave puede ser vacía o puede incluir un número arbitrario de atributos
definidos en el tipo de datos del canal.
La estructura puede tener uno o más campos y cada campo puede ser alguno de los siguientes
tipos:
char
octet
short
unsigned short
long
unsigned long
long long
unsigned long long
float
double
long double
boolean
enum
union
array o una secuencia
string
Si la clave del tipo de datos es vacía, el canal tiene una única instancia. Este tipo de
canales pueden ser considerados como singletons 3 . Los tipos de datos de los canales que
tienen claves definidas tienen una instancia por cada valor de la clave.
En listado 2.2 se muestra una definición de un tipo de canal cuya clave es la variable
provider.
struct LocEvent
{
string provider;
string msid;
long time;
};
#pragma keylist LocEvent provider
Listado 2.2: Tipo de canal DDS
Un ejemplo que muestra la diferencia entre estos dos tipos de datos de un canal puede
verse en 2.3.
3 Patrón de diseño que garantiza que haya una sola instancia de una determinada clase.

2. ANTECEDENTES 14
struct LocEvent
{
string provider;
string msid;
long time;
};
#pragma keylist LocEvent provider
struct KeyLessLocEvent {
string provider;
string msid;
long time;
};
#pragma keylist LocEvent
Listado 2.3: Tipos de canal con clave y sin clave
Si se escribe en el canal KeyLessLocEvent se modifica el valor que tenía, ya que es la
misma instancia (singleton). En el otro caso, si se escribe en LocEvent se modifica el valor
de una específica instancia del canal, dependiendo del valor de la clave.
El código 2.4 escribe dos muestras para la misma instancia (figura 2.7). Las dos muestras
están en la misma cola de lectura.
dds::Topic leTopic(‘‘KeyLessLocEventTopic’’);
dds:DataWriter dw(leTopic);
KeyLessLocEvent le = {’WIFI’, ’1001254589’, 2};
dw.write(le);
le = {’RFID’, ’1001254589’, 2};
dw.write(le);
Listado 2.4: Escritura en un canal
Figura 2.7: Una única cola de lectura asociada a un canal sin clave especificada
Si se escribe las mismas muestras para LocEvent el resultado es diferente. El código sería
igual pero las muestras están en dos colas diferentes (figure 2.8).

2. ANTECEDENTES 15
Figura 2.8: Varias colas de lectura de cada instancia del canal con clave definida
2.2.3. Publisher/Subscriber
Una infraestructura publicador/suscriptor es capaz de entregar los datos a los nodos adecuados
sin necesitad de establecer una comunicación individual.
Los publicadores sólo necesitan saber el tipo del dato específico de la información que
están enviando. Al igual que los suscriptores sólo necesitan saber el tipo específico del dato
que van a recibir.
2.2.4. Lectura y escritura de datos
En DDS se utilizan objetos de escritura y de lectura para poder establecer una comunicación
entre publicadores y suscriptores. Estos objetos se llaman DataReader y DataWriter.
Lectura de datos
Los objetos DataReader son el principal punto de acceso en una aplicación para acceder
a los datos que han sido recibidos en el suscriptor. Una vez creado y configurado con los
correctos parámetros QOS, una aplicación puede ser notificada de que un dato está disponible
de una de los siguientes maneras:
Retorno de una llamada. DDS ejecuta inmediatamente el retorno de la llamada cuando
un dato es recibido.
Polling del DataReader. Se pregunta constantemente si el dato está disponible.
Condiciones y esperas. La aplicación espera hasta que una condición es satisfecha y
entonces poder acceder al dato desde el DataReader.
Para leer los datos que son recibidos existen dos mecanismos. Uno de los mecanismos es
la operación read que proporciona acceso a los datos recibidos mediante el DataReader sin
eliminarlos de la memoria caché. De este modo los datos estarán disponibles para leerlos de

2. ANTECEDENTES 16
nuevo realizando una llamada a la misma operación.
El otro mecanismo es el que proporciona la operación take que da acceso a los datos recibidos
por el DataReader eliminándolos de la memoria caché, es decir, no se puede acceder
a los datos una vez leídos.
Escritura de datos
Un publicador utiliza los DataWriter como principal punto de acceso para publicar datos.
Una vez creado y configurado con las correctas características de QOS, una aplicación sólo
necesita realizar una llamada de escritura. El ciclo de vida de estos objetos es definido por
su estado. Hay tres posibles estados:
ALIVE: existe al menos un DataWriter escribiendo en la instancia.
NOT_ALIVE_NO_WRITERS: no hay DataWriter escribiendo en la instancia del canal.
NOT_ALIVE_DISPOSED: la instancia es desechada, es decir, no se escribirá más en ella.
En el caso de instancias a canales que no tienen clave, su ciclo de vida depende del ciclo
de vida del DataWriter.
2.2.5. Mecanismos y técnicas para conseguir información
DDS proporciona dos mecanismos para registrar la información: dominios y particiones.
Dominios
Un dominio establece una red virtual que agrupa a todas las aplicaciones que se están
ejecutando. Varias aplicaciones que se están ejecutando en el mismo conjunto de máquinas
están completamente aisladas si están en diferentes dominios. La comunicación entre
dominios no puede ocurrir a menos que sea especificada por la aplicación de usuario.
Particiones
Los dominios pueden ser organizados en particiones donde cada partición representa una
agrupación de canales. Las particiones DDS tienen que estar bajo un dominio para poder
publicar datos y suscribirse a los canales que contiene.
Las particiones se pueden utilizar para organizar canales en diferentes conjuntos o para
separar diferentes instancias. De esta manera se puede optimizar el rendimiento para aquellas
aplicaciones que tienen un gran número de instancias.
2.2.6. Filtrado de canales
Puede ocurrir que se necesiten determinados datos según el estado en el momento de obtener
información. Content-Filtered Topics son canales que restringen los datos que pueden

2. ANTECEDENTES 17
manejar. Cuando hay una suscripción a un canal filtrado, una aplicación recibirá aquellos datos,
de entre todos los publicados, que coincidan con el filtro indicado en el canal. La expresión
del filtro es similar a una cláusula SQL WHERE. Los operadores soportados se muestran
en la tabla 2.1.
Operador Descripción
= Igual
Distinto
> Mayor que
< Menor que
>= Mayor o igual que

2. ANTECEDENTES 18
• Confiable (REALIBLE): El middleware garantiza que todas las muestras en el
historial del DataWriter serán entregadas a todos los DataReader.
• Mejor esfuerzo (BEST EFFORT): Se acepta que el middleware no reintente la
propagación de algunas muestras.
HISTORY
HISTORY controla si DDS debería entregar sólo los datos recientes, tratar de entregar
todos los datos intermedios o una combinación de las dos anteriores.
Esta política puede ser configurada para proporcionar las siguientes semánticas:
• Conservar lo último (KEEP_LAST): DDS sólo mantendrá los datos más recientes
atendiendo a la variable depth de cada instancia de datos identificados por su
clave.
• Conservar todo (KEEP_ALL): DDS conservará todas las muestras de cada instancia
de los datos identificados por su clave.
Teóricamente lo único que asegura que una aplicación tendrá todas las muestras producidas
por el publicador es usar RELIABLE y KEEP_ALL de manera conjunta.
2.2.9. Control de las propiedades del tiempo real
La política DEADLINE permite definir el máximo intervalo de tiempo de entrega entre
las muestras de datos. Los objetos DataWriter escriben un nuevo valor al menos una vez
cada periodo de tiempo indicado por la variable deadline y los objetos DataReader son
notificados por DDS cuando pasa el intervalo de tiempo indicado por deadline.
2.2.10. Estudio de implementaciones existentes
En el apéndice A se describe y se analiza el estudio realizado sobre las implementaciones
RTI Context DDS [RTI] y OpenSplice DDS [OpS].
2.3. Proyecto Elcano
Elcano [VMV + 11] es un proyecto que se está desarrollando en el grupo de investigación
ARCO de la Escuela Superior de Informática (ESI) de Ciudad Real y tiene como objetivo
principal el diseño de una infraestructura de navegación en espacios interiores para personas
con necesidades especiales.
Para posicionar a los usuarios en estos espacios se estudia la combinación de diversos
sistemas de posicionamiento (WIFI, Bluetooth y RFID) de cara a obtener una mejor precisión
en la localización del usuario.
El sistema asume dos tipos de usuario, uno de ellos con necesidades especiales en cuanto

2. ANTECEDENTES 19
a movilidad se refiere, es decir, que utiliza una silla de ruedas para desplazarse por el medio,
y el otro con deficiencias en la percepción visual.
Para navegar por los espacios interiores, el usuario porta un dispositivo tipo smartphone
donde el sistema Elcano instalado le permite interaccionar con el entorno (tareas que se
pueden realizar, rutas hacia las tareas, reconocimiento de voz, etc.)
La arquitectura Elcano está ligada a los servicios basados en los estándares Mobile Location
Protocol (MLP) [MLP11] y Open Geospatial Consortium452 (OPENLS) [Mab08] que
son utilizados para los sistemas geográficos.
Figura 2.9: Arquitectura del sistema Elcano
La figura 2.9 muestra una vista general de los servicios que se ofrecen en el sistema Elcano.
Estos servicios se dividen en tres bloques:
Servicios de localización
Estos servicios son independientes del sistema Elcano, por lo que se pueden utilizar
en cualquier otro proyecto.

2. ANTECEDENTES 20
Existen dos tipos de servicios de localización. Por un lado están los proveedores de
eventos que informan de los usuarios que detectan bajo su área de alcance. Por otro lado
está el servicio de localización propiamente dicho, que se encarga de buscar a todos
los proveedores de eventos que están bajo su área y ofrece una interfaz de alto nivel
que los representa. Con los componentes anteriores y aplicando algoritmos complejos,
se obtiene la posición donde se encuentra el usuario con un cierto margen de error.
Servicios que ofrecen información del edificio
Contiene toda la información relativa al edificio y que se utiliza en el proceso de guiado
del usuario en el interior. Es un sistema distribuido ya que es necesario contar con
información relativa a diversos ámbitos:
• Información relativa a las tareas a desempeñar por un usuario en el entorno. Se
establecen puntos de interés asociados a las diferentes tareas que pueden desempeñar
los usuarios, así como las rutas entre los mismos. Para ello, se utilizan las
implementaciones del Directory Service y Route Service.
• Información relativa a la estructura del edificio (mapas, escaleras, salidas de incendios,
...) que permiten establecer rutas en el interior.
Servicios orientados al usuario
Es necesario que el sistema Elcano mantenga información sobre el estado de los usuarios
y que les ofrezca los servicios que les permitan llevar a cabo las tareas. Para ello se
vale de varios servicios. Por un lado utiliza un servicio genérico (User Manager) que
almacena las características de cada usuario como propiedades. Para incorporar nuevos
usuarios al sistema, el sistema Elcano ofrece el servicio User Access. Finalmente,
el servicio Mobile Service hace que los dispositivos registrados en el sistema puedan
utilizar los servicios que ofrece el sistema Elcano.
En estos momentos, en el proyecto Elcano, se está utilizando el middleware Ice de ZeroC,
que proporciona soporte y servicios avanzados para el desarrollo de aplicaciones distribuidas
basadas en invocación a método remoto. Aunque es un enfoque adecuado y sencillo, la
enorme variedad de información a incluir en los eventos de localización y la escalabilidad
del sistema hacen recomendable el uso de middlewares más escalables. Es por ello, que la
utilización del sistema que se plantea en este proyecto en Elcano proporcione importantes
ventajas con respecto a la localización de usuarios en el sistema.
Los eventos de localización podrían restringirse a un área determinado donde se encuentra
el usuario, mostrar tareas solo acortes a una temática (asistencia a conferencias, mostrar
aulas donde se imparten clase, etc.), incluir más o menos información según el zoom que
tenga el dispositivo utilizado por el usuario, ... Todas estas restricciones se conseguirían
implantando en el Elcano un sistema similar al propuesto en el estándar DDS de la OMG, que
ofrece diferentes maneras de filtrar la información de los eventos.

2. ANTECEDENTES 21
2.4. Proyecto Energos
Energos [dCENdIT] es un proyecto de investigación que estudia el desarrollo de tecnologías
que permiten la implantación de redes inteligentes de distribución de energía eléctrica.
Estas redes son capaces de gestionar en tiempo real el tráfico que se origina en las mismas.
Esto supone la integración de fuentes renovables de energía a diferentes niveles en la
red, la participación activa de los clientes para la gestión de la energía, mayores niveles de
eficiencia, seguridad y sostenibilidad del suministro eléctrico.
El proyecto pretende abordar las siguientes tareas:
Desarrollar herramientas de obtención de señales y medidas que permitan enlazar la
red con la generación distribuida, el consumo y las unidades de almacenamiento eléctrico
de forma más eficiente.
Investigación de las tecnologías necesarias para la creación de una plataforma que
permita la recogida de las señales de la red inteligente y proporcionar a las aplicaciones
la información necesaria para la gestión de dicha red inteligente.
Analizar y desarrollar métodos y técnicas para la gestión de la red que incrementen su
eficiencia.
Definir estándares y patentes que permitan establecer un protocolo de actuación, facilitando
el uso de la red inteligente.
En este proyecto toman parte importantes entidades que son necesarias para el correcto
funcionamiento de la red inteligente. Una de las entidades más importantes son los consumidores
ya que los requisitos de los mismos irán creciendo según las necesidades de los
mismos, tanto lo referente a calidad del servicio como el precio del mismo. Las comercializadoras
y distribuidoras juegan otro papel importante teniendo que mostrar las ventajas que
ofrece una red inteligente teniendo en cuenta el coste de cara al cliente.
El proyecto se enmarca dentro del ámbito de la investigación, por ello, los investigadores
también juegan un papel importante para el desarrollo de nuevas tecnologías que permitan
mayor eficacia en el sistema. Aquí es donde los suministrados de tecnología forman a su vez
un papel fundamental, exponiendo las posibilidades que ofrece la red inteligente para una
implantación de la misma lo más óptima posible.
Hay otras muchas entidades a tener en cuenta, como los generadores, los reguladores, los
transportistas, ... El conjunto de todas ellas contribuye a un mayor conocimiento para que el
desarrollo y explotación del sistema de red inteligente sea preciso e inmejorable en su mayor
medida posible.

2. ANTECEDENTES 22
2.4.1. Adquisición de información en tiempo real
El sector eléctrico es uno de los ámbitos con mayor demanda de recogida de información
en tiempo real. En los sistemas eléctricos se maneja gran cantidad de información que tiene
que ser recogida y procesada desde la producción hasta el consumo en cada uno de los hogares.
La redes inteligentes hacen posible una dispersión de la información con la posibilidad
de ofrecer nuevos servicios a los usuarios, optimización en el uso del recurso energético y el
conocimiento del comportamiento de la demanda y el abastecimiento energético que engloba
estas redes.
El proyecto Energos se basa en ciertas tecnologías para la recopilación, análisis y transformación
de la información requerida por la red inteligente. A continuación se citan las
tecnologías más importantes que tienen relevancia para el proyecto.
Sistemas middleware de baja latencia
Sistemas como DDS, Java RT, ICE, ... son capaces de operar con diversas capacidades
para la gestión de comunicaciones con diferentes exigencias en tiempo real. La mayoría
de estos servicios funcionan con sistemas distribuidos con requerimientos que
exigen confianza y fiabilidad en tiempo real.
Computación distribuida
Los paquetes de trabajo que se manejan en este proyecto requieren efectuar, en ciertos
casos, cálculos complejos sobre un flujo continuo de datos. De modo que el reparto
de carga es muy importante a la hora de realizar las diferentes tareas de cálculo que
conlleva el sistema de red inteligente.
Motores de procesamiento complejo de eventos
Complex Event Processing (CEP) y Event Stream Processing (ESP) [cep08] son tecnologías
muy útiles utilizadas para trabajar con los diferentes eventos que circulan por
la red. Permiten identificar patrones y de esa manera poder gestionar alarmas, fallos,
intrusos, ataques y multitud de situaciones graves en tiempo real.

Objetivos
3
Para delimitar el alcance del proyecto, se detallan a continuación los objetivos, tanto generales
como específicos, que permitirán comprender y entender la finalidad que se persigue
con el mismo.
3.1. Objetivo general
El objetivo principal del proyecto es la definición e implementación de una interfaz siguiendo
el estándar OMG DDS [OMG07] y utilizando para ello el middleware ZeroC Ice [ICEb].
La finalidad es la realización de un modelo de comunicaciones del tipo publicador/suscriptor
que permita compartir datos que serán independientes de la arquitectura del sistema.
3.2. Objetivos específicos
Se pueden distinguir los siguientes objetivos específicos:
Estudio del estándar DDS y sus implementaciones OpenSplice y RTI
Las características que se definen en el estándar DDS deben estar claras para saber
cómo se tiene que comportar el sistema a implementar. Para tener un mayor conocimiento
del funcionamiento de este tipo de modelo de comunicación, se estudiarán y
se harán ejemplos básicos de las implementaciones OpenSplice [OpS] de PrismTech y
RTI Connext DDS de la compañía Real-Time Innovations (RTI) [RTI].
Modelado e implementación de eventos DDS con ZeroC Ice
La parte a desarrollar se centrará en los aspectos de calidad de servicio relativos al
filtrado de eventos. Se pretende abarcar todas las posibles opciones de filtrado, es decir,
tanto en el publicador, en el suscriptor como en el canal de comunicación.
Aplicación de modelo desarrollado a los eventos del proyecto Elcano
Una de las finalidades de este proyecto es poder implantarlo en el proyecto Elcano
que se está desarrollando en el grupo de investigación ARCO de la ESI. Por ello, se
adaptarán los eventos DDS a los que se manejan en dicho proyecto para posteriormente
poder hacer una demostración de la funcionalidad del modelo de comunicaciones
23

3. OBJETIVOS 24
implementado.
Herramienta de monitorización
Esta herramienta constará de los componentes necesarios donde se permita ver los
eventos de comunicación entre publicadores y suscriptores, teniendo en cuenta el filtrado
de eventos.
Aplicación Android
Representación del funcionamiento del modelo en un dispositivo móvil o en tablet
cuyo sistema operativo sea Android [AND08].

Método de trabajo y herramientas
4
En este capítulo se describe la metodología de desarrollo elegida y las herramientas utilizadas
en la elaboración del proyecto junto con una breve descripción de cada una de ellas.
4.1. Metodología de trabajo
Desde un principio, el proyecto fue pensado para ser construido sobre un sistema distribuido.
Esto permite la utilización de los diferentes componentes independientemente de la
arquitectura del sistema que lo contenga.
Los requisitos del sistemas son especificados desde el inicio y la interacción con el cliente
es una parte importante del desarrollo. Esta interacción continua con el cliente permite obtener
más información detallada para el correcta realización del proyecto. Además, en cada
iteración proporcionará un prototipo totalmente funcional que ayudará a perfilar y añadir los
requisitos necesarios para mejorar el producto final.
Por estas razones, la metodología que se ha utilizado es prototipado incremental.
4.1.1. Prototipado incremental
El prototipado incremental [Som06] se basa en la realización de prototipos funcionales
a lo largo del desarrollo del sistema hasta llegar a un producto final. Estos prototipos son
entregados al cliente, de modo que éste puede comprobar el cumplimiento de los requisitos
especificados y mejorar y/o añadir nuevos. El cliente también puede detectar errores o carencias
que sirvan para refinar con más detalle los requisitos especificados y contribuir de este
modo a una mejora progresiva del prototipo final en cada iteración.
El esquema general de esta metodología se muestra en la figura 4.1. En cada iteración, se
definen nuevas funcionalidades del sistema, se describen más detalladamente y se desarrollan.
El prototipo obtenido se integra en el sistema y se entrega al cliente.
Las ventajas de utilizar esta metodología son las siguientes:
Los clientes puede utilizar el sistema desde las primeras fases de desarrollo, ya que se
obtienen prototipos intermedios con los que poder trabajar. Esto proporciona al cliente
25

4. MÉTODO DE TRABAJO Y HERRAMIENTAS 26
Figura 4.1: Diagrama de flujo del prototipado incremental
mayor confianza y creencia en la obtención final de un producto que cumplirá con los
requisitos especificados.
El desarrollo de prototipos intermedios hace más fácil determinar si los nuevos requisitos
planteados en las siguientes iteraciones son correctos y viables.
El riesgo de errores es muy bajo y los fallos pueden ser fácilmente solventados. En
cada iteración se prueba el prototipo realizado y además se realizan las pruebas de las
iteraciones anteriores para asegurar que el prototipo cumple también con las funcionalidades
añadidas anteriormente.
Las funcionalidades más importantes se entregan en las primeras fases de desarrollo
y es, por lo tanto, la parte del sistema que se somete a más pruebas. Esto conlleva al
desarrollo de un sistema más fiable.
Aunque no todo son ventajas. Disponer de prototipos intermedios puede conducir a situaciones
poco convenientes:
El cliente participa activamente en el proceso de desarrollo, lo que hace que los requisitos
puedan ser modificados continuamente debido a los cambios que el cliente crea
oportunos.
El mantenimiento del sistema puede ser problemático debido a la especificación de
nuevas funcionalidades en su desarrollo. Los desarrolladores, por su parte, pueden
especializar demasiado el producto lo que dificultaría un futuro mantenimiento por el
personal que no está familiarizado.
Para solventar en la medida de lo posible estos problemas, se ha optado por una combinación
de esta metodología con el desarrollo dirigido por pruebas.

4. MÉTODO DE TRABAJO Y HERRAMIENTAS 27
4.1.2. Desarrollo dirigido por pruebas
Desde el principio, el planteamiento fue realizar la implementación de este proyecto usando
una metodología ágil, basando esta idea en el previo conocimiento de las ventajas que
esta técnica ofrecía.
Test Driven Development (TDD) es una técnica incluida en lo que se conoce como metodología
XP [Bec00]. La filosofía de esta técnica es crear las pruebas antes que el código.
Cada prueba garantiza el cumplimiento de un requisito funcional concreto.
Las ventajas de esta técnica son numerosas y algunas de las más importantes son:
Sólo se implementa lo necesario para satisfacer la prueba y no más. No habrá código
que no sea necesario.
Se disminuye el número de errores. Cualquier modificación que afecte a algún componente
se detecta y se resuelve fácilmente.
El código es reutilizable y se puede cambiar con relativa facilidad.
La productividad aumenta considerablemente porque se invierte menos tiempo en la
depuración.
Para poder seguir esta técnica se deben tener claros los escenarios que se quieren probar.
Los escenarios serán la colección de pruebas que servirán para ir construyendo la API
del sistema. La descripción de los escenarios se hace utilizando la técnica Behavior Driven
Development (BDD). Esta técnica utiliza una plantilla que permite entender mejor el funcionamiento
global de sistema:
Given: Dado un contexto inicial.
When: Cuando se produce un evento.
Then: Entonces se obtienen unos resultados.
4.2. Herramientas
4.2.1. Lenguajes de programación
Python - lenguaje de alto nivel, interpretado, multiparadigma y orientado a objetos, creado
por Guido van Roosum. Se utiliza este lenguaje debido a la simplicidad del código y
su amplia librería estándar.
Este lenguaje se usa para implementar el particular modelo de comunicación de eventos
DDS y también es usado para la implementación de las pruebas realizadas.
C++ - lenguaje que proporciona mecanismos de orientación a objetos y es compatible con
C. Fue creado por Bjarne Stroustrup.
C++ se utiliza para implementar los ejemplos básicos de OpenSplice y RTI DDS.

4. MÉTODO DE TRABAJO Y HERRAMIENTAS 28
Java - es un lenguaje de programación a objetos desarrollado por Sun Microsystems. Android
está fuertemente ligado a java, es por ello que se utiliza este lenguaje para la
implementación de la aplicación para un dispositivo móvil o tablet con Android.
4.2.2. Aplicaciones de desarrollo
ZeroC Ice - Middleware de comunicaciones orientado a objetos, multilenguaje y multiplataforma
desarrollado por la empresa ZeroC [ICEb].
Este middleware es una parte importante del proyecto ya que se utilizan su servicio
IceStorm para la realización de un modelo de comunicación atendiendo al estándar
DDS.
GNU Make - herramienta para la generación automática de ejecutables [SMS06].
GNU Compiler Collection (GCC) - colección de compiladores del proyecto GNU [GCC10].
GNU Emacs - entorno de desarrollo de GNU que se ha utilizado tanto para la implementación
como para la documentación [EMA09].
Eclipse - entorno de programación [ECL04] utilizado para el desarrollo de la aplicación móvil
con sistema operativo Android. La integración del SDK de Android en este entorno
de programación es muy sencilla y fácil de manejar [AND08].
Mercurial - sistema de control de versiones distribuido. Se ha hecho uso de esta herramienta
para el código del proyecto y la documentación [MER12].
Atheist - plataforma de pruebas con la que se elaboran las pruebas de integración de este
proyecto. Es un herramienta desarrollada por el grupo ARCO [ATH01].
4.2.3. Documentación
L A TEX - lenguaje de marcado de documentos de carácter técnico y científica, utilizado para
realizar este documento [CLM + 03].
BibTex - herramienta para la descripción de referencias para documentos escritos con L A TEX.
4.2.4. Gestión de proyecto
Redmine - Aplicación web para la gestión de proyectos. Mediante esta herramienta se han
establecido las tareas a realizar a lo largo del ciclo de vida del proyecto. Utilizando esta
herramienta se tiene un visión constante del desarrollo del proyecto (tiempo dedicado
a cada tarea, tareas por terminar, nuevas tareas, etc.) [RED12].
4.2.5. Herramientas hardware
Motorola Tablet PC - Tablet con sistema operativo Android 4.0.

Desarrollo del proyecto
5
Este capítulo describe la planificación y desarrollo del proyecto. Se definen los requisitos
y las distintas iteraciones que se llevan a cabo, así como los prototipos obtenidos en cada una
de ellas. Además, la implementación se describe en base a las pruebas que se realizan para
validar el cumplimiento de los requisitos iniciales.
5.1. Especificación de requisitos
Tras el estudio del estándar DDS de la OMG se ha adquirido un conocimiento más detallado
de la funcionalidad que debe tener un modelo de comunicaciones basado en este estándar.
Como se menciona en los objetivos de la sección 3.2, este proyecto se centra en los aspectos
relativos al filtrado de eventos. La figura 5.1 muestra la parte de la especificación del estándar
DDS que se persigue y que servirá como guía para el desarrollo del sistema.
A partir del conocimiento adquirido debido al estudio del estándar DDS y de las implementaciones
RTI DDS y OpenSplice (apéndice A, y atendiendo a las diferentes funcionalidades
que aporta el servicio IceStorm de ZeroC Ice, se definen los siguientes requisitos funcionales:
Se utilizará el servicio IceStorm que añadirá la funcionalidad necesaria para la gestión
y administración de los canales DDS.
Se debe disponer de un gestor de canales DDS. Este componente se encargará de crear
los canales necesarios atendiendo a los parámetros solicitados.
Los canales podrán ser de dos tipos: canales generales donde tienen cabida eventos de
todo tipo y canales donde se indican filtros. Estos últimos canales limitan la comunicación
de ciertos eventos atendiendo a la descripción de los filtros indicados.
Un canal podrá tener múltiples suscriptores y publicadores.
Un publicador será el encargado de enviar eventos al canal del que es publicador.
Un suscriptor se podrá registrar en un canal para poder recibir los eventos del mismo.
Un suscriptor podrá registrarse en uno o más canales a la vez.
29

5. DESARROLLO DEL PROYECTO 30
Figura 5.1: Visión general para el desarrollo de la API con ZeroC Ice
La suscripción permitirá indicar uno o más filtros. De este modo, los suscriptores recibirán
únicamente la información que les interese.
Un canal puede disponer de publicadores filtrados, es decir, publicadores que solo
envíen datos que coincidan con los filtros especificados en la creación del publicador.
Un suscriptor puede anular la suscripción a un canal.
El gestor de canales DDS tendrá la posibilidad de eliminar canales.
La federación de IceStorm permitirá poder realizar enlaces entre canales filtrados. De
este modo se reducirá el número de canales creados ya que los enlaces permiten la
propagación de eventos de unos canales a otros.
5.2. Casos de uso
El análisis de requisitos permite identificar los diferentes casos de uso que tendrá el sistema
a desarrollar. La figura 5.2 muestra el diagrama de casos de uso indicando la interacción entre
las distintas entidades que componen el sistema.
Cada caso de uso tiene una funcionalidad interna que se detallará más adelante en cada
una de las iteraciones realizadas. Nótese que tanto un suscriptor como un publicador pueden
crear canales sin necesidad de que el sistema tenga una entidad que se encargue de ello. A
modo de resumen, a continuación se muestra un breve descripción de cada uno de los casos
de uso:
Crear canal
El gestor de canales del sistema crea un canal DDS propio indicando el nombre del

5. DESARROLLO DEL PROYECTO 31
Figura 5.2: Diagrama de Casos de Uso
mismo. Este parámetro representará al canal unívocamente en el sistema.
Crear canal filtrado
El gestor de canales del sistema crea un canal filtrado teniendo en cuenta los parámetros
de filtrado y el tipo de datos que tiene que filtrar.
Suscribirse a un canal
Cierta entidad puede suscribirse a un canal creado para que le sean enviados los eventos
que se publican en él.
Suscribirse a un canal indicando filtros
Una determinada entidad quiere suscribirse a un canal pero sólo desea obtener cierta
información que se maneja.
Obtener publicador de un canal
Se adquiere el publicador a un canal creado.

5. DESARROLLO DEL PROYECTO 32
Obtener publicador de canal indicando filtros
Se obtiene un publicador a un canal creado considerando parámetros de restricción.
Publicar en un canal
El publicador envía eventos al canal.
Eliminar suscripción a un canal
Un suscriptor desea no estar suscrito a un determinado canal.
Destruir un canal
Un canal puede ser eliminado del sistema.
Listar canales en el sistema
Se obtiene la lista de canales creados en el sistema.
Enlace a un canal
Un canal solicita que los eventos que se publican en un determinado canal sean propagados
a él.
5.3. Diseño
Una vez analizados los requisitos del proyecto, se continúa con la fase de diseño. En esta
fase se compone la estructura básica del sistema así como los componentes que toman parte
en ella.
El componente básico del que no se puede prescindir es de un gestor de los canales de
eventos DDS. Este componente será el encargado de crear canales acorde a las solicitudes
demandadas. También se encargará de realizar tareas como listar los canales que existen en
el dominio del sistema, proporcionar un determinado canal y tendrá la posibilidad de destruir
uno o más canales que existen en el dominio del sistema.
El gestor de canales de eventos DDS actuará como intermediario entre los publicadores y
suscriptores de los canales del sistema y para ello hará uso del servicio IceStorm de ZeroC
Ice. El servicio IceStorm proporcionará las ventajas que lo caracterizan como son llamada
única para distribuir la información a los suscriptores, independencia entre suscriptores y
publicadores, creación de canales de manera dinámica, ...
Otro componente será el canal de eventos DDS. La funcionalidad propia de esta canal será
proporcionar un mecanismo de suscripción, tanto si la suscripción se realiza indicando parámetros
de filtrado como si se realiza una suscripción sin indicar el filtrado, que será similar
a la suscripción realizada en los canales IceStorm. Además, proporcionará las operaciones
necesarias para obtener el publicador al canal. Al igual que ocurre en la suscripción, el publicador
puede asociarse con unos determinados filtros que implicará la publicación de los
eventos que se ajusten a los mismos.
Por último, el sistema contará con el objeto Publisher. Como su propio nombre indica

5. DESARROLLO DEL PROYECTO 33
Figura 5.3: Arquitectura del modelo de comunicaciones suscriptor/publicador IceDDS
será el publicador de eventos de un canal. En el momento de la publicación se encargará de
realizar las comprobaciones necesarias de filtrado para propagar los eventos a los suscriptores
que corresponda.
Todos los componentes anteriores constituirán un modelo de comunicaciones suscriptor/publicador
con la característica especial de poder realizar filtrado en la información que
circula por el sistema. La figura 5.3 muestra una visión general de la arquitectura que compondrá
el modelo de comunicaciones que se persigue en el desarrollo de este proyecto.
5.4. Implementación
El desarrollo del proyecto está dividido en diferentes iteraciones. En cada una de estas iteraciones
se irán añadiendo nuevas funcionalidades que aportarán las operaciones necesarias
para ir construyendo el producto final. El modelo de comunicaciones que se desarrolla en
este proyecto se llamará IceDDS.
La construcción de IceDDS se realiza utilizando el lenguaje de programación Python,
debido a la sencillez y claridad de programación que ofrece.
Hay que destacar que en cada iteración se lleva a cabo un plan de pruebas, tal y como se
explicó en la sección 4.1.1. El plan de pruebas de desarrollo del proyecto se puede ver en el
apéndice B.
Para conocer la dinámica de las pruebas realizadas para cada iteración, a continuación
se muestran ejemplos de los dos tipos de pruebas que se realizan a lo largo del ciclo del
proyecto.
Pruebas unitarias
Como se explica en el capítulo 4.1.2, las pruebas unitarias siguen la técnica BDD. En el
listado 5.1 se muestra un ejemplo sencillo de prueba unitaria realizada para comprobar

5. DESARROLLO DEL PROYECTO 34
que el subscriptor recibe el evento de un canal.
def test_filteredInTopicOneSubscriber(self):
# given a filtered topic, a publisher and a subcriptor
topic = self.topicManager.createTopic("foo")
publisher = Event.ListenerPrx.uncheckedCast(topic.getPublisher())
subscriber = mocks.Subscriber(self.adapter)
topic.subscribeAndGetPublisher(subscriber.proxy)
# when the publisher sends several events
publisher.sendData(MLP.Coord(1.0, 12.0, 0.0))
subscriber.servant.wait(2)
# then the subscriber receives the events
params = ’send_data’, (1.0, 12.0)
self.assert_(subscriber.servant.method_was_called(∗params))
self.assertEqual(1,
len(subscriber.servant.get_registered_calls()))
Listado 5.1: Ejemplo de prueba unitaria
En esta prueba se cuenta con un canal (topic), un publicador del canal (publisher)
y un suscriptor (subscriber). Como se puede observar, el suscriptor es un objeto que
imita el comportamiento del sirviente real de nuestro sistema, es lo que se denomina
mock. Este objeto simulará a un suscriptor real y dará el resultado esperado. El sirviente
cuenta con una lista de objetos que guarda los eventos recibidos. De esta manera, se
puede comprobar los datos recibidos en cada prueba realizada.
Para comprobar el correcto funcionamiento del envío de un evento, lo primero que hay
que hacer es suscribir el suscriptor al canal. En este momento, ya se tienen todos los
componentes necesarios para realizar un envío de un dato.
Las comprobaciones que se realizan después de que el publicador envíe un dato son
que la lista contenga solamente el número de datos enviados (en este caso 1) y se
comprueba que el dato recibido es el correcto.
La dinámica para el resto de pruebas realizadas es la misma: se crean los componentes
que forman parte de la prueba, se realiza la acción deseada y se comprueba la recepción
de los eventos a los correspondientes suscriptores.
Prueba de sistema
Las pruebas de sistema se realizan con la herramienta atheist [ATH01] que proporciona
una plataforma para realizar pruebas de integración del sistema. Las pruebas se
basan en términos declarativos. En el listado 5.2 se muestra un ejemplo de prueba de
integración en la cual se comprueba que los publicadores han enviado los eventos y los
suscriptores los han recibido.
admin = TestBG(
cmd = "./TopicManager.py −−Ice.Config=IceDDSManagerLocal.
config",
shell = True,

5. DESARROLLO DEL PROYECTO 35
cwd
= ’$basedir’)
subscriber = TestBG(
pre = [Poll(OpenPort(3000)), Poll(TaskRunning(admin))],
cmd = ’./subscriber.py −−Ice.Config=subscriber.cfg ’+
’"IceDDS/TopicManager −t:tcp −p 3000"’,
shell = True,
post = [FileContains("Received Event (2, 3, 4)"),
FileContains("Received Event (5, 14, 20)")]
publisher = Test(
cmd = ’./publisher.py "IceDDS/TopicManager −t:tcp −p 3000"’,
shell = True,
post = FileContains("Send data to general topic"))
TaskTerminator(admin, subscriber)
Listado 5.2: Ejemplo de prueba de integración
Se cuenta con la implementación de un gestor de canales (TopicManager) que se encarga
de crear un canal determinado. También se cuenta con las implementaciones
de un publicador y un suscriptor. En la prueba se especifican pre-condiciones para la
ejecución de los elementos anteriores y mediante las post-condiciones se comprueba
el correcto funcionamiento de cada parte. En este caso se comprobaría que en el
suscriptor se han recibido los eventos (2, 3, 4) y (5, 14, 20).
A continuación se describen detalladamente cada una de las iteraciones.
5.4.1. Suscripción y publicación sin filtros
Análisis y diseño
El modelo de comunicaciones que se implementará debe tener un gestor de canales. Este
gestor es el encargado de crear los diferentes canales que sirven como medio de comunicación
para los publicadores y suscriptores. Para ello se necesitará un adaptador de objetos y
la configuración necesaria para crear el gestor de canales DDS.
Del mismo modo, se necesita describir las operaciones necesarias para la suscripción y la
publicación en un canal.
Implementación
En primera instancia, se lleva a cabo la implementación de las pruebas unitarias necesarias
utilizando la herramienta nose [NOS]. En base a ellas, se implementan las clases TopicManager
que representa el servidor de canales de eventos DDS y Topic que representa a un
determinado canal de eventos DDS.
En la creación de un canal, se creará a su vez un canal IceStorm que formará parte de
nuestro canal de eventos DDS. De este modo, no se necesita implementar una gestión de
canales de eventos ya que esa funcionalidad la proporciona el servicio IceStorm.

5. DESARROLLO DEL PROYECTO 36
En en listado 5.3 se muestran el slice que contiene las interfaces definidas hasta el momento.
module DDS {
interface Topic
Object∗ subscribeAndGetPublisher(Object∗ subscriber);
Object∗ getPublisher();
};
}
interface TopicManager {
Topic∗ createTopic(string name);
};
Listado 5.3: SLICE para el modelo de comunicaciones DDS con ZeroC Ice
5.4.2. Filtrado de eventos a nivel de canal
Análisis y diseño
Se tiene que contar con un procedimiento para crear canales en los que se limita el tráfico
de los datos que no cumplan ciertos requisitos. De este modo se reduce el tráfico de datos en
un canal, pudiendo repartirse entre diferentes canales.
La implantación de un modelo como este en el proyecto Elcano sería una mejor solución
debido a la gran cantidad de información a incluir en los eventos de localización. Por ello, los
datos que se manejarán para la comunicación entre suscriptores y publicadores serán eventos
de localización de Elcano. Estos tipos vienen definidos en el apartado C.1 del apéndice C. Se
realizará un filtrado teniendo en cuenta las coordenadas del mapa donde se sitúa el usuario y
de este modo poder indicar filtros especificando determinadas áreas. Por ello, los eventos de
localización serán del tipo MLP.Coord.
Un obstáculo que se plantea es el conocer los tipos de datos que son enviados. Al canal
llegarán un conjunto de bytes que deberán ser transformados en el dato real que envió el
publicador. Para que esto se pueda llevar a cabo, en la creación de un canal con filtro se
incluirá una definición del dato que se va a manejar en el canal.
Implementación
Las pruebas realizadas para la comprobación y validación de esta característica conducen
a la necesidad de la creación de los siguientes elementos:
Filter
El tipo para los filtros es una secuencia de cadenas (listado 5.4). La decisión de la
especificación de los filtros con una cadena es debida a la posibilidad de indicar gran
cantidad de filtros diferentes sin necesidad de crear objetos específicos.

5. DESARROLLO DEL PROYECTO 37
sequence FilterSeq;
Listado 5.4: Definición del tipo para filtros
Cada cadena será la expresión del filtro que se compone del nombre de la variable (x,
y ó z) según la coordenada que se quiera filtrar, el operador y el/los valor/es asociados.
Por ejemplo:
’x in range(1,5)’
La tabla 5.1 muestra los tipos de operadores que se pueden especificar para indicar los
filtros.
Operador Descripción
== Igual
> Mayor que
< Menor que
in range( , ) Rango
Cuadro 5.1: Tipos de filtros en IceDDS
De manera interna, la expresión del filtro es transformada en un objeto manipulable.
En el apéndice D se describen los objetos que se crean internamente teniendo en cuenta
los filtros especificados.
TypeCode
TypeCode es el parámetro que indica el tipo de datos del evento. Se compone de un
conjunto de variables y sus tipos asociados. Este parámetro se necesita porque el canal
tiene que saber el contenido de los eventos para poder extraer los datos y realizar las
comparaciones correspondientes con los filtros especificados.
En el caso de DDS, el tipo de canal está compuesto por una estructura (struct) y para
determinar el tipo de un objeto, se hace introspección de la estructura en tiempo de
ejecución.
Agregar introspección de tipos a este proyecto supone un esfuerzo más a incluir en el
desarrollo. Por lo tanto, se plantea la alternativa de indicar el tipo de datos que manejará
el canal con la variable TypeCode nombrada anteriormente, dejando la introspección
para un trabajo futuro.
El listado 5.5 muestra la definición del parámetro TypeCode que lo constituyen un
conjunto de pares de cadenas (nombre de variable, tipo de variable).

5. DESARROLLO DEL PROYECTO 38
struct VariableTypeCode {
string variableName;
string variableType;
};
sequence TypeCode;
Listado 5.5: Tipo de código de los filtros
DataDissector
La clase DataDissector se utiliza internamente como un objecto que contiene la información
necesaria de los filtros de un canal. Esta clase proporciona un método que
comprueba que los valores de los datos enviados puedan circular por el canal, verificándolos
en los filtros indicados en la creación del canal.
Además de los componentes anteriores, la batería de pruebas añade las siguientes características:
Creación de un canal teniendo en cuenta los filtros indicados junto con el tipo de datos
de los eventos que manejará el canal.
Es necesario la realización de la clase Publisher ya que será la encargada de decidir
si un evento puede ser enviado al canal, utilizando para ello una comprobación de
los filtros del canal en el que se publica. La clase Publisher hereda de Blobject e
implementará el método ice_invoke. Todas las llamadas remotas al sirviente serán
manejadas a través de la función ice_invoke. Es en esta función donde se hace la
comprobación para validar que los valores recibidos concuerdan con los filtros especificados,
en este caso, en el canal.
Para una mayor fiabilidad en los datos enviados, en la creación del canal filtrado se comprueba
que el tipo de código especificado y los filtros indicados coinciden.
En en listado 5.6 se puede ver la especificación del slice con todos los componentes añadidos
en esta iteración.
module DDS {
struct VariableTypeCode {
string variableName;
string variableType;
};
sequence TypeCode;
sequence FilterSeq;
interface Topic {
Object∗ getPublisher();
Object∗ subscribeAndGetPublisher(Object∗ subscriber);
};
interface TopicManager {

5. DESARROLLO DEL PROYECTO 39
};
Topic∗ createTopic(string name);
Topic∗ createFilteredTopic(string name, FilterSeq filters,
TypeCode eventTypecode);
};
Listado 5.6: SLICE para el modelo de comunicaciones DDS con ZeroC Ice
En la figura 5.4 se muestra el diagrama de secuencia cuyo escenario es el envío de un
evento desde un publicador al canal filtrado. En este escenario se supone que el suscriptor ya
está suscrito a dicho canal.
Figura 5.4: Diagrama de secuencia de la creación de un canal con filtros
5.4.3. Filtrado a nivel de publicador
Análisis y diseño
Además del filtro a nivel de canal, los publicadores que se crean de cada canal, también
tienen que ser capaces de filtrar la información que envían. Los propios canales pueden
tener la intención de filtrar los eventos en determinadas ocasiones y el sistema, no por ello,
tenga que crear otros canales filtrados para ese propósito. En estas situaciones se crearían
publicadores filtrados que cumplirían las restricciones demandadas por el sistema.
Todo este razonamiento requiere la necesidad de facilitar un mecanismo donde se pueda
establecer un publicador propio de un canal con parámetros de filtros. Para este tipo de

5. DESARROLLO DEL PROYECTO 40
publicadores habrá que indicar, además del filtrado que se quiere hacer en un determinado
publicador, los filtros propios del canal en que se desea publicar.
Una particularidad que no se ha tenido en cuenta hasta este momento es la comprobación
de que las expresiones que definen los filtros sean proporcionadas de la manera correcta, es
decir, con la estructura que se define en la iteración anterior: “NombreVariable operador/es(tabla
5.1) valor/es”.
Implementación
La colección de pruebas para esta nueva funcionalidad exige la creación de una nueva
operación cuyos parámetros son un nombre que identifique unívocamente al publicador de
un determinado canal en el dominio del sistema, los filtros que el publicador utilizará para
enviar sólo ciertos eventos y el tipo que tienen los datos que se envían.
El listado 5.7 muestra el SLICE que se define en este punto del desarrollo del proyecto.
Como se puede observar en este listado, se introduce el lanzamiento de la excepción FilterError
mediante la cual se indica un error en la definición de un cierto filtro y además, en
el mensaje del error se especifica la manera correcta de definir esa expresión.
module DDS {
};
struct VariableTypeCode {
string variableName;
string variableType;
};
sequence TypeCode;
sequence FilterSeq;
exception FilterError {
string msg;
};
interface Topic {
Object∗ getPublisher();
Object∗ getFilteredPublisher(string publisherName, FilterSeq filters,
TypeCode eventTypecode) throws
FilterError;
Object∗ subscribeAndGetPublisher(Object∗ subscriber);
};
interface TopicManager {
Topic∗ createTopic(string name);
Topic∗ createFilteredTopic(string name, FilterSeq filters,
TypeCode eventTypecode);
};
Listado 5.7: SLICE para el modelo de comunicaciones DDS con ZeroC Ice

5. DESARROLLO DEL PROYECTO 41
La operación getFilteredPublisher se encarga de crear un publicador que aplica tanto
los filtros del canal al que está asociado, en caso de ser un canal con filtros, como los propios
filtros.
La figura 5.5 muestra el diagrama de secuencia cuyo escenario sería la existencia de un
publicador filtrado que manda un evento a canal filtrado.
Figura 5.5: Diagrama de secuencia para un publicador filtrado
5.4.4. Filtrado a nivel de suscripción
Análisis y diseño
Otra característica interesante que se plantea es que los suscriptores puedan definir una
serie de datos de los que quieren ser informados. Puede ser que en un canal existan datos
en los que el suscriptor no está interesado. Ante esta situación, el modelo de comunicación
del presente proyecto deberá proporcionar la operación u operaciones necesarias para poder
realizar una suscripción a un canal indicando unos determinados filtros.

5. DESARROLLO DEL PROYECTO 42
Implementación
La batería de pruebas implementadas para esta iteración hacen que se necesite la implementación
de una nueva operación para que el suscriptor pueda especificar que se quiere
suscribir a un determinado canal con unos filtros establecidos. Además, se añade la funcionalidad
de poder cancelar una suscripción de un canal.
Como el formato de los filtros se ha definido en iteraciones anteriores, solamente hace falta
la implementación del propio método que es necesario. De esta manera se añade al SLICE del
sistema como la función subscribeWithFilters quedando definido como se muestran en
el listado 5.8.
module DDS {
};
struct VariableTypeCode {
string variableName;
string variableType;
};
sequence TypeCode;
sequence FilterSeq;
exception FilterError {
string msg;
};
interface Topic {
Object∗ getPublisher();
Object∗ getFilteredPublisher(string publisherName, FilterSeq filters,
TypeCode eventTypecode) throws
FilterError;
};
Object∗ subscribeAndGetPublisher(Object∗ subscriber);
Object∗ subscribeWithFilters(Object∗ subscriber, FilterSeq filters,
TypeCode eventTypecode) throws FilterError;
void unsubscribe(Object∗ subscriber);
interface TopicManager {
Topic∗ createTopic(string name);
Topic∗ createFilteredTopic(string name, FilterSeq filters,
TypeCode eventTypecode);
};
Listado 5.8: SLICE para el modelo de comunicaciones DDS con ZeroC Ice
El mecanismo que se sigue en la operación suscribir con filtros es el siguiente:
1. Se crea un nuevo canal indicando un nuevo nombre y los filtros que se indican en la
suscripción.
2. Se añade el nuevo canal creado al adaptador de objetos del sistema.

5. DESARROLLO DEL PROYECTO 43
3. El suscriptor se registra en el nuevo canal creado.
4. Se obtiene el publicador del nuevo canal creado.
5. Se enlaza el publicador del nuevo canal. Esto en realidad lo que hace es subscribir el
publicador al canal principal. De ese modo, se consigue que los eventos enviados al
canal principal los filtre el publicador del canal creado y de ahí propagarlos al suscriptor.
La cancelación de la suscripción a un canal se delega al servicio IceStorm ya que este
proporciona la misma funcionalidad.
En la figura 5.6 y en el diagrama de secuencia 5.7 se muestra una visión general de la
dinámica de esta operación. En estos esquemas se puede ver con más claridad la dinámica de
la operación: el suscriptor es registrado en el nuevo canal creado y el publicador del mismo
es el que se encarga de la correspondiente comprobación para propagar los eventos.
Figura 5.6: Procedimiento de una suscripción indicando filtros en el modelo de comunicaciones
IceDDS
5.4.5. Federación de canales
Análisis y diseño
Como se explicó en el capítulo 2.1.1, la federación permite la propagación de eventos
de un canal a otro. La federación de IceStorm puede restringir la propagación de mensajes
asociando un coste a cada enlace. Cuando un mensaje es publicado en un canal, se compara
el coste asociado de cada uno de sus enlaces con el coste del mensaje y la propagación se
realiza únicamente a los enlaces cuyo coste sea igual o no excede del coste del mensaje.
En el modelo de comunicaciones del presente proyecto se pretende proporcionar federación
de canales pero teniendo en cuenta una restricción en los datos que se envían. La
propagación de eventos entre canales se hará en función del filtrado de los datos que se haya
especificado en cada enlace.

5. DESARROLLO DEL PROYECTO 44
Figura 5.7: Diagrama de secuencia de una suscripción con filtros
El uso de la federación de canales permite una reducción del número de publicadores. Un
solo publicador puede servir como publicador de eventos para varios canales.
Implementación
Para implementar esta funcionalidad no se puede utilizar la propia operación link de
IceStorm porque solo permite la propagación de todos los eventos si se indica un coste 0
o, en todo caso, restringir los eventos según el coste que lleven asociados. Por lo tanto, se
implementa una nueva operación que permite indicar de algún modo un filtrado en los datos
que pueden ser propagados.
La manera de conseguir una propagación acorde a determinados filtros es similar al mecanismo
realizado en la suscripción con filtros. La única diferencia presente es que los canales
implicados existen en el dominio del sistema o son creados previamente.
La figura 5.8 representa el mecanismo de enlace de estas características. Existen dos canales:
canal 1 y canal 2. El canal 2 quiere que ciertos eventos del canal 1 sean propagados hacia
él. Para que esto ocurra, se crea un publicador del canal 2 que contenga los filtros con los que
quiere realizar el enlace al canal 1. Por último, se hace una llamada a la función linkFiltered
pasándole como parámetro el publicador creado. La propia función hace una suscripción
de este publicador al canal 1. De este modo, el publicador actúa como un suscriptor filtrado
del canal 1 que a su vez filtra los eventos para propagarlos al canal 2.
Al igual que un canal puede enlazarse a otro, también existe la posibilidad de eliminar
ese enlace, para ello, se implementa una funcionalidad cuyo procedimiento será cancelar

5. DESARROLLO DEL PROYECTO 45
Figura 5.8: Federación de canales con filtro en IceDDS
el enlace. Realmente, la acción ejecutada es una anulación de la suscripción del publicador
previamente suscrito.
El listado 5.9 muestra el SLICE de IceDDS añadiendo las propiedades anteriores.
module DDS {
struct VariableTypeCode {
string variableName;
string variableType;
};
sequence TypeCode;
sequence FilterSeq;
exception FilterError {
string msg;
};
interface Topic {
Object∗ getPublisher();
Object∗ getFilteredPublisher(string publisherName, FilterSeq filters,
TypeCode eventTypecode) throws
FilterError;
};
Object∗ subscribeAndGetPublisher(Object∗ subscriber);
Object∗ subscribeWithFilters(Object∗ subscriber, FilterSeq filters,
TypeCode eventTypecode) throws FilterError;
void unsubscribe(Object∗ subscriber);
void linkFiltered(Object∗ publisher);
void unlinkFiltered(Object∗ publisher);
interface TopicManager {
Topic∗ createTopic(string name);
Topic∗ createFilteredTopic(string name, FilterSeq filters,
TypeCode eventTypecode);
};
};
Listado 5.9: SLICE para el modelo de comunicaciones DDS con ZeroC Ice

5. DESARROLLO DEL PROYECTO 46
5.4.6. Modificación de filtros de un suscriptor
Análisis y diseño
Los suscriptores que están interesados en determinados datos pueden cambiar de criterio
según la condiciones en un momento determinado. Por ello, el sistema debe dar soporte para
poder cambiar los criterios de filtrado de un suscriptor. De esta manera, los eventos que se
reciben en los suscriptores podrán cambiar según las necesidades de estos en determinadas
situaciones.
Implementación
Según el mecanismo que se sigue para realizar una suscripción con filtros, un nuevo canal
es creado con los filtros específicos que se indican en la suscripción. Por medio de este canal
es desde donde realmente el suscriptor recibe los eventos, por lo tanto, es este canal el que
debe ser modificado.
Para cambiar el filtro del canal, se añade la operación setFilters. Este método se encarga
de cambiar los filtros específicos del canal y modificar su publicador para hacer constar
que el filtro para limitar el transporte de datos ha sido cambiado. El canal en el que realmente
está registrado el subscriptor se obtiene al hacer la suscripción, es decir, el método subscribeWithFilters
devuelve el canal creado para, más tarde, poder modificar sus filtros.
Esto conlleva cambiar el tipo del objeto devuelto en la función subscribeWithFilters por
Topic*, es decir, un objeto tipo canal.
Además de poder cambiar los filtros, también se añade una operación para conocer los filtros
que tiene un canal determinado. Esta operación será getFilters, que devuelve el conjunto
de filtros asociado al canal.
En el listado 5.10 se pueden ver las dos operaciones que se añaden en el SLICE y que son
implementadas por la API IceDDS.
FilterSeq getFilters();
void setFilters(FilterSeq filters, TypeCode eventTypecode);
Listado 5.10: Obtención y modificación de los filtros asociados a un canal
5.4.7. Operaciones del servicio IceStorm
Análisis y diseño
El modelo de comunicaciones IceDDS debe realizar las mismas operaciones que ofrece
el servicio IceStorm además de las descritas anteriormente. Entonces, se deben añadir las
funcionalidades que faltan al modelo de comunicaciones que se desarrolla en el presente
proyecto.
Se usará el servicio IceStorm para delegarle todas estas funcionalidades.

5. DESARROLLO DEL PROYECTO 47
Implementación
Se añaden las siguientes operaciones al SLICE.
interfaz TopicManager:
• retrieve
• retrieveAll
interfaz Topic
• getName
• link
• unlink
• destroy
Para implementar estas operaciones no ha hecho falta utilizar la técnica TDD ya que la
funcionalidad en cada una de ellas se delega al TopicManager de IceStorm y no corresponde
en este proyecto probar el correcto funcionamiento de este servicio. El SLICE resultante se
muestra en el listado 5.11.
module DDS {
struct VariableTypeCode {
string variableName;
string variableType;
};
sequence TypeCode;
sequence FilterSeq;
exception FilterError {
string msg;
};
interface Topic {
FilterSeq getFilters();
void setFilters(FilterSeq filters, TypeCode eventTypecode);
string getName();
Object∗ subscribeAndGetPublisher(Object∗ subscriber);
Topic∗ subscribeWithFilters(Object∗ subscriber, FilterSeq filters,
TypeCode eventTypecode) throws FilterError;
void unsubscribe(Object∗ subscriber);
Object∗ getPublisher();
Object∗ getFilteredPublisher(string publisherName, FilterSeq filters,
TypeCode eventTypecode) throws
FilterError;
void link(Topic∗ linkTo, int cost);
void unlink(Topic∗ linkTo);
void linkFiltered(Object∗ publisher);

5. DESARROLLO DEL PROYECTO 48
};
void unlinkFiltered(Object∗ publisher);
void destroy();
};
dictionary TopicDict;
interface TopicManager {
Topic∗ createTopic(string name);
Topic∗ createFilteredTopic(string name, FilterSeq filters,
TypeCode eventTypecode);
Topic∗ retrieve(string name);
TopicDict retrieveAll();
};
Listado 5.11: SLICE para el modelo de comunicaciones DDS con ZeroC Ice
5.5. Aplicación Android
Se desarrolla una aplicación Android [AND08] para mostrar de manera visual como funciona
el modelo de comunicaciones IceDDS. Para el desarrollo de esta aplicación se ha
tomado en cuenta el entorno donde el proyecto de Elcano trabaja.
La aplicación se limita a reproducir los eventos de localización que se pueden percibir en
la planta baja de la ESI. Para ello, los usuarios conectados al sistema deben suscribirse a los
distintos canales que existen o a los canales cuyos datos sean de interés para él.
Además de una suscripción habitual, la aplicación permite suscribirse a los canales indicando
propios filtros. De esta manera, se tienen cubiertas las dos posibilidades de suscripción
que ofrece el modelo de comunicaciones IceDDS.
El cometido de esta aplicación es la visualización de los distintos eventos que llegan a los
canales por medio de los publicadores. Para diferenciar los eventos de distintos canales y/o
las diferentes suscripciones realizadas, la aplicación representa círculos de diferentes colores.
Este tipo de representación permite ver claramente el filtrado que se realiza, pudiendo
contrastar los diferentes datos que son enviados.
Para una completa guía del uso de la aplicación puede consultarse el apéndice F.

Resultados
6
En este capítulo se describirán las diferentes aplicaciones del modelo de comunicaciones
desarrollado a diferentes situaciones en el ámbito del proyecto Elcano. Igualmente, se hace
un análisis del esfuerzo de desarrollo del proyecto y del tiempo dedicado al mismo, así como
una estimación del coste total que ha supuesto su realización.
6.1. Aplicaciones del modelo a diferentes escenarios
En esta sección se enumeran diferentes escenarios en un sistema de localización de usuarios
en el interior de edificios para justificar las diferentes formas de filtrado que se han
elaborado en este proyecto.
Los eventos de localización que envía el sistema Elcano son del tipo que se muestra en el
listado 6.1. Los eventos de posicionamiento contienen la variable msid que es el identificador
de un determinado proveedor de eventos, time es el momento del envío del evento y theShape
contiene el tipo de datos que sirve para posicionar al usuario en el entorno. El SLICE que
contiene todos los diferentes tipos que pueden ir en el evento se pueden ver en el apéndice
C.
struct Position {
string msid;
long time;
Shape theShape;
};
Listado 6.1: Evento de localización de Elcano
Para simplificar los escenarios que se van a explicar a continuación, se supone que los
eventos enviados son del tipo MLP.Coord. Las coordenadas x,y y z representan los ejes del
plano, donde la variable x representa al eje horizontal, la variable y representa el eje vertical
y la variable z correspondería a la altura. Esta última variable no se tiene en cuenta debido
a que la representación de los eventos de localización se realizan sobre un plano en 2
dimensiones.
La forma de expresar los filtros, al ser una cadena o un conjunto de cadenas, proporciona
49

6. RESULTADOS 50
mayores posibilidades para indicar un conjunto de filtros que sean los más apropiados para
las necesidades de cada suscripción. En cada expresión de filtro, además de poder indicar los
filtros descritos en la tabla 6.1, se pueden añadir los operadores lógicos de la tabla 6.2 para
obtener filtros mucho más versátiles. De esta manera, el conjunto de filtros puede estar determinado
por una especificación mucho más detallada que se ajustaría más a las exigencias
de cada suscriptor.
Operador
Descripción
== Igual
!= Distinto
> Mayor que
< Menor que
>= Mayor o igual que

6. RESULTADOS 51
Figura 6.1: Vista de las áreas que cubre cada canal en el mapa
Figura 6.2: Ruta del usuario en el escenario 1
Previamente, el usuario ha tenido que suscribirse a los canales, ya sea de manera manual o
porque la aplicación subscribe a los usuarios del sistema directamente. En la figura 6.3 se
puede ver el rastro del camino del usuario. En la aplicación se muestra el punto únicamente
donde se encuentra el usuario en cada momento, de manera intermitente, pero en la figura
6.3 se muestra una vista del camino completo para su mejor entendimiento.
6.1.2. Escenario 2: Subscriptores filtrados
En la aplicación Elcano pueden recibirse multitud de eventos de localización diferentes
que proceden de diferentes proveedores de eventos (WIFI, Bluetooh y RFID). Además de los
eventos de localización se recibe información del entorno, tales como tareas, rutas, etc.
Si un usuario está viendo en la pantalla de la tablet cierta parte del mapa, lo más lógico es
pensar que sólo le interesarán los eventos que se reciban en ese área específica (figura 6.4).
El usuario, por lo tanto, estará suscrito a los canales de eventos indicando sus propios filtros
que serán los que delimiten el área mostrada en pantalla. Cuando hay un desplazamiento de
la pantalla, bien porque se ha generado un deslizamiento con el dedo, o se ha modificado el

6. RESULTADOS 52
Figura 6.3: Ruta del usuario en la aplicación IceDDSAndroid
zoom, este filtro cambiará para indicar el nuevo área de visualización.
Figura 6.4: Visión que muestra la pantalla del dispositivo con respecto al mapa completo
La posibilidad de cambiar el filtro de la suscripción disminuye la creación de canales
dentro del sistema, ya que la suscripción con filtros supone la creación de un canal filtrado
dentro de sistema (capítulo 5.4.4), pero de esta manera no hace falta una nueva suscripción,
simplemente se cambian los filtros del canal deseado.
6.1.3. Escenario 3: Publicadores filtrados
En capítulos anteriores se ha descrito como los canales pueden tener varios publicadores
y además restringir los datos que envían los mismos indicando un conjunto de filtros.
Con esta perspectiva, la situación que se trata en este escenario es la existencia de varios

6. RESULTADOS 53
publicadores de un canal global que se encargan de enviar eventos atendiendo a coordenadas
específicas. En la figura 6.5 se pueden observar los distintos publicadores que podrían existir
en un canal que maneja eventos correspondientes al mapa completo donde puede navegar el
usuario.
Figura 6.5: Publicadores existentes que limitan el envío de datos a zonas concretas
Cada publicador se encarga de enviar los eventos de localización correspondientes a una
zona específica y así, la responsabilidad del envío de datos estaría repartida entre varios.
En cada publicador se puede limitar los eventos de localización que se salen del mapa, las
zonas por las que el usuario no tiene acceso, otras zonas donde no es relevante mantener la
información de la posición del usuario (por ej.: los aseos), ...
6.1.4. Escenario 4: Federación de canales filtrados
Los servicios que ofrece el proyecto Elcano se podrían ampliar y expandir a varios edificios
de la Escuela de Informática. De este modo, se tendría un control de los usuarios en
los diferentes edificios. Cada edificio supone la recogida de información de su entorno, así
como definir las tareas que los usuarios pueden realizar y los caminos o rutas que deben
seguir desde su posición a la tarea elegida.
El escenario descrito constaría de un monitor de sistema donde se mostraría los eventos
de localización de todos los edificios. Estos eventos se enviarían a un canal que a su vez
propagaría la información a los diferentes canales que representarían a cada edificio. En la
figura 6.6 se muestra un esquema general del funcionamiento del sistema.
En este supuesto, se puede ver claramente que los datos serán propagados por medio de
los enlaces realizados y por lo tanto, cada canal de eventos de cada edificio podrá a su vez
tener sus propios suscriptores (filtrados y no filtrados).

6. RESULTADOS 54
Figura 6.6: Federación de canales filtrados
6.2. Recursos y costes
La duración del proyecto ha sido de 10 meses, aunque el tiempo dedicado al desarrollo del
proyecto ha estado compaginado con el trabajo dentro del grupo ARCO, con lo cual no se ha
podido realizar una dedicación a tiempo completo.
Al inicio, fue necesario el estudio y el enriquecimiento sobre el estándar DDS en el que
se centra el proyecto, así como aprender a utilizar las diferentes tecnologías que se han
empleado para su desarrollo (Icestorm, Android, etc.). Todo esto supuso un incremento del
esfuerzo realizado para la elaboración de este proyecto.
A continuación, se muestra el número de líneas de código del proyecto divididas por los
diferentes elementos desarrollados (tabla 6.3).
La tabla 6.4 muestra un resumen del número líneas de código totales por cada uno de los
lenguajes de programación empleados.
Finalmente, la tabla 6.5 presenta la estimación del coste del proyecto generado usando
sloccount [SLO] basado en el modelo COCOMO. En esta estimación no se tiene en cuenta
los IDL y SLICE definidos, ya que la herramienta no proporciona soporte para los mismos.
6.2.1. Repositorio
El código del proyecto se encuentra en bitbucket.org [bit], que es un servicio de alojamiento
basado en web para proyectos. Para descargar el repositorio se ejecuta la siguiente
sentencia en un terminal:

6. RESULTADOS 55
$ hg clone https://bitbucket.org/arco_group/icedds
Este servicio permite utilizar Mercurial [MER12] como sistema de control de versiones.
Esta herramienta nos permite ver los cambios realizados en cada actualización, lo que permite
hacer un seguimiento del desarrollo del proyecto.
El repositorio de la documentación también se encuentra en bitbucket.org y se descarga
con la siguiente sentencia:
$ hg clone https://bitbucket.org/arco_group/pfc.icedds
Componente Lenguaje N o líneas
RTI DDS C++ 301
IDL 5
XML 39
Pruebas 18
OpenSplice DDS C++ 1520
IDL 16
Pruebas 63
Modelo IceDDS Python 580
Slice 58
Pruebas 1104
Aplicación Android Java 1544
XML 480
Cuadro 6.3: Líneas de código separado por elementos
Lenguaje N o líneas
Python 580
C++ 1821
Java 1544
XML 519
Pruebas 1185
Slice 58
IDL 21
Cuadro 6.4: Líneas de código por lenguaje de programación

6. RESULTADOS 56
Costes del proyecto
N o líneas
Total de líneas física de código (SLOC) 5649
Esfuerzo de desarrollo en personas-año (personas-mes) 1.23 (14.78)
Estimación de calendario, en Años (Meses) 0.58 (6.96)
Número estimado de desarrolladores 2.12
Coste Total estimado de desarrollo
53,442 e
(Salario medio: 18,000 e/año brutos)
Cuadro 6.5: Estimación de costes del proyecto

Conclusiones y trabajo futuro
7
En este capítulo se describen los objetivos alcanzados durante la elaboración de este proyecto.
Además, se realizan una serie de propuestas como trabajo futuro para mejorar e incrementar
la eficiencia y funcionalidad del modelo presentado en este proyecto.
7.1. Objectivos alcanzados
Después de realizar un análisis del trabajo desarrollado en el capítulo 5, se puede afirmar
que se ha alcanzado satisfactoriamente el objetivo general del proyecto (capítulo 3).
Las herramientas y servicios desarrollados en el proyecto proporcionan un sistema que
aprovecha los beneficios y ventajas que ofrece el servicio IceStorm (llamadas simples para
distribuir la información a los suscriptores, independencia entre entidades del sistema, etc.)
añadiendo calidad de servicio por la que se caracteriza el estándar DDS de la OMG.
Con respecto a los objetivos específicos (capítulo 3.2), se ha cumplido con todos ellos.
Además del estudio del estándar DDS realizado en la primera fase del proyecto junto con el
estudio de las implementaciones existentes del mismo contribuyó a la realización del modelo
de comunicaciones de eventos DDS con ZeroC Ice poniendo gran interés en los parámetros de
calidad de servicio que añaden mayor fiabilidad, calidad y eficiencia al modelo construido.
A través de la definición de un evento semejante a los datos manejados en el proyecto Elcano
permitió la construcción del modelo teniendo en cuenta un entorno real de propagación de
eventos.
El desarrollo orientado a pruebas ha hecho posible construir un modelo que cumple a la
perfección los requisitos funcionales que se pretendían. En cada iteración se ejecutaban las
pruebas para corroborar que todo seguía funcionando correctamente. Esto permitió localizar
errores más rápidamente y resolverlos de manera sencilla, por lo que el tiempo que se ha
dedicado a la depuración ha sido casi insignificante.
Para dar acceso a los distintos aspectos que constituyen el modelo de comunicaciones
desarrollado, se ha realizado la implementación de un servicio por medio del cual se pueden
acceder a las diferentes operaciones que se necesitan para crear la comunicación entre publicadores
y suscriptores. Además, actúa como gestor de canales en el dominio del sistema.
57

7. CONCLUSIONES Y TRABAJO FUTURO 58
Por último, para demostrar su utilidad en un caso real y mostrar de forma visual las características
de las que consta el modelo de comunicaciones creado en este proyecto, se ha
realizado una aplicación Android minimalista que muestra la recepción de los distintos eventos
ateniendo a las necesidades del usuario. En esta aplicación se puede interactuar con los
servicios de suscripción y creación de canales que proporciona el modelo.
7.2. Trabajo futuro
Aunque el modelo desarrollado cubra todos los posibles aspectos de filtrado (canales, publicadores
y suscriptores), sólo es una de las características más importantes en las que se
envuelve el estándar DDS para sistemas distribuidos. Como propuestas de mejora y desarrollo
del modelo para una mayor aplicación a sistemas que necesitan una comunicación de
información en tiempo real serían:
Persistencia de datos: posibilidad de conservar un historial de los datos que son enviados
al canal. Atendiendo al estándar DDS, se podría establecer el criterio para mantener
solamente los datos más recientes o, en cambio, guardar todas las muestras de datos.
Confiabilidad: establecer un parámetro que garantice la entrega de determinados datos
a nuevos subscriptores. En este caso, podría garantizarse que la información de eventos
anteriores será entrega a todos los subscriptores, o por el contrario, no se reenvíen los
datos de algunos eventos.
Posesión de la información: se decide si múltiples publicadores pueden actualizar la
misma información de un mismo objeto. Pueden existir varios canales en un mismo
dominio pero sólo se quieren obtener los datos del canal principal. Para ello, se restringiría
la publicación de la información al canal principal.
Tiempo de vida: se establece una propiedad para indicar el máximo intervalo de tiempo
de entrega de los datos. Si se excede ese tiempo máximo, el dato no será entregado.
Prioridad de transporte: permitir enviar mensajes aplicando diferentes niveles de prioridad.
En el ámbito del proyecto Elcano, los eventos con mayor precisión de posicionamiento
tendrían más prioridad sobre otros eventos enviados con un rango mayor de
error.
Las características anteriores aportarían al modelo un mayor nivel de fiabilidad en cuanto
a la recepción de eventos en tiempo real, incrementando y mejorando la calidad del sistema.
Otro rasgo interesante sería la creación de una herramienta de gestión más sofisticada que
permitiera obtener información más detallada de los diferentes componentes que constituyen
el sistema proporcionando:

7. CONCLUSIONES Y TRABAJO FUTURO 59
La eliminación de canales que no se estén utilizando, es decir, canales en los que no
existan suscriptores y estén consumiendo innecesariamente recursos del sistema.
La creación de canales según las necesidades de los suscriptores. Pueden existir gran
cantidad de suscriptores a un canal que hayan indicado en la suscripción filtros similares.
En este caso, lo más óptimo sería crear un canal filtrado definido por los filtros
más demandados y cambiar la suscripción a este canal de todos aquellos suscriptores
con las mismas necesidades.
La creación y eliminación de publicadores para tener un mayor control de la información
que está circulando entre los diferentes componentes del sistema.

ANEXOS

Casos de estudio: OpenSplice y RTI
A
A.1.
RTI Context DDS
RTI Data Distribution Service (RTI DDS) es un middleware de red para aplicaciones distribuidas
en tiempo real. RTI DDS simplifica el desarrollo, implementación y mantenimiento
de aplicaciones y proporciona una distribución rápida y predecible de los datos en un conjunto
de redes de transporte.
La clave del éxito de este modelo es que las aplicaciones que utilizan este modelo están
totalmente desacopladas. Se emplea muy poco tiempo en diseñar la forma en las que estas
aplicaciones interactúan.
RTI DDS se encarga de automatizar todos los aspectos de la entrega de mensajes, sin
necesidad de ninguna intervención por parte de las aplicaciones de usuario, incluyendo:
Determina quién debe recibir los mensajes.
Dónde se encuentran los destinatarios de los mensajes.
Qué ocurre si los mensajes no pueden ser entregados.
RTI DDS incluye las siguientes características, que han sido diseñadas para satisfacer las
necesidades de las aplicaciones de tiempo real distribuidas:
Centro de datos para las comunicaciones publicador/suscriptor Simplifica la programación
de las aplicaciones y garantiza que los datos lleguen a su destino con la mínima
latencia.
Tipos de datos definidos por el usuario Habilita a los usuarios para especificar el formato
de la información que será enviada a cada aplicación.
Mensajes fiables Las aplicaciones que se dedican a la suscripción pueden especificar la
entrega fiable de muestras.
Múltiples dominios de comunicaciones Pueden haber múltiples dominios utilizando la misma
red física y cada aplicación puede ser configurada para participar en múltiples dominios.
61

A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 62
Arquitectura simétrica No hay servidor centralizado ni nodos privilegiados. Las suscripciones
y las publicaciones puede ser añadidas y eliminadas dinámicamente del sistema
en cualquier momento.
Frameworks de transporte RTI DDS incluye la habilidad para definir nuevas herramientas
de transporte. RTI DDS especifica un plugin de transporte UDP/IP y transporte
de memoria compartida. Puede ser configurado para trabajar sobre gran variedad de
mecanismos, tecnologías de redes, etc.
Soporte multilenguaje Soporta APIs para los lenguajes C, C++, C++/CLI, C# y Java.
Soporte multiplataforma Incluye soporte para UNIX, sistemas de tiempo-real (INTEGRITY,
VxWorks, QNX y LynxOS) y Windows (2000, 2003, CE, Vista y XP).
Cumplimiento de estándar La API cumple la capa DCPS de la especificación de DDS de la
OMG. El formado de los paquetes de datos que envía RTI DDS cumple con la especificación
del protocolo RTPS.
Un ejemplo básico para ver el funcionamiento de un publicador y un suscriptor utilizando
RTI DDS se puede encontrar en el cdrom adjunto en el directorio src/samples/RTI/HelloWorld
y además la prueba de integración correspondiente en el directorio test/samples.
Este ejemplo no se analiza ya que los ejemplos realizados con OpenSplice especificados
en el próximo capítulo son más claros para conocer la dinámica de DDS.
A.2.
OpenSplice DDS
A.2.1. Arquitecture OpenSplice DDS
OpenSplice DDS compone una arquitectura que utiliza memoria compartida para conectar
no sólo todas las aplicaciones que residen dentro de un nodo computacional, sino también el
conjunto de servicios que ofrecen diferentes hosts 1 . Esta arquitectura garantiza la escalabilidad,
flexibilidad y extensibilidad.
En la memoria compartida que utiliza esta arquitectura, los datos están físicamente una
vez en cada máquina y la administración proporciona a cada suscriptor una vista privada de
esos datos. Esto permite que una caché de datos del suscriptor será percibida como una base
de datos individual que puede estar filtrada, encolada, etc.
OpenSplice DDS puede ser fácilmente configurable especificando los servicios necesarios
que se utilizarán, así como la configuración de los servicios que persigue un acoplamiento
óptimo en el dominio de aplicación (los parámetros de red, la durabilidad, niveles, etc). La
figura A.1 muestra la arquitectura de un nodo en OpenSplice DDS.
1 Nodo conectada a la red que proporciona servicios y solicita servicios de otros.

A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 63
Figura A.1: Arquitectura de un nodo de la tecnología OpenSplice DDS
A.2.2. Características de OpenSplice DDS
La última versión de OpenSplice DDS es la versión 6 y se caracteriza por:
Múltiples arquitecturas - Proporciona opciones de desarrollo configurables que permiten
adaptarse a las características de rendimiento, escalabilidad y tolerancia a fallos que
envuelven las necesidades de un determinado sistema, reduciendo así los costes iniciales
y los costes durante el desarrollo.
Múltiples paradigmas - OpenSplice V6 ofrece una solución adecuada al problema de interacción
entre distintos modelos de comunicación como son los modelos publicador/suscriptor,
cachés de objetos distribuidos e invocación de métodos remotos (RMI).
Además, la calidad de servicio (QoS) proporcionado por DDS puede ser utilizada para
controlar la calidad de servicio asociada con servicios individuales, así como con
invocaciones específicas.
Tiempo real y escalable - Máxima escalabilidad y mínimas latencias junto con eventos en
tiempo real ofrecen sistemas de tiempo real a gran escala. Para ello, OpenSplice DDS
proporciona dos características principales: un protocolo de red de tiempo real optimizado
y escalabilidad; y opciones de despliegue de memoria compartida para minimizar
el uso de los recursos, optimizando la comunicación entre nucleos y aplicando las políticas
de tráfico de red a los nodos del sistema.
Conectividad - La puerta de enlace OpenSplice proporciona soporte para unas 80 conexio-

A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 64
Figura A.2: Puerta de enlace de la tecnología OpenSplice DDS
nes a otras tecnologías de mensajería (por ej. JMS 2 , AMQP 3 ) y a tecnologías Web
propietarias (por ej. W3C Web Services) (figura A.2).
Herramienta de pruebas - OpenSplice DDS v6 proporciona una herramienta para realizar
pruebas que simplifican el testeo de los sistemas distribuidos basados en DDS.
Código abierto - OpenSplice v6 está disponible bajo la licencia LGPLv3 y también bajo la
propia licencia de PrismTech Commercial.
Cumplimiento de estándares - OpenSplice DDS es una estricta implementación del estándar
DDS de OMG. Esto garantiza la portabilidad y la interoperabilidad entre las
implementaciones de DDS.
A.2.3. Estudio de la comunicación de eventos OpenSplice DDS
Se han realizado algunos ejemplos para conocer la dinámica de esta arquitectura. En este
capítulo se muestra uno de estos ejemplos para la compresión de la dinámica de trabajo de
OpenSplice DDS. El IDL utilizado para el ejemplo se muestra en el listado A.1.
module HelloWorldData {
struct Msg
{
long userID;
string message;
};
#pragma keylist Msg userID
};
Listado A.1: IDL utilizado para el ejemplo HelloWorld de OpenSplice DDS
La implementación de un simple ejemplo es muy sencilla y se puede interpretar fácilmente.
En el listado A.2 y en el listado A.3 se pueden ver las correspondientes implementaciones
2 Java Message Service, es un API que se utiliza para el uso de colas de mensajes. Permite crear, enviar,
recibir y leer mensajes
3 Advanced Message Queuing Protocol es un protocolo utilizado en la capa de aplicaciones de un sistema
de comunicación. Soporta orientación a mensajes, uso de colas y enrutamiento (punto-a-punto y publicaciónsuscripción)

A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 65
de un suscriptor y de un publicador para el modelo de comunicaciones OpenSpliceDDS.
En las dos implementaciones se sigue el mismo procedimiento:
1. Se crea un dominio que va a contener el canal de comunicación entre publicador y
suscriptor.
2. Se crea el tipo del canal. El tipo de canal viene definido en el IDL especificado para
este ejemplo (listado A.1).
3. Una vez obtenido el tipo del canal, se crea el canal correspondiente cuyo nombre tiene
que ser el mismo tanto en la parte del suscriptor como en la del publicador.
4. En cada caso, se crea el publicador del canal y se crea el subscriptor del canal.
5. Para el publicador se crea el objeto DataWriter correspondiente y para el suscriptor
se crea el objeto DataReader.
6. Se envían eventos en el caso del publicador y el subscriptor espera la recepción de
eventos.
7. Finalmente, se eliminan los DataReader y DataWriter, el canal, el suscriptor y el
publicador.
#include
#include
#include
#include "DDSEntityManager.h"
#include "ccpp_HelloWorldData.h"
#include "os.h"
using namespace DDS;
using namespace HelloWorldData;
int main(int argc, char ∗argv[])
{
os_time delay_2ms = { 0, 2000000 };
os_time delay_200ms = { 0, 200000000 };
MsgSeq msgList;
SampleInfoSeq infoSeq;
DDSEntityManager ∗mgr = new DDSEntityManager();
// create domain participant
mgr−>createParticipant("HelloWorld example");
//create type
MsgTypeSupport_var mt = new MsgTypeSupport();
mgr−>registerType(mt.in());
//create Topic
char topic_name[] = "HelloWorldData_Msg";
mgr−>createTopic(topic_name);
//create Subscriber
mgr−>createSubscriber();
// create DataReader
mgr−>createReader();

A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 66
}
DataReader_ptr dreader = mgr−>getReader();
MsgDataReader_var HelloWorldReader = MsgDataReader::_narrow(dreader);
checkHandle(HelloWorldReader, "MsgDataReader::_narrow");
cout

A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 67
//create type
MsgTypeSupport_var mt = new MsgTypeSupport();
mgr−>registerType(mt.in());
//create Topic
char topic_name[] = "HelloWorldData_Msg";
mgr−>createTopic(topic_name);
//create Publisher
mgr−>createPublisher();
// create DataWriter :
// If autodispose_unregistered_instances is set to true (default value)
,
// you will have to start the subscriber before the publisher
bool autodispose_unregistered_instances = false;
mgr−>createWriter(autodispose_unregistered_instances);
// Publish Events
DataWriter_ptr dwriter = mgr−>getWriter();
MsgDataWriter_var HelloWorldWriter = MsgDataWriter::_narrow(dwriter);
}
Msg msgInstance; /∗ Example on Stack ∗/
for (count=0; count < 4; count ++) {
msgInstance.userID = count;
msgInstance.message = CORBA::string_dup("Hello World");
cout

A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 68
A.2.4. Estudio del filtrado de eventos
Se realiza un estudio de la comunicación entre un subscriptor y un publicador en la tecnología
OpenSplice DDS utilizando para ello un canal cuyo tipo será una estructura semejante
a los eventos utilizados en el proyecto Elcano. El listado A.4 muestra el IDL definido para
ello.
module EventElcanoFilter
{
struct Point {
double x;
double y;
double z;
};
struct LocEvent
{
string provider;
string msid;
long time;
Point point;
};
#pragma keylist LocEvent provider
};
Listado A.4: IDL que especifica el tipo de canal con una estructura de datos semejante a la
utilizada en los eventos del proyecto Elcano
En este ejemplo se analiza el tráfico de la red cuando hay filtrado de eventos. La dinámica
del subscriptor y del publicador son muy similares a las implementadas en el ejemplo
HelloWorld antes mencionado. Las nuevas operaciones se pueden ver en el listado A.5 donde
el suscriptor crea un canal filtrado (ContentFilteredTopic) indicando el filtro que se
realizará en los eventos recibidos.
char sTopicName[] = "MyLocEventTopic";
// create subscription filter
ostringstream buf;
buf

A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 69
Análisis del tráfico en la herramienta Wireshark
La herramienta Wireshark [Com11] ofrece un análisis del tráfico que circula por la red
(información de cada paquete, protocolos, ...). El interés de utilizar esta herramienta radica
en conocer qué información es enviada en los paquetes que contiene los eventos que se
envían desde los publicadores a los suscriptores.
Se ha analizado el tráfico entre un publicador y un suscriptor ejecutados en diferentes máquinas.
El publicador tiene la ip 161.67.106.124 y el suscriptor tiene la ip 161.67.106.141.
El suscriptor se registra al canal con el filtro WIFI, es decir, recibirá todos los eventos cuyo
proveedor sea WIFI.
En la figura A.3 se puede observar cómo en la máquina que ejecuta el suscriptor se registra
indicando el nombre del canal(LocEventTrakerExclusive), el tipo de dato al que se suscribe(LocEvent)
y se indica también el nombre de dominio del participante(EventElcanoFilterTopic
example). Del mismo modo, en la otra máquina se crea el publicador.
A partir de la creación del publicador, se empiezan a mandar los eventos de localización.
La figura A.4 muestra el contenido de un paquete que contiene un evento de localización.

A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 70
Figura A.3: El consumidor se suscribe al canal

A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 71
Figura A.4: Paquete que contiene los datos de un evento de localización

Plan de pruebas
B
En este apéndice se especifica el plan de pruebas que se ha llevado a cabo durante el
desarrollo del proyecto. Como se explica en la sección 4.1.2 se sigue la técnica de BDD para
describir las pruebas.
B.1.
Suscripción y publicación sin filtrado
El comportamiento de los publicadores y los suscriptores debe ser similar al comportamiento
de los suscriptores y publicadores de los canales IceStorm.
Para probar esta funcionalidad se especifican tanto pruebas positivas como pruebas negativas.
De esta forma se asegura el correcto funcionamiento del servicio IceStorm acoplado al
servicio IceDDS.
B.1.1. Mensaje recibido
En esta prueba se comprueba que los mensajes enviados desde un publicador son recibidos
en el suscriptor del mismo canal.
Dado - un canal, un publicador del canal y un suscriptor del canal.
Cuando - el publicador del canal envía eventos.
Entonces - el suscriptor del canal recibe los eventos.
B.1.2. Mensaje no recibido
Se comprueba que los suscriptores no registrados en un canal, no reciben los eventos.
Dado - un canal T1, un canal T2, un publicador del canal T1 y un suscriptor del canal T2.
Cuando - el publicador del canal T1 envía eventos.
Entonces - el suscriptor del canal T2 no recibe ningún evento.
B.1.3.
Mensaje recibido en varios suscriptores
Todos los suscriptores registrados en un canal reciben los eventos que llegan al mismo.
72

B. PLAN DE PRUEBAS 73
Dado - un canal, un publicador del canal y dos suscriptores al canal.
Cuando - el publicador del canal envía un evento.
Entonces - los dos suscriptores del canal reciben el evento.
B.1.4. Varios publicadores en un canal
Los suscriptores a un canal reciben todos los eventos que envíe cualquier publicador.
Dado - un canal, dos publicadores del canal y un suscriptor al canal.
Cuando - cada publicador envía un evento al canal.
Entonces - el suscriptor reciben dos eventos, uno de cada publicador del canal.
B.1.5. Varios canales y publicadores y un sólo suscriptor
En esta prueba, el suscriptor se registra en dos canales, por lo tanto, debe recibir los eventos
de los dos canales.
Dado - un canal T1, un canal T2, un publicador del canal T1, un publicador del canal T2 y
un suscriptor registrado al canal T1 y al canal T2.
Cuando - cada publicador envía un evento al canal.
Entonces - el suscriptor reciben dos eventos, uno del publicador del canal T1 y otro evento
procedente del publicador del canal T2.
B.2.
Filtrado de eventos a nivel de canal
El objetivo de la siguiente batería de pruebas es la comprobación de que los canales filtran
los eventos cuyos valores no sean válidos para los filtros especificados a la hora de crear un
canal.
Además, se realizan pruebas para validación de tipos de código que circulan por el canal.
La creación de filtros conlleva a crear otro conjunto de pruebas que verifican que las funciones
de comprobación de valores de las distintas clases de filtros se comportan correctamente.
B.2.1. Comprobación de valores en los filtros
Estas pruebas comprueban que ciertos valores pertenecen a los valores que comprenden
los diferentes tipos de filtro (ver apéndice D).

B. PLAN DE PRUEBAS 74
B.2.2. Tipos de los datos que circulan por el canal
Se hacen pruebas tanto negativas como positivas corroborando que haya una correspondencia
entre los filtros especificados y el tipo de datos especificado (TypeCode).
B.2.3. Filtrado en el canal con un suscriptor
Se comprueba que un suscriptor registrado en un canal que contiene un filtrado de eventos
recibe los eventos correctos.
Dado - un canal filtrado, un publicador del canal y un suscriptor registrado al canal.
Cuando - el publicador envía varios eventos al canal.
Entonces - el suscriptor recibe los eventos.
B.2.4. Filtrado en el canal con varios suscriptores
Se comprueba que varios suscriptores registrados en un canal que contiene un filtrado de
eventos reciben los eventos correctos. En el sistema se producirá un warning.
Dado - un canal filtrado, un publicador del canal y dos suscriptores registrados al canal.
Cuando - el publicador envía varios eventos al canal.
Entonces - los suscriptores reciben los eventos enviados al canal.
B.2.5. Se envía un dato inválido a un canal con filtro
El publicador de un canal con filtro envía un dato que debe filtrarlo el canal. El sistema
notificará este hecho con un warning avisando de que el dato enviado es inválido.
Dado - un canal filtrado, un publicador del canal y un suscriptor.
Cuando - el publicador envía un evento no válido al canal.
Entonces - el suscriptor no recibe ningún evento, ya que aunque el publicador lo envía, el
canal lo filtra.
B.2.6. Se indican varios filtros
Todas las pruebas anteriores, se realizan solamente indicando un filtro. En esta prueba,
se comprueba el éxito en la recepción de un evento cuando se crea un canal con varios
filtros.
Dado - un canal filtrado, un publicador del canal y un suscriptor.
Cuando - el publicador envía un evento al canal.
Entonces - el suscriptor recibe el evento.

B. PLAN DE PRUEBAS 75
B.3.
Filtrado de eventos a nivel de publicador
En este capítulo se realizan las pruebas correspondiente a los publicadores filtrados. Además,
se hacen pruebas para validar la expresión en los filtros, es decir, que la cadena contenga
un nombre de variable, un operador tal y como se definen en la tabla 5.1 y uno o varios valores,
según el filtro. Estas pruebas no se definen en detalle en este apéndice debido a la
igualdad de los casos de prueba. Las pruebas sobre filtros se pueden encontrar en el cdrom
adjunto a la documentación en el directorio test/unit/filters/.
B.3.1. Correcta definición de las expresiones en los filtros
Las pruebas comprueban todas las posibles expresiones erróneas y aseguran que se va a
producir una excepción.
B.3.2. Evento recibido con publicador filtrado
Se comprueba la correcta recepción de los eventos que manda un publicador que tiene
filtros asociados a un canal.
Dado - un canal, un publicador con filtro y un suscriptor al canal.
Cuando - el publicador envía varios eventos al canal.
Entonces - el subscriptor al canal recibe todos los eventos.
B.3.3. Evento recibido con publicador filtrado en un canal filtrado
Se comprueba la correcta recepción de los eventos que manda un publicador que tiene
filtros asociados a un canal que tiene sus propios filtros.
Dado - un canal filtrado, un publicador con filtro y un suscriptor al canal.
Cuando - el publicador envía varios eventos válidos al canal.
Entonces - el subscriptor al canal recibe todos los eventos.
B.3.4. Se envía un dato inválido a un canal
El publicador de un canal con filtro envía un dato que no corresponde con el filtro asociado
a este publicador. El sistema notificará este hecho con un warning avisando de que el dato
enviado es inválido.
Dado - un canal, un publicador con filtro y un suscriptor al canal.
Cuando - el publicador envía un evento no válido.
Entonces - el suscriptor no recibe ningún evento, ya que aunque el publicador lo envía,
también lo filtra.

B. PLAN DE PRUEBAS 76
B.3.5. Se envía un dato inválido a un canal con filtros
El publicador de un canal con filtro envía un dato que no corresponde con el filtro asociado
a este publicador, pero que es válido en el canal. El sistema notificará este hecho con un
warning avisando de que el dato enviado es inválido.
Dado - un canal, un publicador con filtro y un suscriptor al canal.
Cuando - el publicador envía un evento no válido en este pero válido en el canal.
Entonces - el suscriptor no recibe ningún evento.
B.3.6. Un publicador con filtros y otro sin filtros
Un canal tiene dos publicadores. Uno con determinados filtros y otro sin filtros. Un subscriptor
al canal recibe todos los eventos, es decir, todos los eventos enviados por el publicador
que filtra y todos los eventos enviados por el publicador que no filtra.
Dado - un canal, un publicador con filtro, un publicador sin filtro y un suscriptor al canal.
Cuando - el publicador sin filtro envía un evento y el publicador que filtra envía otro evento.
Entonces - el suscriptor recibe todos los eventos.
B.3.7. Un publicador con filtros y otro sin filtros en un canal con filtros
Esta prueba es similar a la anterior pero creando un canal con filtros.
Dado - un canal con filtros, un publicador con filtro, un publicador sin filtro y un suscriptor
al canal.
Cuando - el publicador sin filtro envía un evento y el publicador que filtra envía otro evento.
Entonces - el suscriptor recibe todos los eventos determinando también el filtro que realiza
el propio canal.
B.3.8. Se indican varios filtros
En las pruebas anteriores los filtros están compuestos por solo un miembro, es decir, se
indica solo un filtro. En esta prueba se indican más de un filtro.
Dado - un canal filtrado, un publicador con filtros y un suscriptor.
Cuando - el publicador envía un evento al canal.
Entonces - el suscriptor recibe el evento.

B. PLAN DE PRUEBAS 77
B.4.
Filtrado de eventos a nivel de suscripción
El conjunto de pruebas que se especifican a continuación componen los posibles casos que
se pueden dar al realizar una suscripción indicando determinados filtros.
B.4.1. Subscripción con filtro en un canal
El suscriptor indica su intención de registrarse indicando unos determinados filtros y se
comprueba que, de los eventos que se publican, sólo le son proporcionados los compatibles
con los filtros especificados.
Dado - un canal, un publicador del canal y un suscriptor al canal indicando filtros específicos.
Cuando - el publicador envía varios eventos.
Entonces - el suscriptor sólo recibe aquellos eventos que pertenecen a los filtros con los que
se ha suscrito.
B.4.2. Varias suscripciones (con y sin filtro) a un canal
Esta prueba es similar a la anterior pero se utilizan dos suscriptores. Se garantiza el funcionamiento
con dos suscriptores, uno realizando la suscripción normal y otro realizando la
suscripción indicando filtros.
Dado - un canal, un publicador del canal, un suscriptor 1 al canal y otro suscriptor 2 al canal
indicando filtros específicos.
Cuando - el publicador envía varios eventos.
Entonces - el suscriptor 2 sólo recibe aquellos eventos que pertenecen a los filtros con los
que se ha suscrito, mientras que el suscriptor 1 recibe todos los eventos.
B.4.3. Subscripción con filtro en un canal con su propio filtro
La peculiaridad de esta prueba reside en la existencia de un canal que posee un filtrado.
Un suscriptor puede registrarse a un canal y algunos de los filtros indicados en la suscripción
no corresponderse con los filtros del canal. En este caso, los eventos de localización que se
notifican en el suscriptor serán los eventos que sean válidos tanto en el canal como en el
suscriptor.
Dado - un canal con filtros, un publicador del canal y un suscriptor al canal indicando filtros
específicos.
Cuando - el publicador envía varios eventos.
Entonces - el suscriptor sólo recibe aquellos eventos que pertenecen a los filtros con los que
se ha suscrito y teniendo en cuenta los filtros del canal.

B. PLAN DE PRUEBAS 78
B.4.4. Varias suscripciones a un canal con un publicador general
Como en la prueba anterior, se comprueba que los eventos sea reportados de manera correcta
y además, esta prueba asegura un correcto funcionamiento cuando hay más de un
suscriptor.
Dado - un canal con filtros, un publicador del canal, un suscriptor 1 al canal y otro suscriptor
2 al canal indicando sus propios filtros.
Cuando - el publicador envía varios eventos.
Entonces - el suscriptor 2 sólo recibe aquellos eventos que pertenecen a los filtros con los
que se ha suscrito y sin olvidarse de los filtros propios del canal, mientras que el
suscriptor 1 recibe todos los eventos que puede manejar el canal.
B.4.5. Suscripción con filtro a un canal con publicador, ambos con filtros
Se comprueba y valida la suscripción con filtros cuando existe un canal con filtrado y un
publicador a ese canal con filtrado en la publicación.
Dado - un canal con filtros, un publicador del canal con filtrado, un suscriptor al canal
indicando sus propios filtros.
Cuando - el publicador envía varios eventos.
Entonces - el suscriptor sólo recibe aquellos eventos que pertenecen a los filtros con los que
se ha suscrito y teniendo en cuenta los filtros del canal además del filtrado que realiza
el publicador.
B.4.6. Suscripción con filtro a un canal con publicador, ambos con filtros
Esta prueba es semejante a las pruebas anteriores. Se demuestra la misma circunstancia
con más de un suscriptor.
Dado - un canal con filtro, un publicador del canal con filtrado, un suscriptor 1 al canal y un
suscriptor 2 al canal indicando sus propios filtros.
Cuando - el publicador envía varios eventos.
Entonces - el suscriptor 2 sólo recibe aquellos eventos que pertenecen a los filtros con los
que se ha suscrito teniendo en cuenta los filtros propios del canal y el filtrado en el publicador,
mientras que el suscriptor 1 recibe todos los eventos que envía el publicador.

B. PLAN DE PRUEBAS 79
B.4.7. Se indican varios filtros
En esta prueba se verifica que el funcionamiento es igual indicando varios filtros en la
suscripción, ya que en las pruebas anteriores se indica solamente un filtro.
Dado - un canal, un publicador y un suscriptor con filtros.
Cuando - el publicador envía eventos al canal.
Entonces - el suscriptor recibe los eventos que concuerdan con los filtros especificados.
B.4.8. Eliminar la suscripción a un canal
Se comprueba que un suscriptor no recibe eventos después de que haya eliminado la suscripción
a un canal.
Dado - un canal, un publicador y un suscriptor con filtros.
Cuando - el publicador envía un evento al canal.
Entonces - el suscriptor recibe el evento que concuerda con los filtros especificados.
Después cuando - el suscriptor cancela la suscripción al canal y el publicador envía otro
evento.
Entonces - el suscriptor no recibe ningún evento más.
B.4.9. Federación de canales
El conjunto de pruebas descritas en esta sección corresponden a la federación de canales
con la peculiaridad de indicar filtros que limiten la propagación de eventos de unos canales
a otros.
B.4.10. Federación entre canales filtrados
En esta prueba determinada se verifica que un evento publicado en un canal se propaga
a otro canal enlazado a este primero, ya que el evento es válido para los filtros de los
canales.
Dado - un canal 1 con un filtro de rango (1, 5), un canal 2 que solo acepta eventos cuya ’x’
sea igual a 2, un publicador del canal 1 y un suscriptor al canal 2.
Cuando - el canal 2 realiza un enlace al canal 1, el suscriptor se registra en el canal 2 y el
publicador del canal 1 envía un evento cuya ’x’ es igual a 2.
Entonces - el suscriptor recibe el evento desde el canal 1.
B.4.11. Federación entre un canal con filtro y un canal sin filtro
Un canal puede recibir todo tipo de eventos, pero desea que de otro canal sólo le lleguen
ciertos valores.

B. PLAN DE PRUEBAS 80
Dado - un canal 1 con un filtro de rango (1, 5), un canal 2 sin filtro, un publicador del canal
1, un suscriptor al canal 1 y un suscriptor al canal 2.
Cuando - el canal 2 realiza un enlace al canal 1 limitando la propagación a eventos cuyos
valores de ’x’ estén en un rango (2, 4) y el publicador del canal 1 envía varios eventos.
Entonces - el suscriptor del canal 1 recibe todos los eventos mientras que el suscriptor del
canal 2 sólo recibe aquellos cuyos valores de ’x’ están en un rango (2, 4).
B.4.12. Federación con suscriptores con filtro y sin filtro
Se prueba la federación teniendo suscriptores diferentes, uno con filtro y otro sin filtro.
Dado - un canal 1 y un canal 2, un publicador del canal 1, un suscriptor al canal 2 con filtro
y otro suscriptor al canal 2 con filtro.
Cuando - el canal 2 realiza un enlace al canal 1 limitando la propagación a eventos cuyos
valores de ’x’ estén en un rango (2, 4) y el publicador del canal 1 envía varios eventos.
Entonces - el suscriptor sin filtro recibe todos los eventos y el otro suscriptor sólo recibe los
eventos cuyos valores de ’x’ sean mayores de 2.
B.4.13. Eventos no válidos para el enlace especificado
En esta prueba se muestra como se publican eventos en un canal que no se propagan a
otros canales enlazados debido a los filtros indicados.
Dado - un canal 1 y un canal 2, un publicador del canal 1, un suscriptor al canal 1 y otro
suscriptor al canal 2.
Cuando - el canal 2 realiza un enlace al canal 1 limitando la propagación a eventos cuyos
valores de ’x’ sean igual a 8 y el publicador del canal 1 envía un evento cuyo valor de
la ’x’ es distinto de 8.
Entonces - el suscriptor del canal 1 recibe todos los eventos y el suscriptor del canal 2 no
recibe ningún evento.
B.4.14. Eliminar el enlace entre canales
En esta prueba se comprueba que después de eliminar el enlace entre canales, no se siguen
propagando los eventos.
Dado - un canal 1 con un filtro de rango (1, 5), un canal 2 que solo acepta eventos cuya ’x’
sea igual a 2, un publicador del canal 1 y un suscriptor al canal 2.
Cuando - el canal 2 realiza un enlace al canal 1, el suscriptor se registra en el canal 2 y el
publicador del canal 1 envía un evento cuya ’x’ es igual a 2.
Entonces - el suscriptor recibe el evento desde el canal 1.

B. PLAN DE PRUEBAS 81
Después cuando - el canal 2 elimina el enlace al canal 2 y el publicador envía otro evento.
Entonces - el suscriptor del canal 2 no reciben el nuevo evento.
B.5.
Modificación del filtro en un suscriptor
En las siguientes pruebas se validará el proceso para que un suscriptor registrado en un
canal y con un filtro determinado pueda cambiar este por otro diferente.
B.5.1. Cambio de filtro y recepción de eventos
Se reciben los eventos antes y después del cambio de filtro, ya que los valores de los eventos
enviados están dentro de los filtros especificados, tanto antes como después del filtro.
Dado - un canal 1, un publicador del canal 1 y un suscriptor con un determinado filtro.
Cuando - el publicador envía eventos.
Entonces - el subscriptor recibe los eventos.
Después cuando - el subscriptor cambia el filtro con el que se suscribe al canal y el publicador
envía un nuevo evento.
Entonces - el suscriptor recibe el nuevo evento ya que también es válido dentro de los filtros
especificados.
B.5.2. Cambio de filtro y no recepción de eventos
El suscriptor cambia el filtro y no recibe el evento ya que el valor del mismo no es válido
para el filtro especificado.
Dado - un canal 1, un publicador del canal 1 y un suscriptor con un determinado filtro.
Cuando - el publicador envía eventos.
Entonces - el subscriptor recibe los eventos.
Después cuando - el subscriptor cambia el filtro con el que se suscribe al canal y el publicador
envía un nuevo evento.
Entonces - el suscriptor no recibe el nuevo evento ya que el valor del mismo no es correcto
dentro de los filtros especificados.
B.6.
Pruebas de integración
Por último, se realiza una prueba de integración en las que están envueltos todos los tipos
de filtrado, así como la federación de canales filtrados. En la figura B.1 se muestra el esquema
de la prueba de integración realizada.

B. PLAN DE PRUEBAS 82
Figura B.1: Escenario para la prueba de integración de IceDDS
Para esta prueba se tiene los siguientes componentes:
Un canal general.
Un canal filtrado.
Otro canal filtrado enlazado al canal general (federación).
Un publicador general que envía eventos a los dos primeros canales.
Un publicador filtrado que envía eventos a los dos primeros canales.
Un suscriptor general suscrito a los dos primeros canales.
Un suscriptor filtrado suscrito a los dos primeros canales.
Un suscriptor del canal federado.
En esta prueba, se comprueban la correcta recepción de los eventos enviados, así como la
correcta propagación de los mismos.

Slices
C
C.1.
Eventos de localización del proyecto Elcano
#ifndef SHAPE_ICE
#define SHAPE_ICE
#include
module MLP {
struct Coord {
double x;
double y;
double z;
};
sequence CoordSeq;
class Shape extends P::T {
};
class Point extends Shape {
Coord center;
};
sequence PointSeq;
class LineString extends Shape {
["uml:multi:2..n"] CoordSeq points;
};
sequence LineStringSeq;
class Box extends Shape {
Coord topLeft;
Coord bottomRight;
};
class LinearRing extends Shape {
["uml:multi:3..n"] CoordSeq points;
};
sequence LinearRingSeq;
class PolygonBase extends Shape {
};
83

C. SLICES 84
};
sequence PolygonBaseSeq;
class Polygon extends PolygonBase {
LinearRing outerBoundaryIs;
["uml:multi:0..n"] LinearRingSeq innerBoundaryIs;
};
class CircularArcArea extends PolygonBase {
Coord center;
double inRadius;
double outRadius;
double startAngle;
double stopAngle;
};
class CircularArea extends PolygonBase {
Coord center;
double radius;
};
class EllipticalArea extends PolygonBase {
Coord center;
double angle;
double semiMinor;
double semiMajor;
};
class MultiLineString extends Shape {
["uml:multi:1..n"] LineStringSeq lines;
};
class MultiPoint extends Shape {
["uml:multi:1..n"] PointSeq points;
};
class MultiPolygon extends Shape {
["uml:multi:1..n"] PolygonBaseSeq polygons;
};
#endif
Listado C.1: Posibles eventos de localización del proyecto Elcano

Tipos de filtros
D
Los filtros se indican en un secuencia de cadenas, que internamente son transformadas en
instancias de las siguientes clases. Cada clase contiene un método para comprobar que un
cierto valor es correcto en el filtro.
D.1.
EventFilter
Si en la cadena donde se indica el filtro, el operador definido es “==”, el objeto correspondiente
será una instancia a la clase EventFilter. La utilización de este filtro indicará que
los valores en una cierta coordenada serán iguales a un determinado valor.
class EventFilter(object):
def __init__(self, name, num):
self.field_name = name
self.num = num
def match(self, value):
return value == self.num
def equal(self, filter_):
return ((type(filter_)==type(self))
and (filter_.field_name == self.field_name)
and (filter_.num == self.num))
Listado D.1: Clase EventFilter
D.2.
EventFilterRange
Si el operador especificado en la cadena del filtro es “in range”, se creará una instancia de
la clase EventFilterRange. Esta clase representa a los valores de una determinada coordenada
que pertenecen al rango entre dos valores.
class EventFilterRange(object):
def __init__(self, name, n, m):
self.field_name = name
self.valueLow = n
self.valueHigh = m
def match(self, low, high=None):
85

D. TIPOS DE FILTROS 86
if high:
return ((low in range(self.valueLow, self.valueHigh))
and (high in range(self.valueLow, self.valueHigh))
and (low >= self.valueLow) and (high= self.valueLow) and (low < self.valueHigh)
def equal(self, filter_):
return ((type(filter_)==type(self))
and (filter_.field_name == self.field_name)
and (filter_.valueLow == self.valueLow)
and (filter_.valueHigh == self.valueHigh))
Listado D.2: Clase EventFilterRange
D.3.
EventFilterOver
Se crea la clase EventFilterOver cuando el operador definido en la cadena del filtro es “>”.
Esta clase se emplea para aquellos datos que son mayores a un valor.
class EventFilterOver(object):
def __init__(self, name, num):
self.field_name = name
self.num = num
def match(self, value):
return not(value

D. TIPOS DE FILTROS 87
and (filter_.num == self.num))
Listado D.4: Clase EventFilterBelow
D.5.
Función eval
La función eval de python parsea y evalua una expression. Por ejemplo:
>>>> x = 3
>>>> eval(’x > 1’)
True
Esta función es una gran herramienta que ofrece la posibilidad de indicar gran cantidad de
filtros sin la necesidad de realizar clases de objetos de manera interna para poder hacer las
comprobaciones de los filtros.
De esta manera, se podría expresar un filtro de la forma:
expression = ’x > 3 and (x in range(9,10)) and (y not in range (4,8))’
En las tablas D.1 y D.2 se muestran los operadores lógicos y los operadores comparativos
que pueden utilizarse para especificar un conjunto de filtros.
Operador
and
or
not
Descripción
Conjunción
Disyunción
Negación
Cuadro D.1: Operadores lógicos para expresar un conjunto de filtros
Operador
Descripción
== Igual
!= Distinto
> Mayor que
< Menor que
>= Mayor o igual que

D. TIPOS DE FILTROS 88
de la creación de las clases que representan los diferentes filtros a evaluar anteriormente
mencionadas.

Estudio IceStorm
E
Durante la fase del proyecto en la cual se realiza un aprendizaje del middleware ZeroC Ice
y en particular del servicio IceStorm, se realizó una comunicación entre un subscriptor y un
publicador pero con la particularidad de que el sirviente sea de un determinado tipo.
Esto asegura que los suscriptores serán de un tipo determinado, por lo que la información
que maneja el canal puede ser manipulada atendiendo a dicho tipo.
La aplicación de este comportamiento al modelo de comunicaciones desarrollado en este
proyecto conllevaría a asegurar los tipos de datos que esperan los suscriptores, así como los
datos que envían los publicadores. Por lo tanto, no sería necesario comunicar al canal el tipo
de datos que manejará.
E.1.
Implementación
Para conseguir este comportamiento se cuenta con un componente que actúa como intermediario
(Delegate) entre los suscriptores/publicadores y el servicio IceStorm. Este componente
es el que garantiza que los suscriptores serán de un tipo específico. En el listado E.1
se muestra las interfaces que entran en juego en este sistema. La interfaz Listener es el sirviente
y la interfaz ASDA es la que implementa el componente que actúa de intermediario.
module ASD {
interface Listener {
void adv(string name);
};
interface ASDA {
void addListener(ASD::Listener∗ listener);
Listener∗ getPublisher();
};
};
Listado E.1: Interfaces utilizadas para establecer un determinado tipo de suscriptor)
En el listado E.2 se muestra la implementación de la interfaz ASDA y la clase Delegate.
Aquí, se crea el canal que será el que establezca la comunicación entre publicadores
y suscriptores. La operación addListener se encarga de realizar la suscripción al canal
89

E. ESTUDIO IceStorm 90
IceStorm y getPublisher devuelve el publicador del canal de determinado tipo. Como
se puede observar en el SLICE definido en E.1, el parámetro listener tiene que ser del tipo
ASD::Listener, de esta manera se asegura que el objeto a suscribir es del tipo deseado.
import sys, Ice, IceStorm
Ice.loadSlice(’ASDF.ice’)
import ASD
class ASDAI(ASD.ASDA):
def __init__(self, topic_mgr):
try:
self.topic = topic_mgr.create("ASDATopic")
print "create ASDATopic"
except IceStorm.TopicExists, e:
print "topic already created"
self.topic = topic_mgr.retrieve("ASDATopic")
def addListener(self, listener, current=None):
qos = {}
self.topic.subscribe(qos, listener)
def getPublisher(self, current=None):
pub = self.topic.getPublisher()
return ASD.ListenerPrx.uncheckedCast(pub)
class Delegate(Ice.Application):
def get_topic_manager(self):
properties = self.communicator().getProperties()
prop_key = "IceStormAdmin.TopicManager.Default"
strproxy = properties.getProperty(prop_key)
if not strproxy:
print "property", prop_key, "not set"
return 0
print "Using IceStorm in ’ %s’"
% strproxy
base = self.communicator().stringToProxy(strproxy)
return IceStorm.TopicManagerPrx.checkedCast(base)
def run(self, argv):
servant = ASDAI(self.get_topic_manager())
ic = self.communicator()
adapter = ic.createObjectAdapterWithEndpoints("Adapter", "tcp −p
3000")
proxy = adapter.add(servant, ic.stringToIdentity("ASDA"))
print proxy
adapter.activate()
ic.waitForShutdown()
return 0
sys.exit(Delegate().main(sys.argv))
Listado E.2: Canal encargado de la comunicación con los servicios IceStorm

E. ESTUDIO IceStorm 91
En las implementaciones del suscriptor y del publicador (listados E.3 y E.4) se puede ver
el uso de Delegate como el canal de comunicación entre los publicadores y los suscriptores.
class ListenerI(ASD.Listener):
def adv(self, s, current=None):
print "Hola"
class Subscriber(Ice.Application):
def run(self, argv):
servant = ListenerI()
ic = self.communicator()
adapter = ic.createObjectAdapter("Listener.Subscriber")
proxy = adapter.addWithUUID(servant)
base = self.communicator().stringToProxy(argv[1])
delegate = ASD.ASDAPrx.checkedCast(base)
print "::", delegate
listener = ASD.ListenerPrx.uncheckedCast(proxy)
delegate.addListener(listener)
print ’SUBSCRIBED!!’
print "Waiting events..."
adapter.activate()
ic.waitForShutdown()
return 0
sys.exit(Subscriber().main(sys.argv))
Listado E.3: Implementación de un suscriptor para el canal delegado
class Publisher(Ice.Application):
def run(self, argv):
base = self.communicator().stringToProxy(argv[1])
delegate = ASD.ASDAPrx.checkedCast(base)
print base
publisher = delegate.getPublisher()
prx = ASD.ListenerPrx.uncheckedCast(publisher)
print "Publishing..."
for i in range(5):
prx.adv("Hello!!")
return 0
sys.exit(Publisher().main(sys.argv))
Listado E.4: Implementación de un publicador para el canal delegado

Manual de usuario
F
Para que un usuario pueda probar las funcionalidades que ofrece el modelo de comunicaciones
IceDDS se desarrolló una aplicación con Android 2.3 que permite efectuar suscripciones
con filtro y sin filtro y visualizar los eventos de localización que envían los publicadores,
además permite crear nuevos canales para aquellos datos que no están reflejados en ningún
otro canal existente.
A continuación se describe las distintas opciones que maneja esta aplicación.
F.1.
Inicio
La pantalla principal que se muestra al ejecutar la aplicación se muestra en la figura F.1.
Esta pantalla consta del mapa del lugar donde el usuario va a interactuar y un botón para
listar los canales en el sistema.
Figura F.1: Pantalla principal de la aplicación aAndroid
Cabe destacar que la aplicación no se iniciará si el servicio que proporciona la comunicación
con el modelo IceDDS no se está ejecutando. En lugar de la pantalla principal aparecerá
un error propio de Android como el que se muestra en la figura F.2.
92

F. MANUAL DE USUARIO 93
Figura F.2: Error lanzado por aplicaciones Android
El dispositivo utilizado (móvil smartphone o tablet) debe estar conectado a la red para
poder interactuar con el servicio que maneja los canales de eventos de IceDDS.
F.2.
Listar canales
Para listar los canales existentes en el dominio del sistema, el usuario debe pulsar el botón
que aparece en la esquina inferior (Show Topics List).
Al pulsarse este botón aparecerá un panel a la derecha de la pantalla donde se muestran
dos listas: la lista de los canales existentes en el sistema y la lista de los canales a los que el
usuario está suscrito (ver figura F.3).
Figura F.3: Lista de canales en el sistema
Para ocultar el panel de “Listar canales”, el usuario debe pulsar el botón (Hide Topics List)
situado en la esquina inferior derecha.
El botón Refresh situado en la esquina superior derecha actualiza los canales existentes en
el sistema.
F.3.
Crear un nuevo canal
Para crear un nuevo canal, el usuario debe pulsar el botón Create new topic que aparece
en el panel “Listar canales”. Al pulsar este botón aparecerá el panel de la figura F.4.

F. MANUAL DE USUARIO 94
Figura F.4: Crear un nuevo canal
Se pueden crear dos tipos de canales:
Canal general - Para crear este tipo de canal solamente hay que introducir un nombre que
sea único en el sistema. El usuario debe procurar no introducir un nombre de canal ya
existente. Si lo hace, no se creará ningún nuevo canal, ya que el sistema devolverá el
canal existente.
Canal con filtros - El usuario, además de introducir el nombre del canal, puede añadir filtros
a la creación de un canal. En el panel F.4 se pueden ver las distintas opciones que
existen para añadir un determinado filtro. Al pulsar el botón Add Filter, el nuevo filtro
se colocará en la lista de filtros en la parte derecha del panel. Al igual que se pueden
añadir filtros, también se pueden eliminar. Si se selecciona un filtro de los existentes
en la lista aparecerá un diálogo preguntando si se desea eliminar el filtro seleccionado
(ver figura F.5).
Figura F.5: Eliminar filtro cuando se quiere crear un canal
Para crear el canal especificado, el usuario debe pulsar el botón Create Topic o, en caso
contrario, el usuario pulsará Cancel para no crear el canal.
F.4.
Suscribirse a un canal
Para realizar la suscripción a un canal, el usuario debe seleccionar un canal de entre los
de la lista. Una vez seleccionado aparecerá un diálogo (ver figura F.6) que contiene tres
botones:

F. MANUAL DE USUARIO 95
Subscribe: el usuario se suscribe al canal seleccionado sin más.
Subscribe with filters: el usuario se suscribe al canal indicando propios filtros.
Cancel: el usuario no se suscribe al canal.
Figura F.6: Diálogo para realizar la suscripción a un canal
Para realizar la suscripción, el usuario debe pulsar el botón Subscribe o pulsar Cancel para
no realizar ningún tipo de suscripción.
F.4.1. Subscribirse a un canal indicando filtros
Si el usuario elige la opción de la suscripción con filtros aparecerá un panel que permite
la adición de filtros (ver figura F.7). El panel es muy similar al mostrado para crear un filtro
(figura F.4)
Figura F.7: Suscripción añadiendo filtros propios
El usuario añadirá filtros mediante el botón Add Filter y se suscribirá al canal pulsando el
botón Subscribe. Al igual que en la creación de un canal, también se permite la eliminación
de filtros de la lista de filtros. Si el usuario pulsa el botón Cancel no se realizará ninguna
suscripción y se volverá a la pantalla principal de la aplicación.

Bibliografía
[AND08]
[ATH01]
Open Handset Alliance y Google Inc. Android Developers, Open Source Project,
2008. url: http://developer.android.com/.
David Villa Alises. Atheist’s, testing framework, 2001. url: http://arco.esi.
uclm.es/~david.villa/atheist/html/.
[Bec00] K. Beck. Una explicación de la programación extrema: aceptar el cambio.
Addison Wesley, edición 1 a , 2000.
[bit]
Atlassian Bitbucket. url: https://bitbucket.org/.
[cep08] Complex Event Proccesing, Event Stream Processing,
2008. url: http://www.omg.org/news/meetings/workshops/
Real-time WS Final Presentations 2008/Tutorials/00-T6 Vincent.
pdf.
[CLM + 03] B. Cascales, P. Lucas, J.M. Mira, A.J. Pallarés, y S. Sánchez-Pedreño. El libro
de L A TEX. Prentice Hall, edición 1 a , 2003.
[Com11]
[COR]
Gerald Combs. Wireshark, 2011. url: http://www.wireshark.org/.
Object Management Group. The Common Object Request Broker: Architecture
and Specification. url: http://www.corba.org/.
[dCENdIT] Programa de Consorcios Estratégicos Nacionales de Investigación Técnico(CENIT).
Energos. url: http://innovationenergy.org/energos/.
[ECL04]
The Eclipse Foundation open source community. Eclipse IDE for JAVA EE
Developers, 2004. url: https://www.eclipse.org/.
[EMA09] GENU Operating Sytem. GNU Emacs, 2009. url: http://www.gnu.org/
software/emacs/.
[GCC10] Free Software Foundation. Using GCC: The GNU Compiler Collection, 2010.
url: http://gcc.gnu.org/onlinedocs/gcc/.
[GNO04]
GNOME. ORBit2, 2004. url: http://projects.gnome.org/ORBit2/.
96

BIBLIOGRAFÍA 97
[icea]
[ICEb]
IceStorm de ZeroC Ice. url: http://www.zeroc.com/icestorm/index.html.
Internet Communications Engine, Zeroc. url: http://www.zeroc.com.
[Inc06] Sun Microsystems Inc. Java Remote Method Invocation (Java RMI),
2006. url: http://java.sun.com/javase/6/docs/technotes/guides/rmi/
index.html.
[Mab08]
[MER12]
Marwa Mabrouk. OpenGIS Location Services (OpenLS): Core Services. Technical
report, Open Geospatial Consortium Inc., Septiembre 2008.
Mercurial: Work easier, Work faster, 2012. url: http://mercurial.selenic.
com/.
[MLP11] Open Moobile Alliance. Mobile Location Protocol V3.1, 2011. url:
http://www.openmobilealliance.org/technical/release program/
mlp v31.aspx.
[NOS] Testing with nose. url: http://readthedocs.org/docs/nose/en/latest/
testing.html.
[OMG97]
[OMG07]
Object Management Group, 1997. url: http://www.omg.org/.
Data Distribution Service, Object Management Group, Enero 2007. url: http:
//www.omgwiki.org/dds.
[OPC] OpenFusion CORBA from PrismTech. url: http://www.prismtech.com/
openfusion/technologies/corba.
[OpS] OpenSplice DDS from PrismTech. url: http://www.prismtech.com/
opensplice.
[RED12] Redmine, project management web application, 2012. url: http://www.
redmine.org/.
[RTI]
[SLO]
[SMS06]
Real-Time Innovations Data Distribution Service. url: http://www.rti.com/
products/dds/index.html.
David A. Wheeler. SLOCCount. url: http://www.dwheeler.com/sloccount/
.
R.M. Stallman, R. McGrath, y P.D. Smith. GNU Make: A program for directing
recompilation (Version 3.81). Free Software Foundation., 2006.
[Som06] I. Sommerville. Ingeniería del software. Addison Wesley, edición 7 a , 2006.

BIBLIOGRAFÍA 98
[TCO10]
Real-Time CORBA with TAO (The ACE ORB), 2010. url: http://www.cs.
wustl.edu/~schmidt/TAO.html.
[ucs11] Unamanned AirCraft Systems Control Segment, 2011. url:
http://www.ucsarchitecture.org/page/technical information#
middleware software platform.
[VMV + 11] F.J. Villanueva, M.A. Martínez, D. Villa, C. González, y J.C. López. Elcano:
Multimodal indoor navigation infrastructure for disabled people. En Consumer
Electronics (ICCE), 2011 IEEE International Conference on, páginas 611 –612,
jan. 2011.

Este documento fue editado y tipografiado con L A TEX
empleando la clase arco-pfc que se puede encontrar en:
https://bitbucket.org/arco group/arco-pfc
[Respeta esta atribución al autor]