Grupo ARCO - Universidad de Castilla-La Mancha
Grupo ARCO - Universidad de Castilla-La Mancha 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
- Page 2 and 3: UNIVERSIDAD DE CASTILLA-LA MANCHA E
- Page 4 and 5: Alicia Serrano Sánchez Ciudad Real
- Page 6 and 7: Resumen Hoy en día, las tecnologí
- Page 8 and 9: 2.2.9. Control de las propiedades d
- Page 10 and 11: B.3.3. Evento recibido con publicad
- Page 12 and 13: Índice de cuadros 2.1. Operadores
- Page 14 and 15: A.2. Puerta de enlace de la tecnolo
- Page 16 and 17: E.2. Canal encargado de la comunica
- Page 18 and 19: RTPS SCADA Slice TCP TDD WiFi Real-
- Page 20 and 21: A mis padres, por su paciencia y co
- Page 22 and 23: 1. INTRODUCCIÓN 2 los eventos de l
- Page 24 and 25: Antecedentes 2 En este capítulo se
- Page 26 and 27: 2. ANTECEDENTES 6 del exterior. El
- Page 28 and 29: 2. ANTECEDENTES 8 Figura 2.3: Feder
- Page 30 and 31: 2. ANTECEDENTES 10 se especifica me
- Page 32 and 33: 2. ANTECEDENTES 12 Figura 2.6: Est
- Page 34 and 35: 2. ANTECEDENTES 14 struct LocEvent
- Page 36 and 37: 2. ANTECEDENTES 16 nuevo realizando
- Page 38 and 39: 2. ANTECEDENTES 18 • Confiable (R
- Page 40 and 41: 2. ANTECEDENTES 20 Existen dos tipo
- Page 42 and 43: 2. ANTECEDENTES 22 2.4.1. Adquisici
- Page 44 and 45: 3. OBJETIVOS 24 implementado. Herra
- Page 46 and 47: 4. MÉTODO DE TRABAJO Y HERRAMIENTA
- Page 48 and 49: 4. MÉTODO DE TRABAJO Y HERRAMIENTA
- Page 50 and 51: 5. DESARROLLO DEL PROYECTO 30 Figur
IMPLEMENTACIÓN DE UNA PLATAFORMA DE PROPAGACIÓN DE<br />
EVENTOS DDS MEDIANTE OBJETOS DISTRIBUIDOS, Y SU APLICACIÓN A<br />
UN CASO DE ESTUDIO
UNIVERSIDAD DE CASTILLA-LA MANCHA<br />
ESCUELA SUPERIOR DE INFORMÁTICA<br />
INGENIERÍA<br />
EN INFORMÁTICA<br />
PROYECTO FIN DE CARRERA<br />
Implementación <strong>de</strong> una plataforma <strong>de</strong> propagación <strong>de</strong> eventos<br />
DDS mediante objetos distribuidos, y su aplicación a un caso<br />
<strong>de</strong> estudio<br />
Alicia Serrano Sánchez<br />
Junio, 2012
UNIVERSIDAD DE CASTILLA-LA MANCHA<br />
ESCUELA SUPERIOR DE INFORMÁTICA<br />
Departamento <strong>de</strong> Tecnologías y Sistemas <strong>de</strong> Información<br />
PROYECTO FIN DE CARRERA<br />
Implementación <strong>de</strong> una plataforma <strong>de</strong> propagación <strong>de</strong> eventos<br />
DDS mediante objetos distribuidos, y su aplicación a un caso<br />
<strong>de</strong> estudio<br />
Autor: Alicia Serrano Sánchez<br />
Director: David Villa Alises<br />
Junio, 2012
Alicia Serrano Sánchez<br />
Ciudad Real – Spain<br />
E-mail: Alicia.Serrano1@alu.uclm.es<br />
Web site:<br />
c○ 2012 Alicia Serrano Sánchez<br />
Permission is granted to copy, distribute and/or modify this document un<strong>de</strong>r the terms of the GNU<br />
Free Documentation License, Version 1.3 or any later version published by the Free Software<br />
Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy<br />
of the license is inclu<strong>de</strong>d in the section entitled "GNU Free Documentation License".<br />
Se permite la copia, distribución y/o modificación <strong>de</strong> este documento bajo los términos <strong>de</strong> la<br />
Licencia <strong>de</strong> Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada por<br />
la Free Software Foundation; sin secciones invariantes. Una copia <strong>de</strong> esta licencia esta incluida en<br />
el apéndice titulado «GNU Free Documentation License».<br />
Muchos <strong>de</strong> los nombres usados por las compañías para diferenciar sus productos y servicios son<br />
reclamados como marcas registradas. Allí don<strong>de</strong> estos nombres aparezcan en este documento, y<br />
cuando el autor haya sido informado <strong>de</strong> esas marcas registradas, los nombres estarán escritos en<br />
mayúsculas o como nombres propios.
TRIBUNAL:<br />
Presi<strong>de</strong>nte:<br />
Vocal 1:<br />
Vocal 2:<br />
Secretario:<br />
FECHA DE DEFENSA:<br />
CALIFICACIÓN:<br />
PRESIDENTE VOCAL 1 VOCAL 2 SECRETARIO<br />
Fdo.: Fdo.: Fdo.: Fdo.:
Resumen<br />
Hoy en día, las tecnologías nos ofrecen la posibilidad <strong>de</strong> gestionar, controlar y manipular<br />
gran cantidad <strong>de</strong> información. <strong>La</strong> oportunidad <strong>de</strong> po<strong>de</strong>r utilizar esta información ha contribuido<br />
a la creación <strong>de</strong> sistemas que preten<strong>de</strong>n solventar las dificulta<strong>de</strong>s a las que se exponen<br />
ciertas situaciones que conllevan multitud <strong>de</strong> riesgos impre<strong>de</strong>cibles. Estas sistemas llevan a<br />
cabo tareas que requieren mucha precisión y exactitud, por ello es importante que la información<br />
esté disponible en el momento justo y en el lugar a<strong>de</strong>cuado. Son las tecnologías que<br />
trabajan con comunicación <strong>de</strong> datos en tiempo real.<br />
En este documento, se realizará un estudio y comprensión <strong>de</strong>l estándar DDS [OMG07]<br />
cuyo contenido es la <strong>de</strong>scripción <strong>de</strong> un middleware para la comunicación entre publicadores<br />
y suscriptores en sistemas distribuidos <strong>de</strong> tiempo real. A<strong>de</strong>más, se analizan varias implementaciones<br />
existentes <strong>de</strong> este estándar.<br />
Como resultado, se realizará la implementación <strong>de</strong> un mo<strong>de</strong>lo <strong>de</strong> comunicación <strong>de</strong>l tipo<br />
publicador/suscriptor añadiendo al mismo los aspectos <strong>de</strong> calidad <strong>de</strong> servicio relativos<br />
al filtrado <strong>de</strong> eventos especificado en el estándar DDS. Para ello se utilizará el middleware<br />
orientado a objetos ZeroC Ice, que proporciona soporte y servicios avanzados para <strong>de</strong>sarrollar<br />
aplicaciones distribuidas basadas en invocaciones a método remoto.<br />
VI
Índice general<br />
Resumen<br />
Índice general<br />
Índice <strong>de</strong> cuadros<br />
Índice <strong>de</strong> figuras<br />
Índice <strong>de</strong> listados<br />
Listado <strong>de</strong> acrónimos<br />
Agra<strong>de</strong>cimientos<br />
VI<br />
VII<br />
XII<br />
XIII<br />
XV<br />
XVII<br />
XIX<br />
1. Introducción 1<br />
1.1. Estructura <strong>de</strong>l documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
2. Antece<strong>de</strong>ntes 4<br />
2.1. Middleware orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
2.1.1. ZeroC Ice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
2.1.2. CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.1.3. JAVA RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.2. Data Distribution Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
2.2.1. Espacio global <strong>de</strong> datos . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
2.2.2. Canales (Topics) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
2.2.3. Publisher/Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
2.2.4. Lectura y escritura <strong>de</strong> datos . . . . . . . . . . . . . . . . . . . . . 15<br />
2.2.5. Mecanismos y técnicas para conseguir información . . . . . . . . . 16<br />
2.2.6. Filtrado <strong>de</strong> canales . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
2.2.7. Query Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
2.2.8. Calidad <strong>de</strong> Servicio (Quality of Service) . . . . . . . . . . . . . . . 17<br />
VII
2.2.9. Control <strong>de</strong> las propieda<strong>de</strong>s <strong>de</strong>l tiempo real . . . . . . . . . . . . . . 18<br />
2.2.10. Estudio <strong>de</strong> implementaciones existentes . . . . . . . . . . . . . . . 18<br />
2.3. Proyecto Elcano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
2.4. Proyecto Energos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
2.4.1. Adquisición <strong>de</strong> información en tiempo real . . . . . . . . . . . . . 22<br />
3. Objetivos 23<br />
3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
3.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
4. Método <strong>de</strong> trabajo y herramientas 25<br />
4.1. Metodología <strong>de</strong> trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
4.1.1. Prototipado incremental . . . . . . . . . . . . . . . . . . . . . . . 25<br />
4.1.2. Desarrollo dirigido por pruebas . . . . . . . . . . . . . . . . . . . 27<br />
4.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27<br />
4.2.1. Lenguajes <strong>de</strong> programación . . . . . . . . . . . . . . . . . . . . . 27<br />
4.2.2. Aplicaciones <strong>de</strong> <strong>de</strong>sarrollo . . . . . . . . . . . . . . . . . . . . . . 28<br />
4.2.3. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
4.2.4. Gestión <strong>de</strong> proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
4.2.5. Herramientas hardware . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
5. Desarrollo <strong>de</strong>l proyecto 29<br />
5.1. Especificación <strong>de</strong> requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
5.2. Casos <strong>de</strong> uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
5.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
5.4. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
5.4.1. Suscripción y publicación sin filtros . . . . . . . . . . . . . . . . . 35<br />
5.4.2. Filtrado <strong>de</strong> eventos a nivel <strong>de</strong> canal . . . . . . . . . . . . . . . . . 36<br />
5.4.3. Filtrado a nivel <strong>de</strong> publicador . . . . . . . . . . . . . . . . . . . . 39<br />
5.4.4. Filtrado a nivel <strong>de</strong> suscripción . . . . . . . . . . . . . . . . . . . . 41<br />
5.4.5. Fe<strong>de</strong>ración <strong>de</strong> canales . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
5.4.6. Modificación <strong>de</strong> filtros <strong>de</strong> un suscriptor . . . . . . . . . . . . . . . 46<br />
5.4.7. Operaciones <strong>de</strong>l servicio IceStorm . . . . . . . . . . . . . . . . . . 46<br />
5.5. Aplicación Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
6. Resultados 49<br />
6.1. Aplicaciones <strong>de</strong>l mo<strong>de</strong>lo a diferentes escenarios . . . . . . . . . . . . . . . 49
6.1.1. Escenario 1: Canales filtrados . . . . . . . . . . . . . . . . . . . . 50<br />
6.1.2. Escenario 2: Subscriptores filtrados . . . . . . . . . . . . . . . . . 51<br />
6.1.3. Escenario 3: Publicadores filtrados . . . . . . . . . . . . . . . . . . 52<br />
6.1.4. Escenario 4: Fe<strong>de</strong>ración <strong>de</strong> canales filtrados . . . . . . . . . . . . . 53<br />
6.2. Recursos y costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
6.2.1. Repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
7. Conclusiones y trabajo futuro 57<br />
7.1. Objectivos alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57<br />
7.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
A. Casos <strong>de</strong> estudio: OpenSplice y RTI 61<br />
A.1. RTI Context DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
A.2. OpenSplice DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62<br />
A.2.1. Arquitecture OpenSplice DDS . . . . . . . . . . . . . . . . . . . . 62<br />
A.2.2. Características <strong>de</strong> OpenSplice DDS . . . . . . . . . . . . . . . . . 63<br />
A.2.3. Estudio <strong>de</strong> la comunicación <strong>de</strong> eventos OpenSplice DDS . . . . . . 64<br />
A.2.4. Estudio <strong>de</strong>l filtrado <strong>de</strong> eventos . . . . . . . . . . . . . . . . . . . . 68<br />
B. Plan <strong>de</strong> pruebas 72<br />
B.1. Suscripción y publicación sin filtrado . . . . . . . . . . . . . . . . . . . . . 72<br />
B.1.1. Mensaje recibido . . . . . . . . . . . . . . . . . . . . . . . . . . . 72<br />
B.1.2. Mensaje no recibido . . . . . . . . . . . . . . . . . . . . . . . . . 72<br />
B.1.3. Mensaje recibido en varios suscriptores . . . . . . . . . . . . . . . 72<br />
B.1.4. Varios publicadores en un canal . . . . . . . . . . . . . . . . . . . 73<br />
B.1.5. Varios canales y publicadores y un sólo suscriptor . . . . . . . . . . 73<br />
B.2. Filtrado <strong>de</strong> eventos a nivel <strong>de</strong> canal . . . . . . . . . . . . . . . . . . . . . . 73<br />
B.2.1. Comprobación <strong>de</strong> valores en los filtros . . . . . . . . . . . . . . . . 73<br />
B.2.2. Tipos <strong>de</strong> los datos que circulan por el canal . . . . . . . . . . . . . 74<br />
B.2.3. Filtrado en el canal con un suscriptor . . . . . . . . . . . . . . . . 74<br />
B.2.4. Filtrado en el canal con varios suscriptores . . . . . . . . . . . . . 74<br />
B.2.5. Se envía un dato inválido a un canal con filtro . . . . . . . . . . . . 74<br />
B.2.6. Se indican varios filtros . . . . . . . . . . . . . . . . . . . . . . . . 74<br />
B.3. Filtrado <strong>de</strong> eventos a nivel <strong>de</strong> publicador . . . . . . . . . . . . . . . . . . . 75<br />
B.3.1. Correcta <strong>de</strong>finición <strong>de</strong> las expresiones en los filtros . . . . . . . . . 75<br />
B.3.2. Evento recibido con publicador filtrado . . . . . . . . . . . . . . . 75
B.3.3. Evento recibido con publicador filtrado en un canal filtrado . . . . . 75<br />
B.3.4. Se envía un dato inválido a un canal . . . . . . . . . . . . . . . . . 75<br />
B.3.5. Se envía un dato inválido a un canal con filtros . . . . . . . . . . . 76<br />
B.3.6. Un publicador con filtros y otro sin filtros . . . . . . . . . . . . . . 76<br />
B.3.7. Un publicador con filtros y otro sin filtros en un canal con filtros . . 76<br />
B.3.8. Se indican varios filtros . . . . . . . . . . . . . . . . . . . . . . . . 76<br />
B.4. Filtrado <strong>de</strong> eventos a nivel <strong>de</strong> suscripción . . . . . . . . . . . . . . . . . . 77<br />
B.4.1. Subscripción con filtro en un canal . . . . . . . . . . . . . . . . . . 77<br />
B.4.2. Varias suscripciones (con y sin filtro) a un canal . . . . . . . . . . . 77<br />
B.4.3. Subscripción con filtro en un canal con su propio filtro . . . . . . . 77<br />
B.4.4. Varias suscripciones a un canal con un publicador general . . . . . 78<br />
B.4.5. Suscripción con filtro a un canal con publicador, ambos con filtros . 78<br />
B.4.6. Suscripción con filtro a un canal con publicador, ambos con filtros . 78<br />
B.4.7. Se indican varios filtros . . . . . . . . . . . . . . . . . . . . . . . . 79<br />
B.4.8. Eliminar la suscripción a un canal . . . . . . . . . . . . . . . . . . 79<br />
B.4.9. Fe<strong>de</strong>ración <strong>de</strong> canales . . . . . . . . . . . . . . . . . . . . . . . . 79<br />
B.4.10. Fe<strong>de</strong>ración entre canales filtrados . . . . . . . . . . . . . . . . . . 79<br />
B.4.11. Fe<strong>de</strong>ración entre un canal con filtro y un canal sin filtro . . . . . . . 79<br />
B.4.12. Fe<strong>de</strong>ración con suscriptores con filtro y sin filtro . . . . . . . . . . 80<br />
B.4.13. Eventos no válidos para el enlace especificado . . . . . . . . . . . 80<br />
B.4.14. Eliminar el enlace entre canales . . . . . . . . . . . . . . . . . . . 80<br />
B.5. Modificación <strong>de</strong>l filtro en un suscriptor . . . . . . . . . . . . . . . . . . . . 81<br />
B.5.1. Cambio <strong>de</strong> filtro y recepción <strong>de</strong> eventos . . . . . . . . . . . . . . . 81<br />
B.5.2. Cambio <strong>de</strong> filtro y no recepción <strong>de</strong> eventos . . . . . . . . . . . . . 81<br />
B.6. Pruebas <strong>de</strong> integración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81<br />
C. Slices 83<br />
C.1. Eventos <strong>de</strong> localización <strong>de</strong>l proyecto Elcano . . . . . . . . . . . . . . . . . 83<br />
D. Tipos <strong>de</strong> filtros 85<br />
D.1. EventFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85<br />
D.2. EventFilterRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85<br />
D.3. EventFilterOver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86<br />
D.4. EventFilterBelow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86<br />
D.5. Función eval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
E. Estudio IceStorm 89<br />
E.1. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89<br />
F. Manual <strong>de</strong> usuario 92<br />
F.1. Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92<br />
F.2. Listar canales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93<br />
F.3. Crear un nuevo canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93<br />
F.4. Suscribirse a un canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94<br />
F.4.1. Subscribirse a un canal indicando filtros . . . . . . . . . . . . . . . 95<br />
Bibliografía 96
Índice <strong>de</strong> cuadros<br />
2.1. Operadores utilizados para filtros en DDS . . . . . . . . . . . . . . . . . . 17<br />
5.1. Tipos <strong>de</strong> filtros en IceDDS . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
6.1. Operadores comparativos para expresar filtros . . . . . . . . . . . . . . . . 50<br />
6.2. Operadores lógicos para filtros . . . . . . . . . . . . . . . . . . . . . . . . 50<br />
6.3. Líneas <strong>de</strong> código separado por elementos . . . . . . . . . . . . . . . . . . 55<br />
6.4. Líneas <strong>de</strong> código por lenguaje <strong>de</strong> programación . . . . . . . . . . . . . . . 55<br />
6.5. Estimación <strong>de</strong> costes <strong>de</strong>l proyecto . . . . . . . . . . . . . . . . . . . . . . 56<br />
D.1. Operadores lógicos para expresar un conjunto <strong>de</strong> filtros . . . . . . . . . . . 87<br />
D.2. Operadores comparativos para expresar filtros . . . . . . . . . . . . . . . . 87<br />
XII
Índice <strong>de</strong> figuras<br />
2.1. Invocación entre dos objetos . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
2.2. Estructura <strong>de</strong> comunicación cliente-servidor en Ice . . . . . . . . . . . . . 5<br />
2.3. Fe<strong>de</strong>ración <strong>de</strong> canales IceStorm . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
2.4. Arquitectura CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.5. Arquitectura Java RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
2.6. Estándar DDS [ucs11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
2.7. Una única cola <strong>de</strong> lectura asociada a un canal sin clave especificada . . . . 14<br />
2.8. Varias colas <strong>de</strong> lectura <strong>de</strong> cada instancia <strong>de</strong>l canal con clave <strong>de</strong>finida . . . . 15<br />
2.9. Arquitectura <strong>de</strong>l sistema Elcano . . . . . . . . . . . . . . . . . . . . . . . 19<br />
4.1. Diagrama <strong>de</strong> flujo <strong>de</strong>l prototipado incremental . . . . . . . . . . . . . . . . 26<br />
5.1. Visión general para el <strong>de</strong>sarrollo <strong>de</strong> la API con ZeroC Ice . . . . . . . . . . 30<br />
5.2. Diagrama <strong>de</strong> Casos <strong>de</strong> Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
5.3. Arquitectura <strong>de</strong>l mo<strong>de</strong>lo <strong>de</strong> comunicaciones suscriptor/publicador IceDDS . 33<br />
5.4. Diagrama <strong>de</strong> secuencia <strong>de</strong> la creación <strong>de</strong> un canal con filtros . . . . . . . . 39<br />
5.5. Diagrama <strong>de</strong> secuencia para un publicador filtrado . . . . . . . . . . . . . . 41<br />
5.6. Procedimiento <strong>de</strong> una suscripción indicando filtros en el mo<strong>de</strong>lo <strong>de</strong> comunicaciones<br />
IceDDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
5.7. Diagrama <strong>de</strong> secuencia <strong>de</strong> una suscripción con filtros . . . . . . . . . . . . 44<br />
5.8. Fe<strong>de</strong>ración <strong>de</strong> canales con filtro en IceDDS . . . . . . . . . . . . . . . . . 45<br />
6.1. Vista <strong>de</strong> las áreas que cubre cada canal en el mapa . . . . . . . . . . . . . . 51<br />
6.2. Ruta <strong>de</strong>l usuario en el escenario 1 . . . . . . . . . . . . . . . . . . . . . . 51<br />
6.3. Ruta <strong>de</strong>l usuario en la aplicación IceDDSAndroid . . . . . . . . . . . . . . 52<br />
6.4. Visión que muestra la pantalla <strong>de</strong>l dispositivo con respecto al mapa completo 52<br />
6.5. Publicadores existentes que limitan el envío <strong>de</strong> datos a zonas concretas . . . 53<br />
6.6. Fe<strong>de</strong>ración <strong>de</strong> canales filtrados . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
A.1. Arquitectura <strong>de</strong> un nodo <strong>de</strong> la tecnología OpenSplice DDS . . . . . . . . . 63<br />
XIII
A.2. Puerta <strong>de</strong> enlace <strong>de</strong> la tecnología OpenSplice DDS . . . . . . . . . . . . . . 64<br />
A.3. El consumidor se suscribe al canal . . . . . . . . . . . . . . . . . . . . . . 70<br />
A.4. Paquete que contiene los datos <strong>de</strong> un evento <strong>de</strong> localización . . . . . . . . . 71<br />
B.1. Escenario para la prueba <strong>de</strong> integración <strong>de</strong> IceDDS . . . . . . . . . . . . . 82<br />
F.1. Pantalla principal <strong>de</strong> la aplicación aAndroid . . . . . . . . . . . . . . . . . 92<br />
F.2. Error lanzado por aplicaciones Android . . . . . . . . . . . . . . . . . . . 93<br />
F.3. Lista <strong>de</strong> canales en el sistema . . . . . . . . . . . . . . . . . . . . . . . . . 93<br />
F.4. Crear un nuevo canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94<br />
F.5. Eliminar filtro cuando se quiere crear un canal . . . . . . . . . . . . . . . . 94<br />
F.6. Diálogo para realizar la suscripción a un canal . . . . . . . . . . . . . . . . 95<br />
F.7. Suscripción añadiendo filtros propios . . . . . . . . . . . . . . . . . . . . . 95
Índice <strong>de</strong> listados<br />
2.1. Ejemplo <strong>de</strong> interfaz SLICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
2.2. Tipo <strong>de</strong> canal DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
2.3. Tipos <strong>de</strong> canal con clave y sin clave . . . . . . . . . . . . . . . . . . . . . 14<br />
2.4. Escritura en un canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
5.1. Ejemplo <strong>de</strong> prueba unitaria . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
5.2. Ejemplo <strong>de</strong> prueba <strong>de</strong> integración . . . . . . . . . . . . . . . . . . . . . . 34<br />
5.3. SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice . . . . . . . . 36<br />
5.4. Definición <strong>de</strong>l tipo para filtros . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
5.5. Tipo <strong>de</strong> código <strong>de</strong> los filtros . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
5.6. SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice . . . . . . . . 38<br />
5.7. SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice . . . . . . . . 40<br />
5.8. SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice . . . . . . . . 42<br />
5.9. SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice . . . . . . . . 45<br />
5.10. Obtención y modificación <strong>de</strong> los filtros asociados a un canal . . . . . . . . 46<br />
5.11. SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice . . . . . . . . 47<br />
6.1. Evento <strong>de</strong> localización <strong>de</strong> Elcano . . . . . . . . . . . . . . . . . . . . . . . 49<br />
A.1. IDL utilizado para el ejemplo HelloWorld <strong>de</strong> OpenSplice DDS . . . . . . . 64<br />
A.2. Suscriptor <strong>de</strong> OpenSplice DDS . . . . . . . . . . . . . . . . . . . . . . . . 65<br />
A.3. Publicador <strong>de</strong> OpenSplice DDS . . . . . . . . . . . . . . . . . . . . . . . . 66<br />
A.4. IDL que especifica el tipo <strong>de</strong> canal con una estructura <strong>de</strong> datos semejante a<br />
la utilizada en los eventos <strong>de</strong>l proyecto Elcano . . . . . . . . . . . . . . . . 68<br />
A.5. Operaciones realizadas para la creación <strong>de</strong> un canal filtrado en OpenSplice<br />
DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68<br />
C.1. Posibles eventos <strong>de</strong> localización <strong>de</strong>l proyecto Elcano . . . . . . . . . . . . 83<br />
D.1. Clase EventFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85<br />
D.2. Clase EventFilterRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85<br />
D.3. Clase EventFilterOver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86<br />
D.4. Clase EventFilterBelow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86<br />
E.1. Interfaces utilizadas para establecer un <strong>de</strong>terminado tipo <strong>de</strong> suscriptor) . . . 89<br />
XV
E.2. Canal encargado <strong>de</strong> la comunicación con los servicios IceStorm . . . . . . 90<br />
E.3. Implementación <strong>de</strong> un suscriptor para el canal <strong>de</strong>legado . . . . . . . . . . . 91<br />
E.4. Implementación <strong>de</strong> un publicador para el canal <strong>de</strong>legado . . . . . . . . . . 91
Listado <strong>de</strong> acrónimos<br />
API<br />
Arco<br />
BDD<br />
CEP<br />
CORBA<br />
DCPS<br />
DDS<br />
DDSI<br />
ESI<br />
ESP<br />
GCC<br />
GDS<br />
GIOP<br />
GPL<br />
GPS<br />
Ice<br />
IDL<br />
IIOP<br />
OMG<br />
OpenLS<br />
ORB<br />
MLP<br />
QoS<br />
RFID<br />
RMI<br />
RTI<br />
Application Programming Interface<br />
Arquitectura y Re<strong>de</strong>s <strong>de</strong> Computadores<br />
Behavior Driven Development<br />
Complex Event Processing<br />
Common Object Request Broker Architecture<br />
Data-Centric Publish-Subscribe<br />
Data Distribution Service<br />
DDS Interoperability Wire Protocol<br />
Escuela Superior <strong>de</strong> Informática<br />
Event Stream Processing<br />
GNU Compiler Collection<br />
Global Data Space<br />
General Inter-ORB Protocol<br />
GNU General Public License<br />
Global Positioning System<br />
Internet Communications Engine<br />
Interface Definition <strong>La</strong>nguage<br />
Internet Inter-ORB Protocol<br />
Object Management Group<br />
Open Geospatial Consortium452<br />
Object Request Broker<br />
Mobile Location Protocol<br />
Quality of Service<br />
Radio Frequency IDentification<br />
Java Remote Method Invocation<br />
Real-Time Innovations<br />
XVII
RTPS<br />
SCADA<br />
Slice<br />
TCP<br />
TDD<br />
WiFi<br />
Real-Time Publish-Subscribe<br />
Supervisory Control And Data Acquisition<br />
Specification <strong>La</strong>nguage for Ice<br />
Transmission Control Protocol<br />
Test Driven Development<br />
Wireless Fi<strong>de</strong>lity
Agra<strong>de</strong>cimientos<br />
«Creer es primo hermano <strong>de</strong> la mentira»<br />
Mi padre<br />
...pero parece ser que ya no es una creencia, sino una realidad, ha llegado el final. Todos<br />
estos años han servido para formarme tanto académica como personalmente y, la verdad, me<br />
da un poquito <strong>de</strong> pena abandonar el barco. Pero es la hora <strong>de</strong> empezar otra nueva etapa y<br />
antes <strong>de</strong> ello, me gustaría agra<strong>de</strong>cer a todas las personas que han estado a mi lado en este<br />
trayecto <strong>de</strong> mi vida.<br />
En primer lugar, me gustaría darle las gracias a mis padres. Ellos siempre me han dado<br />
su cariño incondicional y me han enseñado a valorar y a disfrutar las buenas cosas <strong>de</strong> la<br />
vida. También tengo que agra<strong>de</strong>cer a mi hermana, que a pesar <strong>de</strong> ser la más pequeña, le <strong>de</strong>bo<br />
mucho, gracias por tu apoyo.<br />
A mis compañeros <strong>de</strong> la universidad: Alicia, Luis, Miguel, Sergio, Pirri... con los que<br />
he compartido inquietu<strong>de</strong>s, <strong>de</strong>svelos, alegrías y entusiasmo, gracias por convertiros en unos<br />
amigos admirables y espero que conservemos nuestra amistad durante mucho tiempo.<br />
Gracias a mis compañeros <strong>de</strong>l laboratorio por hacer <strong>de</strong>l trabajo algo más que una simple<br />
ocupación. Me alegro <strong>de</strong> haber entrado a formar parte <strong>de</strong> ellos, ya que está siendo una<br />
experiencia muy satisfactoria tanto a nivel personal como profesional.<br />
Agra<strong>de</strong>zco el tiempo <strong>de</strong>dicado a mi director David Villa, sin el cual este proyecto no<br />
hubiese llegado a su fin. Gracias por aumentar mis ganas <strong>de</strong> apren<strong>de</strong>r y enriquecer mi formación.<br />
Tampoco puedo olvidarme <strong>de</strong> mis amigos “no informáticos”: mis compañeras <strong>de</strong> piso y<br />
amigas Selene y Chiqui, y mis amigos <strong>de</strong>l pueblo Cristina (Poten), Jose, Silvia, M a José<br />
(Patata), Ana y Consuelo. A ellos quiero agra<strong>de</strong>cerles aguantar todas mis locuras y estar ahí<br />
siempre, en los buenos y en los malos momentos.<br />
Por último, agra<strong>de</strong>cer a mi banda <strong>de</strong> música, ella me ha dado momentos inolvidables que<br />
han hecho que mi vida sea más apasionante cada día que paso tocando entre sus músicos.<br />
Gracias a todos.<br />
XIX
A mis padres, por su paciencia y comprensión
Introducción<br />
1<br />
En la actualidad existen cada vez más sistemas centrados en la comunicación <strong>de</strong> datos<br />
haciendo uso <strong>de</strong> la red. <strong>La</strong> eficiencia, escalabilidad y la calidad <strong>de</strong> servicio constituyen los<br />
pilares básicos que representan a las tecnologías en sistemas <strong>de</strong> este tipo.<br />
Estos sistemas suelen compren<strong>de</strong>r <strong>de</strong>spliegues <strong>de</strong> tecnología a gran escala en los cuales los<br />
diferentes componentes que forman parte <strong>de</strong>l mismo necesitan la recogida <strong>de</strong> la información<br />
que circula entre ellos en tiempo real. A<strong>de</strong>más, se caracterizan por ser sistemas distribuidos<br />
que utilizan middlewares que hacen que las distintas partes que los constituyen esten<br />
integradas <strong>de</strong> manera transparente para el resto <strong>de</strong>l sistema. De esta manera se consigue in<strong>de</strong>pen<strong>de</strong>ncia<br />
tanto <strong>de</strong> arquitectura hardware, sistema operativo y lenguajes <strong>de</strong> programación<br />
utilizados para el <strong>de</strong>sarrollo <strong>de</strong> los diferentes módulos que lo forman. Simuladores, sistemas<br />
<strong>de</strong> <strong>de</strong>fensa naval y aéreo, control y gestión <strong>de</strong>l tráfico aéreo, sistemas Supervisory Control<br />
And Data Acquisition (SCADA) <strong>de</strong> gran escala,... son algunos ejemplos <strong>de</strong> tecnologías don<strong>de</strong><br />
la adquisición <strong>de</strong> la información en tiempo real es lo más importante.<br />
Des<strong>de</strong> el año 2003, el grupo Object Management Group (OMG) [OMG97] publica la primera<br />
versión <strong>de</strong>l estándar Data Distribution Service (DDS) [OMG07], una especificación <strong>de</strong><br />
un middleware <strong>de</strong> tipo publicador/suscriptor con gran<strong>de</strong>s ventajas prácticas para el transporte<br />
<strong>de</strong> eventos complejos en tiempo real que, actualmente, se está utilizando en muchos <strong>de</strong> los<br />
sistemas anteriormente mencionados.<br />
A menor escala, también existen tecnologías que necesitan obtener información en tiempo<br />
real. Es el caso <strong>de</strong> la localización <strong>de</strong> dispositivos en <strong>de</strong>terminados espacios ya sean exteriores<br />
o interiores. <strong>La</strong> tecnología GPS, ampliamente utilizada, hace posible el posicionamiento y el<br />
guiado en lugares exteriores (calles, carreteras, autovías, etc.), pero el <strong>de</strong>sarrollo <strong>de</strong> tecnologías<br />
para el posicionamiento <strong>de</strong> personas en el interior <strong>de</strong> edificios está menos solventado.<br />
En este ámbito se enmarca el proyecto Elcano que está siendo <strong>de</strong>sarrollado en el grupo <strong>de</strong><br />
investigación <strong>ARCO</strong>. En este proyecto se combinan las tecnologías WIFI, Bluetooth y RFID<br />
para posicionar al usuario <strong>de</strong>ntro <strong>de</strong> un espacio limitado.<br />
En Elcano es notable la importancia que adquiere la recepción <strong>de</strong> datos en tiempo real, ya<br />
que la posición <strong>de</strong> los diferentes usuarios en el sistema tiene que ser lo más afín posible a<br />
la posición real que mantienen los mismos. <strong>La</strong> enorme variedad <strong>de</strong> información a incluir en<br />
1
1. INTRODUCCIÓN 2<br />
los eventos <strong>de</strong> localización hacen aconsejable el uso <strong>de</strong> middlewares más escalables como el<br />
especificado en el estándar DDS.<br />
Teniendo en cuenta los problemas que existen en el Elcano, el presente proyecto persigue<br />
dar una solución implementado un mo<strong>de</strong>lo <strong>de</strong> comunicaciones orientado a objetos, basado<br />
en software libre, que utilice los servicios ofrecidos por el middleware ZeroC Ice introduciendo<br />
parámetros <strong>de</strong> calidad <strong>de</strong> servicio atendiendo al estándar DDS <strong>de</strong> OMG. Aunque el<br />
<strong>de</strong>sarrollo <strong>de</strong>l proyecto esté envuelvo <strong>de</strong>ntro <strong>de</strong>l proyecto Elcano, sirviendo éste como ayuda<br />
o escenario real para ir construyendo el mo<strong>de</strong>lo <strong>de</strong> comunicaciones requerido, el producto<br />
final será perfectamente aplicable a otras tecnologías.<br />
1.1. Estructura <strong>de</strong>l documento<br />
A continuación se <strong>de</strong>tallan los capítulos que componen este documento con una breve<br />
<strong>de</strong>scripción <strong>de</strong>l contenido <strong>de</strong> cada uno <strong>de</strong> ellos.<br />
Capítulo 2: «Antece<strong>de</strong>ntes»<br />
En este capítulo se realiza un breve repaso <strong>de</strong> los middleware <strong>de</strong> comunicaciones orientados<br />
a objetos, el estándar Data Distribution Service (DDS) para sistemas en tiempo<br />
real creado por OMG y los diferentes implementaciones existentes en el mercado.<br />
A<strong>de</strong>más, se <strong>de</strong>scribe las características <strong>de</strong> los proyectos Elcano, <strong>de</strong>sarrollado en el<br />
grupo <strong>ARCO</strong>, y Energos, que hacen a los mismos candidatos para implantar el mo<strong>de</strong>lo<br />
<strong>de</strong> comunicaciones a <strong>de</strong>sarrollar en este proyecto.<br />
Capítulo 3: «Objetivos»<br />
El objetivo principal <strong>de</strong>l proyecto es la implementación <strong>de</strong> una API atendiendo a los<br />
parámetros <strong>de</strong> calidad <strong>de</strong> servicio (QOS) <strong>de</strong>l estándar OMG DDS [OMG07] utilizando<br />
el middleware ZeroC Ice [ICEb].<br />
En este capítulo se <strong>de</strong>tallarán los objetivos específicos que se preten<strong>de</strong>n alcanzar a lo<br />
largo <strong>de</strong>l ciclo <strong>de</strong> vida <strong>de</strong>l proyecto.<br />
Capítulo 4: «Método <strong>de</strong> trabajo y herramientas»<br />
<strong>La</strong> metodología que se sigue para el <strong>de</strong>sarrollo <strong>de</strong> este proyecto es el prototipado<br />
incremental junto con la técnica Test Driven Development (TDD) para la implementación<br />
<strong>de</strong>l mismo.<br />
En este capítulo se <strong>de</strong>scribe la metodología y técnica anteriores, así como las herramientas<br />
que se han utilizado durante la realización <strong>de</strong>l proyecto.<br />
Capítulo 5: «Desarrollo <strong>de</strong>l proyecto»<br />
En este capítulo se exponen el trabajo realizado en las diferentes iteraciones en las que<br />
se ha dividido el proyecto, así como los requisitos iniciales y el diseño que tiene que<br />
cumplir el mo<strong>de</strong>lo <strong>de</strong> comunicaciones a implementar.
1. INTRODUCCIÓN 3<br />
Capítulo 6: «Resultados»<br />
Se <strong>de</strong>scriben diversos escenarios reales en los cuales la utilidad <strong>de</strong> producto realizado<br />
es claramente beneficiosa. También se <strong>de</strong>scribirán el esfuerzo realizado, las líneas <strong>de</strong><br />
código, la estimación <strong>de</strong> los costes <strong>de</strong>l proyecto, ...<br />
Capítulo 7: «Conclusiones y trabajo futuro»<br />
El proyecto solo se centra en algunos aspectos concretos <strong>de</strong>l estándar DDS, por ello,<br />
permite la continuación <strong>de</strong>l <strong>de</strong>sarrollo añadiendo el resto <strong>de</strong> las funcionalida<strong>de</strong>s que<br />
proporciona dicho estándar.<br />
En este capítulo se muestran los trabajos futuros y las diferentes opciones cuyo <strong>de</strong>sarrollo<br />
dotará al proyecto <strong>de</strong> mejoras beneficiosas en el ámbito <strong>de</strong> sistemas en tiempo<br />
real.
Antece<strong>de</strong>ntes<br />
2<br />
En este capítulo se realiza una presentación <strong>de</strong> los conceptos y herramientas que se han<br />
utilizado para la elaboración <strong>de</strong>l proyecto, así como una <strong>de</strong>scripción y valoración <strong>de</strong> la especificación<br />
DDS para un middleware <strong>de</strong>l tipo publicador-suscriptor en sistemas distribuidos y<br />
un estudio <strong>de</strong> algunos <strong>de</strong> los mo<strong>de</strong>los existentes en el mercado. Este aprendizaje enriquecerá<br />
el <strong>de</strong>sarrollo <strong>de</strong>l proyecto.<br />
2.1. Middleware orientado a objetos<br />
Un middleware <strong>de</strong> comunicaciones orientado a objetos es una plataforma utilizada para el<br />
<strong>de</strong>sarrollo <strong>de</strong> aplicaciones <strong>de</strong> sistemas distribuidos. Este tipo <strong>de</strong> plataforma permite al programador<br />
abstraerse <strong>de</strong> la tecnología <strong>de</strong> red que se utiliza para establecer las comunicaciones<br />
entre las distintas aplicaciones. <strong>La</strong> comunicación entre objetos se realiza mediante invocaciones.<br />
En la figura 2.1 se muestra un ejemplo <strong>de</strong> una llamada <strong>de</strong> un objeto Cliente a otro<br />
objeto Servidor que está en otro nodo <strong>de</strong> la red. <strong>La</strong> invocación a esta llamada es traducida<br />
por el middleware para permitir que el mensaje sea enviado <strong>de</strong> un nodo a otro. En este tipo<br />
<strong>de</strong> plataformas, el cliente es el que efectúa las peticiones y el servidor es la entidad que las<br />
atien<strong>de</strong>, aunque las dos entida<strong>de</strong>s pue<strong>de</strong>n actuar <strong>de</strong> servidor o <strong>de</strong> cliente indistintamente.<br />
Figura 2.1: Invocación entre dos objetos<br />
En la actualidad existen diferentes alternativas que se ajustan a este comportamiento. A<br />
continuación se explicarán algunas <strong>de</strong> las más importantes, aunque se hace más hincapié en<br />
ZeroC Ice ya que es una parte importante <strong>de</strong>l presente proyecto.<br />
2.1.1. ZeroC Ice<br />
Internet Communications Engine (ICE) es un middleware <strong>de</strong> comunicación orientado a<br />
objetos con licencia GPL y <strong>de</strong>sarrollado por la empresa ZeroC. Soporta varios lenguajes, lo<br />
4
2. ANTECEDENTES 5<br />
que permite una mayor adaptabilidad según las necesida<strong>de</strong>s.<br />
Al ser un middleware <strong>de</strong> comunicaciones orientado a objetos, ICE está basado en una<br />
arquitectura cliente-servidor. Para establecer la comunicación entre estas dos entida<strong>de</strong>s el<br />
cliente necesita un proxy al objeto para po<strong>de</strong>r solicitar sus servicios y el servidor tiene que<br />
ser añadido a un adaptador <strong>de</strong> objetos para que el cliente pueda acce<strong>de</strong>r a él a través <strong>de</strong>l<br />
middleware. En la figura 2.2 se muestra una visión general <strong>de</strong> esta arquitectura.<br />
Figura 2.2: Estructura <strong>de</strong> comunicación cliente-servidor en Ice<br />
A continuación se <strong>de</strong>scriben los conceptos básicos <strong>de</strong> la arquitectura ICE así como una<br />
breve explicación <strong>de</strong> los servicios que ofrece.<br />
Adaptador <strong>de</strong> objetos<br />
El adaptador <strong>de</strong> objetos es un mecanismo que actúa como contenedor <strong>de</strong> los objetos <strong>de</strong>l<br />
servidor que son accedidos mediante invocaciones remotas. Cada adaptador <strong>de</strong> objetos tiene<br />
una o varias direcciones asignadas que son conocidas como endpoints. Cada endpoint se<br />
i<strong>de</strong>ntifica mediante una ca<strong>de</strong>na que contiene el protocolo <strong>de</strong> transporte utilizado, la dirección<br />
IP y el puerto. Un ejemplo <strong>de</strong> endpoint es el siguiente:<br />
tcp -h 127.0.0.1 -p 10000<br />
don<strong>de</strong> tcp indica que se utilizará un protocolo <strong>de</strong> transporte TCP, se escuchará por la<br />
interfaz con dirección 127.0.0.1 y en el puerto 10000.<br />
Sirviente<br />
El sirviente es un instancia <strong>de</strong>l objeto remoto que recibe las invocaciones. Los sirvientes<br />
son los objetos que se aña<strong>de</strong>n a los adaptadores <strong>de</strong> objetos para que puedan recibir solicitu<strong>de</strong>s
2. ANTECEDENTES 6<br />
<strong>de</strong>l exterior. El cliente realizará las llamadas remotas mediante un objeto proxy proporcionado<br />
por el middleware.<br />
I<strong>de</strong>ntidad <strong>de</strong> un objeto<br />
Los sirvientes que son añadidos al adaptador <strong>de</strong> objetos se registran con una i<strong>de</strong>ntidad<br />
que los i<strong>de</strong>ntifica <strong>de</strong> manera única en el sistema distribuido. Esta característica pue<strong>de</strong> ser<br />
añadida por el programador o <strong>de</strong> manera automática mediante los diferentes métodos que<br />
proporciona el adaptador <strong>de</strong> objetos <strong>de</strong> ICE.<br />
Proxy<br />
El proxy se representa como una ca<strong>de</strong>na <strong>de</strong> caracteres que contiene la i<strong>de</strong>ntidad <strong>de</strong>l objeto<br />
unida al endpoint <strong>de</strong>l adaptador don<strong>de</strong> se ha añadido. Por ejemplo:<br />
I<strong>de</strong>ntity -t : tcp -h 127.0.0.1 -p 10000<br />
<strong>La</strong> opción -t es el modo <strong>de</strong> acceso al objeto. Significa twoway, es <strong>de</strong>cir, el sirviente recibe<br />
peticiones y se espera una respuesta. Hay otras posibles opciones, como por ejemplo -o<br />
(oneway) don<strong>de</strong> el sirviente recibe peticiones y no hay respuesta.<br />
Communicator<br />
El Communicator es el elemento más importante <strong>de</strong>l middleware. Proporciona la comunicación<br />
entre los clientes y los servidores en el sistema distribuido. Se encarga <strong>de</strong> crear los<br />
adaptadores <strong>de</strong> objetos, proxys, i<strong>de</strong>ntida<strong>de</strong>s <strong>de</strong> objetos, ...<br />
Slice<br />
Specification <strong>La</strong>nguage for Ice (SLICE) es un lenguaje que se utiliza para <strong>de</strong>scribir las operaciones<br />
sobre las que los clientes pue<strong>de</strong>n hacer invocaciones. Aquí se <strong>de</strong>fine la interfaz y las<br />
operaciones que serán accesibles mediante un proxy a un sirviente <strong>de</strong>terminado y se establecen<br />
in<strong>de</strong>pendientemente <strong>de</strong>l lenguaje <strong>de</strong> programación que se vaya a utilizar. ICE proporciona<br />
herramientas para traducir la interfaz SLICE en diferentes lenguajes. Los lenguajes a los que<br />
ICE da soporte son C++, Python, Java, .NET, PHP, Objective-C, Ruby y ActionScript. En el<br />
listado 2.1 se muestra un ejemplo sencillo <strong>de</strong> SLICE.<br />
module UCLM {<br />
interface Hello {<br />
void puts(string str);<br />
};<br />
};<br />
Listado 2.1: Ejemplo <strong>de</strong> interfaz SLICE
2. ANTECEDENTES 7<br />
Tanto el cliente como el servidor pue<strong>de</strong>n estar implementados en diferentes lenguajes <strong>de</strong><br />
programación, lo que ofrece una ventaja bastante importante, ya que se pue<strong>de</strong> implementar<br />
clientes en diferentes lenguajes sin necesidad <strong>de</strong> cambiar nada en el servidor.<br />
Servicios<br />
ICE ofrece una serie <strong>de</strong> servicios que gestionan otras características para propósitos más<br />
concretos:<br />
IceStorm<br />
IceStorm [icea] es un servicio que proporciona comunicaciones entre clientes y servidores<br />
mediante la creación <strong>de</strong> canales <strong>de</strong> eventos. En este ámbito se habla <strong>de</strong> publicador<br />
y suscriptor en vez <strong>de</strong> cliente y servidor. Los publicadores envían datos al canal<br />
mediante invocaciones remotas que serán enviadas a los suscriptores <strong>de</strong> dicho canal.<br />
De este modo, un único evento <strong>de</strong> un publicador pue<strong>de</strong> ser enviado a múltiples suscriptores.<br />
Cada canal está i<strong>de</strong>ntificado unívocamente por un nombre y pue<strong>de</strong> tener a su<br />
vez múltiples publicadores y múltiples suscriptores.<br />
IceStorm también soporta manejo <strong>de</strong> excepciones causadas por un comportamiento<br />
ina<strong>de</strong>cuado <strong>de</strong> la red o por la pérdida <strong>de</strong> suscriptores.<br />
Los eventos IceStorm son unidireccionales, es <strong>de</strong>cir, el publicador no recibe respuestas<br />
<strong>de</strong>s<strong>de</strong> los suscriptores.<br />
Una <strong>de</strong> las características <strong>de</strong> este servicio es la fe<strong>de</strong>ración. <strong>La</strong> fe<strong>de</strong>ración permite realizar<br />
enlaces entre canales. Cada enlace es una asociación unidireccional <strong>de</strong>s<strong>de</strong> un canal<br />
o otro y tiene asociado un coste que pue<strong>de</strong> limitar la entrega en ese canal.<br />
Estos enlaces hacen que los eventos publicados en un canal también sean publicados<br />
en todos los canales que estén enlazados a él con coste que no exceda <strong>de</strong>l indicado en<br />
el momento <strong>de</strong> la creación <strong>de</strong>l enlace.<br />
<strong>La</strong> figura 2.3 representa un ejemplo <strong>de</strong> fe<strong>de</strong>ración <strong>de</strong> canales. El canal T1 tiene enlaces<br />
a T2 y T3. Los suscriptores S1 y S2 reciben todos los eventos publicados en T2 así como<br />
los publicados en T1. El suscriptor S3 sólo recibe los eventos <strong>de</strong> T1 y el suscriptor<br />
S4 recibe los eventos <strong>de</strong> T1 y T3.<br />
Este servicio es el más relevante ya que será utilizado en el <strong>de</strong>sarrollo <strong>de</strong> este proyecto.<br />
IceGrid<br />
IceGrid es un servicio <strong>de</strong> localización y activación para las aplicaciones ICE. Esto<br />
permite que un cliente se comunique con un objeto remoto sin saber en qué máquina<br />
y en qué puerto está (proxies indirectos).<br />
Una <strong>de</strong> las características <strong>de</strong> IceGrid es la activación <strong>de</strong> los servidores bajo <strong>de</strong>manda,<br />
es <strong>de</strong>cir, cuando un cliente realiza una solicitud a un objeto en el servidor.
2. ANTECEDENTES 8<br />
Figura 2.3: Fe<strong>de</strong>ración <strong>de</strong> canales IceStorm<br />
IceGrid permite la replicación mediante la agrupación <strong>de</strong> los adaptadores <strong>de</strong> objetos<br />
<strong>de</strong> varios servidores en un único adaptador <strong>de</strong> objetos virtual y el balanceo <strong>de</strong> carga.<br />
A<strong>de</strong>más, soporta interfaces que proporcionan a las aplicaciones un control sobre su<br />
actividad y notificaciones acerca <strong>de</strong> eventos significativos, lo que permite el <strong>de</strong>sarrollo<br />
<strong>de</strong> herramientas personalizadas.<br />
IceBox<br />
IceBox es un servidor <strong>de</strong> aplicaciones que gestiona el arranque y <strong>de</strong>tención <strong>de</strong> distintos<br />
componentes <strong>de</strong> una aplicación.<br />
El servidor IceBox se configura a través <strong>de</strong> las propieda<strong>de</strong>s <strong>de</strong> los servicios <strong>de</strong> la aplicación.<br />
Estos servicios se pue<strong>de</strong>n administrar <strong>de</strong> forma remota y compartir una interfaz<br />
común que permite una administración centralizada.<br />
IcePatch<br />
IcePatch es un servicio que permite la distribución <strong>de</strong> actualizaciones <strong>de</strong> software a los<br />
nodos que componen el grid. El servicio comprueba automáticamente la versión que<br />
tiene cada nodo y envía las actualizaciones disponibles. Esta comunicación se pue<strong>de</strong><br />
realizar <strong>de</strong> forma segura utilizando el servicio Glacier2 mencionado más a<strong>de</strong>lante.<br />
Glacier2<br />
Glacier2 es un servicio <strong>de</strong> firewall 1 que permite una comunicación segura entre clientes<br />
y servidores. Los datos que se transportan entre clientes y servidores están encriptados.<br />
1 Sistema que permite bloquear los accesos no autorizados, así como permitir los autorizados.
2. ANTECEDENTES 9<br />
Freeze<br />
Freeze ofrece un servicio <strong>de</strong> persistencia que le permite guardar el estado <strong>de</strong> los objetos<br />
ICE en una base <strong>de</strong> datos Berkeley 2 con muy poco esfuerzo. Freeze pue<strong>de</strong> recuperar<br />
automáticamente bajo <strong>de</strong>manda los objetos <strong>de</strong> una base <strong>de</strong> datos y actualizarla cuando<br />
cambia el estado <strong>de</strong> un objeto.<br />
2.1.2. CORBA<br />
Common Object Request Broker Architecture (CORBA) [COR] es un estándar <strong>de</strong>finido<br />
por Object Management Group (OMG) para la programación <strong>de</strong> aplicaciones distribuidas.<br />
CORBA es una <strong>de</strong> las arquitecturas actualmente más extendida. Permite que los componentes<br />
puedan estar escritos en diferentes lenguajes y ejecutarse en diferentes máquinas. El mo<strong>de</strong>lo<br />
cliente-servidor <strong>de</strong> CORBA (figura 2.4) es muy parecido al <strong>de</strong> ICE. Se utilizan interfaces IDL<br />
para la comunicación entre dos o más aplicaciones.<br />
Figura 2.4: Arquitectura CORBA<br />
Una parte esencial <strong>de</strong> la arquitectura CORBA es el Object Request Broker (ORB) que se<br />
encarga <strong>de</strong> facilitar la comunicación entre objetos, es <strong>de</strong>cir, es el encargado <strong>de</strong> enviar las<br />
invocaciones realizadas por los clientes y <strong>de</strong> retornar las repuestas a los mismos.<br />
El estándar CORBA especifica un protocolo <strong>de</strong> transporte llamado General Inter-ORB Protocol<br />
(GIOP) para las comunicaciones entre varios componentes ORBs e Internet Inter-ORB<br />
Protocol (IIOP) es el protocolo utilizado para re<strong>de</strong>s TCP/IP.<br />
Existen muchas implementaciones <strong>de</strong>l estándar CORBA tanto privativas como libres. Algunos<br />
ejemplos son TAO [TCO10], OpenFusion CORBA [OPC] y ORBit2 <strong>de</strong> GNOME [GNO04].<br />
2.1.3. JAVA RMI<br />
Java Remote Method Invocation (RMI) [Inc06] es un middleware creado por Sun Microsystems<br />
para aplicaciones <strong>de</strong>sarrolladas en Java. <strong>La</strong> interfaz entre el cliente y el servidor<br />
2 Biblioteca <strong>de</strong> software que proporciona una base <strong>de</strong> datos integrada <strong>de</strong> alto rendimiento para los datos con<br />
formato clave/valor.
2. ANTECEDENTES 10<br />
se especifica mediante clases abstractas <strong>de</strong>finidas en java. Esto implica que los clientes y los<br />
servidores tienen que estar <strong>de</strong>sarrollados en java.<br />
En la figura 2.5 se muestra el funcionamiento <strong>de</strong> la arquitectura cliente-servidor <strong>de</strong> RMI.<br />
El servidor utiliza RMIRegistry para registrar los objetos que serán accesibles remotamente.<br />
Cada objeto se asocia con un único nombre utilizando el sistema RMI’s simple naming<br />
facility. Los clientes obtendrán una referencia a un objeto al cual hacer invocaciones remotas.<br />
Cada objeto registrado <strong>de</strong>be implementar al menos la interfaz Remote <strong>de</strong>finida en el<br />
middleware RMI.<br />
Figura 2.5: Arquitectura Java RMI<br />
El inconveniente <strong>de</strong> tener que <strong>de</strong>sarrollar los clientes y servidores en java hizo que no<br />
se tuviera en cuenta esta alternativa, ya que uno <strong>de</strong> los intereses <strong>de</strong> este proyecto es po<strong>de</strong>r<br />
aplicar el mo<strong>de</strong>lo cliente-servidor in<strong>de</strong>pendientemente <strong>de</strong> los lenguajes <strong>de</strong> programación en<br />
los que se <strong>de</strong>sarrollen.<br />
2.2. Data Distribution Service<br />
El estándar Data Distribution Service (DDS) <strong>de</strong> OMG fue introducido en 2004 para dirigir<br />
las estrategias <strong>de</strong> los sistemas <strong>de</strong> <strong>de</strong>fensa y aplicaciones aeroespaciales <strong>de</strong> manera distribuida.<br />
El objetivo principal para la utilización <strong>de</strong>l estándar fue el alto rendimiento y escalabilidad<br />
en sistemas integrados <strong>de</strong> gran escala.<br />
Actualmente, DDS está recomendado como clave para la administración y utilizado más<br />
allá <strong>de</strong>l aeroespacio y <strong>de</strong> la <strong>de</strong>fensa como pue<strong>de</strong> ser el comercio automatizado, simulaciones,<br />
telemetría, etc.
2. ANTECEDENTES 11<br />
DDS es una especificación <strong>de</strong> un API y un protocolo <strong>de</strong> interoperabilidad que <strong>de</strong>fine una arquitectura<br />
basada en el mo<strong>de</strong>lo publicador-subscriptor para la comunicación <strong>de</strong> información<br />
anónima entre proveedores y consumidores. Un proveedor <strong>de</strong> datos (publicador) publica flujos<br />
<strong>de</strong> datos i<strong>de</strong>ntificados por nombres llamados topics (canales) a los que los consumidores<br />
pue<strong>de</strong>n suscribirse. A<strong>de</strong>más, una aplicación pue<strong>de</strong> <strong>de</strong>sempeñar al mismo tiempo el rol <strong>de</strong><br />
proveedor y el <strong>de</strong> consumidor.<br />
<strong>La</strong>s características <strong>de</strong> DDS son:<br />
Desacoplamiento: los publicadores y los suscriptores pue<strong>de</strong>n estar en diferentes lugares.<br />
In<strong>de</strong>pen<strong>de</strong>ncia <strong>de</strong> plataformas: los publicadores y suscriptores pue<strong>de</strong>n estar implementados<br />
en plataformas diferentes y escritos en diferentes lenguajes <strong>de</strong> programación.<br />
Multiplicidad: pue<strong>de</strong>n existir múltiples publicadores y suscriptores en el mismo canal.<br />
Tiempo real: la información se entrega en el lugar y tiempo correctos. No entregar una<br />
información necesaria en el momento preciso pue<strong>de</strong> llevar a situaciones que entren en<br />
conflicto con los objetivos <strong>de</strong>seados.<br />
Fiable: se asegura la fiabilidad, seguridad e integridad a pesar <strong>de</strong> fallos <strong>de</strong> hardware y<br />
software.<br />
Alto rendimiento: permite distribuir gran<strong>de</strong>s volúmenes <strong>de</strong> datos con una baja latencia.<br />
Actualmente, el estándar DDS <strong>de</strong> la OMG está compuesto por DDS v1.2 API y DDS Interoperability<br />
Wire Protocol (DDSI) v2.1 (figura 2.6). El estándar DDS API garantiza la portabilidad<br />
<strong>de</strong>l código fuente a pesar <strong>de</strong> que los proveedores tengan diferentes implementaciones,<br />
mientras que el estándar DDSI asegura la interoperabilidad a través <strong>de</strong> implementaciones<br />
DDS <strong>de</strong> diferentes proveedores.<br />
Data-Centric Publish-Subscribe (DCPS) es la capa <strong>de</strong> DDS que proporciona la funcionalidad<br />
requerida para que una aplicación pueda publicar y suscribirse a los datos específicos <strong>de</strong><br />
los objetos y consta <strong>de</strong> 5 módulos:<br />
Mo<strong>de</strong>lo <strong>de</strong> la infraestructura – <strong>de</strong>fine las clases abstractas y las interfaces que son refinadas<br />
en otros módulos.<br />
Mo<strong>de</strong>lo <strong>de</strong>l dominio – contiene la clase DomainParticipant que actúa como un contenedor<br />
para otros objetos que componen la aplicación.<br />
Mo<strong>de</strong>lo <strong>de</strong>l canal – contiene las clases Topic, ContentFilteredTopic y MultiTopic. Estas clases<br />
<strong>de</strong>finen los diferentes canales. <strong>La</strong> clase ContentFilteredTopic <strong>de</strong>fine un canal al que<br />
se le aplica un filtro y la clase MultiTopic se utiliza para suscribirse a múltiples canales<br />
y combinar y/o filtrar los datos recibidos obteniendo como resultado un tipo.
2. ANTECEDENTES 12<br />
Figura 2.6: Estándar DDS [ucs11]<br />
Mo<strong>de</strong>lo <strong>de</strong> publicación – <strong>de</strong>fine las clases Publisher y DataWriter que son necesarias<br />
para publicar los datos.<br />
Mo<strong>de</strong>lo <strong>de</strong> suscripción – <strong>de</strong>fine las clases Subscriber y DataRea<strong>de</strong>r que son necesarios<br />
para po<strong>de</strong>r recibir los datos publicados.<br />
2.2.1. Espacio global <strong>de</strong> datos<br />
DDS está basado en un espacio global <strong>de</strong> datos (GDS) totalmente distribuido para evitar<br />
puntos <strong>de</strong> ruptura o cuellos <strong>de</strong> botella. Los publicadores y los subscriptores pue<strong>de</strong>n unirse<br />
o abandonar un GDS en cualquier momento. A<strong>de</strong>más, las aplicaciones pue<strong>de</strong>n automáticamente<br />
escribir y/o leer datos asíncronamente en/<strong>de</strong>l GDS.<br />
2.2.2. Canales (Topics)<br />
Los canales proporcionan el punto <strong>de</strong> conexión base entre los publicadores y los suscriptores.<br />
Para que la información viaje <strong>de</strong> manera correcta, el canal <strong>de</strong> un publicador en un nodo<br />
<strong>de</strong>be coincidir con el canal <strong>de</strong> un suscriptor asociado en cualquier otro nodo.<br />
Un canal está compuesto por un nombre, un tipo <strong>de</strong> datos y un conjunto <strong>de</strong> parámetros<br />
<strong>de</strong> Calidad <strong>de</strong> Servicio(QOS) que son usados para controlar las propieda<strong>de</strong>s no funcionales<br />
<strong>de</strong>l canal. Estos parámetros permiten a los diseñadores <strong>de</strong>l sistema construir una aplicación<br />
distribuida basada en requerimientos para cada parte específica <strong>de</strong> los datos.<br />
El nombre <strong>de</strong>l canal es una ca<strong>de</strong>na que i<strong>de</strong>ntifica unívocamente al canal en un dominio y
2. ANTECEDENTES 13<br />
el tipo es la <strong>de</strong>finición <strong>de</strong>l contenido <strong>de</strong> los datos en el canal.<br />
Se utiliza IDL como la forma para <strong>de</strong>scribir los datos <strong>de</strong> representación comunes en el<br />
canal. IDL es una sintaxis estándar para expresar varios tipos manteniendo la in<strong>de</strong>pen<strong>de</strong>ncia<br />
<strong>de</strong> un lenguaje <strong>de</strong> programación específico.<br />
Un tipo <strong>de</strong> canal está compuesto por una estructura IDL y una clave o un conjunto <strong>de</strong><br />
claves asociadas. <strong>La</strong> clave pue<strong>de</strong> ser vacía o pue<strong>de</strong> incluir un número arbitrario <strong>de</strong> atributos<br />
<strong>de</strong>finidos en el tipo <strong>de</strong> datos <strong>de</strong>l canal.<br />
<strong>La</strong> estructura pue<strong>de</strong> tener uno o más campos y cada campo pue<strong>de</strong> ser alguno <strong>de</strong> los siguientes<br />
tipos:<br />
char<br />
octet<br />
short<br />
unsigned short<br />
long<br />
unsigned long<br />
long long<br />
unsigned long long<br />
float<br />
double<br />
long double<br />
boolean<br />
enum<br />
union<br />
array o una secuencia<br />
string<br />
Si la clave <strong>de</strong>l tipo <strong>de</strong> datos es vacía, el canal tiene una única instancia. Este tipo <strong>de</strong><br />
canales pue<strong>de</strong>n ser consi<strong>de</strong>rados como singletons 3 . Los tipos <strong>de</strong> datos <strong>de</strong> los canales que<br />
tienen claves <strong>de</strong>finidas tienen una instancia por cada valor <strong>de</strong> la clave.<br />
En listado 2.2 se muestra una <strong>de</strong>finición <strong>de</strong> un tipo <strong>de</strong> canal cuya clave es la variable<br />
provi<strong>de</strong>r.<br />
struct LocEvent<br />
{<br />
string provi<strong>de</strong>r;<br />
string msid;<br />
long time;<br />
};<br />
#pragma keylist LocEvent provi<strong>de</strong>r<br />
Listado 2.2: Tipo <strong>de</strong> canal DDS<br />
Un ejemplo que muestra la diferencia entre estos dos tipos <strong>de</strong> datos <strong>de</strong> un canal pue<strong>de</strong><br />
verse en 2.3.<br />
3 Patrón <strong>de</strong> diseño que garantiza que haya una sola instancia <strong>de</strong> una <strong>de</strong>terminada clase.
2. ANTECEDENTES 14<br />
struct LocEvent<br />
{<br />
string provi<strong>de</strong>r;<br />
string msid;<br />
long time;<br />
};<br />
#pragma keylist LocEvent provi<strong>de</strong>r<br />
struct KeyLessLocEvent {<br />
string provi<strong>de</strong>r;<br />
string msid;<br />
long time;<br />
};<br />
#pragma keylist LocEvent<br />
Listado 2.3: Tipos <strong>de</strong> canal con clave y sin clave<br />
Si se escribe en el canal KeyLessLocEvent se modifica el valor que tenía, ya que es la<br />
misma instancia (singleton). En el otro caso, si se escribe en LocEvent se modifica el valor<br />
<strong>de</strong> una específica instancia <strong>de</strong>l canal, <strong>de</strong>pendiendo <strong>de</strong>l valor <strong>de</strong> la clave.<br />
El código 2.4 escribe dos muestras para la misma instancia (figura 2.7). <strong>La</strong>s dos muestras<br />
están en la misma cola <strong>de</strong> lectura.<br />
dds::Topic leTopic(‘‘KeyLessLocEventTopic’’);<br />
dds:DataWriter dw(leTopic);<br />
KeyLessLocEvent le = {’WIFI’, ’1001254589’, 2};<br />
dw.write(le);<br />
le = {’RFID’, ’1001254589’, 2};<br />
dw.write(le);<br />
Listado 2.4: Escritura en un canal<br />
Figura 2.7: Una única cola <strong>de</strong> lectura asociada a un canal sin clave especificada<br />
Si se escribe las mismas muestras para LocEvent el resultado es diferente. El código sería<br />
igual pero las muestras están en dos colas diferentes (figure 2.8).
2. ANTECEDENTES 15<br />
Figura 2.8: Varias colas <strong>de</strong> lectura <strong>de</strong> cada instancia <strong>de</strong>l canal con clave <strong>de</strong>finida<br />
2.2.3. Publisher/Subscriber<br />
Una infraestructura publicador/suscriptor es capaz <strong>de</strong> entregar los datos a los nodos a<strong>de</strong>cuados<br />
sin necesitad <strong>de</strong> establecer una comunicación individual.<br />
Los publicadores sólo necesitan saber el tipo <strong>de</strong>l dato específico <strong>de</strong> la información que<br />
están enviando. Al igual que los suscriptores sólo necesitan saber el tipo específico <strong>de</strong>l dato<br />
que van a recibir.<br />
2.2.4. Lectura y escritura <strong>de</strong> datos<br />
En DDS se utilizan objetos <strong>de</strong> escritura y <strong>de</strong> lectura para po<strong>de</strong>r establecer una comunicación<br />
entre publicadores y suscriptores. Estos objetos se llaman DataRea<strong>de</strong>r y DataWriter.<br />
Lectura <strong>de</strong> datos<br />
Los objetos DataRea<strong>de</strong>r son el principal punto <strong>de</strong> acceso en una aplicación para acce<strong>de</strong>r<br />
a los datos que han sido recibidos en el suscriptor. Una vez creado y configurado con los<br />
correctos parámetros QOS, una aplicación pue<strong>de</strong> ser notificada <strong>de</strong> que un dato está disponible<br />
<strong>de</strong> una <strong>de</strong> los siguientes maneras:<br />
Retorno <strong>de</strong> una llamada. DDS ejecuta inmediatamente el retorno <strong>de</strong> la llamada cuando<br />
un dato es recibido.<br />
Polling <strong>de</strong>l DataRea<strong>de</strong>r. Se pregunta constantemente si el dato está disponible.<br />
Condiciones y esperas. <strong>La</strong> aplicación espera hasta que una condición es satisfecha y<br />
entonces po<strong>de</strong>r acce<strong>de</strong>r al dato <strong>de</strong>s<strong>de</strong> el DataRea<strong>de</strong>r.<br />
Para leer los datos que son recibidos existen dos mecanismos. Uno <strong>de</strong> los mecanismos es<br />
la operación read que proporciona acceso a los datos recibidos mediante el DataRea<strong>de</strong>r sin<br />
eliminarlos <strong>de</strong> la memoria caché. De este modo los datos estarán disponibles para leerlos <strong>de</strong>
2. ANTECEDENTES 16<br />
nuevo realizando una llamada a la misma operación.<br />
El otro mecanismo es el que proporciona la operación take que da acceso a los datos recibidos<br />
por el DataRea<strong>de</strong>r eliminándolos <strong>de</strong> la memoria caché, es <strong>de</strong>cir, no se pue<strong>de</strong> acce<strong>de</strong>r<br />
a los datos una vez leídos.<br />
Escritura <strong>de</strong> datos<br />
Un publicador utiliza los DataWriter como principal punto <strong>de</strong> acceso para publicar datos.<br />
Una vez creado y configurado con las correctas características <strong>de</strong> QOS, una aplicación sólo<br />
necesita realizar una llamada <strong>de</strong> escritura. El ciclo <strong>de</strong> vida <strong>de</strong> estos objetos es <strong>de</strong>finido por<br />
su estado. Hay tres posibles estados:<br />
ALIVE: existe al menos un DataWriter escribiendo en la instancia.<br />
NOT_ALIVE_NO_WRITERS: no hay DataWriter escribiendo en la instancia <strong>de</strong>l canal.<br />
NOT_ALIVE_DISPOSED: la instancia es <strong>de</strong>sechada, es <strong>de</strong>cir, no se escribirá más en ella.<br />
En el caso <strong>de</strong> instancias a canales que no tienen clave, su ciclo <strong>de</strong> vida <strong>de</strong>pen<strong>de</strong> <strong>de</strong>l ciclo<br />
<strong>de</strong> vida <strong>de</strong>l DataWriter.<br />
2.2.5. Mecanismos y técnicas para conseguir información<br />
DDS proporciona dos mecanismos para registrar la información: dominios y particiones.<br />
Dominios<br />
Un dominio establece una red virtual que agrupa a todas las aplicaciones que se están<br />
ejecutando. Varias aplicaciones que se están ejecutando en el mismo conjunto <strong>de</strong> máquinas<br />
están completamente aisladas si están en diferentes dominios. <strong>La</strong> comunicación entre<br />
dominios no pue<strong>de</strong> ocurrir a menos que sea especificada por la aplicación <strong>de</strong> usuario.<br />
Particiones<br />
Los dominios pue<strong>de</strong>n ser organizados en particiones don<strong>de</strong> cada partición representa una<br />
agrupación <strong>de</strong> canales. <strong>La</strong>s particiones DDS tienen que estar bajo un dominio para po<strong>de</strong>r<br />
publicar datos y suscribirse a los canales que contiene.<br />
<strong>La</strong>s particiones se pue<strong>de</strong>n utilizar para organizar canales en diferentes conjuntos o para<br />
separar diferentes instancias. De esta manera se pue<strong>de</strong> optimizar el rendimiento para aquellas<br />
aplicaciones que tienen un gran número <strong>de</strong> instancias.<br />
2.2.6. Filtrado <strong>de</strong> canales<br />
Pue<strong>de</strong> ocurrir que se necesiten <strong>de</strong>terminados datos según el estado en el momento <strong>de</strong> obtener<br />
información. Content-Filtered Topics son canales que restringen los datos que pue<strong>de</strong>n
2. ANTECEDENTES 17<br />
manejar. Cuando hay una suscripción a un canal filtrado, una aplicación recibirá aquellos datos,<br />
<strong>de</strong> entre todos los publicados, que coincidan con el filtro indicado en el canal. <strong>La</strong> expresión<br />
<strong>de</strong>l filtro es similar a una cláusula SQL WHERE. Los operadores soportados se muestran<br />
en la tabla 2.1.<br />
Operador Descripción<br />
= Igual<br />
Distinto<br />
> Mayor que<br />
< Menor que<br />
>= Mayor o igual que<br />
2. ANTECEDENTES 18<br />
• Confiable (REALIBLE): El middleware garantiza que todas las muestras en el<br />
historial <strong>de</strong>l DataWriter serán entregadas a todos los DataRea<strong>de</strong>r.<br />
• Mejor esfuerzo (BEST EFFORT): Se acepta que el middleware no reintente la<br />
propagación <strong>de</strong> algunas muestras.<br />
HISTORY<br />
HISTORY controla si DDS <strong>de</strong>bería entregar sólo los datos recientes, tratar <strong>de</strong> entregar<br />
todos los datos intermedios o una combinación <strong>de</strong> las dos anteriores.<br />
Esta política pue<strong>de</strong> ser configurada para proporcionar las siguientes semánticas:<br />
• Conservar lo último (KEEP_LAST): DDS sólo mantendrá los datos más recientes<br />
atendiendo a la variable <strong>de</strong>pth <strong>de</strong> cada instancia <strong>de</strong> datos i<strong>de</strong>ntificados por su<br />
clave.<br />
• Conservar todo (KEEP_ALL): DDS conservará todas las muestras <strong>de</strong> cada instancia<br />
<strong>de</strong> los datos i<strong>de</strong>ntificados por su clave.<br />
Teóricamente lo único que asegura que una aplicación tendrá todas las muestras producidas<br />
por el publicador es usar RELIABLE y KEEP_ALL <strong>de</strong> manera conjunta.<br />
2.2.9. Control <strong>de</strong> las propieda<strong>de</strong>s <strong>de</strong>l tiempo real<br />
<strong>La</strong> política DEADLINE permite <strong>de</strong>finir el máximo intervalo <strong>de</strong> tiempo <strong>de</strong> entrega entre<br />
las muestras <strong>de</strong> datos. Los objetos DataWriter escriben un nuevo valor al menos una vez<br />
cada periodo <strong>de</strong> tiempo indicado por la variable <strong>de</strong>adline y los objetos DataRea<strong>de</strong>r son<br />
notificados por DDS cuando pasa el intervalo <strong>de</strong> tiempo indicado por <strong>de</strong>adline.<br />
2.2.10. Estudio <strong>de</strong> implementaciones existentes<br />
En el apéndice A se <strong>de</strong>scribe y se analiza el estudio realizado sobre las implementaciones<br />
RTI Context DDS [RTI] y OpenSplice DDS [OpS].<br />
2.3. Proyecto Elcano<br />
Elcano [VMV + 11] es un proyecto que se está <strong>de</strong>sarrollando en el grupo <strong>de</strong> investigación<br />
<strong>ARCO</strong> <strong>de</strong> la Escuela Superior <strong>de</strong> Informática (ESI) <strong>de</strong> Ciudad Real y tiene como objetivo<br />
principal el diseño <strong>de</strong> una infraestructura <strong>de</strong> navegación en espacios interiores para personas<br />
con necesida<strong>de</strong>s especiales.<br />
Para posicionar a los usuarios en estos espacios se estudia la combinación <strong>de</strong> diversos<br />
sistemas <strong>de</strong> posicionamiento (WIFI, Bluetooth y RFID) <strong>de</strong> cara a obtener una mejor precisión<br />
en la localización <strong>de</strong>l usuario.<br />
El sistema asume dos tipos <strong>de</strong> usuario, uno <strong>de</strong> ellos con necesida<strong>de</strong>s especiales en cuanto
2. ANTECEDENTES 19<br />
a movilidad se refiere, es <strong>de</strong>cir, que utiliza una silla <strong>de</strong> ruedas para <strong>de</strong>splazarse por el medio,<br />
y el otro con <strong>de</strong>ficiencias en la percepción visual.<br />
Para navegar por los espacios interiores, el usuario porta un dispositivo tipo smartphone<br />
don<strong>de</strong> el sistema Elcano instalado le permite interaccionar con el entorno (tareas que se<br />
pue<strong>de</strong>n realizar, rutas hacia las tareas, reconocimiento <strong>de</strong> voz, etc.)<br />
<strong>La</strong> arquitectura Elcano está ligada a los servicios basados en los estándares Mobile Location<br />
Protocol (MLP) [MLP11] y Open Geospatial Consortium452 (OPENLS) [Mab08] que<br />
son utilizados para los sistemas geográficos.<br />
Figura 2.9: Arquitectura <strong>de</strong>l sistema Elcano<br />
<strong>La</strong> figura 2.9 muestra una vista general <strong>de</strong> los servicios que se ofrecen en el sistema Elcano.<br />
Estos servicios se divi<strong>de</strong>n en tres bloques:<br />
Servicios <strong>de</strong> localización<br />
Estos servicios son in<strong>de</strong>pendientes <strong>de</strong>l sistema Elcano, por lo que se pue<strong>de</strong>n utilizar<br />
en cualquier otro proyecto.
2. ANTECEDENTES 20<br />
Existen dos tipos <strong>de</strong> servicios <strong>de</strong> localización. Por un lado están los proveedores <strong>de</strong><br />
eventos que informan <strong>de</strong> los usuarios que <strong>de</strong>tectan bajo su área <strong>de</strong> alcance. Por otro lado<br />
está el servicio <strong>de</strong> localización propiamente dicho, que se encarga <strong>de</strong> buscar a todos<br />
los proveedores <strong>de</strong> eventos que están bajo su área y ofrece una interfaz <strong>de</strong> alto nivel<br />
que los representa. Con los componentes anteriores y aplicando algoritmos complejos,<br />
se obtiene la posición don<strong>de</strong> se encuentra el usuario con un cierto margen <strong>de</strong> error.<br />
Servicios que ofrecen información <strong>de</strong>l edificio<br />
Contiene toda la información relativa al edificio y que se utiliza en el proceso <strong>de</strong> guiado<br />
<strong>de</strong>l usuario en el interior. Es un sistema distribuido ya que es necesario contar con<br />
información relativa a diversos ámbitos:<br />
• Información relativa a las tareas a <strong>de</strong>sempeñar por un usuario en el entorno. Se<br />
establecen puntos <strong>de</strong> interés asociados a las diferentes tareas que pue<strong>de</strong>n <strong>de</strong>sempeñar<br />
los usuarios, así como las rutas entre los mismos. Para ello, se utilizan las<br />
implementaciones <strong>de</strong>l Directory Service y Route Service.<br />
• Información relativa a la estructura <strong>de</strong>l edificio (mapas, escaleras, salidas <strong>de</strong> incendios,<br />
...) que permiten establecer rutas en el interior.<br />
Servicios orientados al usuario<br />
Es necesario que el sistema Elcano mantenga información sobre el estado <strong>de</strong> los usuarios<br />
y que les ofrezca los servicios que les permitan llevar a cabo las tareas. Para ello se<br />
vale <strong>de</strong> varios servicios. Por un lado utiliza un servicio genérico (User Manager) que<br />
almacena las características <strong>de</strong> cada usuario como propieda<strong>de</strong>s. Para incorporar nuevos<br />
usuarios al sistema, el sistema Elcano ofrece el servicio User Access. Finalmente,<br />
el servicio Mobile Service hace que los dispositivos registrados en el sistema puedan<br />
utilizar los servicios que ofrece el sistema Elcano.<br />
En estos momentos, en el proyecto Elcano, se está utilizando el middleware Ice <strong>de</strong> ZeroC,<br />
que proporciona soporte y servicios avanzados para el <strong>de</strong>sarrollo <strong>de</strong> aplicaciones distribuidas<br />
basadas en invocación a método remoto. Aunque es un enfoque a<strong>de</strong>cuado y sencillo, la<br />
enorme variedad <strong>de</strong> información a incluir en los eventos <strong>de</strong> localización y la escalabilidad<br />
<strong>de</strong>l sistema hacen recomendable el uso <strong>de</strong> middlewares más escalables. Es por ello, que la<br />
utilización <strong>de</strong>l sistema que se plantea en este proyecto en Elcano proporcione importantes<br />
ventajas con respecto a la localización <strong>de</strong> usuarios en el sistema.<br />
Los eventos <strong>de</strong> localización podrían restringirse a un área <strong>de</strong>terminado don<strong>de</strong> se encuentra<br />
el usuario, mostrar tareas solo acortes a una temática (asistencia a conferencias, mostrar<br />
aulas don<strong>de</strong> se imparten clase, etc.), incluir más o menos información según el zoom que<br />
tenga el dispositivo utilizado por el usuario, ... Todas estas restricciones se conseguirían<br />
implantando en el Elcano un sistema similar al propuesto en el estándar DDS <strong>de</strong> la OMG, que<br />
ofrece diferentes maneras <strong>de</strong> filtrar la información <strong>de</strong> los eventos.
2. ANTECEDENTES 21<br />
2.4. Proyecto Energos<br />
Energos [dCENdIT] es un proyecto <strong>de</strong> investigación que estudia el <strong>de</strong>sarrollo <strong>de</strong> tecnologías<br />
que permiten la implantación <strong>de</strong> re<strong>de</strong>s inteligentes <strong>de</strong> distribución <strong>de</strong> energía eléctrica.<br />
Estas re<strong>de</strong>s son capaces <strong>de</strong> gestionar en tiempo real el tráfico que se origina en las mismas.<br />
Esto supone la integración <strong>de</strong> fuentes renovables <strong>de</strong> energía a diferentes niveles en la<br />
red, la participación activa <strong>de</strong> los clientes para la gestión <strong>de</strong> la energía, mayores niveles <strong>de</strong><br />
eficiencia, seguridad y sostenibilidad <strong>de</strong>l suministro eléctrico.<br />
El proyecto preten<strong>de</strong> abordar las siguientes tareas:<br />
Desarrollar herramientas <strong>de</strong> obtención <strong>de</strong> señales y medidas que permitan enlazar la<br />
red con la generación distribuida, el consumo y las unida<strong>de</strong>s <strong>de</strong> almacenamiento eléctrico<br />
<strong>de</strong> forma más eficiente.<br />
Investigación <strong>de</strong> las tecnologías necesarias para la creación <strong>de</strong> una plataforma que<br />
permita la recogida <strong>de</strong> las señales <strong>de</strong> la red inteligente y proporcionar a las aplicaciones<br />
la información necesaria para la gestión <strong>de</strong> dicha red inteligente.<br />
Analizar y <strong>de</strong>sarrollar métodos y técnicas para la gestión <strong>de</strong> la red que incrementen su<br />
eficiencia.<br />
Definir estándares y patentes que permitan establecer un protocolo <strong>de</strong> actuación, facilitando<br />
el uso <strong>de</strong> la red inteligente.<br />
En este proyecto toman parte importantes entida<strong>de</strong>s que son necesarias para el correcto<br />
funcionamiento <strong>de</strong> la red inteligente. Una <strong>de</strong> las entida<strong>de</strong>s más importantes son los consumidores<br />
ya que los requisitos <strong>de</strong> los mismos irán creciendo según las necesida<strong>de</strong>s <strong>de</strong> los<br />
mismos, tanto lo referente a calidad <strong>de</strong>l servicio como el precio <strong>de</strong>l mismo. <strong>La</strong>s comercializadoras<br />
y distribuidoras juegan otro papel importante teniendo que mostrar las ventajas que<br />
ofrece una red inteligente teniendo en cuenta el coste <strong>de</strong> cara al cliente.<br />
El proyecto se enmarca <strong>de</strong>ntro <strong>de</strong>l ámbito <strong>de</strong> la investigación, por ello, los investigadores<br />
también juegan un papel importante para el <strong>de</strong>sarrollo <strong>de</strong> nuevas tecnologías que permitan<br />
mayor eficacia en el sistema. Aquí es don<strong>de</strong> los suministrados <strong>de</strong> tecnología forman a su vez<br />
un papel fundamental, exponiendo las posibilida<strong>de</strong>s que ofrece la red inteligente para una<br />
implantación <strong>de</strong> la misma lo más óptima posible.<br />
Hay otras muchas entida<strong>de</strong>s a tener en cuenta, como los generadores, los reguladores, los<br />
transportistas, ... El conjunto <strong>de</strong> todas ellas contribuye a un mayor conocimiento para que el<br />
<strong>de</strong>sarrollo y explotación <strong>de</strong>l sistema <strong>de</strong> red inteligente sea preciso e inmejorable en su mayor<br />
medida posible.
2. ANTECEDENTES 22<br />
2.4.1. Adquisición <strong>de</strong> información en tiempo real<br />
El sector eléctrico es uno <strong>de</strong> los ámbitos con mayor <strong>de</strong>manda <strong>de</strong> recogida <strong>de</strong> información<br />
en tiempo real. En los sistemas eléctricos se maneja gran cantidad <strong>de</strong> información que tiene<br />
que ser recogida y procesada <strong>de</strong>s<strong>de</strong> la producción hasta el consumo en cada uno <strong>de</strong> los hogares.<br />
<strong>La</strong> re<strong>de</strong>s inteligentes hacen posible una dispersión <strong>de</strong> la información con la posibilidad<br />
<strong>de</strong> ofrecer nuevos servicios a los usuarios, optimización en el uso <strong>de</strong>l recurso energético y el<br />
conocimiento <strong>de</strong>l comportamiento <strong>de</strong> la <strong>de</strong>manda y el abastecimiento energético que engloba<br />
estas re<strong>de</strong>s.<br />
El proyecto Energos se basa en ciertas tecnologías para la recopilación, análisis y transformación<br />
<strong>de</strong> la información requerida por la red inteligente. A continuación se citan las<br />
tecnologías más importantes que tienen relevancia para el proyecto.<br />
Sistemas middleware <strong>de</strong> baja latencia<br />
Sistemas como DDS, Java RT, ICE, ... son capaces <strong>de</strong> operar con diversas capacida<strong>de</strong>s<br />
para la gestión <strong>de</strong> comunicaciones con diferentes exigencias en tiempo real. <strong>La</strong> mayoría<br />
<strong>de</strong> estos servicios funcionan con sistemas distribuidos con requerimientos que<br />
exigen confianza y fiabilidad en tiempo real.<br />
Computación distribuida<br />
Los paquetes <strong>de</strong> trabajo que se manejan en este proyecto requieren efectuar, en ciertos<br />
casos, cálculos complejos sobre un flujo continuo <strong>de</strong> datos. De modo que el reparto<br />
<strong>de</strong> carga es muy importante a la hora <strong>de</strong> realizar las diferentes tareas <strong>de</strong> cálculo que<br />
conlleva el sistema <strong>de</strong> red inteligente.<br />
Motores <strong>de</strong> procesamiento complejo <strong>de</strong> eventos<br />
Complex Event Processing (CEP) y Event Stream Processing (ESP) [cep08] son tecnologías<br />
muy útiles utilizadas para trabajar con los diferentes eventos que circulan por<br />
la red. Permiten i<strong>de</strong>ntificar patrones y <strong>de</strong> esa manera po<strong>de</strong>r gestionar alarmas, fallos,<br />
intrusos, ataques y multitud <strong>de</strong> situaciones graves en tiempo real.
Objetivos<br />
3<br />
Para <strong>de</strong>limitar el alcance <strong>de</strong>l proyecto, se <strong>de</strong>tallan a continuación los objetivos, tanto generales<br />
como específicos, que permitirán compren<strong>de</strong>r y enten<strong>de</strong>r la finalidad que se persigue<br />
con el mismo.<br />
3.1. Objetivo general<br />
El objetivo principal <strong>de</strong>l proyecto es la <strong>de</strong>finición e implementación <strong>de</strong> una interfaz siguiendo<br />
el estándar OMG DDS [OMG07] y utilizando para ello el middleware ZeroC Ice [ICEb].<br />
<strong>La</strong> finalidad es la realización <strong>de</strong> un mo<strong>de</strong>lo <strong>de</strong> comunicaciones <strong>de</strong>l tipo publicador/suscriptor<br />
que permita compartir datos que serán in<strong>de</strong>pendientes <strong>de</strong> la arquitectura <strong>de</strong>l sistema.<br />
3.2. Objetivos específicos<br />
Se pue<strong>de</strong>n distinguir los siguientes objetivos específicos:<br />
Estudio <strong>de</strong>l estándar DDS y sus implementaciones OpenSplice y RTI<br />
<strong>La</strong>s características que se <strong>de</strong>finen en el estándar DDS <strong>de</strong>ben estar claras para saber<br />
cómo se tiene que comportar el sistema a implementar. Para tener un mayor conocimiento<br />
<strong>de</strong>l funcionamiento <strong>de</strong> este tipo <strong>de</strong> mo<strong>de</strong>lo <strong>de</strong> comunicación, se estudiarán y<br />
se harán ejemplos básicos <strong>de</strong> las implementaciones OpenSplice [OpS] <strong>de</strong> PrismTech y<br />
RTI Connext DDS <strong>de</strong> la compañía Real-Time Innovations (RTI) [RTI].<br />
Mo<strong>de</strong>lado e implementación <strong>de</strong> eventos DDS con ZeroC Ice<br />
<strong>La</strong> parte a <strong>de</strong>sarrollar se centrará en los aspectos <strong>de</strong> calidad <strong>de</strong> servicio relativos al<br />
filtrado <strong>de</strong> eventos. Se preten<strong>de</strong> abarcar todas las posibles opciones <strong>de</strong> filtrado, es <strong>de</strong>cir,<br />
tanto en el publicador, en el suscriptor como en el canal <strong>de</strong> comunicación.<br />
Aplicación <strong>de</strong> mo<strong>de</strong>lo <strong>de</strong>sarrollado a los eventos <strong>de</strong>l proyecto Elcano<br />
Una <strong>de</strong> las finalida<strong>de</strong>s <strong>de</strong> este proyecto es po<strong>de</strong>r implantarlo en el proyecto Elcano<br />
que se está <strong>de</strong>sarrollando en el grupo <strong>de</strong> investigación <strong>ARCO</strong> <strong>de</strong> la ESI. Por ello, se<br />
adaptarán los eventos DDS a los que se manejan en dicho proyecto para posteriormente<br />
po<strong>de</strong>r hacer una <strong>de</strong>mostración <strong>de</strong> la funcionalidad <strong>de</strong>l mo<strong>de</strong>lo <strong>de</strong> comunicaciones<br />
23
3. OBJETIVOS 24<br />
implementado.<br />
Herramienta <strong>de</strong> monitorización<br />
Esta herramienta constará <strong>de</strong> los componentes necesarios don<strong>de</strong> se permita ver los<br />
eventos <strong>de</strong> comunicación entre publicadores y suscriptores, teniendo en cuenta el filtrado<br />
<strong>de</strong> eventos.<br />
Aplicación Android<br />
Representación <strong>de</strong>l funcionamiento <strong>de</strong>l mo<strong>de</strong>lo en un dispositivo móvil o en tablet<br />
cuyo sistema operativo sea Android [AND08].
Método <strong>de</strong> trabajo y herramientas<br />
4<br />
En este capítulo se <strong>de</strong>scribe la metodología <strong>de</strong> <strong>de</strong>sarrollo elegida y las herramientas utilizadas<br />
en la elaboración <strong>de</strong>l proyecto junto con una breve <strong>de</strong>scripción <strong>de</strong> cada una <strong>de</strong> ellas.<br />
4.1. Metodología <strong>de</strong> trabajo<br />
Des<strong>de</strong> un principio, el proyecto fue pensado para ser construido sobre un sistema distribuido.<br />
Esto permite la utilización <strong>de</strong> los diferentes componentes in<strong>de</strong>pendientemente <strong>de</strong> la<br />
arquitectura <strong>de</strong>l sistema que lo contenga.<br />
Los requisitos <strong>de</strong>l sistemas son especificados <strong>de</strong>s<strong>de</strong> el inicio y la interacción con el cliente<br />
es una parte importante <strong>de</strong>l <strong>de</strong>sarrollo. Esta interacción continua con el cliente permite obtener<br />
más información <strong>de</strong>tallada para el correcta realización <strong>de</strong>l proyecto. A<strong>de</strong>más, en cada<br />
iteración proporcionará un prototipo totalmente funcional que ayudará a perfilar y añadir los<br />
requisitos necesarios para mejorar el producto final.<br />
Por estas razones, la metodología que se ha utilizado es prototipado incremental.<br />
4.1.1. Prototipado incremental<br />
El prototipado incremental [Som06] se basa en la realización <strong>de</strong> prototipos funcionales<br />
a lo largo <strong>de</strong>l <strong>de</strong>sarrollo <strong>de</strong>l sistema hasta llegar a un producto final. Estos prototipos son<br />
entregados al cliente, <strong>de</strong> modo que éste pue<strong>de</strong> comprobar el cumplimiento <strong>de</strong> los requisitos<br />
especificados y mejorar y/o añadir nuevos. El cliente también pue<strong>de</strong> <strong>de</strong>tectar errores o carencias<br />
que sirvan para refinar con más <strong>de</strong>talle los requisitos especificados y contribuir <strong>de</strong> este<br />
modo a una mejora progresiva <strong>de</strong>l prototipo final en cada iteración.<br />
El esquema general <strong>de</strong> esta metodología se muestra en la figura 4.1. En cada iteración, se<br />
<strong>de</strong>finen nuevas funcionalida<strong>de</strong>s <strong>de</strong>l sistema, se <strong>de</strong>scriben más <strong>de</strong>talladamente y se <strong>de</strong>sarrollan.<br />
El prototipo obtenido se integra en el sistema y se entrega al cliente.<br />
<strong>La</strong>s ventajas <strong>de</strong> utilizar esta metodología son las siguientes:<br />
Los clientes pue<strong>de</strong> utilizar el sistema <strong>de</strong>s<strong>de</strong> las primeras fases <strong>de</strong> <strong>de</strong>sarrollo, ya que se<br />
obtienen prototipos intermedios con los que po<strong>de</strong>r trabajar. Esto proporciona al cliente<br />
25
4. MÉTODO DE TRABAJO Y HERRAMIENTAS 26<br />
Figura 4.1: Diagrama <strong>de</strong> flujo <strong>de</strong>l prototipado incremental<br />
mayor confianza y creencia en la obtención final <strong>de</strong> un producto que cumplirá con los<br />
requisitos especificados.<br />
El <strong>de</strong>sarrollo <strong>de</strong> prototipos intermedios hace más fácil <strong>de</strong>terminar si los nuevos requisitos<br />
planteados en las siguientes iteraciones son correctos y viables.<br />
El riesgo <strong>de</strong> errores es muy bajo y los fallos pue<strong>de</strong>n ser fácilmente solventados. En<br />
cada iteración se prueba el prototipo realizado y a<strong>de</strong>más se realizan las pruebas <strong>de</strong> las<br />
iteraciones anteriores para asegurar que el prototipo cumple también con las funcionalida<strong>de</strong>s<br />
añadidas anteriormente.<br />
<strong>La</strong>s funcionalida<strong>de</strong>s más importantes se entregan en las primeras fases <strong>de</strong> <strong>de</strong>sarrollo<br />
y es, por lo tanto, la parte <strong>de</strong>l sistema que se somete a más pruebas. Esto conlleva al<br />
<strong>de</strong>sarrollo <strong>de</strong> un sistema más fiable.<br />
Aunque no todo son ventajas. Disponer <strong>de</strong> prototipos intermedios pue<strong>de</strong> conducir a situaciones<br />
poco convenientes:<br />
El cliente participa activamente en el proceso <strong>de</strong> <strong>de</strong>sarrollo, lo que hace que los requisitos<br />
puedan ser modificados continuamente <strong>de</strong>bido a los cambios que el cliente crea<br />
oportunos.<br />
El mantenimiento <strong>de</strong>l sistema pue<strong>de</strong> ser problemático <strong>de</strong>bido a la especificación <strong>de</strong><br />
nuevas funcionalida<strong>de</strong>s en su <strong>de</strong>sarrollo. Los <strong>de</strong>sarrolladores, por su parte, pue<strong>de</strong>n<br />
especializar <strong>de</strong>masiado el producto lo que dificultaría un futuro mantenimiento por el<br />
personal que no está familiarizado.<br />
Para solventar en la medida <strong>de</strong> lo posible estos problemas, se ha optado por una combinación<br />
<strong>de</strong> esta metodología con el <strong>de</strong>sarrollo dirigido por pruebas.
4. MÉTODO DE TRABAJO Y HERRAMIENTAS 27<br />
4.1.2. Desarrollo dirigido por pruebas<br />
Des<strong>de</strong> el principio, el planteamiento fue realizar la implementación <strong>de</strong> este proyecto usando<br />
una metodología ágil, basando esta i<strong>de</strong>a en el previo conocimiento <strong>de</strong> las ventajas que<br />
esta técnica ofrecía.<br />
Test Driven Development (TDD) es una técnica incluida en lo que se conoce como metodología<br />
XP [Bec00]. <strong>La</strong> filosofía <strong>de</strong> esta técnica es crear las pruebas antes que el código.<br />
Cada prueba garantiza el cumplimiento <strong>de</strong> un requisito funcional concreto.<br />
<strong>La</strong>s ventajas <strong>de</strong> esta técnica son numerosas y algunas <strong>de</strong> las más importantes son:<br />
Sólo se implementa lo necesario para satisfacer la prueba y no más. No habrá código<br />
que no sea necesario.<br />
Se disminuye el número <strong>de</strong> errores. Cualquier modificación que afecte a algún componente<br />
se <strong>de</strong>tecta y se resuelve fácilmente.<br />
El código es reutilizable y se pue<strong>de</strong> cambiar con relativa facilidad.<br />
<strong>La</strong> productividad aumenta consi<strong>de</strong>rablemente porque se invierte menos tiempo en la<br />
<strong>de</strong>puración.<br />
Para po<strong>de</strong>r seguir esta técnica se <strong>de</strong>ben tener claros los escenarios que se quieren probar.<br />
Los escenarios serán la colección <strong>de</strong> pruebas que servirán para ir construyendo la API<br />
<strong>de</strong>l sistema. <strong>La</strong> <strong>de</strong>scripción <strong>de</strong> los escenarios se hace utilizando la técnica Behavior Driven<br />
Development (BDD). Esta técnica utiliza una plantilla que permite enten<strong>de</strong>r mejor el funcionamiento<br />
global <strong>de</strong> sistema:<br />
Given: Dado un contexto inicial.<br />
When: Cuando se produce un evento.<br />
Then: Entonces se obtienen unos resultados.<br />
4.2. Herramientas<br />
4.2.1. Lenguajes <strong>de</strong> programación<br />
Python - lenguaje <strong>de</strong> alto nivel, interpretado, multiparadigma y orientado a objetos, creado<br />
por Guido van Roosum. Se utiliza este lenguaje <strong>de</strong>bido a la simplicidad <strong>de</strong>l código y<br />
su amplia librería estándar.<br />
Este lenguaje se usa para implementar el particular mo<strong>de</strong>lo <strong>de</strong> comunicación <strong>de</strong> eventos<br />
DDS y también es usado para la implementación <strong>de</strong> las pruebas realizadas.<br />
C++ - lenguaje que proporciona mecanismos <strong>de</strong> orientación a objetos y es compatible con<br />
C. Fue creado por Bjarne Stroustrup.<br />
C++ se utiliza para implementar los ejemplos básicos <strong>de</strong> OpenSplice y RTI DDS.
4. MÉTODO DE TRABAJO Y HERRAMIENTAS 28<br />
Java - es un lenguaje <strong>de</strong> programación a objetos <strong>de</strong>sarrollado por Sun Microsystems. Android<br />
está fuertemente ligado a java, es por ello que se utiliza este lenguaje para la<br />
implementación <strong>de</strong> la aplicación para un dispositivo móvil o tablet con Android.<br />
4.2.2. Aplicaciones <strong>de</strong> <strong>de</strong>sarrollo<br />
ZeroC Ice - Middleware <strong>de</strong> comunicaciones orientado a objetos, multilenguaje y multiplataforma<br />
<strong>de</strong>sarrollado por la empresa ZeroC [ICEb].<br />
Este middleware es una parte importante <strong>de</strong>l proyecto ya que se utilizan su servicio<br />
IceStorm para la realización <strong>de</strong> un mo<strong>de</strong>lo <strong>de</strong> comunicación atendiendo al estándar<br />
DDS.<br />
GNU Make - herramienta para la generación automática <strong>de</strong> ejecutables [SMS06].<br />
GNU Compiler Collection (GCC) - colección <strong>de</strong> compiladores <strong>de</strong>l proyecto GNU [GCC10].<br />
GNU Emacs - entorno <strong>de</strong> <strong>de</strong>sarrollo <strong>de</strong> GNU que se ha utilizado tanto para la implementación<br />
como para la documentación [EMA09].<br />
Eclipse - entorno <strong>de</strong> programación [ECL04] utilizado para el <strong>de</strong>sarrollo <strong>de</strong> la aplicación móvil<br />
con sistema operativo Android. <strong>La</strong> integración <strong>de</strong>l SDK <strong>de</strong> Android en este entorno<br />
<strong>de</strong> programación es muy sencilla y fácil <strong>de</strong> manejar [AND08].<br />
Mercurial - sistema <strong>de</strong> control <strong>de</strong> versiones distribuido. Se ha hecho uso <strong>de</strong> esta herramienta<br />
para el código <strong>de</strong>l proyecto y la documentación [MER12].<br />
Atheist - plataforma <strong>de</strong> pruebas con la que se elaboran las pruebas <strong>de</strong> integración <strong>de</strong> este<br />
proyecto. Es un herramienta <strong>de</strong>sarrollada por el grupo <strong>ARCO</strong> [ATH01].<br />
4.2.3. Documentación<br />
L A TEX - lenguaje <strong>de</strong> marcado <strong>de</strong> documentos <strong>de</strong> carácter técnico y científica, utilizado para<br />
realizar este documento [CLM + 03].<br />
BibTex - herramienta para la <strong>de</strong>scripción <strong>de</strong> referencias para documentos escritos con L A TEX.<br />
4.2.4. Gestión <strong>de</strong> proyecto<br />
Redmine - Aplicación web para la gestión <strong>de</strong> proyectos. Mediante esta herramienta se han<br />
establecido las tareas a realizar a lo largo <strong>de</strong>l ciclo <strong>de</strong> vida <strong>de</strong>l proyecto. Utilizando esta<br />
herramienta se tiene un visión constante <strong>de</strong>l <strong>de</strong>sarrollo <strong>de</strong>l proyecto (tiempo <strong>de</strong>dicado<br />
a cada tarea, tareas por terminar, nuevas tareas, etc.) [RED12].<br />
4.2.5. Herramientas hardware<br />
Motorola Tablet PC - Tablet con sistema operativo Android 4.0.
Desarrollo <strong>de</strong>l proyecto<br />
5<br />
Este capítulo <strong>de</strong>scribe la planificación y <strong>de</strong>sarrollo <strong>de</strong>l proyecto. Se <strong>de</strong>finen los requisitos<br />
y las distintas iteraciones que se llevan a cabo, así como los prototipos obtenidos en cada una<br />
<strong>de</strong> ellas. A<strong>de</strong>más, la implementación se <strong>de</strong>scribe en base a las pruebas que se realizan para<br />
validar el cumplimiento <strong>de</strong> los requisitos iniciales.<br />
5.1. Especificación <strong>de</strong> requisitos<br />
Tras el estudio <strong>de</strong>l estándar DDS <strong>de</strong> la OMG se ha adquirido un conocimiento más <strong>de</strong>tallado<br />
<strong>de</strong> la funcionalidad que <strong>de</strong>be tener un mo<strong>de</strong>lo <strong>de</strong> comunicaciones basado en este estándar.<br />
Como se menciona en los objetivos <strong>de</strong> la sección 3.2, este proyecto se centra en los aspectos<br />
relativos al filtrado <strong>de</strong> eventos. <strong>La</strong> figura 5.1 muestra la parte <strong>de</strong> la especificación <strong>de</strong>l estándar<br />
DDS que se persigue y que servirá como guía para el <strong>de</strong>sarrollo <strong>de</strong>l sistema.<br />
A partir <strong>de</strong>l conocimiento adquirido <strong>de</strong>bido al estudio <strong>de</strong>l estándar DDS y <strong>de</strong> las implementaciones<br />
RTI DDS y OpenSplice (apéndice A, y atendiendo a las diferentes funcionalida<strong>de</strong>s<br />
que aporta el servicio IceStorm <strong>de</strong> ZeroC Ice, se <strong>de</strong>finen los siguientes requisitos funcionales:<br />
Se utilizará el servicio IceStorm que añadirá la funcionalidad necesaria para la gestión<br />
y administración <strong>de</strong> los canales DDS.<br />
Se <strong>de</strong>be disponer <strong>de</strong> un gestor <strong>de</strong> canales DDS. Este componente se encargará <strong>de</strong> crear<br />
los canales necesarios atendiendo a los parámetros solicitados.<br />
Los canales podrán ser <strong>de</strong> dos tipos: canales generales don<strong>de</strong> tienen cabida eventos <strong>de</strong><br />
todo tipo y canales don<strong>de</strong> se indican filtros. Estos últimos canales limitan la comunicación<br />
<strong>de</strong> ciertos eventos atendiendo a la <strong>de</strong>scripción <strong>de</strong> los filtros indicados.<br />
Un canal podrá tener múltiples suscriptores y publicadores.<br />
Un publicador será el encargado <strong>de</strong> enviar eventos al canal <strong>de</strong>l que es publicador.<br />
Un suscriptor se podrá registrar en un canal para po<strong>de</strong>r recibir los eventos <strong>de</strong>l mismo.<br />
Un suscriptor podrá registrarse en uno o más canales a la vez.<br />
29
5. DESARROLLO DEL PROYECTO 30<br />
Figura 5.1: Visión general para el <strong>de</strong>sarrollo <strong>de</strong> la API con ZeroC Ice<br />
<strong>La</strong> suscripción permitirá indicar uno o más filtros. De este modo, los suscriptores recibirán<br />
únicamente la información que les interese.<br />
Un canal pue<strong>de</strong> disponer <strong>de</strong> publicadores filtrados, es <strong>de</strong>cir, publicadores que solo<br />
envíen datos que coincidan con los filtros especificados en la creación <strong>de</strong>l publicador.<br />
Un suscriptor pue<strong>de</strong> anular la suscripción a un canal.<br />
El gestor <strong>de</strong> canales DDS tendrá la posibilidad <strong>de</strong> eliminar canales.<br />
<strong>La</strong> fe<strong>de</strong>ración <strong>de</strong> IceStorm permitirá po<strong>de</strong>r realizar enlaces entre canales filtrados. De<br />
este modo se reducirá el número <strong>de</strong> canales creados ya que los enlaces permiten la<br />
propagación <strong>de</strong> eventos <strong>de</strong> unos canales a otros.<br />
5.2. Casos <strong>de</strong> uso<br />
El análisis <strong>de</strong> requisitos permite i<strong>de</strong>ntificar los diferentes casos <strong>de</strong> uso que tendrá el sistema<br />
a <strong>de</strong>sarrollar. <strong>La</strong> figura 5.2 muestra el diagrama <strong>de</strong> casos <strong>de</strong> uso indicando la interacción entre<br />
las distintas entida<strong>de</strong>s que componen el sistema.<br />
Cada caso <strong>de</strong> uso tiene una funcionalidad interna que se <strong>de</strong>tallará más a<strong>de</strong>lante en cada<br />
una <strong>de</strong> las iteraciones realizadas. Nótese que tanto un suscriptor como un publicador pue<strong>de</strong>n<br />
crear canales sin necesidad <strong>de</strong> que el sistema tenga una entidad que se encargue <strong>de</strong> ello. A<br />
modo <strong>de</strong> resumen, a continuación se muestra un breve <strong>de</strong>scripción <strong>de</strong> cada uno <strong>de</strong> los casos<br />
<strong>de</strong> uso:<br />
Crear canal<br />
El gestor <strong>de</strong> canales <strong>de</strong>l sistema crea un canal DDS propio indicando el nombre <strong>de</strong>l
5. DESARROLLO DEL PROYECTO 31<br />
Figura 5.2: Diagrama <strong>de</strong> Casos <strong>de</strong> Uso<br />
mismo. Este parámetro representará al canal unívocamente en el sistema.<br />
Crear canal filtrado<br />
El gestor <strong>de</strong> canales <strong>de</strong>l sistema crea un canal filtrado teniendo en cuenta los parámetros<br />
<strong>de</strong> filtrado y el tipo <strong>de</strong> datos que tiene que filtrar.<br />
Suscribirse a un canal<br />
Cierta entidad pue<strong>de</strong> suscribirse a un canal creado para que le sean enviados los eventos<br />
que se publican en él.<br />
Suscribirse a un canal indicando filtros<br />
Una <strong>de</strong>terminada entidad quiere suscribirse a un canal pero sólo <strong>de</strong>sea obtener cierta<br />
información que se maneja.<br />
Obtener publicador <strong>de</strong> un canal<br />
Se adquiere el publicador a un canal creado.
5. DESARROLLO DEL PROYECTO 32<br />
Obtener publicador <strong>de</strong> canal indicando filtros<br />
Se obtiene un publicador a un canal creado consi<strong>de</strong>rando parámetros <strong>de</strong> restricción.<br />
Publicar en un canal<br />
El publicador envía eventos al canal.<br />
Eliminar suscripción a un canal<br />
Un suscriptor <strong>de</strong>sea no estar suscrito a un <strong>de</strong>terminado canal.<br />
Destruir un canal<br />
Un canal pue<strong>de</strong> ser eliminado <strong>de</strong>l sistema.<br />
Listar canales en el sistema<br />
Se obtiene la lista <strong>de</strong> canales creados en el sistema.<br />
Enlace a un canal<br />
Un canal solicita que los eventos que se publican en un <strong>de</strong>terminado canal sean propagados<br />
a él.<br />
5.3. Diseño<br />
Una vez analizados los requisitos <strong>de</strong>l proyecto, se continúa con la fase <strong>de</strong> diseño. En esta<br />
fase se compone la estructura básica <strong>de</strong>l sistema así como los componentes que toman parte<br />
en ella.<br />
El componente básico <strong>de</strong>l que no se pue<strong>de</strong> prescindir es <strong>de</strong> un gestor <strong>de</strong> los canales <strong>de</strong><br />
eventos DDS. Este componente será el encargado <strong>de</strong> crear canales acor<strong>de</strong> a las solicitu<strong>de</strong>s<br />
<strong>de</strong>mandadas. También se encargará <strong>de</strong> realizar tareas como listar los canales que existen en<br />
el dominio <strong>de</strong>l sistema, proporcionar un <strong>de</strong>terminado canal y tendrá la posibilidad <strong>de</strong> <strong>de</strong>struir<br />
uno o más canales que existen en el dominio <strong>de</strong>l sistema.<br />
El gestor <strong>de</strong> canales <strong>de</strong> eventos DDS actuará como intermediario entre los publicadores y<br />
suscriptores <strong>de</strong> los canales <strong>de</strong>l sistema y para ello hará uso <strong>de</strong>l servicio IceStorm <strong>de</strong> ZeroC<br />
Ice. El servicio IceStorm proporcionará las ventajas que lo caracterizan como son llamada<br />
única para distribuir la información a los suscriptores, in<strong>de</strong>pen<strong>de</strong>ncia entre suscriptores y<br />
publicadores, creación <strong>de</strong> canales <strong>de</strong> manera dinámica, ...<br />
Otro componente será el canal <strong>de</strong> eventos DDS. <strong>La</strong> funcionalidad propia <strong>de</strong> esta canal será<br />
proporcionar un mecanismo <strong>de</strong> suscripción, tanto si la suscripción se realiza indicando parámetros<br />
<strong>de</strong> filtrado como si se realiza una suscripción sin indicar el filtrado, que será similar<br />
a la suscripción realizada en los canales IceStorm. A<strong>de</strong>más, proporcionará las operaciones<br />
necesarias para obtener el publicador al canal. Al igual que ocurre en la suscripción, el publicador<br />
pue<strong>de</strong> asociarse con unos <strong>de</strong>terminados filtros que implicará la publicación <strong>de</strong> los<br />
eventos que se ajusten a los mismos.<br />
Por último, el sistema contará con el objeto Publisher. Como su propio nombre indica
5. DESARROLLO DEL PROYECTO 33<br />
Figura 5.3: Arquitectura <strong>de</strong>l mo<strong>de</strong>lo <strong>de</strong> comunicaciones suscriptor/publicador IceDDS<br />
será el publicador <strong>de</strong> eventos <strong>de</strong> un canal. En el momento <strong>de</strong> la publicación se encargará <strong>de</strong><br />
realizar las comprobaciones necesarias <strong>de</strong> filtrado para propagar los eventos a los suscriptores<br />
que corresponda.<br />
Todos los componentes anteriores constituirán un mo<strong>de</strong>lo <strong>de</strong> comunicaciones suscriptor/publicador<br />
con la característica especial <strong>de</strong> po<strong>de</strong>r realizar filtrado en la información que<br />
circula por el sistema. <strong>La</strong> figura 5.3 muestra una visión general <strong>de</strong> la arquitectura que compondrá<br />
el mo<strong>de</strong>lo <strong>de</strong> comunicaciones que se persigue en el <strong>de</strong>sarrollo <strong>de</strong> este proyecto.<br />
5.4. Implementación<br />
El <strong>de</strong>sarrollo <strong>de</strong>l proyecto está dividido en diferentes iteraciones. En cada una <strong>de</strong> estas iteraciones<br />
se irán añadiendo nuevas funcionalida<strong>de</strong>s que aportarán las operaciones necesarias<br />
para ir construyendo el producto final. El mo<strong>de</strong>lo <strong>de</strong> comunicaciones que se <strong>de</strong>sarrolla en<br />
este proyecto se llamará IceDDS.<br />
<strong>La</strong> construcción <strong>de</strong> IceDDS se realiza utilizando el lenguaje <strong>de</strong> programación Python,<br />
<strong>de</strong>bido a la sencillez y claridad <strong>de</strong> programación que ofrece.<br />
Hay que <strong>de</strong>stacar que en cada iteración se lleva a cabo un plan <strong>de</strong> pruebas, tal y como se<br />
explicó en la sección 4.1.1. El plan <strong>de</strong> pruebas <strong>de</strong> <strong>de</strong>sarrollo <strong>de</strong>l proyecto se pue<strong>de</strong> ver en el<br />
apéndice B.<br />
Para conocer la dinámica <strong>de</strong> las pruebas realizadas para cada iteración, a continuación<br />
se muestran ejemplos <strong>de</strong> los dos tipos <strong>de</strong> pruebas que se realizan a lo largo <strong>de</strong>l ciclo <strong>de</strong>l<br />
proyecto.<br />
Pruebas unitarias<br />
Como se explica en el capítulo 4.1.2, las pruebas unitarias siguen la técnica BDD. En el<br />
listado 5.1 se muestra un ejemplo sencillo <strong>de</strong> prueba unitaria realizada para comprobar
5. DESARROLLO DEL PROYECTO 34<br />
que el subscriptor recibe el evento <strong>de</strong> un canal.<br />
<strong>de</strong>f test_filteredInTopicOneSubscriber(self):<br />
# given a filtered topic, a publisher and a subcriptor<br />
topic = self.topicManager.createTopic("foo")<br />
publisher = Event.ListenerPrx.uncheckedCast(topic.getPublisher())<br />
subscriber = mocks.Subscriber(self.adapter)<br />
topic.subscribeAndGetPublisher(subscriber.proxy)<br />
# when the publisher sends several events<br />
publisher.sendData(MLP.Coord(1.0, 12.0, 0.0))<br />
subscriber.servant.wait(2)<br />
# then the subscriber receives the events<br />
params = ’send_data’, (1.0, 12.0)<br />
self.assert_(subscriber.servant.method_was_called(∗params))<br />
self.assertEqual(1,<br />
len(subscriber.servant.get_registered_calls()))<br />
Listado 5.1: Ejemplo <strong>de</strong> prueba unitaria<br />
En esta prueba se cuenta con un canal (topic), un publicador <strong>de</strong>l canal (publisher)<br />
y un suscriptor (subscriber). Como se pue<strong>de</strong> observar, el suscriptor es un objeto que<br />
imita el comportamiento <strong>de</strong>l sirviente real <strong>de</strong> nuestro sistema, es lo que se <strong>de</strong>nomina<br />
mock. Este objeto simulará a un suscriptor real y dará el resultado esperado. El sirviente<br />
cuenta con una lista <strong>de</strong> objetos que guarda los eventos recibidos. De esta manera, se<br />
pue<strong>de</strong> comprobar los datos recibidos en cada prueba realizada.<br />
Para comprobar el correcto funcionamiento <strong>de</strong>l envío <strong>de</strong> un evento, lo primero que hay<br />
que hacer es suscribir el suscriptor al canal. En este momento, ya se tienen todos los<br />
componentes necesarios para realizar un envío <strong>de</strong> un dato.<br />
<strong>La</strong>s comprobaciones que se realizan <strong>de</strong>spués <strong>de</strong> que el publicador envíe un dato son<br />
que la lista contenga solamente el número <strong>de</strong> datos enviados (en este caso 1) y se<br />
comprueba que el dato recibido es el correcto.<br />
<strong>La</strong> dinámica para el resto <strong>de</strong> pruebas realizadas es la misma: se crean los componentes<br />
que forman parte <strong>de</strong> la prueba, se realiza la acción <strong>de</strong>seada y se comprueba la recepción<br />
<strong>de</strong> los eventos a los correspondientes suscriptores.<br />
Prueba <strong>de</strong> sistema<br />
<strong>La</strong>s pruebas <strong>de</strong> sistema se realizan con la herramienta atheist [ATH01] que proporciona<br />
una plataforma para realizar pruebas <strong>de</strong> integración <strong>de</strong>l sistema. <strong>La</strong>s pruebas se<br />
basan en términos <strong>de</strong>clarativos. En el listado 5.2 se muestra un ejemplo <strong>de</strong> prueba <strong>de</strong><br />
integración en la cual se comprueba que los publicadores han enviado los eventos y los<br />
suscriptores los han recibido.<br />
admin = TestBG(<br />
cmd = "./TopicManager.py −−Ice.Config=IceDDSManagerLocal.<br />
config",<br />
shell = True,
5. DESARROLLO DEL PROYECTO 35<br />
cwd<br />
= ’$basedir’)<br />
subscriber = TestBG(<br />
pre = [Poll(OpenPort(3000)), Poll(TaskRunning(admin))],<br />
cmd = ’./subscriber.py −−Ice.Config=subscriber.cfg ’+<br />
’"IceDDS/TopicManager −t:tcp −p 3000"’,<br />
shell = True,<br />
post = [FileContains("Received Event (2, 3, 4)"),<br />
FileContains("Received Event (5, 14, 20)")]<br />
publisher = Test(<br />
cmd = ’./publisher.py "IceDDS/TopicManager −t:tcp −p 3000"’,<br />
shell = True,<br />
post = FileContains("Send data to general topic"))<br />
TaskTerminator(admin, subscriber)<br />
Listado 5.2: Ejemplo <strong>de</strong> prueba <strong>de</strong> integración<br />
Se cuenta con la implementación <strong>de</strong> un gestor <strong>de</strong> canales (TopicManager) que se encarga<br />
<strong>de</strong> crear un canal <strong>de</strong>terminado. También se cuenta con las implementaciones<br />
<strong>de</strong> un publicador y un suscriptor. En la prueba se especifican pre-condiciones para la<br />
ejecución <strong>de</strong> los elementos anteriores y mediante las post-condiciones se comprueba<br />
el correcto funcionamiento <strong>de</strong> cada parte. En este caso se comprobaría que en el<br />
suscriptor se han recibido los eventos (2, 3, 4) y (5, 14, 20).<br />
A continuación se <strong>de</strong>scriben <strong>de</strong>talladamente cada una <strong>de</strong> las iteraciones.<br />
5.4.1. Suscripción y publicación sin filtros<br />
Análisis y diseño<br />
El mo<strong>de</strong>lo <strong>de</strong> comunicaciones que se implementará <strong>de</strong>be tener un gestor <strong>de</strong> canales. Este<br />
gestor es el encargado <strong>de</strong> crear los diferentes canales que sirven como medio <strong>de</strong> comunicación<br />
para los publicadores y suscriptores. Para ello se necesitará un adaptador <strong>de</strong> objetos y<br />
la configuración necesaria para crear el gestor <strong>de</strong> canales DDS.<br />
Del mismo modo, se necesita <strong>de</strong>scribir las operaciones necesarias para la suscripción y la<br />
publicación en un canal.<br />
Implementación<br />
En primera instancia, se lleva a cabo la implementación <strong>de</strong> las pruebas unitarias necesarias<br />
utilizando la herramienta nose [NOS]. En base a ellas, se implementan las clases TopicManager<br />
que representa el servidor <strong>de</strong> canales <strong>de</strong> eventos DDS y Topic que representa a un<br />
<strong>de</strong>terminado canal <strong>de</strong> eventos DDS.<br />
En la creación <strong>de</strong> un canal, se creará a su vez un canal IceStorm que formará parte <strong>de</strong><br />
nuestro canal <strong>de</strong> eventos DDS. De este modo, no se necesita implementar una gestión <strong>de</strong><br />
canales <strong>de</strong> eventos ya que esa funcionalidad la proporciona el servicio IceStorm.
5. DESARROLLO DEL PROYECTO 36<br />
En en listado 5.3 se muestran el slice que contiene las interfaces <strong>de</strong>finidas hasta el momento.<br />
module DDS {<br />
interface Topic<br />
Object∗ subscribeAndGetPublisher(Object∗ subscriber);<br />
Object∗ getPublisher();<br />
};<br />
}<br />
interface TopicManager {<br />
Topic∗ createTopic(string name);<br />
};<br />
Listado 5.3: SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice<br />
5.4.2. Filtrado <strong>de</strong> eventos a nivel <strong>de</strong> canal<br />
Análisis y diseño<br />
Se tiene que contar con un procedimiento para crear canales en los que se limita el tráfico<br />
<strong>de</strong> los datos que no cumplan ciertos requisitos. De este modo se reduce el tráfico <strong>de</strong> datos en<br />
un canal, pudiendo repartirse entre diferentes canales.<br />
<strong>La</strong> implantación <strong>de</strong> un mo<strong>de</strong>lo como este en el proyecto Elcano sería una mejor solución<br />
<strong>de</strong>bido a la gran cantidad <strong>de</strong> información a incluir en los eventos <strong>de</strong> localización. Por ello, los<br />
datos que se manejarán para la comunicación entre suscriptores y publicadores serán eventos<br />
<strong>de</strong> localización <strong>de</strong> Elcano. Estos tipos vienen <strong>de</strong>finidos en el apartado C.1 <strong>de</strong>l apéndice C. Se<br />
realizará un filtrado teniendo en cuenta las coor<strong>de</strong>nadas <strong>de</strong>l mapa don<strong>de</strong> se sitúa el usuario y<br />
<strong>de</strong> este modo po<strong>de</strong>r indicar filtros especificando <strong>de</strong>terminadas áreas. Por ello, los eventos <strong>de</strong><br />
localización serán <strong>de</strong>l tipo MLP.Coord.<br />
Un obstáculo que se plantea es el conocer los tipos <strong>de</strong> datos que son enviados. Al canal<br />
llegarán un conjunto <strong>de</strong> bytes que <strong>de</strong>berán ser transformados en el dato real que envió el<br />
publicador. Para que esto se pueda llevar a cabo, en la creación <strong>de</strong> un canal con filtro se<br />
incluirá una <strong>de</strong>finición <strong>de</strong>l dato que se va a manejar en el canal.<br />
Implementación<br />
<strong>La</strong>s pruebas realizadas para la comprobación y validación <strong>de</strong> esta característica conducen<br />
a la necesidad <strong>de</strong> la creación <strong>de</strong> los siguientes elementos:<br />
Filter<br />
El tipo para los filtros es una secuencia <strong>de</strong> ca<strong>de</strong>nas (listado 5.4). <strong>La</strong> <strong>de</strong>cisión <strong>de</strong> la<br />
especificación <strong>de</strong> los filtros con una ca<strong>de</strong>na es <strong>de</strong>bida a la posibilidad <strong>de</strong> indicar gran<br />
cantidad <strong>de</strong> filtros diferentes sin necesidad <strong>de</strong> crear objetos específicos.
5. DESARROLLO DEL PROYECTO 37<br />
sequence FilterSeq;<br />
Listado 5.4: Definición <strong>de</strong>l tipo para filtros<br />
Cada ca<strong>de</strong>na será la expresión <strong>de</strong>l filtro que se compone <strong>de</strong>l nombre <strong>de</strong> la variable (x,<br />
y ó z) según la coor<strong>de</strong>nada que se quiera filtrar, el operador y el/los valor/es asociados.<br />
Por ejemplo:<br />
’x in range(1,5)’<br />
<strong>La</strong> tabla 5.1 muestra los tipos <strong>de</strong> operadores que se pue<strong>de</strong>n especificar para indicar los<br />
filtros.<br />
Operador Descripción<br />
== Igual<br />
> Mayor que<br />
< Menor que<br />
in range( , ) Rango<br />
Cuadro 5.1: Tipos <strong>de</strong> filtros en IceDDS<br />
De manera interna, la expresión <strong>de</strong>l filtro es transformada en un objeto manipulable.<br />
En el apéndice D se <strong>de</strong>scriben los objetos que se crean internamente teniendo en cuenta<br />
los filtros especificados.<br />
TypeCo<strong>de</strong><br />
TypeCo<strong>de</strong> es el parámetro que indica el tipo <strong>de</strong> datos <strong>de</strong>l evento. Se compone <strong>de</strong> un<br />
conjunto <strong>de</strong> variables y sus tipos asociados. Este parámetro se necesita porque el canal<br />
tiene que saber el contenido <strong>de</strong> los eventos para po<strong>de</strong>r extraer los datos y realizar las<br />
comparaciones correspondientes con los filtros especificados.<br />
En el caso <strong>de</strong> DDS, el tipo <strong>de</strong> canal está compuesto por una estructura (struct) y para<br />
<strong>de</strong>terminar el tipo <strong>de</strong> un objeto, se hace introspección <strong>de</strong> la estructura en tiempo <strong>de</strong><br />
ejecución.<br />
Agregar introspección <strong>de</strong> tipos a este proyecto supone un esfuerzo más a incluir en el<br />
<strong>de</strong>sarrollo. Por lo tanto, se plantea la alternativa <strong>de</strong> indicar el tipo <strong>de</strong> datos que manejará<br />
el canal con la variable TypeCo<strong>de</strong> nombrada anteriormente, <strong>de</strong>jando la introspección<br />
para un trabajo futuro.<br />
El listado 5.5 muestra la <strong>de</strong>finición <strong>de</strong>l parámetro TypeCo<strong>de</strong> que lo constituyen un<br />
conjunto <strong>de</strong> pares <strong>de</strong> ca<strong>de</strong>nas (nombre <strong>de</strong> variable, tipo <strong>de</strong> variable).
5. DESARROLLO DEL PROYECTO 38<br />
struct VariableTypeCo<strong>de</strong> {<br />
string variableName;<br />
string variableType;<br />
};<br />
sequence TypeCo<strong>de</strong>;<br />
Listado 5.5: Tipo <strong>de</strong> código <strong>de</strong> los filtros<br />
DataDissector<br />
<strong>La</strong> clase DataDissector se utiliza internamente como un objecto que contiene la información<br />
necesaria <strong>de</strong> los filtros <strong>de</strong> un canal. Esta clase proporciona un método que<br />
comprueba que los valores <strong>de</strong> los datos enviados puedan circular por el canal, verificándolos<br />
en los filtros indicados en la creación <strong>de</strong>l canal.<br />
A<strong>de</strong>más <strong>de</strong> los componentes anteriores, la batería <strong>de</strong> pruebas aña<strong>de</strong> las siguientes características:<br />
Creación <strong>de</strong> un canal teniendo en cuenta los filtros indicados junto con el tipo <strong>de</strong> datos<br />
<strong>de</strong> los eventos que manejará el canal.<br />
Es necesario la realización <strong>de</strong> la clase Publisher ya que será la encargada <strong>de</strong> <strong>de</strong>cidir<br />
si un evento pue<strong>de</strong> ser enviado al canal, utilizando para ello una comprobación <strong>de</strong><br />
los filtros <strong>de</strong>l canal en el que se publica. <strong>La</strong> clase Publisher hereda <strong>de</strong> Blobject e<br />
implementará el método ice_invoke. Todas las llamadas remotas al sirviente serán<br />
manejadas a través <strong>de</strong> la función ice_invoke. Es en esta función don<strong>de</strong> se hace la<br />
comprobación para validar que los valores recibidos concuerdan con los filtros especificados,<br />
en este caso, en el canal.<br />
Para una mayor fiabilidad en los datos enviados, en la creación <strong>de</strong>l canal filtrado se comprueba<br />
que el tipo <strong>de</strong> código especificado y los filtros indicados coinci<strong>de</strong>n.<br />
En en listado 5.6 se pue<strong>de</strong> ver la especificación <strong>de</strong>l slice con todos los componentes añadidos<br />
en esta iteración.<br />
module DDS {<br />
struct VariableTypeCo<strong>de</strong> {<br />
string variableName;<br />
string variableType;<br />
};<br />
sequence TypeCo<strong>de</strong>;<br />
sequence FilterSeq;<br />
interface Topic {<br />
Object∗ getPublisher();<br />
Object∗ subscribeAndGetPublisher(Object∗ subscriber);<br />
};<br />
interface TopicManager {
5. DESARROLLO DEL PROYECTO 39<br />
};<br />
Topic∗ createTopic(string name);<br />
Topic∗ createFilteredTopic(string name, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>);<br />
};<br />
Listado 5.6: SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice<br />
En la figura 5.4 se muestra el diagrama <strong>de</strong> secuencia cuyo escenario es el envío <strong>de</strong> un<br />
evento <strong>de</strong>s<strong>de</strong> un publicador al canal filtrado. En este escenario se supone que el suscriptor ya<br />
está suscrito a dicho canal.<br />
Figura 5.4: Diagrama <strong>de</strong> secuencia <strong>de</strong> la creación <strong>de</strong> un canal con filtros<br />
5.4.3. Filtrado a nivel <strong>de</strong> publicador<br />
Análisis y diseño<br />
A<strong>de</strong>más <strong>de</strong>l filtro a nivel <strong>de</strong> canal, los publicadores que se crean <strong>de</strong> cada canal, también<br />
tienen que ser capaces <strong>de</strong> filtrar la información que envían. Los propios canales pue<strong>de</strong>n<br />
tener la intención <strong>de</strong> filtrar los eventos en <strong>de</strong>terminadas ocasiones y el sistema, no por ello,<br />
tenga que crear otros canales filtrados para ese propósito. En estas situaciones se crearían<br />
publicadores filtrados que cumplirían las restricciones <strong>de</strong>mandadas por el sistema.<br />
Todo este razonamiento requiere la necesidad <strong>de</strong> facilitar un mecanismo don<strong>de</strong> se pueda<br />
establecer un publicador propio <strong>de</strong> un canal con parámetros <strong>de</strong> filtros. Para este tipo <strong>de</strong>
5. DESARROLLO DEL PROYECTO 40<br />
publicadores habrá que indicar, a<strong>de</strong>más <strong>de</strong>l filtrado que se quiere hacer en un <strong>de</strong>terminado<br />
publicador, los filtros propios <strong>de</strong>l canal en que se <strong>de</strong>sea publicar.<br />
Una particularidad que no se ha tenido en cuenta hasta este momento es la comprobación<br />
<strong>de</strong> que las expresiones que <strong>de</strong>finen los filtros sean proporcionadas <strong>de</strong> la manera correcta, es<br />
<strong>de</strong>cir, con la estructura que se <strong>de</strong>fine en la iteración anterior: “NombreVariable operador/es(tabla<br />
5.1) valor/es”.<br />
Implementación<br />
<strong>La</strong> colección <strong>de</strong> pruebas para esta nueva funcionalidad exige la creación <strong>de</strong> una nueva<br />
operación cuyos parámetros son un nombre que i<strong>de</strong>ntifique unívocamente al publicador <strong>de</strong><br />
un <strong>de</strong>terminado canal en el dominio <strong>de</strong>l sistema, los filtros que el publicador utilizará para<br />
enviar sólo ciertos eventos y el tipo que tienen los datos que se envían.<br />
El listado 5.7 muestra el SLICE que se <strong>de</strong>fine en este punto <strong>de</strong>l <strong>de</strong>sarrollo <strong>de</strong>l proyecto.<br />
Como se pue<strong>de</strong> observar en este listado, se introduce el lanzamiento <strong>de</strong> la excepción FilterError<br />
mediante la cual se indica un error en la <strong>de</strong>finición <strong>de</strong> un cierto filtro y a<strong>de</strong>más, en<br />
el mensaje <strong>de</strong>l error se especifica la manera correcta <strong>de</strong> <strong>de</strong>finir esa expresión.<br />
module DDS {<br />
};<br />
struct VariableTypeCo<strong>de</strong> {<br />
string variableName;<br />
string variableType;<br />
};<br />
sequence TypeCo<strong>de</strong>;<br />
sequence FilterSeq;<br />
exception FilterError {<br />
string msg;<br />
};<br />
interface Topic {<br />
Object∗ getPublisher();<br />
Object∗ getFilteredPublisher(string publisherName, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>) throws<br />
FilterError;<br />
Object∗ subscribeAndGetPublisher(Object∗ subscriber);<br />
};<br />
interface TopicManager {<br />
Topic∗ createTopic(string name);<br />
Topic∗ createFilteredTopic(string name, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>);<br />
};<br />
Listado 5.7: SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice
5. DESARROLLO DEL PROYECTO 41<br />
<strong>La</strong> operación getFilteredPublisher se encarga <strong>de</strong> crear un publicador que aplica tanto<br />
los filtros <strong>de</strong>l canal al que está asociado, en caso <strong>de</strong> ser un canal con filtros, como los propios<br />
filtros.<br />
<strong>La</strong> figura 5.5 muestra el diagrama <strong>de</strong> secuencia cuyo escenario sería la existencia <strong>de</strong> un<br />
publicador filtrado que manda un evento a canal filtrado.<br />
Figura 5.5: Diagrama <strong>de</strong> secuencia para un publicador filtrado<br />
5.4.4. Filtrado a nivel <strong>de</strong> suscripción<br />
Análisis y diseño<br />
Otra característica interesante que se plantea es que los suscriptores puedan <strong>de</strong>finir una<br />
serie <strong>de</strong> datos <strong>de</strong> los que quieren ser informados. Pue<strong>de</strong> ser que en un canal existan datos<br />
en los que el suscriptor no está interesado. Ante esta situación, el mo<strong>de</strong>lo <strong>de</strong> comunicación<br />
<strong>de</strong>l presente proyecto <strong>de</strong>berá proporcionar la operación u operaciones necesarias para po<strong>de</strong>r<br />
realizar una suscripción a un canal indicando unos <strong>de</strong>terminados filtros.
5. DESARROLLO DEL PROYECTO 42<br />
Implementación<br />
<strong>La</strong> batería <strong>de</strong> pruebas implementadas para esta iteración hacen que se necesite la implementación<br />
<strong>de</strong> una nueva operación para que el suscriptor pueda especificar que se quiere<br />
suscribir a un <strong>de</strong>terminado canal con unos filtros establecidos. A<strong>de</strong>más, se aña<strong>de</strong> la funcionalidad<br />
<strong>de</strong> po<strong>de</strong>r cancelar una suscripción <strong>de</strong> un canal.<br />
Como el formato <strong>de</strong> los filtros se ha <strong>de</strong>finido en iteraciones anteriores, solamente hace falta<br />
la implementación <strong>de</strong>l propio método que es necesario. De esta manera se aña<strong>de</strong> al SLICE <strong>de</strong>l<br />
sistema como la función subscribeWithFilters quedando <strong>de</strong>finido como se muestran en<br />
el listado 5.8.<br />
module DDS {<br />
};<br />
struct VariableTypeCo<strong>de</strong> {<br />
string variableName;<br />
string variableType;<br />
};<br />
sequence TypeCo<strong>de</strong>;<br />
sequence FilterSeq;<br />
exception FilterError {<br />
string msg;<br />
};<br />
interface Topic {<br />
Object∗ getPublisher();<br />
Object∗ getFilteredPublisher(string publisherName, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>) throws<br />
FilterError;<br />
};<br />
Object∗ subscribeAndGetPublisher(Object∗ subscriber);<br />
Object∗ subscribeWithFilters(Object∗ subscriber, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>) throws FilterError;<br />
void unsubscribe(Object∗ subscriber);<br />
interface TopicManager {<br />
Topic∗ createTopic(string name);<br />
Topic∗ createFilteredTopic(string name, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>);<br />
};<br />
Listado 5.8: SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice<br />
El mecanismo que se sigue en la operación suscribir con filtros es el siguiente:<br />
1. Se crea un nuevo canal indicando un nuevo nombre y los filtros que se indican en la<br />
suscripción.<br />
2. Se aña<strong>de</strong> el nuevo canal creado al adaptador <strong>de</strong> objetos <strong>de</strong>l sistema.
5. DESARROLLO DEL PROYECTO 43<br />
3. El suscriptor se registra en el nuevo canal creado.<br />
4. Se obtiene el publicador <strong>de</strong>l nuevo canal creado.<br />
5. Se enlaza el publicador <strong>de</strong>l nuevo canal. Esto en realidad lo que hace es subscribir el<br />
publicador al canal principal. De ese modo, se consigue que los eventos enviados al<br />
canal principal los filtre el publicador <strong>de</strong>l canal creado y <strong>de</strong> ahí propagarlos al suscriptor.<br />
<strong>La</strong> cancelación <strong>de</strong> la suscripción a un canal se <strong>de</strong>lega al servicio IceStorm ya que este<br />
proporciona la misma funcionalidad.<br />
En la figura 5.6 y en el diagrama <strong>de</strong> secuencia 5.7 se muestra una visión general <strong>de</strong> la<br />
dinámica <strong>de</strong> esta operación. En estos esquemas se pue<strong>de</strong> ver con más claridad la dinámica <strong>de</strong><br />
la operación: el suscriptor es registrado en el nuevo canal creado y el publicador <strong>de</strong>l mismo<br />
es el que se encarga <strong>de</strong> la correspondiente comprobación para propagar los eventos.<br />
Figura 5.6: Procedimiento <strong>de</strong> una suscripción indicando filtros en el mo<strong>de</strong>lo <strong>de</strong> comunicaciones<br />
IceDDS<br />
5.4.5. Fe<strong>de</strong>ración <strong>de</strong> canales<br />
Análisis y diseño<br />
Como se explicó en el capítulo 2.1.1, la fe<strong>de</strong>ración permite la propagación <strong>de</strong> eventos<br />
<strong>de</strong> un canal a otro. <strong>La</strong> fe<strong>de</strong>ración <strong>de</strong> IceStorm pue<strong>de</strong> restringir la propagación <strong>de</strong> mensajes<br />
asociando un coste a cada enlace. Cuando un mensaje es publicado en un canal, se compara<br />
el coste asociado <strong>de</strong> cada uno <strong>de</strong> sus enlaces con el coste <strong>de</strong>l mensaje y la propagación se<br />
realiza únicamente a los enlaces cuyo coste sea igual o no exce<strong>de</strong> <strong>de</strong>l coste <strong>de</strong>l mensaje.<br />
En el mo<strong>de</strong>lo <strong>de</strong> comunicaciones <strong>de</strong>l presente proyecto se preten<strong>de</strong> proporcionar fe<strong>de</strong>ración<br />
<strong>de</strong> canales pero teniendo en cuenta una restricción en los datos que se envían. <strong>La</strong><br />
propagación <strong>de</strong> eventos entre canales se hará en función <strong>de</strong>l filtrado <strong>de</strong> los datos que se haya<br />
especificado en cada enlace.
5. DESARROLLO DEL PROYECTO 44<br />
Figura 5.7: Diagrama <strong>de</strong> secuencia <strong>de</strong> una suscripción con filtros<br />
El uso <strong>de</strong> la fe<strong>de</strong>ración <strong>de</strong> canales permite una reducción <strong>de</strong>l número <strong>de</strong> publicadores. Un<br />
solo publicador pue<strong>de</strong> servir como publicador <strong>de</strong> eventos para varios canales.<br />
Implementación<br />
Para implementar esta funcionalidad no se pue<strong>de</strong> utilizar la propia operación link <strong>de</strong><br />
IceStorm porque solo permite la propagación <strong>de</strong> todos los eventos si se indica un coste 0<br />
o, en todo caso, restringir los eventos según el coste que lleven asociados. Por lo tanto, se<br />
implementa una nueva operación que permite indicar <strong>de</strong> algún modo un filtrado en los datos<br />
que pue<strong>de</strong>n ser propagados.<br />
<strong>La</strong> manera <strong>de</strong> conseguir una propagación acor<strong>de</strong> a <strong>de</strong>terminados filtros es similar al mecanismo<br />
realizado en la suscripción con filtros. <strong>La</strong> única diferencia presente es que los canales<br />
implicados existen en el dominio <strong>de</strong>l sistema o son creados previamente.<br />
<strong>La</strong> figura 5.8 representa el mecanismo <strong>de</strong> enlace <strong>de</strong> estas características. Existen dos canales:<br />
canal 1 y canal 2. El canal 2 quiere que ciertos eventos <strong>de</strong>l canal 1 sean propagados hacia<br />
él. Para que esto ocurra, se crea un publicador <strong>de</strong>l canal 2 que contenga los filtros con los que<br />
quiere realizar el enlace al canal 1. Por último, se hace una llamada a la función linkFiltered<br />
pasándole como parámetro el publicador creado. <strong>La</strong> propia función hace una suscripción<br />
<strong>de</strong> este publicador al canal 1. De este modo, el publicador actúa como un suscriptor filtrado<br />
<strong>de</strong>l canal 1 que a su vez filtra los eventos para propagarlos al canal 2.<br />
Al igual que un canal pue<strong>de</strong> enlazarse a otro, también existe la posibilidad <strong>de</strong> eliminar<br />
ese enlace, para ello, se implementa una funcionalidad cuyo procedimiento será cancelar
5. DESARROLLO DEL PROYECTO 45<br />
Figura 5.8: Fe<strong>de</strong>ración <strong>de</strong> canales con filtro en IceDDS<br />
el enlace. Realmente, la acción ejecutada es una anulación <strong>de</strong> la suscripción <strong>de</strong>l publicador<br />
previamente suscrito.<br />
El listado 5.9 muestra el SLICE <strong>de</strong> IceDDS añadiendo las propieda<strong>de</strong>s anteriores.<br />
module DDS {<br />
struct VariableTypeCo<strong>de</strong> {<br />
string variableName;<br />
string variableType;<br />
};<br />
sequence TypeCo<strong>de</strong>;<br />
sequence FilterSeq;<br />
exception FilterError {<br />
string msg;<br />
};<br />
interface Topic {<br />
Object∗ getPublisher();<br />
Object∗ getFilteredPublisher(string publisherName, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>) throws<br />
FilterError;<br />
};<br />
Object∗ subscribeAndGetPublisher(Object∗ subscriber);<br />
Object∗ subscribeWithFilters(Object∗ subscriber, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>) throws FilterError;<br />
void unsubscribe(Object∗ subscriber);<br />
void linkFiltered(Object∗ publisher);<br />
void unlinkFiltered(Object∗ publisher);<br />
interface TopicManager {<br />
Topic∗ createTopic(string name);<br />
Topic∗ createFilteredTopic(string name, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>);<br />
};<br />
};<br />
Listado 5.9: SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice
5. DESARROLLO DEL PROYECTO 46<br />
5.4.6. Modificación <strong>de</strong> filtros <strong>de</strong> un suscriptor<br />
Análisis y diseño<br />
Los suscriptores que están interesados en <strong>de</strong>terminados datos pue<strong>de</strong>n cambiar <strong>de</strong> criterio<br />
según la condiciones en un momento <strong>de</strong>terminado. Por ello, el sistema <strong>de</strong>be dar soporte para<br />
po<strong>de</strong>r cambiar los criterios <strong>de</strong> filtrado <strong>de</strong> un suscriptor. De esta manera, los eventos que se<br />
reciben en los suscriptores podrán cambiar según las necesida<strong>de</strong>s <strong>de</strong> estos en <strong>de</strong>terminadas<br />
situaciones.<br />
Implementación<br />
Según el mecanismo que se sigue para realizar una suscripción con filtros, un nuevo canal<br />
es creado con los filtros específicos que se indican en la suscripción. Por medio <strong>de</strong> este canal<br />
es <strong>de</strong>s<strong>de</strong> don<strong>de</strong> realmente el suscriptor recibe los eventos, por lo tanto, es este canal el que<br />
<strong>de</strong>be ser modificado.<br />
Para cambiar el filtro <strong>de</strong>l canal, se aña<strong>de</strong> la operación setFilters. Este método se encarga<br />
<strong>de</strong> cambiar los filtros específicos <strong>de</strong>l canal y modificar su publicador para hacer constar<br />
que el filtro para limitar el transporte <strong>de</strong> datos ha sido cambiado. El canal en el que realmente<br />
está registrado el subscriptor se obtiene al hacer la suscripción, es <strong>de</strong>cir, el método subscribeWithFilters<br />
<strong>de</strong>vuelve el canal creado para, más tar<strong>de</strong>, po<strong>de</strong>r modificar sus filtros.<br />
Esto conlleva cambiar el tipo <strong>de</strong>l objeto <strong>de</strong>vuelto en la función subscribeWithFilters por<br />
Topic*, es <strong>de</strong>cir, un objeto tipo canal.<br />
A<strong>de</strong>más <strong>de</strong> po<strong>de</strong>r cambiar los filtros, también se aña<strong>de</strong> una operación para conocer los filtros<br />
que tiene un canal <strong>de</strong>terminado. Esta operación será getFilters, que <strong>de</strong>vuelve el conjunto<br />
<strong>de</strong> filtros asociado al canal.<br />
En el listado 5.10 se pue<strong>de</strong>n ver las dos operaciones que se aña<strong>de</strong>n en el SLICE y que son<br />
implementadas por la API IceDDS.<br />
FilterSeq getFilters();<br />
void setFilters(FilterSeq filters, TypeCo<strong>de</strong> eventTypeco<strong>de</strong>);<br />
Listado 5.10: Obtención y modificación <strong>de</strong> los filtros asociados a un canal<br />
5.4.7. Operaciones <strong>de</strong>l servicio IceStorm<br />
Análisis y diseño<br />
El mo<strong>de</strong>lo <strong>de</strong> comunicaciones IceDDS <strong>de</strong>be realizar las mismas operaciones que ofrece<br />
el servicio IceStorm a<strong>de</strong>más <strong>de</strong> las <strong>de</strong>scritas anteriormente. Entonces, se <strong>de</strong>ben añadir las<br />
funcionalida<strong>de</strong>s que faltan al mo<strong>de</strong>lo <strong>de</strong> comunicaciones que se <strong>de</strong>sarrolla en el presente<br />
proyecto.<br />
Se usará el servicio IceStorm para <strong>de</strong>legarle todas estas funcionalida<strong>de</strong>s.
5. DESARROLLO DEL PROYECTO 47<br />
Implementación<br />
Se aña<strong>de</strong>n las siguientes operaciones al SLICE.<br />
interfaz TopicManager:<br />
• retrieve<br />
• retrieveAll<br />
interfaz Topic<br />
• getName<br />
• link<br />
• unlink<br />
• <strong>de</strong>stroy<br />
Para implementar estas operaciones no ha hecho falta utilizar la técnica TDD ya que la<br />
funcionalidad en cada una <strong>de</strong> ellas se <strong>de</strong>lega al TopicManager <strong>de</strong> IceStorm y no correspon<strong>de</strong><br />
en este proyecto probar el correcto funcionamiento <strong>de</strong> este servicio. El SLICE resultante se<br />
muestra en el listado 5.11.<br />
module DDS {<br />
struct VariableTypeCo<strong>de</strong> {<br />
string variableName;<br />
string variableType;<br />
};<br />
sequence TypeCo<strong>de</strong>;<br />
sequence FilterSeq;<br />
exception FilterError {<br />
string msg;<br />
};<br />
interface Topic {<br />
FilterSeq getFilters();<br />
void setFilters(FilterSeq filters, TypeCo<strong>de</strong> eventTypeco<strong>de</strong>);<br />
string getName();<br />
Object∗ subscribeAndGetPublisher(Object∗ subscriber);<br />
Topic∗ subscribeWithFilters(Object∗ subscriber, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>) throws FilterError;<br />
void unsubscribe(Object∗ subscriber);<br />
Object∗ getPublisher();<br />
Object∗ getFilteredPublisher(string publisherName, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>) throws<br />
FilterError;<br />
void link(Topic∗ linkTo, int cost);<br />
void unlink(Topic∗ linkTo);<br />
void linkFiltered(Object∗ publisher);
5. DESARROLLO DEL PROYECTO 48<br />
};<br />
void unlinkFiltered(Object∗ publisher);<br />
void <strong>de</strong>stroy();<br />
};<br />
dictionary TopicDict;<br />
interface TopicManager {<br />
Topic∗ createTopic(string name);<br />
Topic∗ createFilteredTopic(string name, FilterSeq filters,<br />
TypeCo<strong>de</strong> eventTypeco<strong>de</strong>);<br />
Topic∗ retrieve(string name);<br />
TopicDict retrieveAll();<br />
};<br />
Listado 5.11: SLICE para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones DDS con ZeroC Ice<br />
5.5. Aplicación Android<br />
Se <strong>de</strong>sarrolla una aplicación Android [AND08] para mostrar <strong>de</strong> manera visual como funciona<br />
el mo<strong>de</strong>lo <strong>de</strong> comunicaciones IceDDS. Para el <strong>de</strong>sarrollo <strong>de</strong> esta aplicación se ha<br />
tomado en cuenta el entorno don<strong>de</strong> el proyecto <strong>de</strong> Elcano trabaja.<br />
<strong>La</strong> aplicación se limita a reproducir los eventos <strong>de</strong> localización que se pue<strong>de</strong>n percibir en<br />
la planta baja <strong>de</strong> la ESI. Para ello, los usuarios conectados al sistema <strong>de</strong>ben suscribirse a los<br />
distintos canales que existen o a los canales cuyos datos sean <strong>de</strong> interés para él.<br />
A<strong>de</strong>más <strong>de</strong> una suscripción habitual, la aplicación permite suscribirse a los canales indicando<br />
propios filtros. De esta manera, se tienen cubiertas las dos posibilida<strong>de</strong>s <strong>de</strong> suscripción<br />
que ofrece el mo<strong>de</strong>lo <strong>de</strong> comunicaciones IceDDS.<br />
El cometido <strong>de</strong> esta aplicación es la visualización <strong>de</strong> los distintos eventos que llegan a los<br />
canales por medio <strong>de</strong> los publicadores. Para diferenciar los eventos <strong>de</strong> distintos canales y/o<br />
las diferentes suscripciones realizadas, la aplicación representa círculos <strong>de</strong> diferentes colores.<br />
Este tipo <strong>de</strong> representación permite ver claramente el filtrado que se realiza, pudiendo<br />
contrastar los diferentes datos que son enviados.<br />
Para una completa guía <strong>de</strong>l uso <strong>de</strong> la aplicación pue<strong>de</strong> consultarse el apéndice F.
Resultados<br />
6<br />
En este capítulo se <strong>de</strong>scribirán las diferentes aplicaciones <strong>de</strong>l mo<strong>de</strong>lo <strong>de</strong> comunicaciones<br />
<strong>de</strong>sarrollado a diferentes situaciones en el ámbito <strong>de</strong>l proyecto Elcano. Igualmente, se hace<br />
un análisis <strong>de</strong>l esfuerzo <strong>de</strong> <strong>de</strong>sarrollo <strong>de</strong>l proyecto y <strong>de</strong>l tiempo <strong>de</strong>dicado al mismo, así como<br />
una estimación <strong>de</strong>l coste total que ha supuesto su realización.<br />
6.1. Aplicaciones <strong>de</strong>l mo<strong>de</strong>lo a diferentes escenarios<br />
En esta sección se enumeran diferentes escenarios en un sistema <strong>de</strong> localización <strong>de</strong> usuarios<br />
en el interior <strong>de</strong> edificios para justificar las diferentes formas <strong>de</strong> filtrado que se han<br />
elaborado en este proyecto.<br />
Los eventos <strong>de</strong> localización que envía el sistema Elcano son <strong>de</strong>l tipo que se muestra en el<br />
listado 6.1. Los eventos <strong>de</strong> posicionamiento contienen la variable msid que es el i<strong>de</strong>ntificador<br />
<strong>de</strong> un <strong>de</strong>terminado proveedor <strong>de</strong> eventos, time es el momento <strong>de</strong>l envío <strong>de</strong>l evento y theShape<br />
contiene el tipo <strong>de</strong> datos que sirve para posicionar al usuario en el entorno. El SLICE que<br />
contiene todos los diferentes tipos que pue<strong>de</strong>n ir en el evento se pue<strong>de</strong>n ver en el apéndice<br />
C.<br />
struct Position {<br />
string msid;<br />
long time;<br />
Shape theShape;<br />
};<br />
Listado 6.1: Evento <strong>de</strong> localización <strong>de</strong> Elcano<br />
Para simplificar los escenarios que se van a explicar a continuación, se supone que los<br />
eventos enviados son <strong>de</strong>l tipo MLP.Coord. <strong>La</strong>s coor<strong>de</strong>nadas x,y y z representan los ejes <strong>de</strong>l<br />
plano, don<strong>de</strong> la variable x representa al eje horizontal, la variable y representa el eje vertical<br />
y la variable z correspon<strong>de</strong>ría a la altura. Esta última variable no se tiene en cuenta <strong>de</strong>bido<br />
a que la representación <strong>de</strong> los eventos <strong>de</strong> localización se realizan sobre un plano en 2<br />
dimensiones.<br />
<strong>La</strong> forma <strong>de</strong> expresar los filtros, al ser una ca<strong>de</strong>na o un conjunto <strong>de</strong> ca<strong>de</strong>nas, proporciona<br />
49
6. RESULTADOS 50<br />
mayores posibilida<strong>de</strong>s para indicar un conjunto <strong>de</strong> filtros que sean los más apropiados para<br />
las necesida<strong>de</strong>s <strong>de</strong> cada suscripción. En cada expresión <strong>de</strong> filtro, a<strong>de</strong>más <strong>de</strong> po<strong>de</strong>r indicar los<br />
filtros <strong>de</strong>scritos en la tabla 6.1, se pue<strong>de</strong>n añadir los operadores lógicos <strong>de</strong> la tabla 6.2 para<br />
obtener filtros mucho más versátiles. De esta manera, el conjunto <strong>de</strong> filtros pue<strong>de</strong> estar <strong>de</strong>terminado<br />
por una especificación mucho más <strong>de</strong>tallada que se ajustaría más a las exigencias<br />
<strong>de</strong> cada suscriptor.<br />
Operador<br />
Descripción<br />
== Igual<br />
!= Distinto<br />
> Mayor que<br />
< Menor que<br />
>= Mayor o igual que<br />
6. RESULTADOS 51<br />
Figura 6.1: Vista <strong>de</strong> las áreas que cubre cada canal en el mapa<br />
Figura 6.2: Ruta <strong>de</strong>l usuario en el escenario 1<br />
Previamente, el usuario ha tenido que suscribirse a los canales, ya sea <strong>de</strong> manera manual o<br />
porque la aplicación subscribe a los usuarios <strong>de</strong>l sistema directamente. En la figura 6.3 se<br />
pue<strong>de</strong> ver el rastro <strong>de</strong>l camino <strong>de</strong>l usuario. En la aplicación se muestra el punto únicamente<br />
don<strong>de</strong> se encuentra el usuario en cada momento, <strong>de</strong> manera intermitente, pero en la figura<br />
6.3 se muestra una vista <strong>de</strong>l camino completo para su mejor entendimiento.<br />
6.1.2. Escenario 2: Subscriptores filtrados<br />
En la aplicación Elcano pue<strong>de</strong>n recibirse multitud <strong>de</strong> eventos <strong>de</strong> localización diferentes<br />
que proce<strong>de</strong>n <strong>de</strong> diferentes proveedores <strong>de</strong> eventos (WIFI, Bluetooh y RFID). A<strong>de</strong>más <strong>de</strong> los<br />
eventos <strong>de</strong> localización se recibe información <strong>de</strong>l entorno, tales como tareas, rutas, etc.<br />
Si un usuario está viendo en la pantalla <strong>de</strong> la tablet cierta parte <strong>de</strong>l mapa, lo más lógico es<br />
pensar que sólo le interesarán los eventos que se reciban en ese área específica (figura 6.4).<br />
El usuario, por lo tanto, estará suscrito a los canales <strong>de</strong> eventos indicando sus propios filtros<br />
que serán los que <strong>de</strong>limiten el área mostrada en pantalla. Cuando hay un <strong>de</strong>splazamiento <strong>de</strong><br />
la pantalla, bien porque se ha generado un <strong>de</strong>slizamiento con el <strong>de</strong>do, o se ha modificado el
6. RESULTADOS 52<br />
Figura 6.3: Ruta <strong>de</strong>l usuario en la aplicación IceDDSAndroid<br />
zoom, este filtro cambiará para indicar el nuevo área <strong>de</strong> visualización.<br />
Figura 6.4: Visión que muestra la pantalla <strong>de</strong>l dispositivo con respecto al mapa completo<br />
<strong>La</strong> posibilidad <strong>de</strong> cambiar el filtro <strong>de</strong> la suscripción disminuye la creación <strong>de</strong> canales<br />
<strong>de</strong>ntro <strong>de</strong>l sistema, ya que la suscripción con filtros supone la creación <strong>de</strong> un canal filtrado<br />
<strong>de</strong>ntro <strong>de</strong> sistema (capítulo 5.4.4), pero <strong>de</strong> esta manera no hace falta una nueva suscripción,<br />
simplemente se cambian los filtros <strong>de</strong>l canal <strong>de</strong>seado.<br />
6.1.3. Escenario 3: Publicadores filtrados<br />
En capítulos anteriores se ha <strong>de</strong>scrito como los canales pue<strong>de</strong>n tener varios publicadores<br />
y a<strong>de</strong>más restringir los datos que envían los mismos indicando un conjunto <strong>de</strong> filtros.<br />
Con esta perspectiva, la situación que se trata en este escenario es la existencia <strong>de</strong> varios
6. RESULTADOS 53<br />
publicadores <strong>de</strong> un canal global que se encargan <strong>de</strong> enviar eventos atendiendo a coor<strong>de</strong>nadas<br />
específicas. En la figura 6.5 se pue<strong>de</strong>n observar los distintos publicadores que podrían existir<br />
en un canal que maneja eventos correspondientes al mapa completo don<strong>de</strong> pue<strong>de</strong> navegar el<br />
usuario.<br />
Figura 6.5: Publicadores existentes que limitan el envío <strong>de</strong> datos a zonas concretas<br />
Cada publicador se encarga <strong>de</strong> enviar los eventos <strong>de</strong> localización correspondientes a una<br />
zona específica y así, la responsabilidad <strong>de</strong>l envío <strong>de</strong> datos estaría repartida entre varios.<br />
En cada publicador se pue<strong>de</strong> limitar los eventos <strong>de</strong> localización que se salen <strong>de</strong>l mapa, las<br />
zonas por las que el usuario no tiene acceso, otras zonas don<strong>de</strong> no es relevante mantener la<br />
información <strong>de</strong> la posición <strong>de</strong>l usuario (por ej.: los aseos), ...<br />
6.1.4. Escenario 4: Fe<strong>de</strong>ración <strong>de</strong> canales filtrados<br />
Los servicios que ofrece el proyecto Elcano se podrían ampliar y expandir a varios edificios<br />
<strong>de</strong> la Escuela <strong>de</strong> Informática. De este modo, se tendría un control <strong>de</strong> los usuarios en<br />
los diferentes edificios. Cada edificio supone la recogida <strong>de</strong> información <strong>de</strong> su entorno, así<br />
como <strong>de</strong>finir las tareas que los usuarios pue<strong>de</strong>n realizar y los caminos o rutas que <strong>de</strong>ben<br />
seguir <strong>de</strong>s<strong>de</strong> su posición a la tarea elegida.<br />
El escenario <strong>de</strong>scrito constaría <strong>de</strong> un monitor <strong>de</strong> sistema don<strong>de</strong> se mostraría los eventos<br />
<strong>de</strong> localización <strong>de</strong> todos los edificios. Estos eventos se enviarían a un canal que a su vez<br />
propagaría la información a los diferentes canales que representarían a cada edificio. En la<br />
figura 6.6 se muestra un esquema general <strong>de</strong>l funcionamiento <strong>de</strong>l sistema.<br />
En este supuesto, se pue<strong>de</strong> ver claramente que los datos serán propagados por medio <strong>de</strong><br />
los enlaces realizados y por lo tanto, cada canal <strong>de</strong> eventos <strong>de</strong> cada edificio podrá a su vez<br />
tener sus propios suscriptores (filtrados y no filtrados).
6. RESULTADOS 54<br />
Figura 6.6: Fe<strong>de</strong>ración <strong>de</strong> canales filtrados<br />
6.2. Recursos y costes<br />
<strong>La</strong> duración <strong>de</strong>l proyecto ha sido <strong>de</strong> 10 meses, aunque el tiempo <strong>de</strong>dicado al <strong>de</strong>sarrollo <strong>de</strong>l<br />
proyecto ha estado compaginado con el trabajo <strong>de</strong>ntro <strong>de</strong>l grupo <strong>ARCO</strong>, con lo cual no se ha<br />
podido realizar una <strong>de</strong>dicación a tiempo completo.<br />
Al inicio, fue necesario el estudio y el enriquecimiento sobre el estándar DDS en el que<br />
se centra el proyecto, así como apren<strong>de</strong>r a utilizar las diferentes tecnologías que se han<br />
empleado para su <strong>de</strong>sarrollo (Icestorm, Android, etc.). Todo esto supuso un incremento <strong>de</strong>l<br />
esfuerzo realizado para la elaboración <strong>de</strong> este proyecto.<br />
A continuación, se muestra el número <strong>de</strong> líneas <strong>de</strong> código <strong>de</strong>l proyecto divididas por los<br />
diferentes elementos <strong>de</strong>sarrollados (tabla 6.3).<br />
<strong>La</strong> tabla 6.4 muestra un resumen <strong>de</strong>l número líneas <strong>de</strong> código totales por cada uno <strong>de</strong> los<br />
lenguajes <strong>de</strong> programación empleados.<br />
Finalmente, la tabla 6.5 presenta la estimación <strong>de</strong>l coste <strong>de</strong>l proyecto generado usando<br />
sloccount [SLO] basado en el mo<strong>de</strong>lo COCOMO. En esta estimación no se tiene en cuenta<br />
los IDL y SLICE <strong>de</strong>finidos, ya que la herramienta no proporciona soporte para los mismos.<br />
6.2.1. Repositorio<br />
El código <strong>de</strong>l proyecto se encuentra en bitbucket.org [bit], que es un servicio <strong>de</strong> alojamiento<br />
basado en web para proyectos. Para <strong>de</strong>scargar el repositorio se ejecuta la siguiente<br />
sentencia en un terminal:
6. RESULTADOS 55<br />
$ hg clone https://bitbucket.org/arco_group/icedds<br />
Este servicio permite utilizar Mercurial [MER12] como sistema <strong>de</strong> control <strong>de</strong> versiones.<br />
Esta herramienta nos permite ver los cambios realizados en cada actualización, lo que permite<br />
hacer un seguimiento <strong>de</strong>l <strong>de</strong>sarrollo <strong>de</strong>l proyecto.<br />
El repositorio <strong>de</strong> la documentación también se encuentra en bitbucket.org y se <strong>de</strong>scarga<br />
con la siguiente sentencia:<br />
$ hg clone https://bitbucket.org/arco_group/pfc.icedds<br />
Componente Lenguaje N o líneas<br />
RTI DDS C++ 301<br />
IDL 5<br />
XML 39<br />
Pruebas 18<br />
OpenSplice DDS C++ 1520<br />
IDL 16<br />
Pruebas 63<br />
Mo<strong>de</strong>lo IceDDS Python 580<br />
Slice 58<br />
Pruebas 1104<br />
Aplicación Android Java 1544<br />
XML 480<br />
Cuadro 6.3: Líneas <strong>de</strong> código separado por elementos<br />
Lenguaje N o líneas<br />
Python 580<br />
C++ 1821<br />
Java 1544<br />
XML 519<br />
Pruebas 1185<br />
Slice 58<br />
IDL 21<br />
Cuadro 6.4: Líneas <strong>de</strong> código por lenguaje <strong>de</strong> programación
6. RESULTADOS 56<br />
Costes <strong>de</strong>l proyecto<br />
N o líneas<br />
Total <strong>de</strong> líneas física <strong>de</strong> código (SLOC) 5649<br />
Esfuerzo <strong>de</strong> <strong>de</strong>sarrollo en personas-año (personas-mes) 1.23 (14.78)<br />
Estimación <strong>de</strong> calendario, en Años (Meses) 0.58 (6.96)<br />
Número estimado <strong>de</strong> <strong>de</strong>sarrolladores 2.12<br />
Coste Total estimado <strong>de</strong> <strong>de</strong>sarrollo<br />
53,442 e<br />
(Salario medio: 18,000 e/año brutos)<br />
Cuadro 6.5: Estimación <strong>de</strong> costes <strong>de</strong>l proyecto
Conclusiones y trabajo futuro<br />
7<br />
En este capítulo se <strong>de</strong>scriben los objetivos alcanzados durante la elaboración <strong>de</strong> este proyecto.<br />
A<strong>de</strong>más, se realizan una serie <strong>de</strong> propuestas como trabajo futuro para mejorar e incrementar<br />
la eficiencia y funcionalidad <strong>de</strong>l mo<strong>de</strong>lo presentado en este proyecto.<br />
7.1. Objectivos alcanzados<br />
Después <strong>de</strong> realizar un análisis <strong>de</strong>l trabajo <strong>de</strong>sarrollado en el capítulo 5, se pue<strong>de</strong> afirmar<br />
que se ha alcanzado satisfactoriamente el objetivo general <strong>de</strong>l proyecto (capítulo 3).<br />
<strong>La</strong>s herramientas y servicios <strong>de</strong>sarrollados en el proyecto proporcionan un sistema que<br />
aprovecha los beneficios y ventajas que ofrece el servicio IceStorm (llamadas simples para<br />
distribuir la información a los suscriptores, in<strong>de</strong>pen<strong>de</strong>ncia entre entida<strong>de</strong>s <strong>de</strong>l sistema, etc.)<br />
añadiendo calidad <strong>de</strong> servicio por la que se caracteriza el estándar DDS <strong>de</strong> la OMG.<br />
Con respecto a los objetivos específicos (capítulo 3.2), se ha cumplido con todos ellos.<br />
A<strong>de</strong>más <strong>de</strong>l estudio <strong>de</strong>l estándar DDS realizado en la primera fase <strong>de</strong>l proyecto junto con el<br />
estudio <strong>de</strong> las implementaciones existentes <strong>de</strong>l mismo contribuyó a la realización <strong>de</strong>l mo<strong>de</strong>lo<br />
<strong>de</strong> comunicaciones <strong>de</strong> eventos DDS con ZeroC Ice poniendo gran interés en los parámetros <strong>de</strong><br />
calidad <strong>de</strong> servicio que aña<strong>de</strong>n mayor fiabilidad, calidad y eficiencia al mo<strong>de</strong>lo construido.<br />
A través <strong>de</strong> la <strong>de</strong>finición <strong>de</strong> un evento semejante a los datos manejados en el proyecto Elcano<br />
permitió la construcción <strong>de</strong>l mo<strong>de</strong>lo teniendo en cuenta un entorno real <strong>de</strong> propagación <strong>de</strong><br />
eventos.<br />
El <strong>de</strong>sarrollo orientado a pruebas ha hecho posible construir un mo<strong>de</strong>lo que cumple a la<br />
perfección los requisitos funcionales que se pretendían. En cada iteración se ejecutaban las<br />
pruebas para corroborar que todo seguía funcionando correctamente. Esto permitió localizar<br />
errores más rápidamente y resolverlos <strong>de</strong> manera sencilla, por lo que el tiempo que se ha<br />
<strong>de</strong>dicado a la <strong>de</strong>puración ha sido casi insignificante.<br />
Para dar acceso a los distintos aspectos que constituyen el mo<strong>de</strong>lo <strong>de</strong> comunicaciones<br />
<strong>de</strong>sarrollado, se ha realizado la implementación <strong>de</strong> un servicio por medio <strong>de</strong>l cual se pue<strong>de</strong>n<br />
acce<strong>de</strong>r a las diferentes operaciones que se necesitan para crear la comunicación entre publicadores<br />
y suscriptores. A<strong>de</strong>más, actúa como gestor <strong>de</strong> canales en el dominio <strong>de</strong>l sistema.<br />
57
7. CONCLUSIONES Y TRABAJO FUTURO 58<br />
Por último, para <strong>de</strong>mostrar su utilidad en un caso real y mostrar <strong>de</strong> forma visual las características<br />
<strong>de</strong> las que consta el mo<strong>de</strong>lo <strong>de</strong> comunicaciones creado en este proyecto, se ha<br />
realizado una aplicación Android minimalista que muestra la recepción <strong>de</strong> los distintos eventos<br />
ateniendo a las necesida<strong>de</strong>s <strong>de</strong>l usuario. En esta aplicación se pue<strong>de</strong> interactuar con los<br />
servicios <strong>de</strong> suscripción y creación <strong>de</strong> canales que proporciona el mo<strong>de</strong>lo.<br />
7.2. Trabajo futuro<br />
Aunque el mo<strong>de</strong>lo <strong>de</strong>sarrollado cubra todos los posibles aspectos <strong>de</strong> filtrado (canales, publicadores<br />
y suscriptores), sólo es una <strong>de</strong> las características más importantes en las que se<br />
envuelve el estándar DDS para sistemas distribuidos. Como propuestas <strong>de</strong> mejora y <strong>de</strong>sarrollo<br />
<strong>de</strong>l mo<strong>de</strong>lo para una mayor aplicación a sistemas que necesitan una comunicación <strong>de</strong><br />
información en tiempo real serían:<br />
Persistencia <strong>de</strong> datos: posibilidad <strong>de</strong> conservar un historial <strong>de</strong> los datos que son enviados<br />
al canal. Atendiendo al estándar DDS, se podría establecer el criterio para mantener<br />
solamente los datos más recientes o, en cambio, guardar todas las muestras <strong>de</strong> datos.<br />
Confiabilidad: establecer un parámetro que garantice la entrega <strong>de</strong> <strong>de</strong>terminados datos<br />
a nuevos subscriptores. En este caso, podría garantizarse que la información <strong>de</strong> eventos<br />
anteriores será entrega a todos los subscriptores, o por el contrario, no se reenvíen los<br />
datos <strong>de</strong> algunos eventos.<br />
Posesión <strong>de</strong> la información: se <strong>de</strong>ci<strong>de</strong> si múltiples publicadores pue<strong>de</strong>n actualizar la<br />
misma información <strong>de</strong> un mismo objeto. Pue<strong>de</strong>n existir varios canales en un mismo<br />
dominio pero sólo se quieren obtener los datos <strong>de</strong>l canal principal. Para ello, se restringiría<br />
la publicación <strong>de</strong> la información al canal principal.<br />
Tiempo <strong>de</strong> vida: se establece una propiedad para indicar el máximo intervalo <strong>de</strong> tiempo<br />
<strong>de</strong> entrega <strong>de</strong> los datos. Si se exce<strong>de</strong> ese tiempo máximo, el dato no será entregado.<br />
Prioridad <strong>de</strong> transporte: permitir enviar mensajes aplicando diferentes niveles <strong>de</strong> prioridad.<br />
En el ámbito <strong>de</strong>l proyecto Elcano, los eventos con mayor precisión <strong>de</strong> posicionamiento<br />
tendrían más prioridad sobre otros eventos enviados con un rango mayor <strong>de</strong><br />
error.<br />
<strong>La</strong>s características anteriores aportarían al mo<strong>de</strong>lo un mayor nivel <strong>de</strong> fiabilidad en cuanto<br />
a la recepción <strong>de</strong> eventos en tiempo real, incrementando y mejorando la calidad <strong>de</strong>l sistema.<br />
Otro rasgo interesante sería la creación <strong>de</strong> una herramienta <strong>de</strong> gestión más sofisticada que<br />
permitiera obtener información más <strong>de</strong>tallada <strong>de</strong> los diferentes componentes que constituyen<br />
el sistema proporcionando:
7. CONCLUSIONES Y TRABAJO FUTURO 59<br />
<strong>La</strong> eliminación <strong>de</strong> canales que no se estén utilizando, es <strong>de</strong>cir, canales en los que no<br />
existan suscriptores y estén consumiendo innecesariamente recursos <strong>de</strong>l sistema.<br />
<strong>La</strong> creación <strong>de</strong> canales según las necesida<strong>de</strong>s <strong>de</strong> los suscriptores. Pue<strong>de</strong>n existir gran<br />
cantidad <strong>de</strong> suscriptores a un canal que hayan indicado en la suscripción filtros similares.<br />
En este caso, lo más óptimo sería crear un canal filtrado <strong>de</strong>finido por los filtros<br />
más <strong>de</strong>mandados y cambiar la suscripción a este canal <strong>de</strong> todos aquellos suscriptores<br />
con las mismas necesida<strong>de</strong>s.<br />
<strong>La</strong> creación y eliminación <strong>de</strong> publicadores para tener un mayor control <strong>de</strong> la información<br />
que está circulando entre los diferentes componentes <strong>de</strong>l sistema.
ANEXOS
Casos <strong>de</strong> estudio: OpenSplice y RTI<br />
A<br />
A.1.<br />
RTI Context DDS<br />
RTI Data Distribution Service (RTI DDS) es un middleware <strong>de</strong> red para aplicaciones distribuidas<br />
en tiempo real. RTI DDS simplifica el <strong>de</strong>sarrollo, implementación y mantenimiento<br />
<strong>de</strong> aplicaciones y proporciona una distribución rápida y pre<strong>de</strong>cible <strong>de</strong> los datos en un conjunto<br />
<strong>de</strong> re<strong>de</strong>s <strong>de</strong> transporte.<br />
<strong>La</strong> clave <strong>de</strong>l éxito <strong>de</strong> este mo<strong>de</strong>lo es que las aplicaciones que utilizan este mo<strong>de</strong>lo están<br />
totalmente <strong>de</strong>sacopladas. Se emplea muy poco tiempo en diseñar la forma en las que estas<br />
aplicaciones interactúan.<br />
RTI DDS se encarga <strong>de</strong> automatizar todos los aspectos <strong>de</strong> la entrega <strong>de</strong> mensajes, sin<br />
necesidad <strong>de</strong> ninguna intervención por parte <strong>de</strong> las aplicaciones <strong>de</strong> usuario, incluyendo:<br />
Determina quién <strong>de</strong>be recibir los mensajes.<br />
Dón<strong>de</strong> se encuentran los <strong>de</strong>stinatarios <strong>de</strong> los mensajes.<br />
Qué ocurre si los mensajes no pue<strong>de</strong>n ser entregados.<br />
RTI DDS incluye las siguientes características, que han sido diseñadas para satisfacer las<br />
necesida<strong>de</strong>s <strong>de</strong> las aplicaciones <strong>de</strong> tiempo real distribuidas:<br />
Centro <strong>de</strong> datos para las comunicaciones publicador/suscriptor Simplifica la programación<br />
<strong>de</strong> las aplicaciones y garantiza que los datos lleguen a su <strong>de</strong>stino con la mínima<br />
latencia.<br />
Tipos <strong>de</strong> datos <strong>de</strong>finidos por el usuario Habilita a los usuarios para especificar el formato<br />
<strong>de</strong> la información que será enviada a cada aplicación.<br />
Mensajes fiables <strong>La</strong>s aplicaciones que se <strong>de</strong>dican a la suscripción pue<strong>de</strong>n especificar la<br />
entrega fiable <strong>de</strong> muestras.<br />
Múltiples dominios <strong>de</strong> comunicaciones Pue<strong>de</strong>n haber múltiples dominios utilizando la misma<br />
red física y cada aplicación pue<strong>de</strong> ser configurada para participar en múltiples dominios.<br />
61
A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 62<br />
Arquitectura simétrica No hay servidor centralizado ni nodos privilegiados. <strong>La</strong>s suscripciones<br />
y las publicaciones pue<strong>de</strong> ser añadidas y eliminadas dinámicamente <strong>de</strong>l sistema<br />
en cualquier momento.<br />
Frameworks <strong>de</strong> transporte RTI DDS incluye la habilidad para <strong>de</strong>finir nuevas herramientas<br />
<strong>de</strong> transporte. RTI DDS especifica un plugin <strong>de</strong> transporte UDP/IP y transporte<br />
<strong>de</strong> memoria compartida. Pue<strong>de</strong> ser configurado para trabajar sobre gran variedad <strong>de</strong><br />
mecanismos, tecnologías <strong>de</strong> re<strong>de</strong>s, etc.<br />
Soporte multilenguaje Soporta APIs para los lenguajes C, C++, C++/CLI, C# y Java.<br />
Soporte multiplataforma Incluye soporte para UNIX, sistemas <strong>de</strong> tiempo-real (INTEGRITY,<br />
VxWorks, QNX y LynxOS) y Windows (2000, 2003, CE, Vista y XP).<br />
Cumplimiento <strong>de</strong> estándar <strong>La</strong> API cumple la capa DCPS <strong>de</strong> la especificación <strong>de</strong> DDS <strong>de</strong> la<br />
OMG. El formado <strong>de</strong> los paquetes <strong>de</strong> datos que envía RTI DDS cumple con la especificación<br />
<strong>de</strong>l protocolo RTPS.<br />
Un ejemplo básico para ver el funcionamiento <strong>de</strong> un publicador y un suscriptor utilizando<br />
RTI DDS se pue<strong>de</strong> encontrar en el cdrom adjunto en el directorio src/samples/RTI/HelloWorld<br />
y a<strong>de</strong>más la prueba <strong>de</strong> integración correspondiente en el directorio test/samples.<br />
Este ejemplo no se analiza ya que los ejemplos realizados con OpenSplice especificados<br />
en el próximo capítulo son más claros para conocer la dinámica <strong>de</strong> DDS.<br />
A.2.<br />
OpenSplice DDS<br />
A.2.1. Arquitecture OpenSplice DDS<br />
OpenSplice DDS compone una arquitectura que utiliza memoria compartida para conectar<br />
no sólo todas las aplicaciones que resi<strong>de</strong>n <strong>de</strong>ntro <strong>de</strong> un nodo computacional, sino también el<br />
conjunto <strong>de</strong> servicios que ofrecen diferentes hosts 1 . Esta arquitectura garantiza la escalabilidad,<br />
flexibilidad y extensibilidad.<br />
En la memoria compartida que utiliza esta arquitectura, los datos están físicamente una<br />
vez en cada máquina y la administración proporciona a cada suscriptor una vista privada <strong>de</strong><br />
esos datos. Esto permite que una caché <strong>de</strong> datos <strong>de</strong>l suscriptor será percibida como una base<br />
<strong>de</strong> datos individual que pue<strong>de</strong> estar filtrada, encolada, etc.<br />
OpenSplice DDS pue<strong>de</strong> ser fácilmente configurable especificando los servicios necesarios<br />
que se utilizarán, así como la configuración <strong>de</strong> los servicios que persigue un acoplamiento<br />
óptimo en el dominio <strong>de</strong> aplicación (los parámetros <strong>de</strong> red, la durabilidad, niveles, etc). <strong>La</strong><br />
figura A.1 muestra la arquitectura <strong>de</strong> un nodo en OpenSplice DDS.<br />
1 Nodo conectada a la red que proporciona servicios y solicita servicios <strong>de</strong> otros.
A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 63<br />
Figura A.1: Arquitectura <strong>de</strong> un nodo <strong>de</strong> la tecnología OpenSplice DDS<br />
A.2.2. Características <strong>de</strong> OpenSplice DDS<br />
<strong>La</strong> última versión <strong>de</strong> OpenSplice DDS es la versión 6 y se caracteriza por:<br />
Múltiples arquitecturas - Proporciona opciones <strong>de</strong> <strong>de</strong>sarrollo configurables que permiten<br />
adaptarse a las características <strong>de</strong> rendimiento, escalabilidad y tolerancia a fallos que<br />
envuelven las necesida<strong>de</strong>s <strong>de</strong> un <strong>de</strong>terminado sistema, reduciendo así los costes iniciales<br />
y los costes durante el <strong>de</strong>sarrollo.<br />
Múltiples paradigmas - OpenSplice V6 ofrece una solución a<strong>de</strong>cuada al problema <strong>de</strong> interacción<br />
entre distintos mo<strong>de</strong>los <strong>de</strong> comunicación como son los mo<strong>de</strong>los publicador/suscriptor,<br />
cachés <strong>de</strong> objetos distribuidos e invocación <strong>de</strong> métodos remotos (RMI).<br />
A<strong>de</strong>más, la calidad <strong>de</strong> servicio (QoS) proporcionado por DDS pue<strong>de</strong> ser utilizada para<br />
controlar la calidad <strong>de</strong> servicio asociada con servicios individuales, así como con<br />
invocaciones específicas.<br />
Tiempo real y escalable - Máxima escalabilidad y mínimas latencias junto con eventos en<br />
tiempo real ofrecen sistemas <strong>de</strong> tiempo real a gran escala. Para ello, OpenSplice DDS<br />
proporciona dos características principales: un protocolo <strong>de</strong> red <strong>de</strong> tiempo real optimizado<br />
y escalabilidad; y opciones <strong>de</strong> <strong>de</strong>spliegue <strong>de</strong> memoria compartida para minimizar<br />
el uso <strong>de</strong> los recursos, optimizando la comunicación entre nucleos y aplicando las políticas<br />
<strong>de</strong> tráfico <strong>de</strong> red a los nodos <strong>de</strong>l sistema.<br />
Conectividad - <strong>La</strong> puerta <strong>de</strong> enlace OpenSplice proporciona soporte para unas 80 conexio-
A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 64<br />
Figura A.2: Puerta <strong>de</strong> enlace <strong>de</strong> la tecnología OpenSplice DDS<br />
nes a otras tecnologías <strong>de</strong> mensajería (por ej. JMS 2 , AMQP 3 ) y a tecnologías Web<br />
propietarias (por ej. W3C Web Services) (figura A.2).<br />
Herramienta <strong>de</strong> pruebas - OpenSplice DDS v6 proporciona una herramienta para realizar<br />
pruebas que simplifican el testeo <strong>de</strong> los sistemas distribuidos basados en DDS.<br />
Código abierto - OpenSplice v6 está disponible bajo la licencia LGPLv3 y también bajo la<br />
propia licencia <strong>de</strong> PrismTech Commercial.<br />
Cumplimiento <strong>de</strong> estándares - OpenSplice DDS es una estricta implementación <strong>de</strong>l estándar<br />
DDS <strong>de</strong> OMG. Esto garantiza la portabilidad y la interoperabilidad entre las<br />
implementaciones <strong>de</strong> DDS.<br />
A.2.3. Estudio <strong>de</strong> la comunicación <strong>de</strong> eventos OpenSplice DDS<br />
Se han realizado algunos ejemplos para conocer la dinámica <strong>de</strong> esta arquitectura. En este<br />
capítulo se muestra uno <strong>de</strong> estos ejemplos para la compresión <strong>de</strong> la dinámica <strong>de</strong> trabajo <strong>de</strong><br />
OpenSplice DDS. El IDL utilizado para el ejemplo se muestra en el listado A.1.<br />
module HelloWorldData {<br />
struct Msg<br />
{<br />
long userID;<br />
string message;<br />
};<br />
#pragma keylist Msg userID<br />
};<br />
Listado A.1: IDL utilizado para el ejemplo HelloWorld <strong>de</strong> OpenSplice DDS<br />
<strong>La</strong> implementación <strong>de</strong> un simple ejemplo es muy sencilla y se pue<strong>de</strong> interpretar fácilmente.<br />
En el listado A.2 y en el listado A.3 se pue<strong>de</strong>n ver las correspondientes implementaciones<br />
2 Java Message Service, es un API que se utiliza para el uso <strong>de</strong> colas <strong>de</strong> mensajes. Permite crear, enviar,<br />
recibir y leer mensajes<br />
3 Advanced Message Queuing Protocol es un protocolo utilizado en la capa <strong>de</strong> aplicaciones <strong>de</strong> un sistema<br />
<strong>de</strong> comunicación. Soporta orientación a mensajes, uso <strong>de</strong> colas y enrutamiento (punto-a-punto y publicaciónsuscripción)
A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 65<br />
<strong>de</strong> un suscriptor y <strong>de</strong> un publicador para el mo<strong>de</strong>lo <strong>de</strong> comunicaciones OpenSpliceDDS.<br />
En las dos implementaciones se sigue el mismo procedimiento:<br />
1. Se crea un dominio que va a contener el canal <strong>de</strong> comunicación entre publicador y<br />
suscriptor.<br />
2. Se crea el tipo <strong>de</strong>l canal. El tipo <strong>de</strong> canal viene <strong>de</strong>finido en el IDL especificado para<br />
este ejemplo (listado A.1).<br />
3. Una vez obtenido el tipo <strong>de</strong>l canal, se crea el canal correspondiente cuyo nombre tiene<br />
que ser el mismo tanto en la parte <strong>de</strong>l suscriptor como en la <strong>de</strong>l publicador.<br />
4. En cada caso, se crea el publicador <strong>de</strong>l canal y se crea el subscriptor <strong>de</strong>l canal.<br />
5. Para el publicador se crea el objeto DataWriter correspondiente y para el suscriptor<br />
se crea el objeto DataRea<strong>de</strong>r.<br />
6. Se envían eventos en el caso <strong>de</strong>l publicador y el subscriptor espera la recepción <strong>de</strong><br />
eventos.<br />
7. Finalmente, se eliminan los DataRea<strong>de</strong>r y DataWriter, el canal, el suscriptor y el<br />
publicador.<br />
#inclu<strong>de</strong> <br />
#inclu<strong>de</strong> <br />
#inclu<strong>de</strong> <br />
#inclu<strong>de</strong> "DDSEntityManager.h"<br />
#inclu<strong>de</strong> "ccpp_HelloWorldData.h"<br />
#inclu<strong>de</strong> "os.h"<br />
using namespace DDS;<br />
using namespace HelloWorldData;<br />
int main(int argc, char ∗argv[])<br />
{<br />
os_time <strong>de</strong>lay_2ms = { 0, 2000000 };<br />
os_time <strong>de</strong>lay_200ms = { 0, 200000000 };<br />
MsgSeq msgList;<br />
SampleInfoSeq infoSeq;<br />
DDSEntityManager ∗mgr = new DDSEntityManager();<br />
// create domain participant<br />
mgr−>createParticipant("HelloWorld example");<br />
//create type<br />
MsgTypeSupport_var mt = new MsgTypeSupport();<br />
mgr−>registerType(mt.in());<br />
//create Topic<br />
char topic_name[] = "HelloWorldData_Msg";<br />
mgr−>createTopic(topic_name);<br />
//create Subscriber<br />
mgr−>createSubscriber();<br />
// create DataRea<strong>de</strong>r<br />
mgr−>createRea<strong>de</strong>r();
A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 66<br />
}<br />
DataRea<strong>de</strong>r_ptr drea<strong>de</strong>r = mgr−>getRea<strong>de</strong>r();<br />
MsgDataRea<strong>de</strong>r_var HelloWorldRea<strong>de</strong>r = MsgDataRea<strong>de</strong>r::_narrow(drea<strong>de</strong>r);<br />
checkHandle(HelloWorldRea<strong>de</strong>r, "MsgDataRea<strong>de</strong>r::_narrow");<br />
cout
A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 67<br />
//create type<br />
MsgTypeSupport_var mt = new MsgTypeSupport();<br />
mgr−>registerType(mt.in());<br />
//create Topic<br />
char topic_name[] = "HelloWorldData_Msg";<br />
mgr−>createTopic(topic_name);<br />
//create Publisher<br />
mgr−>createPublisher();<br />
// create DataWriter :<br />
// If autodispose_unregistered_instances is set to true (<strong>de</strong>fault value)<br />
,<br />
// you will have to start the subscriber before the publisher<br />
bool autodispose_unregistered_instances = false;<br />
mgr−>createWriter(autodispose_unregistered_instances);<br />
// Publish Events<br />
DataWriter_ptr dwriter = mgr−>getWriter();<br />
MsgDataWriter_var HelloWorldWriter = MsgDataWriter::_narrow(dwriter);<br />
}<br />
Msg msgInstance; /∗ Example on Stack ∗/<br />
for (count=0; count < 4; count ++) {<br />
msgInstance.userID = count;<br />
msgInstance.message = CORBA::string_dup("Hello World");<br />
cout
A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 68<br />
A.2.4. Estudio <strong>de</strong>l filtrado <strong>de</strong> eventos<br />
Se realiza un estudio <strong>de</strong> la comunicación entre un subscriptor y un publicador en la tecnología<br />
OpenSplice DDS utilizando para ello un canal cuyo tipo será una estructura semejante<br />
a los eventos utilizados en el proyecto Elcano. El listado A.4 muestra el IDL <strong>de</strong>finido para<br />
ello.<br />
module EventElcanoFilter<br />
{<br />
struct Point {<br />
double x;<br />
double y;<br />
double z;<br />
};<br />
struct LocEvent<br />
{<br />
string provi<strong>de</strong>r;<br />
string msid;<br />
long time;<br />
Point point;<br />
};<br />
#pragma keylist LocEvent provi<strong>de</strong>r<br />
};<br />
Listado A.4: IDL que especifica el tipo <strong>de</strong> canal con una estructura <strong>de</strong> datos semejante a la<br />
utilizada en los eventos <strong>de</strong>l proyecto Elcano<br />
En este ejemplo se analiza el tráfico <strong>de</strong> la red cuando hay filtrado <strong>de</strong> eventos. <strong>La</strong> dinámica<br />
<strong>de</strong>l subscriptor y <strong>de</strong>l publicador son muy similares a las implementadas en el ejemplo<br />
HelloWorld antes mencionado. <strong>La</strong>s nuevas operaciones se pue<strong>de</strong>n ver en el listado A.5 don<strong>de</strong><br />
el suscriptor crea un canal filtrado (ContentFilteredTopic) indicando el filtro que se<br />
realizará en los eventos recibidos.<br />
char sTopicName[] = "MyLocEventTopic";<br />
// create subscription filter<br />
ostringstream buf;<br />
buf
A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 69<br />
Análisis <strong>de</strong>l tráfico en la herramienta Wireshark<br />
<strong>La</strong> herramienta Wireshark [Com11] ofrece un análisis <strong>de</strong>l tráfico que circula por la red<br />
(información <strong>de</strong> cada paquete, protocolos, ...). El interés <strong>de</strong> utilizar esta herramienta radica<br />
en conocer qué información es enviada en los paquetes que contiene los eventos que se<br />
envían <strong>de</strong>s<strong>de</strong> los publicadores a los suscriptores.<br />
Se ha analizado el tráfico entre un publicador y un suscriptor ejecutados en diferentes máquinas.<br />
El publicador tiene la ip 161.67.106.124 y el suscriptor tiene la ip 161.67.106.141.<br />
El suscriptor se registra al canal con el filtro WIFI, es <strong>de</strong>cir, recibirá todos los eventos cuyo<br />
proveedor sea WIFI.<br />
En la figura A.3 se pue<strong>de</strong> observar cómo en la máquina que ejecuta el suscriptor se registra<br />
indicando el nombre <strong>de</strong>l canal(LocEventTrakerExclusive), el tipo <strong>de</strong> dato al que se suscribe(LocEvent)<br />
y se indica también el nombre <strong>de</strong> dominio <strong>de</strong>l participante(EventElcanoFilterTopic<br />
example). Del mismo modo, en la otra máquina se crea el publicador.<br />
A partir <strong>de</strong> la creación <strong>de</strong>l publicador, se empiezan a mandar los eventos <strong>de</strong> localización.<br />
<strong>La</strong> figura A.4 muestra el contenido <strong>de</strong> un paquete que contiene un evento <strong>de</strong> localización.
A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 70<br />
Figura A.3: El consumidor se suscribe al canal
A. CASOS DE ESTUDIO: OPENSPLICE Y RTI 71<br />
Figura A.4: Paquete que contiene los datos <strong>de</strong> un evento <strong>de</strong> localización
Plan <strong>de</strong> pruebas<br />
B<br />
En este apéndice se especifica el plan <strong>de</strong> pruebas que se ha llevado a cabo durante el<br />
<strong>de</strong>sarrollo <strong>de</strong>l proyecto. Como se explica en la sección 4.1.2 se sigue la técnica <strong>de</strong> BDD para<br />
<strong>de</strong>scribir las pruebas.<br />
B.1.<br />
Suscripción y publicación sin filtrado<br />
El comportamiento <strong>de</strong> los publicadores y los suscriptores <strong>de</strong>be ser similar al comportamiento<br />
<strong>de</strong> los suscriptores y publicadores <strong>de</strong> los canales IceStorm.<br />
Para probar esta funcionalidad se especifican tanto pruebas positivas como pruebas negativas.<br />
De esta forma se asegura el correcto funcionamiento <strong>de</strong>l servicio IceStorm acoplado al<br />
servicio IceDDS.<br />
B.1.1. Mensaje recibido<br />
En esta prueba se comprueba que los mensajes enviados <strong>de</strong>s<strong>de</strong> un publicador son recibidos<br />
en el suscriptor <strong>de</strong>l mismo canal.<br />
Dado - un canal, un publicador <strong>de</strong>l canal y un suscriptor <strong>de</strong>l canal.<br />
Cuando - el publicador <strong>de</strong>l canal envía eventos.<br />
Entonces - el suscriptor <strong>de</strong>l canal recibe los eventos.<br />
B.1.2. Mensaje no recibido<br />
Se comprueba que los suscriptores no registrados en un canal, no reciben los eventos.<br />
Dado - un canal T1, un canal T2, un publicador <strong>de</strong>l canal T1 y un suscriptor <strong>de</strong>l canal T2.<br />
Cuando - el publicador <strong>de</strong>l canal T1 envía eventos.<br />
Entonces - el suscriptor <strong>de</strong>l canal T2 no recibe ningún evento.<br />
B.1.3.<br />
Mensaje recibido en varios suscriptores<br />
Todos los suscriptores registrados en un canal reciben los eventos que llegan al mismo.<br />
72
B. PLAN DE PRUEBAS 73<br />
Dado - un canal, un publicador <strong>de</strong>l canal y dos suscriptores al canal.<br />
Cuando - el publicador <strong>de</strong>l canal envía un evento.<br />
Entonces - los dos suscriptores <strong>de</strong>l canal reciben el evento.<br />
B.1.4. Varios publicadores en un canal<br />
Los suscriptores a un canal reciben todos los eventos que envíe cualquier publicador.<br />
Dado - un canal, dos publicadores <strong>de</strong>l canal y un suscriptor al canal.<br />
Cuando - cada publicador envía un evento al canal.<br />
Entonces - el suscriptor reciben dos eventos, uno <strong>de</strong> cada publicador <strong>de</strong>l canal.<br />
B.1.5. Varios canales y publicadores y un sólo suscriptor<br />
En esta prueba, el suscriptor se registra en dos canales, por lo tanto, <strong>de</strong>be recibir los eventos<br />
<strong>de</strong> los dos canales.<br />
Dado - un canal T1, un canal T2, un publicador <strong>de</strong>l canal T1, un publicador <strong>de</strong>l canal T2 y<br />
un suscriptor registrado al canal T1 y al canal T2.<br />
Cuando - cada publicador envía un evento al canal.<br />
Entonces - el suscriptor reciben dos eventos, uno <strong>de</strong>l publicador <strong>de</strong>l canal T1 y otro evento<br />
proce<strong>de</strong>nte <strong>de</strong>l publicador <strong>de</strong>l canal T2.<br />
B.2.<br />
Filtrado <strong>de</strong> eventos a nivel <strong>de</strong> canal<br />
El objetivo <strong>de</strong> la siguiente batería <strong>de</strong> pruebas es la comprobación <strong>de</strong> que los canales filtran<br />
los eventos cuyos valores no sean válidos para los filtros especificados a la hora <strong>de</strong> crear un<br />
canal.<br />
A<strong>de</strong>más, se realizan pruebas para validación <strong>de</strong> tipos <strong>de</strong> código que circulan por el canal.<br />
<strong>La</strong> creación <strong>de</strong> filtros conlleva a crear otro conjunto <strong>de</strong> pruebas que verifican que las funciones<br />
<strong>de</strong> comprobación <strong>de</strong> valores <strong>de</strong> las distintas clases <strong>de</strong> filtros se comportan correctamente.<br />
B.2.1. Comprobación <strong>de</strong> valores en los filtros<br />
Estas pruebas comprueban que ciertos valores pertenecen a los valores que compren<strong>de</strong>n<br />
los diferentes tipos <strong>de</strong> filtro (ver apéndice D).
B. PLAN DE PRUEBAS 74<br />
B.2.2. Tipos <strong>de</strong> los datos que circulan por el canal<br />
Se hacen pruebas tanto negativas como positivas corroborando que haya una correspon<strong>de</strong>ncia<br />
entre los filtros especificados y el tipo <strong>de</strong> datos especificado (TypeCo<strong>de</strong>).<br />
B.2.3. Filtrado en el canal con un suscriptor<br />
Se comprueba que un suscriptor registrado en un canal que contiene un filtrado <strong>de</strong> eventos<br />
recibe los eventos correctos.<br />
Dado - un canal filtrado, un publicador <strong>de</strong>l canal y un suscriptor registrado al canal.<br />
Cuando - el publicador envía varios eventos al canal.<br />
Entonces - el suscriptor recibe los eventos.<br />
B.2.4. Filtrado en el canal con varios suscriptores<br />
Se comprueba que varios suscriptores registrados en un canal que contiene un filtrado <strong>de</strong><br />
eventos reciben los eventos correctos. En el sistema se producirá un warning.<br />
Dado - un canal filtrado, un publicador <strong>de</strong>l canal y dos suscriptores registrados al canal.<br />
Cuando - el publicador envía varios eventos al canal.<br />
Entonces - los suscriptores reciben los eventos enviados al canal.<br />
B.2.5. Se envía un dato inválido a un canal con filtro<br />
El publicador <strong>de</strong> un canal con filtro envía un dato que <strong>de</strong>be filtrarlo el canal. El sistema<br />
notificará este hecho con un warning avisando <strong>de</strong> que el dato enviado es inválido.<br />
Dado - un canal filtrado, un publicador <strong>de</strong>l canal y un suscriptor.<br />
Cuando - el publicador envía un evento no válido al canal.<br />
Entonces - el suscriptor no recibe ningún evento, ya que aunque el publicador lo envía, el<br />
canal lo filtra.<br />
B.2.6. Se indican varios filtros<br />
Todas las pruebas anteriores, se realizan solamente indicando un filtro. En esta prueba,<br />
se comprueba el éxito en la recepción <strong>de</strong> un evento cuando se crea un canal con varios<br />
filtros.<br />
Dado - un canal filtrado, un publicador <strong>de</strong>l canal y un suscriptor.<br />
Cuando - el publicador envía un evento al canal.<br />
Entonces - el suscriptor recibe el evento.
B. PLAN DE PRUEBAS 75<br />
B.3.<br />
Filtrado <strong>de</strong> eventos a nivel <strong>de</strong> publicador<br />
En este capítulo se realizan las pruebas correspondiente a los publicadores filtrados. A<strong>de</strong>más,<br />
se hacen pruebas para validar la expresión en los filtros, es <strong>de</strong>cir, que la ca<strong>de</strong>na contenga<br />
un nombre <strong>de</strong> variable, un operador tal y como se <strong>de</strong>finen en la tabla 5.1 y uno o varios valores,<br />
según el filtro. Estas pruebas no se <strong>de</strong>finen en <strong>de</strong>talle en este apéndice <strong>de</strong>bido a la<br />
igualdad <strong>de</strong> los casos <strong>de</strong> prueba. <strong>La</strong>s pruebas sobre filtros se pue<strong>de</strong>n encontrar en el cdrom<br />
adjunto a la documentación en el directorio test/unit/filters/.<br />
B.3.1. Correcta <strong>de</strong>finición <strong>de</strong> las expresiones en los filtros<br />
<strong>La</strong>s pruebas comprueban todas las posibles expresiones erróneas y aseguran que se va a<br />
producir una excepción.<br />
B.3.2. Evento recibido con publicador filtrado<br />
Se comprueba la correcta recepción <strong>de</strong> los eventos que manda un publicador que tiene<br />
filtros asociados a un canal.<br />
Dado - un canal, un publicador con filtro y un suscriptor al canal.<br />
Cuando - el publicador envía varios eventos al canal.<br />
Entonces - el subscriptor al canal recibe todos los eventos.<br />
B.3.3. Evento recibido con publicador filtrado en un canal filtrado<br />
Se comprueba la correcta recepción <strong>de</strong> los eventos que manda un publicador que tiene<br />
filtros asociados a un canal que tiene sus propios filtros.<br />
Dado - un canal filtrado, un publicador con filtro y un suscriptor al canal.<br />
Cuando - el publicador envía varios eventos válidos al canal.<br />
Entonces - el subscriptor al canal recibe todos los eventos.<br />
B.3.4. Se envía un dato inválido a un canal<br />
El publicador <strong>de</strong> un canal con filtro envía un dato que no correspon<strong>de</strong> con el filtro asociado<br />
a este publicador. El sistema notificará este hecho con un warning avisando <strong>de</strong> que el dato<br />
enviado es inválido.<br />
Dado - un canal, un publicador con filtro y un suscriptor al canal.<br />
Cuando - el publicador envía un evento no válido.<br />
Entonces - el suscriptor no recibe ningún evento, ya que aunque el publicador lo envía,<br />
también lo filtra.
B. PLAN DE PRUEBAS 76<br />
B.3.5. Se envía un dato inválido a un canal con filtros<br />
El publicador <strong>de</strong> un canal con filtro envía un dato que no correspon<strong>de</strong> con el filtro asociado<br />
a este publicador, pero que es válido en el canal. El sistema notificará este hecho con un<br />
warning avisando <strong>de</strong> que el dato enviado es inválido.<br />
Dado - un canal, un publicador con filtro y un suscriptor al canal.<br />
Cuando - el publicador envía un evento no válido en este pero válido en el canal.<br />
Entonces - el suscriptor no recibe ningún evento.<br />
B.3.6. Un publicador con filtros y otro sin filtros<br />
Un canal tiene dos publicadores. Uno con <strong>de</strong>terminados filtros y otro sin filtros. Un subscriptor<br />
al canal recibe todos los eventos, es <strong>de</strong>cir, todos los eventos enviados por el publicador<br />
que filtra y todos los eventos enviados por el publicador que no filtra.<br />
Dado - un canal, un publicador con filtro, un publicador sin filtro y un suscriptor al canal.<br />
Cuando - el publicador sin filtro envía un evento y el publicador que filtra envía otro evento.<br />
Entonces - el suscriptor recibe todos los eventos.<br />
B.3.7. Un publicador con filtros y otro sin filtros en un canal con filtros<br />
Esta prueba es similar a la anterior pero creando un canal con filtros.<br />
Dado - un canal con filtros, un publicador con filtro, un publicador sin filtro y un suscriptor<br />
al canal.<br />
Cuando - el publicador sin filtro envía un evento y el publicador que filtra envía otro evento.<br />
Entonces - el suscriptor recibe todos los eventos <strong>de</strong>terminando también el filtro que realiza<br />
el propio canal.<br />
B.3.8. Se indican varios filtros<br />
En las pruebas anteriores los filtros están compuestos por solo un miembro, es <strong>de</strong>cir, se<br />
indica solo un filtro. En esta prueba se indican más <strong>de</strong> un filtro.<br />
Dado - un canal filtrado, un publicador con filtros y un suscriptor.<br />
Cuando - el publicador envía un evento al canal.<br />
Entonces - el suscriptor recibe el evento.
B. PLAN DE PRUEBAS 77<br />
B.4.<br />
Filtrado <strong>de</strong> eventos a nivel <strong>de</strong> suscripción<br />
El conjunto <strong>de</strong> pruebas que se especifican a continuación componen los posibles casos que<br />
se pue<strong>de</strong>n dar al realizar una suscripción indicando <strong>de</strong>terminados filtros.<br />
B.4.1. Subscripción con filtro en un canal<br />
El suscriptor indica su intención <strong>de</strong> registrarse indicando unos <strong>de</strong>terminados filtros y se<br />
comprueba que, <strong>de</strong> los eventos que se publican, sólo le son proporcionados los compatibles<br />
con los filtros especificados.<br />
Dado - un canal, un publicador <strong>de</strong>l canal y un suscriptor al canal indicando filtros específicos.<br />
Cuando - el publicador envía varios eventos.<br />
Entonces - el suscriptor sólo recibe aquellos eventos que pertenecen a los filtros con los que<br />
se ha suscrito.<br />
B.4.2. Varias suscripciones (con y sin filtro) a un canal<br />
Esta prueba es similar a la anterior pero se utilizan dos suscriptores. Se garantiza el funcionamiento<br />
con dos suscriptores, uno realizando la suscripción normal y otro realizando la<br />
suscripción indicando filtros.<br />
Dado - un canal, un publicador <strong>de</strong>l canal, un suscriptor 1 al canal y otro suscriptor 2 al canal<br />
indicando filtros específicos.<br />
Cuando - el publicador envía varios eventos.<br />
Entonces - el suscriptor 2 sólo recibe aquellos eventos que pertenecen a los filtros con los<br />
que se ha suscrito, mientras que el suscriptor 1 recibe todos los eventos.<br />
B.4.3. Subscripción con filtro en un canal con su propio filtro<br />
<strong>La</strong> peculiaridad <strong>de</strong> esta prueba resi<strong>de</strong> en la existencia <strong>de</strong> un canal que posee un filtrado.<br />
Un suscriptor pue<strong>de</strong> registrarse a un canal y algunos <strong>de</strong> los filtros indicados en la suscripción<br />
no correspon<strong>de</strong>rse con los filtros <strong>de</strong>l canal. En este caso, los eventos <strong>de</strong> localización que se<br />
notifican en el suscriptor serán los eventos que sean válidos tanto en el canal como en el<br />
suscriptor.<br />
Dado - un canal con filtros, un publicador <strong>de</strong>l canal y un suscriptor al canal indicando filtros<br />
específicos.<br />
Cuando - el publicador envía varios eventos.<br />
Entonces - el suscriptor sólo recibe aquellos eventos que pertenecen a los filtros con los que<br />
se ha suscrito y teniendo en cuenta los filtros <strong>de</strong>l canal.
B. PLAN DE PRUEBAS 78<br />
B.4.4. Varias suscripciones a un canal con un publicador general<br />
Como en la prueba anterior, se comprueba que los eventos sea reportados <strong>de</strong> manera correcta<br />
y a<strong>de</strong>más, esta prueba asegura un correcto funcionamiento cuando hay más <strong>de</strong> un<br />
suscriptor.<br />
Dado - un canal con filtros, un publicador <strong>de</strong>l canal, un suscriptor 1 al canal y otro suscriptor<br />
2 al canal indicando sus propios filtros.<br />
Cuando - el publicador envía varios eventos.<br />
Entonces - el suscriptor 2 sólo recibe aquellos eventos que pertenecen a los filtros con los<br />
que se ha suscrito y sin olvidarse <strong>de</strong> los filtros propios <strong>de</strong>l canal, mientras que el<br />
suscriptor 1 recibe todos los eventos que pue<strong>de</strong> manejar el canal.<br />
B.4.5. Suscripción con filtro a un canal con publicador, ambos con filtros<br />
Se comprueba y valida la suscripción con filtros cuando existe un canal con filtrado y un<br />
publicador a ese canal con filtrado en la publicación.<br />
Dado - un canal con filtros, un publicador <strong>de</strong>l canal con filtrado, un suscriptor al canal<br />
indicando sus propios filtros.<br />
Cuando - el publicador envía varios eventos.<br />
Entonces - el suscriptor sólo recibe aquellos eventos que pertenecen a los filtros con los que<br />
se ha suscrito y teniendo en cuenta los filtros <strong>de</strong>l canal a<strong>de</strong>más <strong>de</strong>l filtrado que realiza<br />
el publicador.<br />
B.4.6. Suscripción con filtro a un canal con publicador, ambos con filtros<br />
Esta prueba es semejante a las pruebas anteriores. Se <strong>de</strong>muestra la misma circunstancia<br />
con más <strong>de</strong> un suscriptor.<br />
Dado - un canal con filtro, un publicador <strong>de</strong>l canal con filtrado, un suscriptor 1 al canal y un<br />
suscriptor 2 al canal indicando sus propios filtros.<br />
Cuando - el publicador envía varios eventos.<br />
Entonces - el suscriptor 2 sólo recibe aquellos eventos que pertenecen a los filtros con los<br />
que se ha suscrito teniendo en cuenta los filtros propios <strong>de</strong>l canal y el filtrado en el publicador,<br />
mientras que el suscriptor 1 recibe todos los eventos que envía el publicador.
B. PLAN DE PRUEBAS 79<br />
B.4.7. Se indican varios filtros<br />
En esta prueba se verifica que el funcionamiento es igual indicando varios filtros en la<br />
suscripción, ya que en las pruebas anteriores se indica solamente un filtro.<br />
Dado - un canal, un publicador y un suscriptor con filtros.<br />
Cuando - el publicador envía eventos al canal.<br />
Entonces - el suscriptor recibe los eventos que concuerdan con los filtros especificados.<br />
B.4.8. Eliminar la suscripción a un canal<br />
Se comprueba que un suscriptor no recibe eventos <strong>de</strong>spués <strong>de</strong> que haya eliminado la suscripción<br />
a un canal.<br />
Dado - un canal, un publicador y un suscriptor con filtros.<br />
Cuando - el publicador envía un evento al canal.<br />
Entonces - el suscriptor recibe el evento que concuerda con los filtros especificados.<br />
Después cuando - el suscriptor cancela la suscripción al canal y el publicador envía otro<br />
evento.<br />
Entonces - el suscriptor no recibe ningún evento más.<br />
B.4.9. Fe<strong>de</strong>ración <strong>de</strong> canales<br />
El conjunto <strong>de</strong> pruebas <strong>de</strong>scritas en esta sección correspon<strong>de</strong>n a la fe<strong>de</strong>ración <strong>de</strong> canales<br />
con la peculiaridad <strong>de</strong> indicar filtros que limiten la propagación <strong>de</strong> eventos <strong>de</strong> unos canales<br />
a otros.<br />
B.4.10. Fe<strong>de</strong>ración entre canales filtrados<br />
En esta prueba <strong>de</strong>terminada se verifica que un evento publicado en un canal se propaga<br />
a otro canal enlazado a este primero, ya que el evento es válido para los filtros <strong>de</strong> los<br />
canales.<br />
Dado - un canal 1 con un filtro <strong>de</strong> rango (1, 5), un canal 2 que solo acepta eventos cuya ’x’<br />
sea igual a 2, un publicador <strong>de</strong>l canal 1 y un suscriptor al canal 2.<br />
Cuando - el canal 2 realiza un enlace al canal 1, el suscriptor se registra en el canal 2 y el<br />
publicador <strong>de</strong>l canal 1 envía un evento cuya ’x’ es igual a 2.<br />
Entonces - el suscriptor recibe el evento <strong>de</strong>s<strong>de</strong> el canal 1.<br />
B.4.11. Fe<strong>de</strong>ración entre un canal con filtro y un canal sin filtro<br />
Un canal pue<strong>de</strong> recibir todo tipo <strong>de</strong> eventos, pero <strong>de</strong>sea que <strong>de</strong> otro canal sólo le lleguen<br />
ciertos valores.
B. PLAN DE PRUEBAS 80<br />
Dado - un canal 1 con un filtro <strong>de</strong> rango (1, 5), un canal 2 sin filtro, un publicador <strong>de</strong>l canal<br />
1, un suscriptor al canal 1 y un suscriptor al canal 2.<br />
Cuando - el canal 2 realiza un enlace al canal 1 limitando la propagación a eventos cuyos<br />
valores <strong>de</strong> ’x’ estén en un rango (2, 4) y el publicador <strong>de</strong>l canal 1 envía varios eventos.<br />
Entonces - el suscriptor <strong>de</strong>l canal 1 recibe todos los eventos mientras que el suscriptor <strong>de</strong>l<br />
canal 2 sólo recibe aquellos cuyos valores <strong>de</strong> ’x’ están en un rango (2, 4).<br />
B.4.12. Fe<strong>de</strong>ración con suscriptores con filtro y sin filtro<br />
Se prueba la fe<strong>de</strong>ración teniendo suscriptores diferentes, uno con filtro y otro sin filtro.<br />
Dado - un canal 1 y un canal 2, un publicador <strong>de</strong>l canal 1, un suscriptor al canal 2 con filtro<br />
y otro suscriptor al canal 2 con filtro.<br />
Cuando - el canal 2 realiza un enlace al canal 1 limitando la propagación a eventos cuyos<br />
valores <strong>de</strong> ’x’ estén en un rango (2, 4) y el publicador <strong>de</strong>l canal 1 envía varios eventos.<br />
Entonces - el suscriptor sin filtro recibe todos los eventos y el otro suscriptor sólo recibe los<br />
eventos cuyos valores <strong>de</strong> ’x’ sean mayores <strong>de</strong> 2.<br />
B.4.13. Eventos no válidos para el enlace especificado<br />
En esta prueba se muestra como se publican eventos en un canal que no se propagan a<br />
otros canales enlazados <strong>de</strong>bido a los filtros indicados.<br />
Dado - un canal 1 y un canal 2, un publicador <strong>de</strong>l canal 1, un suscriptor al canal 1 y otro<br />
suscriptor al canal 2.<br />
Cuando - el canal 2 realiza un enlace al canal 1 limitando la propagación a eventos cuyos<br />
valores <strong>de</strong> ’x’ sean igual a 8 y el publicador <strong>de</strong>l canal 1 envía un evento cuyo valor <strong>de</strong><br />
la ’x’ es distinto <strong>de</strong> 8.<br />
Entonces - el suscriptor <strong>de</strong>l canal 1 recibe todos los eventos y el suscriptor <strong>de</strong>l canal 2 no<br />
recibe ningún evento.<br />
B.4.14. Eliminar el enlace entre canales<br />
En esta prueba se comprueba que <strong>de</strong>spués <strong>de</strong> eliminar el enlace entre canales, no se siguen<br />
propagando los eventos.<br />
Dado - un canal 1 con un filtro <strong>de</strong> rango (1, 5), un canal 2 que solo acepta eventos cuya ’x’<br />
sea igual a 2, un publicador <strong>de</strong>l canal 1 y un suscriptor al canal 2.<br />
Cuando - el canal 2 realiza un enlace al canal 1, el suscriptor se registra en el canal 2 y el<br />
publicador <strong>de</strong>l canal 1 envía un evento cuya ’x’ es igual a 2.<br />
Entonces - el suscriptor recibe el evento <strong>de</strong>s<strong>de</strong> el canal 1.
B. PLAN DE PRUEBAS 81<br />
Después cuando - el canal 2 elimina el enlace al canal 2 y el publicador envía otro evento.<br />
Entonces - el suscriptor <strong>de</strong>l canal 2 no reciben el nuevo evento.<br />
B.5.<br />
Modificación <strong>de</strong>l filtro en un suscriptor<br />
En las siguientes pruebas se validará el proceso para que un suscriptor registrado en un<br />
canal y con un filtro <strong>de</strong>terminado pueda cambiar este por otro diferente.<br />
B.5.1. Cambio <strong>de</strong> filtro y recepción <strong>de</strong> eventos<br />
Se reciben los eventos antes y <strong>de</strong>spués <strong>de</strong>l cambio <strong>de</strong> filtro, ya que los valores <strong>de</strong> los eventos<br />
enviados están <strong>de</strong>ntro <strong>de</strong> los filtros especificados, tanto antes como <strong>de</strong>spués <strong>de</strong>l filtro.<br />
Dado - un canal 1, un publicador <strong>de</strong>l canal 1 y un suscriptor con un <strong>de</strong>terminado filtro.<br />
Cuando - el publicador envía eventos.<br />
Entonces - el subscriptor recibe los eventos.<br />
Después cuando - el subscriptor cambia el filtro con el que se suscribe al canal y el publicador<br />
envía un nuevo evento.<br />
Entonces - el suscriptor recibe el nuevo evento ya que también es válido <strong>de</strong>ntro <strong>de</strong> los filtros<br />
especificados.<br />
B.5.2. Cambio <strong>de</strong> filtro y no recepción <strong>de</strong> eventos<br />
El suscriptor cambia el filtro y no recibe el evento ya que el valor <strong>de</strong>l mismo no es válido<br />
para el filtro especificado.<br />
Dado - un canal 1, un publicador <strong>de</strong>l canal 1 y un suscriptor con un <strong>de</strong>terminado filtro.<br />
Cuando - el publicador envía eventos.<br />
Entonces - el subscriptor recibe los eventos.<br />
Después cuando - el subscriptor cambia el filtro con el que se suscribe al canal y el publicador<br />
envía un nuevo evento.<br />
Entonces - el suscriptor no recibe el nuevo evento ya que el valor <strong>de</strong>l mismo no es correcto<br />
<strong>de</strong>ntro <strong>de</strong> los filtros especificados.<br />
B.6.<br />
Pruebas <strong>de</strong> integración<br />
Por último, se realiza una prueba <strong>de</strong> integración en las que están envueltos todos los tipos<br />
<strong>de</strong> filtrado, así como la fe<strong>de</strong>ración <strong>de</strong> canales filtrados. En la figura B.1 se muestra el esquema<br />
<strong>de</strong> la prueba <strong>de</strong> integración realizada.
B. PLAN DE PRUEBAS 82<br />
Figura B.1: Escenario para la prueba <strong>de</strong> integración <strong>de</strong> IceDDS<br />
Para esta prueba se tiene los siguientes componentes:<br />
Un canal general.<br />
Un canal filtrado.<br />
Otro canal filtrado enlazado al canal general (fe<strong>de</strong>ración).<br />
Un publicador general que envía eventos a los dos primeros canales.<br />
Un publicador filtrado que envía eventos a los dos primeros canales.<br />
Un suscriptor general suscrito a los dos primeros canales.<br />
Un suscriptor filtrado suscrito a los dos primeros canales.<br />
Un suscriptor <strong>de</strong>l canal fe<strong>de</strong>rado.<br />
En esta prueba, se comprueban la correcta recepción <strong>de</strong> los eventos enviados, así como la<br />
correcta propagación <strong>de</strong> los mismos.
Slices<br />
C<br />
C.1.<br />
Eventos <strong>de</strong> localización <strong>de</strong>l proyecto Elcano<br />
#ifn<strong>de</strong>f SHAPE_ICE<br />
#<strong>de</strong>fine SHAPE_ICE<br />
#inclu<strong>de</strong> <br />
module MLP {<br />
struct Coord {<br />
double x;<br />
double y;<br />
double z;<br />
};<br />
sequence CoordSeq;<br />
class Shape extends P::T {<br />
};<br />
class Point extends Shape {<br />
Coord center;<br />
};<br />
sequence PointSeq;<br />
class LineString extends Shape {<br />
["uml:multi:2..n"] CoordSeq points;<br />
};<br />
sequence LineStringSeq;<br />
class Box extends Shape {<br />
Coord topLeft;<br />
Coord bottomRight;<br />
};<br />
class LinearRing extends Shape {<br />
["uml:multi:3..n"] CoordSeq points;<br />
};<br />
sequence LinearRingSeq;<br />
class PolygonBase extends Shape {<br />
};<br />
83
C. SLICES 84<br />
};<br />
sequence PolygonBaseSeq;<br />
class Polygon extends PolygonBase {<br />
LinearRing outerBoundaryIs;<br />
["uml:multi:0..n"] LinearRingSeq innerBoundaryIs;<br />
};<br />
class CircularArcArea extends PolygonBase {<br />
Coord center;<br />
double inRadius;<br />
double outRadius;<br />
double startAngle;<br />
double stopAngle;<br />
};<br />
class CircularArea extends PolygonBase {<br />
Coord center;<br />
double radius;<br />
};<br />
class EllipticalArea extends PolygonBase {<br />
Coord center;<br />
double angle;<br />
double semiMinor;<br />
double semiMajor;<br />
};<br />
class MultiLineString extends Shape {<br />
["uml:multi:1..n"] LineStringSeq lines;<br />
};<br />
class MultiPoint extends Shape {<br />
["uml:multi:1..n"] PointSeq points;<br />
};<br />
class MultiPolygon extends Shape {<br />
["uml:multi:1..n"] PolygonBaseSeq polygons;<br />
};<br />
#endif<br />
Listado C.1: Posibles eventos <strong>de</strong> localización <strong>de</strong>l proyecto Elcano
Tipos <strong>de</strong> filtros<br />
D<br />
Los filtros se indican en un secuencia <strong>de</strong> ca<strong>de</strong>nas, que internamente son transformadas en<br />
instancias <strong>de</strong> las siguientes clases. Cada clase contiene un método para comprobar que un<br />
cierto valor es correcto en el filtro.<br />
D.1.<br />
EventFilter<br />
Si en la ca<strong>de</strong>na don<strong>de</strong> se indica el filtro, el operador <strong>de</strong>finido es “==”, el objeto correspondiente<br />
será una instancia a la clase EventFilter. <strong>La</strong> utilización <strong>de</strong> este filtro indicará que<br />
los valores en una cierta coor<strong>de</strong>nada serán iguales a un <strong>de</strong>terminado valor.<br />
class EventFilter(object):<br />
<strong>de</strong>f __init__(self, name, num):<br />
self.field_name = name<br />
self.num = num<br />
<strong>de</strong>f match(self, value):<br />
return value == self.num<br />
<strong>de</strong>f equal(self, filter_):<br />
return ((type(filter_)==type(self))<br />
and (filter_.field_name == self.field_name)<br />
and (filter_.num == self.num))<br />
Listado D.1: Clase EventFilter<br />
D.2.<br />
EventFilterRange<br />
Si el operador especificado en la ca<strong>de</strong>na <strong>de</strong>l filtro es “in range”, se creará una instancia <strong>de</strong><br />
la clase EventFilterRange. Esta clase representa a los valores <strong>de</strong> una <strong>de</strong>terminada coor<strong>de</strong>nada<br />
que pertenecen al rango entre dos valores.<br />
class EventFilterRange(object):<br />
<strong>de</strong>f __init__(self, name, n, m):<br />
self.field_name = name<br />
self.valueLow = n<br />
self.valueHigh = m<br />
<strong>de</strong>f match(self, low, high=None):<br />
85
D. TIPOS DE FILTROS 86<br />
if high:<br />
return ((low in range(self.valueLow, self.valueHigh))<br />
and (high in range(self.valueLow, self.valueHigh))<br />
and (low >= self.valueLow) and (high= self.valueLow) and (low < self.valueHigh)<br />
<strong>de</strong>f equal(self, filter_):<br />
return ((type(filter_)==type(self))<br />
and (filter_.field_name == self.field_name)<br />
and (filter_.valueLow == self.valueLow)<br />
and (filter_.valueHigh == self.valueHigh))<br />
Listado D.2: Clase EventFilterRange<br />
D.3.<br />
EventFilterOver<br />
Se crea la clase EventFilterOver cuando el operador <strong>de</strong>finido en la ca<strong>de</strong>na <strong>de</strong>l filtro es “>”.<br />
Esta clase se emplea para aquellos datos que son mayores a un valor.<br />
class EventFilterOver(object):<br />
<strong>de</strong>f __init__(self, name, num):<br />
self.field_name = name<br />
self.num = num<br />
<strong>de</strong>f match(self, value):<br />
return not(value
D. TIPOS DE FILTROS 87<br />
and (filter_.num == self.num))<br />
Listado D.4: Clase EventFilterBelow<br />
D.5.<br />
Función eval<br />
<strong>La</strong> función eval <strong>de</strong> python parsea y evalua una expression. Por ejemplo:<br />
>>>> x = 3<br />
>>>> eval(’x > 1’)<br />
True<br />
Esta función es una gran herramienta que ofrece la posibilidad <strong>de</strong> indicar gran cantidad <strong>de</strong><br />
filtros sin la necesidad <strong>de</strong> realizar clases <strong>de</strong> objetos <strong>de</strong> manera interna para po<strong>de</strong>r hacer las<br />
comprobaciones <strong>de</strong> los filtros.<br />
De esta manera, se podría expresar un filtro <strong>de</strong> la forma:<br />
expression = ’x > 3 and (x in range(9,10)) and (y not in range (4,8))’<br />
En las tablas D.1 y D.2 se muestran los operadores lógicos y los operadores comparativos<br />
que pue<strong>de</strong>n utilizarse para especificar un conjunto <strong>de</strong> filtros.<br />
Operador<br />
and<br />
or<br />
not<br />
Descripción<br />
Conjunción<br />
Disyunción<br />
Negación<br />
Cuadro D.1: Operadores lógicos para expresar un conjunto <strong>de</strong> filtros<br />
Operador<br />
Descripción<br />
== Igual<br />
!= Distinto<br />
> Mayor que<br />
< Menor que<br />
>= Mayor o igual que<br />
D. TIPOS DE FILTROS 88<br />
<strong>de</strong> la creación <strong>de</strong> las clases que representan los diferentes filtros a evaluar anteriormente<br />
mencionadas.
Estudio IceStorm<br />
E<br />
Durante la fase <strong>de</strong>l proyecto en la cual se realiza un aprendizaje <strong>de</strong>l middleware ZeroC Ice<br />
y en particular <strong>de</strong>l servicio IceStorm, se realizó una comunicación entre un subscriptor y un<br />
publicador pero con la particularidad <strong>de</strong> que el sirviente sea <strong>de</strong> un <strong>de</strong>terminado tipo.<br />
Esto asegura que los suscriptores serán <strong>de</strong> un tipo <strong>de</strong>terminado, por lo que la información<br />
que maneja el canal pue<strong>de</strong> ser manipulada atendiendo a dicho tipo.<br />
<strong>La</strong> aplicación <strong>de</strong> este comportamiento al mo<strong>de</strong>lo <strong>de</strong> comunicaciones <strong>de</strong>sarrollado en este<br />
proyecto conllevaría a asegurar los tipos <strong>de</strong> datos que esperan los suscriptores, así como los<br />
datos que envían los publicadores. Por lo tanto, no sería necesario comunicar al canal el tipo<br />
<strong>de</strong> datos que manejará.<br />
E.1.<br />
Implementación<br />
Para conseguir este comportamiento se cuenta con un componente que actúa como intermediario<br />
(Delegate) entre los suscriptores/publicadores y el servicio IceStorm. Este componente<br />
es el que garantiza que los suscriptores serán <strong>de</strong> un tipo específico. En el listado E.1<br />
se muestra las interfaces que entran en juego en este sistema. <strong>La</strong> interfaz Listener es el sirviente<br />
y la interfaz ASDA es la que implementa el componente que actúa <strong>de</strong> intermediario.<br />
module ASD {<br />
interface Listener {<br />
void adv(string name);<br />
};<br />
interface ASDA {<br />
void addListener(ASD::Listener∗ listener);<br />
Listener∗ getPublisher();<br />
};<br />
};<br />
Listado E.1: Interfaces utilizadas para establecer un <strong>de</strong>terminado tipo <strong>de</strong> suscriptor)<br />
En el listado E.2 se muestra la implementación <strong>de</strong> la interfaz ASDA y la clase Delegate.<br />
Aquí, se crea el canal que será el que establezca la comunicación entre publicadores<br />
y suscriptores. <strong>La</strong> operación addListener se encarga <strong>de</strong> realizar la suscripción al canal<br />
89
E. ESTUDIO IceStorm 90<br />
IceStorm y getPublisher <strong>de</strong>vuelve el publicador <strong>de</strong>l canal <strong>de</strong> <strong>de</strong>terminado tipo. Como<br />
se pue<strong>de</strong> observar en el SLICE <strong>de</strong>finido en E.1, el parámetro listener tiene que ser <strong>de</strong>l tipo<br />
ASD::Listener, <strong>de</strong> esta manera se asegura que el objeto a suscribir es <strong>de</strong>l tipo <strong>de</strong>seado.<br />
import sys, Ice, IceStorm<br />
Ice.loadSlice(’ASDF.ice’)<br />
import ASD<br />
class ASDAI(ASD.ASDA):<br />
<strong>de</strong>f __init__(self, topic_mgr):<br />
try:<br />
self.topic = topic_mgr.create("ASDATopic")<br />
print "create ASDATopic"<br />
except IceStorm.TopicExists, e:<br />
print "topic already created"<br />
self.topic = topic_mgr.retrieve("ASDATopic")<br />
<strong>de</strong>f addListener(self, listener, current=None):<br />
qos = {}<br />
self.topic.subscribe(qos, listener)<br />
<strong>de</strong>f getPublisher(self, current=None):<br />
pub = self.topic.getPublisher()<br />
return ASD.ListenerPrx.uncheckedCast(pub)<br />
class Delegate(Ice.Application):<br />
<strong>de</strong>f get_topic_manager(self):<br />
properties = self.communicator().getProperties()<br />
prop_key = "IceStormAdmin.TopicManager.Default"<br />
strproxy = properties.getProperty(prop_key)<br />
if not strproxy:<br />
print "property", prop_key, "not set"<br />
return 0<br />
print "Using IceStorm in ’ %s’"<br />
% strproxy<br />
base = self.communicator().stringToProxy(strproxy)<br />
return IceStorm.TopicManagerPrx.checkedCast(base)<br />
<strong>de</strong>f run(self, argv):<br />
servant = ASDAI(self.get_topic_manager())<br />
ic = self.communicator()<br />
adapter = ic.createObjectAdapterWithEndpoints("Adapter", "tcp −p<br />
3000")<br />
proxy = adapter.add(servant, ic.stringToI<strong>de</strong>ntity("ASDA"))<br />
print proxy<br />
adapter.activate()<br />
ic.waitForShutdown()<br />
return 0<br />
sys.exit(Delegate().main(sys.argv))<br />
Listado E.2: Canal encargado <strong>de</strong> la comunicación con los servicios IceStorm
E. ESTUDIO IceStorm 91<br />
En las implementaciones <strong>de</strong>l suscriptor y <strong>de</strong>l publicador (listados E.3 y E.4) se pue<strong>de</strong> ver<br />
el uso <strong>de</strong> Delegate como el canal <strong>de</strong> comunicación entre los publicadores y los suscriptores.<br />
class ListenerI(ASD.Listener):<br />
<strong>de</strong>f adv(self, s, current=None):<br />
print "Hola"<br />
class Subscriber(Ice.Application):<br />
<strong>de</strong>f run(self, argv):<br />
servant = ListenerI()<br />
ic = self.communicator()<br />
adapter = ic.createObjectAdapter("Listener.Subscriber")<br />
proxy = adapter.addWithUUID(servant)<br />
base = self.communicator().stringToProxy(argv[1])<br />
<strong>de</strong>legate = ASD.ASDAPrx.checkedCast(base)<br />
print "::", <strong>de</strong>legate<br />
listener = ASD.ListenerPrx.uncheckedCast(proxy)<br />
<strong>de</strong>legate.addListener(listener)<br />
print ’SUBSCRIBED!!’<br />
print "Waiting events..."<br />
adapter.activate()<br />
ic.waitForShutdown()<br />
return 0<br />
sys.exit(Subscriber().main(sys.argv))<br />
Listado E.3: Implementación <strong>de</strong> un suscriptor para el canal <strong>de</strong>legado<br />
class Publisher(Ice.Application):<br />
<strong>de</strong>f run(self, argv):<br />
base = self.communicator().stringToProxy(argv[1])<br />
<strong>de</strong>legate = ASD.ASDAPrx.checkedCast(base)<br />
print base<br />
publisher = <strong>de</strong>legate.getPublisher()<br />
prx = ASD.ListenerPrx.uncheckedCast(publisher)<br />
print "Publishing..."<br />
for i in range(5):<br />
prx.adv("Hello!!")<br />
return 0<br />
sys.exit(Publisher().main(sys.argv))<br />
Listado E.4: Implementación <strong>de</strong> un publicador para el canal <strong>de</strong>legado
Manual <strong>de</strong> usuario<br />
F<br />
Para que un usuario pueda probar las funcionalida<strong>de</strong>s que ofrece el mo<strong>de</strong>lo <strong>de</strong> comunicaciones<br />
IceDDS se <strong>de</strong>sarrolló una aplicación con Android 2.3 que permite efectuar suscripciones<br />
con filtro y sin filtro y visualizar los eventos <strong>de</strong> localización que envían los publicadores,<br />
a<strong>de</strong>más permite crear nuevos canales para aquellos datos que no están reflejados en ningún<br />
otro canal existente.<br />
A continuación se <strong>de</strong>scribe las distintas opciones que maneja esta aplicación.<br />
F.1.<br />
Inicio<br />
<strong>La</strong> pantalla principal que se muestra al ejecutar la aplicación se muestra en la figura F.1.<br />
Esta pantalla consta <strong>de</strong>l mapa <strong>de</strong>l lugar don<strong>de</strong> el usuario va a interactuar y un botón para<br />
listar los canales en el sistema.<br />
Figura F.1: Pantalla principal <strong>de</strong> la aplicación aAndroid<br />
Cabe <strong>de</strong>stacar que la aplicación no se iniciará si el servicio que proporciona la comunicación<br />
con el mo<strong>de</strong>lo IceDDS no se está ejecutando. En lugar <strong>de</strong> la pantalla principal aparecerá<br />
un error propio <strong>de</strong> Android como el que se muestra en la figura F.2.<br />
92
F. MANUAL DE USUARIO 93<br />
Figura F.2: Error lanzado por aplicaciones Android<br />
El dispositivo utilizado (móvil smartphone o tablet) <strong>de</strong>be estar conectado a la red para<br />
po<strong>de</strong>r interactuar con el servicio que maneja los canales <strong>de</strong> eventos <strong>de</strong> IceDDS.<br />
F.2.<br />
Listar canales<br />
Para listar los canales existentes en el dominio <strong>de</strong>l sistema, el usuario <strong>de</strong>be pulsar el botón<br />
que aparece en la esquina inferior (Show Topics List).<br />
Al pulsarse este botón aparecerá un panel a la <strong>de</strong>recha <strong>de</strong> la pantalla don<strong>de</strong> se muestran<br />
dos listas: la lista <strong>de</strong> los canales existentes en el sistema y la lista <strong>de</strong> los canales a los que el<br />
usuario está suscrito (ver figura F.3).<br />
Figura F.3: Lista <strong>de</strong> canales en el sistema<br />
Para ocultar el panel <strong>de</strong> “Listar canales”, el usuario <strong>de</strong>be pulsar el botón (Hi<strong>de</strong> Topics List)<br />
situado en la esquina inferior <strong>de</strong>recha.<br />
El botón Refresh situado en la esquina superior <strong>de</strong>recha actualiza los canales existentes en<br />
el sistema.<br />
F.3.<br />
Crear un nuevo canal<br />
Para crear un nuevo canal, el usuario <strong>de</strong>be pulsar el botón Create new topic que aparece<br />
en el panel “Listar canales”. Al pulsar este botón aparecerá el panel <strong>de</strong> la figura F.4.
F. MANUAL DE USUARIO 94<br />
Figura F.4: Crear un nuevo canal<br />
Se pue<strong>de</strong>n crear dos tipos <strong>de</strong> canales:<br />
Canal general - Para crear este tipo <strong>de</strong> canal solamente hay que introducir un nombre que<br />
sea único en el sistema. El usuario <strong>de</strong>be procurar no introducir un nombre <strong>de</strong> canal ya<br />
existente. Si lo hace, no se creará ningún nuevo canal, ya que el sistema <strong>de</strong>volverá el<br />
canal existente.<br />
Canal con filtros - El usuario, a<strong>de</strong>más <strong>de</strong> introducir el nombre <strong>de</strong>l canal, pue<strong>de</strong> añadir filtros<br />
a la creación <strong>de</strong> un canal. En el panel F.4 se pue<strong>de</strong>n ver las distintas opciones que<br />
existen para añadir un <strong>de</strong>terminado filtro. Al pulsar el botón Add Filter, el nuevo filtro<br />
se colocará en la lista <strong>de</strong> filtros en la parte <strong>de</strong>recha <strong>de</strong>l panel. Al igual que se pue<strong>de</strong>n<br />
añadir filtros, también se pue<strong>de</strong>n eliminar. Si se selecciona un filtro <strong>de</strong> los existentes<br />
en la lista aparecerá un diálogo preguntando si se <strong>de</strong>sea eliminar el filtro seleccionado<br />
(ver figura F.5).<br />
Figura F.5: Eliminar filtro cuando se quiere crear un canal<br />
Para crear el canal especificado, el usuario <strong>de</strong>be pulsar el botón Create Topic o, en caso<br />
contrario, el usuario pulsará Cancel para no crear el canal.<br />
F.4.<br />
Suscribirse a un canal<br />
Para realizar la suscripción a un canal, el usuario <strong>de</strong>be seleccionar un canal <strong>de</strong> entre los<br />
<strong>de</strong> la lista. Una vez seleccionado aparecerá un diálogo (ver figura F.6) que contiene tres<br />
botones:
F. MANUAL DE USUARIO 95<br />
Subscribe: el usuario se suscribe al canal seleccionado sin más.<br />
Subscribe with filters: el usuario se suscribe al canal indicando propios filtros.<br />
Cancel: el usuario no se suscribe al canal.<br />
Figura F.6: Diálogo para realizar la suscripción a un canal<br />
Para realizar la suscripción, el usuario <strong>de</strong>be pulsar el botón Subscribe o pulsar Cancel para<br />
no realizar ningún tipo <strong>de</strong> suscripción.<br />
F.4.1. Subscribirse a un canal indicando filtros<br />
Si el usuario elige la opción <strong>de</strong> la suscripción con filtros aparecerá un panel que permite<br />
la adición <strong>de</strong> filtros (ver figura F.7). El panel es muy similar al mostrado para crear un filtro<br />
(figura F.4)<br />
Figura F.7: Suscripción añadiendo filtros propios<br />
El usuario añadirá filtros mediante el botón Add Filter y se suscribirá al canal pulsando el<br />
botón Subscribe. Al igual que en la creación <strong>de</strong> un canal, también se permite la eliminación<br />
<strong>de</strong> filtros <strong>de</strong> la lista <strong>de</strong> filtros. Si el usuario pulsa el botón Cancel no se realizará ninguna<br />
suscripción y se volverá a la pantalla principal <strong>de</strong> la aplicación.
Bibliografía<br />
[AND08]<br />
[ATH01]<br />
Open Handset Alliance y Google Inc. Android Developers, Open Source Project,<br />
2008. url: http://<strong>de</strong>veloper.android.com/.<br />
David Villa Alises. Atheist’s, testing framework, 2001. url: http://arco.esi.<br />
uclm.es/~david.villa/atheist/html/.<br />
[Bec00] K. Beck. Una explicación <strong>de</strong> la programación extrema: aceptar el cambio.<br />
Addison Wesley, edición 1 a , 2000.<br />
[bit]<br />
Atlassian Bitbucket. url: https://bitbucket.org/.<br />
[cep08] Complex Event Proccesing, Event Stream Processing,<br />
2008. url: http://www.omg.org/news/meetings/workshops/<br />
Real-time WS Final Presentations 2008/Tutorials/00-T6 Vincent.<br />
pdf.<br />
[CLM + 03] B. Cascales, P. Lucas, J.M. Mira, A.J. Pallarés, y S. Sánchez-Pedreño. El libro<br />
<strong>de</strong> L A TEX. Prentice Hall, edición 1 a , 2003.<br />
[Com11]<br />
[COR]<br />
Gerald Combs. Wireshark, 2011. url: http://www.wireshark.org/.<br />
Object Management Group. The Common Object Request Broker: Architecture<br />
and Specification. url: http://www.corba.org/.<br />
[dCENdIT] Programa <strong>de</strong> Consorcios Estratégicos Nacionales <strong>de</strong> Investigación Técnico(CENIT).<br />
Energos. url: http://innovationenergy.org/energos/.<br />
[ECL04]<br />
The Eclipse Foundation open source community. Eclipse IDE for JAVA EE<br />
Developers, 2004. url: https://www.eclipse.org/.<br />
[EMA09] GENU Operating Sytem. GNU Emacs, 2009. url: http://www.gnu.org/<br />
software/emacs/.<br />
[GCC10] Free Software Foundation. Using GCC: The GNU Compiler Collection, 2010.<br />
url: http://gcc.gnu.org/onlinedocs/gcc/.<br />
[GNO04]<br />
GNOME. ORBit2, 2004. url: http://projects.gnome.org/ORBit2/.<br />
96
BIBLIOGRAFÍA 97<br />
[icea]<br />
[ICEb]<br />
IceStorm <strong>de</strong> ZeroC Ice. url: http://www.zeroc.com/icestorm/in<strong>de</strong>x.html.<br />
Internet Communications Engine, Zeroc. url: http://www.zeroc.com.<br />
[Inc06] Sun Microsystems Inc. Java Remote Method Invocation (Java RMI),<br />
2006. url: http://java.sun.com/javase/6/docs/technotes/gui<strong>de</strong>s/rmi/<br />
in<strong>de</strong>x.html.<br />
[Mab08]<br />
[MER12]<br />
Marwa Mabrouk. OpenGIS Location Services (OpenLS): Core Services. Technical<br />
report, Open Geospatial Consortium Inc., Septiembre 2008.<br />
Mercurial: Work easier, Work faster, 2012. url: http://mercurial.selenic.<br />
com/.<br />
[MLP11] Open Moobile Alliance. Mobile Location Protocol V3.1, 2011. url:<br />
http://www.openmobilealliance.org/technical/release program/<br />
mlp v31.aspx.<br />
[NOS] Testing with nose. url: http://readthedocs.org/docs/nose/en/latest/<br />
testing.html.<br />
[OMG97]<br />
[OMG07]<br />
Object Management Group, 1997. url: http://www.omg.org/.<br />
Data Distribution Service, Object Management Group, Enero 2007. url: http:<br />
//www.omgwiki.org/dds.<br />
[OPC] OpenFusion CORBA from PrismTech. url: http://www.prismtech.com/<br />
openfusion/technologies/corba.<br />
[OpS] OpenSplice DDS from PrismTech. url: http://www.prismtech.com/<br />
opensplice.<br />
[RED12] Redmine, project management web application, 2012. url: http://www.<br />
redmine.org/.<br />
[RTI]<br />
[SLO]<br />
[SMS06]<br />
Real-Time Innovations Data Distribution Service. url: http://www.rti.com/<br />
products/dds/in<strong>de</strong>x.html.<br />
David A. Wheeler. SLOCCount. url: http://www.dwheeler.com/sloccount/<br />
.<br />
R.M. Stallman, R. McGrath, y P.D. Smith. GNU Make: A program for directing<br />
recompilation (Version 3.81). Free Software Foundation., 2006.<br />
[Som06] I. Sommerville. Ingeniería <strong>de</strong>l software. Addison Wesley, edición 7 a , 2006.
BIBLIOGRAFÍA 98<br />
[TCO10]<br />
Real-Time CORBA with TAO (The ACE ORB), 2010. url: http://www.cs.<br />
wustl.edu/~schmidt/TAO.html.<br />
[ucs11] Unamanned AirCraft Systems Control Segment, 2011. url:<br />
http://www.ucsarchitecture.org/page/technical information#<br />
middleware software platform.<br />
[VMV + 11] F.J. Villanueva, M.A. Martínez, D. Villa, C. González, y J.C. López. Elcano:<br />
Multimodal indoor navigation infrastructure for disabled people. En Consumer<br />
Electronics (ICCE), 2011 IEEE International Conference on, páginas 611 –612,<br />
jan. 2011.
Este documento fue editado y tipografiado con L A TEX<br />
empleando la clase arco-pfc que se pue<strong>de</strong> encontrar en:<br />
https://bitbucket.org/arco group/arco-pfc<br />
[Respeta esta atribución al autor]