herramienta interactiva para ... - arco.esi.uclm.esarco.esi.uclm.es/public/pfc/raquel.burgos.pdf ·...
TRANSCRIPT
HERRAMIENTA INTERACTIVA PARA MONITORIZACIÓN Y CONTROL DELINTERNET DE LAS COSAS
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
INGENIERÍA
EN INFORMÁTICA
PROYECTO FIN DE CARRERA
Herramienta Interactiva para Monitorización y Control delInternet de las Cosas
Raquel Burgos Plaza
Junio, 2013
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICADepartamento de Tecnologías y Sistemas de Información
PROYECTO FIN DE CARRERA
Herramienta Interactiva para Monitorización y Control delInternet de las Cosas
Autor: Raquel Burgos PlazaDirector: David Villa Alises
Junio, 2013
Raquel Burgos Plaza
Ciudad Real – Spain
E-mail: [email protected]
c© 2013 Raquel Burgos Plaza
Permission is granted to copy, distribute and/or modify this document under the terms of the GNUFree Documentation License, Version 1.3 or any later version published by the Free SoftwareFoundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copyof the license is included in the section entitled "GNU Free Documentation License".Se permite la copia, distribución y/o modificación de este documento bajo los términos de laLicencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada porla Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida enel apéndice titulado «GNU Free Documentation License».Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios sonreclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, ycuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos enmayúsculas o como nombres propios.
TRIBUNAL:
Presidente:
Secretario:
Vocal:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE SECRETARIO VOCAL
Fdo.: Fdo.: Fdo.:
Resumen
Actualmente vivimos en un mundo donde cada día millones de dispositivos actúan y secomunican a través de la red para ofrecer servicios, facilidades y entretenimiento a los hu-manos.
El hecho de que cada vez más cosas cuenten con acceso a Internet ha dado paso al flo-recimiento de multitud de sistemas y aplicaciones para gestionar y monitorizar redes dedispositivos distribuidos.
Estos sistemas o aplicaciones suelen depender en gran medida de las tecnologías dondevayan a ser utilizados. Hasta ahora los fabricantes suelen proporcionar a los usuarios he-rramientas implementadas como aplicaciones de escritorio, provocando en algunos casosincompatibilidades con diferentes sistemas operativos o tipos de dispositivos móviles.
En el presente documento se describe el trabajo desarrollado para conseguir una herra-mienta flexible y genérica que permita la monitorización y el control de una red de disposi-tivos distribuidos a través de Internet con independencia de las tecnologías empleadas por elusuario final.
VI
Abstract
Nowadays, millions of devices act and communicate through the Internet to provide ser-vices, facilities and entertainment for humans.
The fact that there are an increasing number of devices connected to the Internet hasresulted in the blooming of a myriad of systems or applications to monitor and manage theso-called “distributed networks”.
These systems are, of course, heavily dependent on the technologies and specificities ofthe places where they will be used. Until now, manufacturers often provide users with toolsthat are implemented as desktop applications. However, many these applications are usuallynot compatible within different operating systems or mobile device types, i.e. they are nottransferable.
This document presents the research and development work carried out to develop a fle-xible and generic tool. This tool allows the user to monitor, control and manage a groupof devices which are distributed through the Internet. Furthermore, this tool can be used byany user, regardless of the technology (i.e. operating system) that the user might be workingwith.
VII
Índice general
Resumen VI
Abstract VII
Índice general VIII
Índice de cuadros XIII
Índice de figuras XIV
Índice de listados XVI
Listado de acrónimos XVIII
Agradecimientos XX
1. Introducción 1
1.1. Internet of Things (IOT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1. Aplicaciones del IOT . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2. Representación de la información . . . . . . . . . . . . . . . . . . 3
1.2. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Antecedentes 5
2.1. Comunicación asíncrona en la web . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Tecnologías Push . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3. Server Sent Events (SSE) . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. Websockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Frameworks de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. QUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2. PhantomJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
VIII
2.2.3. Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4. JsTestDriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3. Middleware de comunicación entre objetos distribuidos . . . . . . . . . . . 17
2.3.1. ZeroC Ice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2. CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.3. RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4. Distributed Universal Objects (DUO) . . . . . . . . . . . . . . . . . . . . . 23
2.4.1. Module Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.2. Module Container . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5. Abstract Service Discovery (ASD) . . . . . . . . . . . . . . . . . . . . . . 26
3. Objetivos 27
3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1. Estudio del desarrollo de aplicaciones distribuidas mediante el middle-ware orientado a objetos ZeroC Ice . . . . . . . . . . . . . . . . . 27
3.2.2. Estudio y comparativa de las tecnologías existentes para la comuni-cación cliente/servidor a través de la web . . . . . . . . . . . . . . 27
3.2.3. Estudio de los diferentes frameworks de pruebas disponibles para eldesarrollo de aplicaciones web . . . . . . . . . . . . . . . . . . . . 28
3.2.4. Programación de un servidor genérico capaz de recibir informaciónde los objetos distribuidos independientemente del controlador alque se asocien y de transmitirla al cliente web y viceversa . . . . . 28
3.2.5. Aplicación web de monitorización que permita representar de mane-ra versátil los objetos que conforman la red y visualizar los eventosde comunicación entre ellos . . . . . . . . . . . . . . . . . . . . . 28
4. Método de trabajo y herramientas 29
4.1. Metodología de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1. Prototipado Incremental . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.2. Desarrollo Dirigido por Pruebas . . . . . . . . . . . . . . . . . . . 30
4.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.1. Lenguajes de Programación . . . . . . . . . . . . . . . . . . . . . 31
4.2.2. Aplicaciones de Desarrollo . . . . . . . . . . . . . . . . . . . . . . 31
4.2.3. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.4. Gestión de proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.5. Recusos Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5. Desarrollo del proyecto 33
5.1. Especificación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. Modelo y vista de objetos simples . . . . . . . . . . . . . . . . . . 36
5.4.2. Modelo y vista de objetos activos . . . . . . . . . . . . . . . . . . 43
5.4.3. Serialización JSON en ambos sentidos . . . . . . . . . . . . . . . . 46
5.4.4. División de la página principal en dos paneles . . . . . . . . . . . . 47
5.4.5. Modelo y vista de objetos genéricos . . . . . . . . . . . . . . . . . 48
5.4.6. Soporte para el cambio de modelos y de vistas . . . . . . . . . . . 49
5.4.7. Modelo y vista para contenedores de objetos . . . . . . . . . . . . 50
5.4.8. Modelo y vista para el Topic Manager y el canal de anunciamientos 51
6. Resultados 54
6.1. Aplicaciones de la herramienta . . . . . . . . . . . . . . . . . . . . . . . . 54
6.1.1. Inspección y control de dispositivos remotos . . . . . . . . . . . . 54
6.1.2. Monitorización de canales de eventos . . . . . . . . . . . . . . . . 56
6.2. Recursos y costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.1. Repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7. Conclusiones y trabajo futuro 59
7.1. Objetivos alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A. Slices 62
A.1. Slice de DUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.2. Slice del módulo ASD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B. Pruebas 65
B.1. Registro y creación de modelos . . . . . . . . . . . . . . . . . . . . . . . . 65
B.1.1. Registro de un nuevo modelo . . . . . . . . . . . . . . . . . . . . . 65
B.1.2. Creación de un modelo dado un proxy . . . . . . . . . . . . . . . . 65
B.2. Consulta y modificación del estado de un objeto . . . . . . . . . . . . . . . 66
B.2.1. Consulta del estado . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.2.2. Modificación del estado . . . . . . . . . . . . . . . . . . . . . . . 66
B.3. Creación e invocación del Listener en objetos activos . . . . . . . . . . . . 66
B.3.1. Invocación del Listener por un objeto activo . . . . . . . . . . . . . 67
B.3.2. Comprobación de que el Listener es un singleton . . . . . . . . . . 67
B.3.3. Invocación del controlador por parte del Listener . . . . . . . . . . 67
B.4. Obtención y asignación de un nuevo observador en objetos activos . . . . . 67
B.4.1. Obtención del Observador . . . . . . . . . . . . . . . . . . . . . . 67
B.4.2. Asignación de un nuevo Observador . . . . . . . . . . . . . . . . . 67
B.5. Inspección y modificación de un objeto contenedor . . . . . . . . . . . . . 68
B.5.1. Obtención de los hijos de un contenedor . . . . . . . . . . . . . . . 68
B.5.2. Creación de un nuevo contenedor dentro de otro . . . . . . . . . . 68
B.5.3. Enlace de un objeto a un contenedor . . . . . . . . . . . . . . . . . 68
B.5.4. Desenlazar un objeto de un contenedor . . . . . . . . . . . . . . . 68
B.5.5. Destruir un objeto contenedor . . . . . . . . . . . . . . . . . . . . 69
B.6. Gestión de canales con el modelo Topic Manager . . . . . . . . . . . . . . 69
B.6.1. Listado de los canales registrados . . . . . . . . . . . . . . . . . . 69
B.6.2. Creación y listado de un nuevo canal . . . . . . . . . . . . . . . . . 69
B.6.3. Petición de un canal que no existe . . . . . . . . . . . . . . . . . . 69
B.7. Eventos en el canal de anunciamientos . . . . . . . . . . . . . . . . . . . . 70
B.8. Peticiones al Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
B.8.1. Petición de la página principal . . . . . . . . . . . . . . . . . . . . 70
B.8.2. Petición de la vista de un objeto . . . . . . . . . . . . . . . . . . . 70
B.8.3. Petición mal formada . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.8.4. Petición de un proxy mal formado . . . . . . . . . . . . . . . . . . 71
B.8.5. Petición de cambio de vista . . . . . . . . . . . . . . . . . . . . . . 71
B.8.6. Petición de cambio de modelo . . . . . . . . . . . . . . . . . . . . 71
B.9. Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
C. Manual de usuario 73
C.1. Configuración y arranque del servidor . . . . . . . . . . . . . . . . . . . . 73
C.1.1. Paquetes necesarios . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.1.2. Arranque del servidor . . . . . . . . . . . . . . . . . . . . . . . . 73
C.2. Acceso remoto al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.3. Inspección de un dispositivo remoto . . . . . . . . . . . . . . . . . . . . . 74
C.3.1. Objetos booleanos . . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.3.2. Objetos enteros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.3.3. Contenedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
C.3.4. Objetos activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
C.3.5. Propiedades generales de un objeto . . . . . . . . . . . . . . . . . 78
C.4. Acceso al Topic Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
C.5. Acceso al Canal de Anunciamientos . . . . . . . . . . . . . . . . . . . . . 79
D. Contenido del CD adjunto 80
Bibliografía 81
Índice de cuadros
6.1. Líneas de código por lenguaje de programación . . . . . . . . . . . . . . . 57
6.2. Líneas de código por componente . . . . . . . . . . . . . . . . . . . . . . 58
XIII
Índice de figuras
2.1. Comparación del modelo tradicional para las aplicaciones web con el modelode AJAX [AJA] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Comparación de la interacción sincrónica de una web tradicional con el pa-trón asincrónico de AJAX. [AJA] . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Diferencia entre AJAX y Comet [COM] . . . . . . . . . . . . . . . . . . . 8
2.4. Diferencia entre Polling tradicional y Long Polling [PLP] . . . . . . . . . . 9
2.5. Resultado de la carga del archivo de pruebas QUnit en el navegador . . . . 12
2.6. Interfaz gráfica de Selenium IDE . . . . . . . . . . . . . . . . . . . . . . . 14
2.7. Arquitectura del framework jsTestDriver [JUT] . . . . . . . . . . . . . . . 15
2.8. Ejecución de las pruebas con jsTestDriver desde la interfaz de Eclipse . . . 16
2.9. Invocación entre dos objetos . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.10. Arquitectura ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.11. Arquitectura CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Diagrama de flujo del prototipado incremental . . . . . . . . . . . . . . . . 30
5.1. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Patrón de arquitectura Modelo Vista Controlador [MVC11] . . . . . . . . . 36
5.3. Diagrama de secuencia de la creación de un modelo y controlador para unobjeto a partir de su proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4. Diagrama de secuencia de actualización de la vista de un objeto Activo . . . 43
5.5. Arquitectura de IceStorm . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1. Vistas básicas de un objeto entero (izquierda) y otro booleano (derecha) . . 55
6.2. Vistas básicas de un objeto entero (izquierda) y un contenedor del que formaparte (derecha) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3. Vistas básicas de un Modelo Activo (izquierda) y de un Modelo Objeto (de-recha) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.4. Vistas del TopicManager (izquierda) y del Canal de Anunciamientos (derecha) 57
C.1. Búsqueda de un nuevo dispositivo por proxy . . . . . . . . . . . . . . . . . 74
XIV
C.2. Distintas vistas para un objeto booleano . . . . . . . . . . . . . . . . . . . 75
C.3. Distintas vistas para un objeto entero . . . . . . . . . . . . . . . . . . . . . 76
C.4. Vista de un objeto booleano (izquierda) y un contenedor (derecha) . . . . . 76
C.5. Objeto booleano añadido al contenedor de la derecha . . . . . . . . . . . . 77
C.6. Vista del Modelo Activo . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
C.7. Vista del un Modelo Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . 78
C.8. Acceso al TopicManager (izquierda) y al Canal de Anunciamientos (derecha) 78
Índice de listados
2.1. Ejemplo de función JavaScript con peticiones AJAX . . . . . . . . . . . . . 6
2.2. Definición del Websocket . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Ejemplo de código en el cliente (JavaScript) . . . . . . . . . . . . . . . . . 10
2.4. Integración de QUnit en JavaScript . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Etiquetas para la correcta visualización de resultados QUnit . . . . . . . . . 12
2.6. Estructura de los test unitarios en QUnit . . . . . . . . . . . . . . . . . . . 12
2.7. Ejemplo de afirmaciones en QUnit . . . . . . . . . . . . . . . . . . . . . . 12
2.8. Ejecución de la integración de QUnit con PhantomJS . . . . . . . . . . . . 13
2.9. Ejemplo de sintaxis en jsTestDriver . . . . . . . . . . . . . . . . . . . . . 15
2.10. Ejemplo de archivo de configuración jsTestDriver.conf . . . . . . . . . . . 16
2.11. Resultado de la ejecución de las pruebas por consola . . . . . . . . . . . . 16
2.12. Ejemplo de interfaz SLICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.13. Fragmento del módulo DUO . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.14. Ejemplo de interfaz compuesta por interfaces básicas de DUO . . . . . . . . 24
2.15. Interfaz del módulo DUO para los objetos activos . . . . . . . . . . . . . . 25
2.16. Slice de los objetos contenedores . . . . . . . . . . . . . . . . . . . . . . . 25
2.17. Slice del módulo ASD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Interfaces implementadas por los modelos booleano y entero . . . . . . . . 37
5.2. Ejemplo de pruebas unitarias para la factoría de modelos . . . . . . . . . . 38
5.3. Ejemplo de pruebas unitarias para los primeros modelos . . . . . . . . . . 39
5.4. Código de la Factoría de Modelos y del Modelo Booleano . . . . . . . . . 39
5.5. Código inicial del Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.6. Ejemplo de pruebas unitarias sobre el script de la vista del modelo booleano 41
5.7. Código del script de una vista para un modelo booleano . . . . . . . . . . . 41
5.8. Factoría de Controladores y controlador inicial . . . . . . . . . . . . . . . 42
5.9. Clase Listener para el modelo booleano . . . . . . . . . . . . . . . . . . . 44
5.10. Creación del Listener y subscripción al observador del modelo . . . . . . . 45
5.11. Slice de los objetos activos . . . . . . . . . . . . . . . . . . . . . . . . . . 45
XVI
5.12. Formato de mensaje para el intercambio de información en el sistema . . . 47
5.13. Función que recibe un mensaje en JSON y lo decodifica . . . . . . . . . . . 47
5.14. Fragmento de la plantilla HTML de la página principal . . . . . . . . . . . . 48
5.15. Parte del Slice de los objetos ICE [ICEb] . . . . . . . . . . . . . . . . . . . 49
5.16. Slice del módulo DUO::Container . . . . . . . . . . . . . . . . . . . . . . 51
5.17. Slice del canal de anunciamientos . . . . . . . . . . . . . . . . . . . . . . 52
5.18. Clase Listener del canal de anunciamientos . . . . . . . . . . . . . . . . . 53
6.1. Estimación de los costes del proyecto . . . . . . . . . . . . . . . . . . . . 58
A.1. Slice del paquete DUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.2. Slice del módulo ASD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Listado de acrónimos
AJAX Asynchronous JavaScript And XML
API Application Programming Interface
ARCO Arquitectura y Redes de Computadores
ASD Abstract Service Discovery
CORBA Common Object Request Broker Architecture
CPU Central Processing Unit
CSS Cascading Style Sheets
DOM Document Object Model
DUO Distributed Universal Objects
FTP File Transfer Protocol
GIOP General Inter-ORB Protocol
GPL GNU General Public License
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
Ice Internet Communications Engine
IDE Integrated Development Environment
IDL Interface Definition Language
IIOP Internet Inter-ORB Protocol
IoT Internet of Things
IP Internet Protocol
IPv6 Internet Protocol version 6
JSON JavaScript Object Notation
MVC Modelo Vista Controlador
OMG Object Management Group
ORB Object Request Broker
PC Personal Computer
XVIII
QR Quick Response Code
RFID Radio Frequency IDentification
RMI Java Remote Method Invocation
Slice Specification Language for Ice
SO Sistema Operativo
SSE Server-Sent Event
TCP Transmission Control Protocol
TDD Test Driven Development
URI Uniform Resource Identifier
URL Uniform Resource Locator
XML eXtensible Markup Language
Agradecimientos
«La paciencia es la madre de la ciencia»
No podía empezar con otra frase. Si existe un denominador común entre todas las personasque han hecho posible que hoy esté escribiendo esto, es la paciencia que han tenido conmigo.Y por eso, casi por encima de todo lo demás, tengo que dar las gracias.
Gracias a mis padres. Por su infinita paciencia todos estos años. Por estar siempre ahí,ayudándome y apoyándome. Papa, ahora sí, ya puedes llamar a la banda de música.
A mi hermano. Por enseñarme, aunque él no lo sepa, que los títulos no lo son todo en lavida. Que lo importante de verdad, es dedicarte a lo que te gusta.
Gracias a mi director, David Villa. Por darme la oportunidad de entrar a formar parte deeste grupo y confiar en mí cuando ni yo misma lo hacía. Por su paciencia, dedicación y ayudatodos estos meses.
A mis compañeros del laboratorio, Alicia, Tato, Dani y el resto del equipo Bulling. Porhacer los días más llevaderos y por echarme una mano siempre que me encontraba conalguna dificultad. No se me olvida que tenemos pendiente un Señor del 3.
Gracias a L@s del Piso, por compartirlo todo desde el primer día. Por haber sido mi familiaculiparda, y por seguir ahí, a pesar de las distancias. Eva, Laura, Lucy, Jose y Santi, por serun ejemplo a seguir en todos los aspectos de la vida.
A mis Referidoras Almoroxanas y los 45 900, por todos los momentos, los vividos hastaahora, y los que quedan por venir. A Maria, porque cuatro ojos ven más que dos. Gracias. Osdebo una cena, o una mesa donde Diego llena de botellines, lo que me salga más barato...
A mi eterna compañera de prácticas y sufrimientos, Laura. Por haber estado ahí desde queempezó todo ésto (¡no ha llovido ni ná!). Por ser la única capaz de entenderme cuando elresto del mundo vivía en una realidad pararela. Por aguantarme tantas chapas monotemáti-cas, y hacerme creer que sí, al final, siempre salimos airosas de cualquier situación (aunquelos miembros biónicos nos insinúen lo contrario). Gracias, de verdad. Métele caña que enseptiembre Londres nos estará esperando.
«No es necesario tener principios, lo importante, es tener finales. Gracias.»
Raquel Burgos Plaza
XX
A todos, a vosotros
11Introducción
En la actualidad, las personas no son los únicos usuarios de Internet. Desde el año 2008, elnúmero de cosas conectadas a la red superó al número de personas que habitan la Tierra.
Los usos que se pueden dar a la interconexión de los objetos a través de Internet son tandispares que van desde el control de varios dispositivos que conforman una red distribuida apequeña escala, hasta sistemas de control y vigilancia de amplia cobertura.
Sea cual sea la aplicación que ofrezcan esos usos, están todos englobados dentro de latendencia que se conoce como el Internet of Things (IOT), en castellano el Internet de las
cosas.
1.1 Internet of Things (IOT)El término se atribuye a Kevin Ashton para referirse a una Internet que incluya a las per-
sonas y sus cosas identificadas con etiquetas RFID [Ash]. Hasta ahora ha sido esa tecnología,junto con la de los códigos QR [qr] las que han abarcado de manera más amplia las apli-caciones desarrolladas dentro de esta filosofía. Sin embargo, el impulso del hardware librecomo la plataforma Arduino[ard], o la adopción del nuevo protocolo de Internet (IPV6) [ipv],permitirán que sean cada vez más los objetos con identidad propia en la red, y que el númerode aplicaciones para identificarlos, localizarlos y trabajar con ellos se multiplique.
1.1.1 Aplicaciones del IOT
Para ilustrar el concepto de IOT, en esta sección se describen brevemente algunos proyectosy propuestas relacionados.
Smartcities: SmartSantander
Se prevee que para el año 2025 el 70 % de la población mundial vivirá en las ciudades.En la actualidad, las ciudades consumen el 75 % de los recursos y de la energía mundial ygeneran el 80 % de los gases responsables del efecto invernadero, ocupando tan sólo el 2 %del territorio mundial [Tin]. Estos datos ponen de manifiesto la necesidad de gestionar demanera eficiente y sostenible los recursos disponibles, y es aquí donde el uso de las nuevastecnologías se hace imprescindible.
1
1. INTRODUCCIÓN 2
Se define Smart City (en castellano Ciudad Inteligente) como aquel núcleo urbano queusa las tecnologías de la información y las comunicaciones para hacer que tanto su infraes-tructura crítica, como sus componentes y servicios públicos ofrecidos sean más interactivos,eficientes y los ciudadanos puedan ser más conscientes de ellos. Es una ciudad comprome-tida con su entorno, tanto desde el punto de vista medioambiental como en lo relativo a loselementos culturales e históricos [Tel].
SmartSantander[smaa] es un proyecto de la Universidad de Cantabria (UC) junto conTelefónica I+D que convierte este municipio español en la primera ciudad inteligente integralde Europa.
En septiembre de 2013 habrá distribuidos 20.000 dispositivos inalámbricos (captadores,actuadores, cámaras, terminales móviles,etc.) a lo largo de la ciudad. Estos dispositivos re-cogerán información de todos los puntos del municipio con múltiples aplicaciones, entrelas que se encuentran las de disponer en tiempo real de la información de las plazas libresde aparcamiento, el análisis de los parámetros ambientales como el ruido o la emisión dedióxido de carbono, o las necesidades de riego de los parques y jardines.
Domótica y las Smart-Homes: SmartThings
Se entiende por Domótica el conjunto de sistemas que permiten la automatización de dis-tintos elementos de un edificio con el fin de gestionar eficientemente el consumo energético,aumentar la seguridad, el bienestar de las personas, etc.
El término Domótica no es algo nuevo, sin embargo, hasta ahora venía ligado a un ele-vado coste de implantación y mantenimiento, que lo convertía en algo exclusivo y pocodifundido. Con la aparición de nuevos dispositivos más económicos y las nuevas tecnologíasnombradas anteriormente, cada vez son más las aplicaciones que permiten a los usuarioscrear sus propias redes de dispositivos domóticos a un precio más asequible, como es el casode SmartThings[smab].
La tecnología de SmartThing está basada en un router y una serie de sensores e interrup-tores inteligentes que se conectan inalámbricamente con este router y que pueden ser moni-torizados a través de un conjunto de aplicaciones para el Smartphone del cliente llamadasSmartApps.
La ventaja de este producto es que cualquier cosa que el usuario tenga en casa puedeconvertirse en inteligente gracias a los diferentes kits que proporcionan los desarrolladores.Dentro de estos kits se integran enchufes de corriente y sensores de presencia y movimiento,pudiendo controlar remotamente el encendido o apagado de cualquier cosa que se puedaenchufar, controlar el estado de las puertas o ventanas, etc., todo ello a través de las distintasSmartApps.
El usuario puede descargarse en su Smartphone las aplicaciones que más se ajusten a sus
1. INTRODUCCIÓN 3
necesidades y a la configuración de sus dispositivos o el kit adquirido.
1.1.2 Representación de la informaciónEn un mundo en el que millones de dispositivos se conectan a internet para acceder o dar
a conocer datos obtenidos a través de sus sensores, es importante la manera en la que esosdatos se comparten y representan para convertirse en información útil para las personas.
Aplicaciones como Vista Data Vision[vdv], Pachube[pac] o Tales of Things[tal], hacenuso de Google Maps[goo] para representar gráficamente los sensores u objetos distribuidospor todo el planeta y a través de las páginas web de cada una de ellas permiten al usuarioadministrar, visualizar y analizar los datos obtenidos de los dispositivos en tiempo real.
A pequeña escala, cuando se trata de controlar elementos del entorno del propio usua-rio, las empresas proporcionan soluciones en forma de App para dispositivos móviles, comoes el caso de SmartThings[smab] para configurar y controlar una red domótica, o el ca-so de Nike+[nik], que a través de sensores en las zapatillas envía información a través deBluetooth[blu] al móvil para hacer un seguimiento preciso del entrenamiento, la distanciarecorrida, las calorías quemadas, etc.
Aunque la tendencia de los fabricantes es proporcionar facilidades para poder utilizar sussistemas independientemente de las tecnologías que emplee el usuario final (tipo de dispo-sitivo, Sistema Operativo...), hasta ahora muchas aplicaciones cuentan con limitaciones eincompatibilidades de este tipo.
La finalidad de este proyecto será conseguir desacoplar los objetos de los dispositivos ytecnologías que interactuarán con ellos, de manera que el usuario pueda configurar su propiared de sensores y actuadores, y pueda acceder a cada uno de ellos remotamente a través deun navegador con independencia del hardware o el SO con el que esté trabajando.
1.2 Estructura del documentoEn esta sección se enumeran los diferentes capítulos que componene este documento junto
con una breve descripción de cada uno de ellos.
Capítulo 2: «Antecedentes»En este capítulo se introducirán las diferentes tecnologías existentes para la comuni-cación asíncrona en la web, describiendo cada una de ellas y analizando los pros ycontras de su utilización en este proyecto. Asimismo, se detallarán los frameworks depruebas para JavaScript estudiados y empleados.
Se introducirán brevemente los middlewares de comunicaciones orientados a objetos,haciendo especial hicapié en el middleware ZeroC Ice [ICEb], que será el empleadodurante el desarrollo del trabajo.
Por último, se describirán el modelo de información DUO y el servicio ASD, ambos
1. INTRODUCCIÓN 4
utilizados para la comunicación del sistema con los dispositivos remotos.
Capítulo 3: «Objetivos»El objetivo del proyecto es el desarrollo de una herramienta dinámica y completamenteflexible, para la monitorización e interacción con los distintos elementos que confor-men una red de objetos distribuidos con independencia de las tecnologías empleadaspor el usuario final.
En este capítulo se describirán con más detalle los objetivos específicos que se preten-den alcanzar a lo largo del ciclo de vida del proyecto.
Capítulo 4: «Método de trabajo y herramientas»Para el desarrollo de este trabajo se ha seguido la metodología del Prototipado Incre-
mental junto con la técnica Test Driven Development (TDD) para su implementación.En este apartado de abordarán brevemente los principios de dicha metodología y seexpondrán las herramientas, tanto hardware como software, utilizadas durante todo elproceso de realización del mismo.
Capítulo 5: «Desarrollo del proyecto»En esta sección se analizarán los requisitos funcionales del proyecto para obtener loscasos de uso correspondientes y se describirá brevemente el patrón de arquitecturaseleccionado para la implementación del sistema. Posteriormente se detallará cada unade las iteraciones en las que se ha dividido el desarrollo del proyecto. En cada una deellas se describirán el análisis de los requisitos y el diseño planteado y, a continuación,se desarrollará más apliamente la implementación del código obtenido.
Capítulo 6: «Resultados»En este capítulo se realizará un resumen del sistema final obtenido y sus aplicaciones.Asimismo, se analizará el esfuerzo de desarrollo del proyecto y del tiempo dedicadoal mismo, así como una estimación del coste total que ha supuesto su realización.
Capítulo 7: «Conclusiones y trabajo futuro»Por último, en este apartado se analizarán los objetivos conseguidos a lo largo deldesarrollo de este proyecto. Además, se detallarán algunas sugerencias de trabajo fu-turo para ampliar y mejorar la funcionalidad del modelo presentado.
22Antecedentes
En esta sección se describirán las herramientas estudiadas y en su caso, empleadas, en eldesarrollo de este proyecto.
2.1 Comunicación asíncrona en la webUno de los objetivos principales del proyecto es el desarrollo de un servidor para poder
ofrecer al usuario información sobre distintos objetos en tiempo real. Por esta razón se ha-ce necesario el estudio de las distintas tecnologías existentes que facilitan la comunicacióncliente/servidor a través de la web.
En esta sección se describirán brevemente cada una de ellas.
2.1.1 AJAXAsynchronous JavaScript And XML (AJAX) es un conjunto de tecnologías que permiten la
creación de páginas web interactivas y completamente asíncronas. Las peticiones se realizandesde el lado del cliente hacia el lado del servidor.
La característica fundamental de AJAX es la capacidad de cargar un contenido dentrode una página web sin necesidad de refrescar el navegador, aumentando la velocidad derespuesta, ya que no debe descargarse información HTML duplicada.
En las aplicaciones web clásicas el usuario realizaba una petición HTML al servidor desdeel navegador. El servidor, tras recibir la petición, realizaba las operaciones oportunas (cálcu-los, consultas a Bases de Datos, etc.) y devolvía un nuevo HTML al cliente. Al ser peticionessíncronas, el cliente debía esperar a que llegara respuesta del servidor y se cargara la nuevapágina.
AJAX introduce un intermediario (el motor AJAX) entre el cliente y el servidor (Figura2.1). Al iniciar la sesión, el navegador carga este motor (escrito en JavaScript). Él es elresponsable de renderizar la página y de comunicarse con el servidor, permitiendo que elusuario interactúe de manera asíncrona con dicho servidor. Esta comunicación se realizamediante un objeto XMLHttpRequest.
Para cada petición del usuario que genera una petición HTML se realiza únicamente una
5
2. ANTECEDENTES 6
Figura 2.1: Comparación del modelo tradicional para las aplicaciones web con el modelo deAJAX [AJA]
llamada a una función JavaScript. Cuando la petición no requiere datos de vuelta (validaciónde un formulario, por ejemplo), se envía hacia el servidor y ahí termina la interacción. Si elmotor precisa datos de vuelta, realiza la petición de manera asíncrona, y únicamente cuandorecibe la respuesta solicitada, ésta se carga en el navegador, sin frenar la interacción delusuario hasta ese momento (Figura 2.2).
En el listado 2.1 se muestra una función JavaScript que realiza la petición de una URL alservidor solicitada por el usuario. Cuando la respuesta está lista, el contenido de esa URL secarga dentro de la página principal, concretamente en el objeto ’dynamicContent’.
var xmlhttp;
function request(url){xmlhttp.onreadystatechange = modifyContent;xmlhttp.open(’GET’,url,true);xmlhttp.send(null);
}
function modifyContent(){if(xmlhttp.readyState == 4){
document.getElementById(’dynamicContent’).innerHTML = xmlhttp.responseText;
}}
Listado 2.1: Ejemplo de función JavaScript con peticiones AJAX
2. ANTECEDENTES 7
Figura 2.2: Comparación de la interacción sincrónica de una web tradicional con el patrónasincrónico de AJAX. [AJA]
Entre las ventajas del uso de AJAX encontramos:
La experiencia de usuario en la navegación es mucho más rica. Ya no se refresca lapágina constantemente al interactuar con ella.
El tiempo de espera para una petición se reduce. El usuario al hacer un pedido (request)al servidor, no recibe toda la página.
Por la misma razón anterior el tráfico de datos hacia el servidor también se reduce.
A pesar de que AJAX es una buena opción a la hora de enviar o solicitar datos desde elcliente, no permite que la comunicación se genere desde el lado del servidor, con lo cual,para el propósito que se busca en este proyecto, su uso queda pobre y requiere de otrastecnologías.
2.1.2 Tecnologías PushLas Tecnologías Push, describen un estilo de comunicaciones web donde las peticiones se
originan en el lado servidor, al contrario que en las Tecnologías Pull, donde las peticiones se
2. ANTECEDENTES 8
originan desde el lado del cliente.
Comet
Se denomina Comet [COM08] o Reverse AJAX a las tecnologías push aplicadas a lasaplicaciones web con AJAX. Es un término global para un conjunto de técnicas de imple-mentación como Streaming y Long Pollin.
Esta tecnología difiere del modelo original de la web, en el que un navegador solicita unapágina web completa o trozos de datos para actualizarla. En la práctica, las aplicacionesComet usan tradicionalmente programación AJAX con una petición prolongada para detectarnueva información en el servidor. En la figura 2.3 se ve la diferencia entre AJAX y Comet.
Figura 2.3: Diferencia entre AJAX y Comet [COM]
Las aplicaciones Comet implementadas con la técnica de Streaming pueden entregar datosal cliente en cualquier momento, no sólo en respuesta a la entrada del usuario. Los datos setransmiten a través de una sola conexión, previamente abierta. Este enfoque reduce la latenciapara la entrega de datos significativamente.
2. ANTECEDENTES 9
Otra manera de implementar Comet es mediante el Long Polling. A diferencia del Pollingtradicional, donde el cliente hace peticiones cada cierto tiempo al servidor para ver si dispo-ne de nuevos datos (con la consiguiente sobrecarga que eso supone), con la técnica del LongPolling, tras una petición por parte del cliente, el servidor no devuelve un mensaje para infor-mar de la inexistencia de nuevos datos; la conexión permanece abierta hasta que haya datosdisponibles para devolver. El cliente, tras recibir la respuesta, realiza inmediatamente otrasolicitud. De esta manera se evita el envío de múltiples solicitudes para una única respuesta,reduciendo el consumo de ancho de banda en la web. Esta diferencia puede apreciarse en laFigura 2.4.
Figura 2.4: Diferencia entre Polling tradicional y Long Polling [PLP]
2.1.3 Server Sent Events (SSE)Server-Sent Event (SSE) [SSE] es una forma estandarizada de enviar información desde el
servidor al cliente sin necesidad de que el cliente la solicite periódicamente. Se basa en Strea-
ming HTTP, que no envía toda la información de una sola vez, sino que agrega una cabeceraespecial y deja abierta la conexión para ir añadiendo partes adicionales a la salida.
Para recibir notificaciones de Server-Sent Events en el cliente se necesita un objeto de tipoEventSource. Este objeto cuenta con tres manejadores diferentes de eventos:
onopen: se activa cuando se abre la conexión con el servidor.
onmessage: se activa cada vez que se recibe información desde el servidor.
onerror: se activa ante la existencia de un error en la conexión.
La desventaja que se encuentra en esta tecnología es que únicamente soporta un canalunidireccional servidor-cliente. Por tanto, no se ajusta a lo que el proyecto necesita, ya quese pretende que el usuario no sólo sea capaz de inspeccionar el estado de un objeto en tiemporeal, sino que pueda interactuar con él para actualizarlo o modificarlo.
2. ANTECEDENTES 10
2.1.4 WebsocketsWebsocket [WS] es una tecnología que proporciona una comunicación bidireccional y
full-duplex permanente y de baja latencia entre el cliente y el servidor sobre un único socketTCP.
La estructura básica de la implementación de Websocket consta de un socket del ladocliente utilizado para enviar datos al servidor. Por otro lado, en el servidor se implementanlas funciones o eventos que manejarán la información enviada a través del Websocket.
Para definir el Websocket se utiliza la clase WebSocket, que recibe como parámetro laURI del mismo. En el listado 2.2 se puede apreciar que la URI se caracteriza por el pro-tocolo “ws://”. Podría utilizarse el protocolo “wss://” en el caso de requerir una conexiónsegura.
var mysocket = new WebSocket("ws://echo.websocket.org");
Listado 2.2: Definición del Websocket
Una vez creado el Websocket se deben definir las funciones de callback que controlarán elintercambio de información con el servidor. Estas funciones, similares a las que utiliza SSE,son:
onopen: al abrir el Websocket.
onmessage: al recibir un mensaje por el Websocket.
onclose: al cerrar el Websocket.
onerror: al producirse un error en el Websocket.
function WebSocketEcho() {ws.onopen = function() {
$("#log").html("Open connection<br>");ws.send("Hello");
};
ws.onmessage = function (message) {var data = message.data;$("#log").append("Message is received: " + data + "<br>");
};
ws.onclose = function () {$("#log").append("Connection closed<br>");
};}
Listado 2.3: Ejemplo de código en el cliente (JavaScript)
En el listado 2.3 se muestra la implementación en JavaScript de un cliente. Tras la lla-mada a la función WebSocketEcho, se abre el Websocket y se añade un mensaje al HTML
indicando que la conexión está abierta. Inmediatamente después se envía un mensaje hacia
2. ANTECEDENTES 11
el servidor. Cuando este responda, la función onmessage añadirá una nueva línea al HTML
con el contenido del mensaje recibido.
Por su naturaleza bidireccional y su eficiencia en el consumo de ancho de banda, la tecno-logía Websocket es la que mejor se adecúa a los requisitos de este proyecto.
2.2 Frameworks de pruebasUna de las características fundamentales del desarrollo de este trabajo es la metodología
de desarrollo empleada, Test Driven Development (TDD), que se describe más detallada-mente en la sección 4.1.2. La realización de pruebas robustas y fiables es una parte crítica yfundamental para el correcto avance de la implementación de este trabajo.
En este caso concreto, existe la dificultad de seleccionar un framework de pruebas paraJavascript que permita la ejecución automatizada de las pruebas, tanto unitarias como deintegración, mediante la consola, para optimizar el tiempo y los recursos consumidos por laaplicación final.
A continuación se detallan los frameworks estudiados y utilizados durante las distintasiteraciones del proyecto.
2.2.1 QUnitQUnit [QU] es un framework desarrollado por la comunidad JQuery [JQU], que se puede
emplear para testear pruebas unitarias sobre el código desarrollado en Javascript.
Integrar las pruebas de QUnit en el sistema es tan simple como crear un archivo HTML
e incluir en sus cabeceras, a parte de los scripts con pruebas unitarias que se quieren pro-bar, un script con la librería y, opcionalmente, una hora de estilos que permite visualizarcorrectamente los resultados.
Como se puede apreciar en el listado 2.4, el programador puede optar por utilizar la li-brería alojada en el repositorio público de github [GIT], o por el contrario, almacenarla ensu propio directorio local. En el caso de optar por la segunda opción, se pueden descargarambos archivos de la página oficial de QUnit. Además, para la correcta visualización delos resultados de las pruebas según los estilos de este framework, se deben añadir etiquetasHTML como las del listado 2.5.
<link rel="stylesheet" href="http://code.jquery.com/qunit/qunit−git.css"><script type="text/javascript" src="http://github.com/jquery/qunit/raw/
master/qunit/qunit.js"></script>
Listado 2.4: Integración de QUnit en JavaScript
Cada una de las pruebas unitarias siguen la estructura del listado 2.6, donde name es unString con el nombre de la prueba, expected es un número opcional que indica el número de
2. ANTECEDENTES 12
<h1 id="qunit−header">QUnit First Test</h1><h2 id="qunit−banner"></h2><div id="qunit−testrunner−toolbar"></div><h2 id="qunit−userAgent"></h2><ol id="qunit−tests"></ol><div id="qunit−fixture">test markup</div>
Listado 2.5: Etiquetas para la correcta visualización de resultados QUnit
afirmaciones que se esperan ejecutar, y function es el código de la prueba donde se incluiránlas afirmaciones que se deben satisfacer para que el resultado de esta sea exitoso.
test(name, [expected], function )
Listado 2.6: Estructura de los test unitarios en QUnit
El listado 2.7 muestra un ejemplo muy sencillo de las afirmaciones soportadas por QUnit,mientras que en la Figura 2.5 se puede apreciar el resultado al cargar el archivo HTML en elnavegador.
test("hello", function() {ok(true, "world");
});test("bye", function(){
equal("hello", "goodbye");});
Listado 2.7: Ejemplo de afirmaciones en QUnit
Figura 2.5: Resultado de la carga del archivo de pruebas QUnit en el navegador
Algunas de las ventajas más significativas de este framework son:
Sintaxis sencilla.
El paquete incluye todo lo necesario para su utilización: librería, CSS y HTML inicial.
2. ANTECEDENTES 13
Permite tests asíncronos.
Por contra, alguna de las desventajas más importantes son:
Requiere de la librería jQuery para su ejecución.
Se necesita cargar el archivo HTML en un navegador para comprobar los resultados delos tests.
Su sintaxis no es estándar. Por ejemplo, en lugar de términos como ’AssertTrue’ seutilizan otros propios como ’ok’.
2.2.2 PhantomJSLa principal desventaja de QUnit es que la ejecución de los tests se realiza mediante la
carga manual del HTML en un navegador. Esto resulta un gran inconveniente a la hora deautomatizar todas las pruebas del proyecto. Una solución a este problema es la integraciónde QUnit en PhantomJS [PHA].
PhantomJS es un navegador sin interfaz gráfica basado en WebKit que se ejecuta por líneade comandos y se puede controlar usando una API en Javascript. Gracias a esto, se puedenlanzar con él scripts que carguen páginas e interactúen con ellas.
Desde la página oficial de PhantomJS se puede obtener tanto el código del frameworkalojado en Github, como el de un script de integración con QUnit (run-qunit.js). Este scriptnos permite inspeccionar el HTML de QUnit para extraer los resultados de la ejecución.
La sentencia utilizada para la ejecución del ejemplo empleado en el apartado 2.2.1, es:
$ phantomjs run−qunit.js hello.html
En el listado 2.8 se observa el resultado obtenido por línea de comandos.
script executed in 100ms.Tests completed in 28 milliseconds.1 assertions of 3 passed, 2 failed.global failure => fail(1, 0, 1)global failure => running(null, null, NaN)hello => pass(0, 1, 1)bye => fail(1, 0, 1)
Listado 2.8: Ejecución de la integración de QUnit con PhantomJS
Entre las ventajas de este framework encontramos:
Integración con QUnit prácticamente trivial.
Ejecución de los test por línea de comandos.
Sin embargo, al ser un navegador basado en WebKit, aunque las pruebas tengan éxito, sepueden encontrar problemas de ejecución en otros navegadores que no estén basados en esta
2. ANTECEDENTES 14
plataforma por las diferencias en la implementación de Javascript.
2.2.3 SeleniumSelenium es un conjunto de herramientas para llevar a cabo pruebas automatizadas de
aplicaciones web. Este framework permite grabar, editar y depurar casos de prueba, quepodrán ser ejecutados de forma automática e iterativa posteriormente.
Las componentes de Selenium que son necesarios para la grabación y ejecución de laspruebas son:
Selenium client: cliente de Selenium, necesario para crear las pruebas con Seleniumen el lenguaje seleccionado.
Selenium IDE: plugin de Firefox para la grabación de las pruebas, paso a paso.
Selenium Server: servidor de Selenium, que es el que realiza las pruebas.
Como se ha comentado, Selenium IDE es una extensión para Firefox. Dicha extensión re-gistra la actividad en el navegador durante un periodo determinado; esta actividad se traduceen una serie de comandos que se podrán repetir, incluyendo aserciones y advertencias pararealizar los tests. Esta serie de comandos puede exportarse en forma de script en lenguajescomo Ruby, Java (JUnit) o C#. En la Figura 2.6 se muestra su interfaz.
Figura 2.6: Interfaz gráfica de Selenium IDE
2. ANTECEDENTES 15
La principal desventaja de este framework es que al ser un plugin de Firefox, todas laspruebas se realizan con este navegador, lo que puede provocar que se pasen por alto incom-patibilidades del código con otros navegadores.
2.2.4 JsTestDriverJsTestDriver [JTD] es un framework de pruebas desarrollado por Google. La figura 2.7
muestra su arquitectura.
Figura 2.7: Arquitectura del framework jsTestDriver [JUT]
Utiliza un pequeño servidor para ejecutar los tests, lo que permite manejarlo a través de lalínea de comandos. Al no necesitar el navegador, se convierte en la herramienta idónea para eldesarrollo de aplicaciones de escritorio o desde el lado del servidor. Además, su integracióncon algunos de los IDEs más populares permite resumir todo el proceso de testeo al pulsarun botón. El listado 2.9 muestra un ejemplo de la sintasix utilizada por este framework.
GreeterTest = TestCase("GreeterTest");
GreeterTest.prototype.testGreet = function() {var greeter = new myapp.Greeter();assertEquals("Hello World!", greeter.greet("World"));
};
Listado 2.9: Ejemplo de sintaxis en jsTestDriver
La librería necesaria para ejecutar las pruebas puede descargarse de la página del proyec-to y debe copiarse en el directorio desde el que se vaya a arrancar el servidor y ejecutarlos test. Además, jsTestDriver también puede instalarse en el sistema como un plugin deEclipse [ECL].
2. ANTECEDENTES 16
Tanto si las pruebas van a realizarse por consola o a través de la interfaz de Eclipse, debecrearse un fichero de configuración llamado jsTestDriver.conf. En este fichero se configuraránlas características de la ejecución de los test. En el listado 2.10 se muestra un ejemplo dondese especifica la dirección y el puerto del servidor jsTestDriver y las rutas de los archivos aprobar y de los archivos de pruebas.
server: http://192.168.0.65:4224
load:− src/Greeter.js
test:− src−test/Greeter_test.js
Listado 2.10: Ejemplo de archivo de configuración jsTestDriver.conf
Para lanzar las pruebas desde la consola, simplemente debe ejecutarse el jar del frameworkindicando la dirección del servidor y el puerto, y los navegadores sobre los que se deseatestear el código.
Total 1 tests (Passed: 1; Fails: 0; Errors: 0) (2,00 ms)Chrome 26.0.1410.43 Linux: Run 1 tests (Passed: 1; Fails: 0; Errors 0)
(2,00 ms)
Listado 2.11: Resultado de la ejecución de las pruebas por consola
Figura 2.8: Ejecución de las pruebas con jsTestDriver desde la interfaz de Eclipse
2. ANTECEDENTES 17
Entre las ventajas de jsTestDriver se encuentran:
Control por línea de comandos.
Ejecución de tests paralelos en múltiples navegadores en múltiples máquinas, incluidoslos dispositivos móviles.
Control total del DOM con inyección directa de código HTML.
Integración con diferentes IDEs de desarrollo.
No precisa de una estructura HTML para mostrar los resultados lo que se traduce enunos tests muy rápidos.
Como conclusión, jsTestDriver es una solución sólida con una sintaxis limpia y clara,muy adecuada para la metodología de desarrollo que se seguirá en el proyecto, que permiterealizar pruebas de integración automáticas rápidas y robustas.
2.3 Middleware de comunicación entre objetos distribuidosUn middleware de comunicaciones orientado a objetos permite al programador abstraerse
de las complejidades y heterogeneidades de las capas inferiores (red, lenguaje de implemen-tación, localización, arquitectura hardware, sistema operativo, etc.), facilitando la programa-ción de aplicaciones y sistemas distribuidos.
La comunicación entre objetos se realiza mediante invocaciones. En la figura 2.9 se mues-tra un ejemplo de una llamada de un objeto Cliente a otro objeto Servidor que está en otronodo de la red. La invocación a esta llamada es traducida por el middleware para permitirque el mensaje sea enviado de un nodo a otro. En este tipo de plataformas, el cliente es el queefectúa las peticiones y el servidor es la entidad que las atiende, aunque las dos entidadespueden adquirir ambos roles indistintamente.
Figura 2.9: Invocación entre dos objetos
A continuación se detallarán algunas de las alternativas disponibles en la actualidad, es-tudiando más en profundidad ZeroC ICE, que será el empleado durante el desarrollo de esteproyecto.
2.3.1 ZeroC IceInternet Communications Engine (ICE) [ICEb] es un middleware orientado a objetos con
licencia GPL construido por la empresa ZeroC. ICE soporta múltiples lenguajes y es multipla-
2. ANTECEDENTES 18
taforma, lo que proporciona una gran flexibilidad para construir sistemas muy heterogéneoso integrar sistemas existentes.
Al ser un middleware de comunicaciones orientado a objetos, ICE está basado en unaarquitectura cliente-servidor. Para establecer la comunicación entre estas dos entidades elcliente necesita un proxy al objeto para poder solicitar sus servicios y el servidor tiene queser añadido a un adaptador de objetos para que el cliente pueda acceder a él a través delmiddleware. En la figura 2.10 se muestra una visión general de esta arquitectura.
Figura 2.10: Arquitectura ICE
Clientes y servidores
Los términos cliente y servidor no están asociados a distintas partes de una aplicación,sino que hacen referencia a los roles que las distintas partes de una aplicación pueden asumirdurante una petición.
El cliente es el elemento activo de la petición. Solicita servicios a objetos remotosmediante invocaciones a sus métodos.
El servidor es la entidad pasiva. Proporciona servicios en respuesta a las solicitudesde los clientes. Se trata de un programa o servicio que inicializa y activa los recursosnecesarios para poner objetos a disposición de los clientes.
Objetos
Un objeto Ice es una entidad abstracta con una serie de características:
Es una entidad en el espacio de direcciones remoto o local que es capaz de respondera las peticiones de los clientes.
2. ANTECEDENTES 19
Un objeto tiene una identidad propia que es única en todo el dominio de comunicaciónICE. Si dos objetos tienen la misma identidad, ambos hacen referencia al mismo objeto.
Un objeto puede tener múltiples instanciaciones simultáneas en diferentes espaciosde direcciones, y sin embargo sigue siendo el mismo objeto porque tiene la mismaidentidad.
Un objeto puede poseer múltiples servicios, cada uno de ellos se denomina faceta y estádescrito mediante una interfaz. Una de ellas es la principal. Desde cualquier interfazel cliente puede navegar a las otras facetas del mismo objeto.
La funcionalidad de un objeto ICE se describe a través de las interfaces que imple-mentan sus facetas. Cada interfaz describe el conjunto de métodos que pueden serinvocados en el puerto que la implementa.
Adaptador de objetos
El adaptador de objetos es un mecanismo proporcionado por el middleware para hacerque los objetos necesarios puedan recibir invocaciones remotas. Dichos adaptadores de ob-jetos deben tener asignada una o varias direcciones de red a nivel de transporte (IP y puerto),conocidas como endpoints. Para representarlos se suele utilizar cadena donde se indica elprotocolo de transporte, la IP y el puerto. Un ejemplo de esta representación sería el siguien-te:
tcp -h 192.168.0.4 -p 21128
donde tcp indica que se utilizará un protocolo de transporte TCP, se escuchará por lainterfaz con dirección 192.168.0.4 y en el puerto 21128.
Sirviente
El sirviente es una instancia del objeto remoto que recibe las invocaciones. Los sirvientesson los objetos que se añaden a los adaptadores de objetos para que puedan recibir solicitudesdel exterior. El cliente realizará las llamadas remotas mediante un objeto proxy proporcio-nado por el middleware.
Identidad de un objeto
Los sirvientes que son añadidos al adaptador de objetos se registran con una identidadque los identifica de manera única en el sistema distribuido. Esta característica puede serañadida por el programador o de manera automática mediante los diferentes métodos queproporciona el adaptador de objetos de ICE.
2. ANTECEDENTES 20
Proxy
Para que un cliente sea capaz de comunicarse con un objeto ha de tener acceso a un proxypara el objeto. Un proxy es un componente local al espacio de direcciones del cliente, yrepresenta al objeto.
El proxy se representa como una cadena de caracteres que contiene la identidad del objetounida al endpoint del adaptador donde se ha añadido. Por ejemplo:
Identity -t : tcp -h 192.168.0.8 -p 10000
La opción -t es el modo de acceso al objeto. Significa twoway, es decir, el sirviente recibepeticiones y se espera una respuesta. Hay otras posibles opciones, como por ejemplo -o(oneway) donde el sirviente recibe peticiones y no hay respuesta.
Communicator
El Communicator es el elemento más importante del middleware. Proporciona la comu-nicación entre los clientes y los servidores en el sistema distribuido. Se encarga de crear losadaptadores de objetos, proxys, identidades de objetos, ...
Slice
Specification Language for Ice (SLICE) es un lenguaje que se utiliza para describir las ope-raciones sobre las que los clientes pueden hacer invocaciones. Aquí se define la interfaz y lasoperaciones que serán accesibles mediante un proxy a un sirviente determinado y se estable-cen independientemente del lenguaje de programación que se vaya a utilizar. ICE proporcionaherramientas para traducir la interfaz SLICE en diferentes lenguajes. Los lenguajes a los queICE da soporte son C++, Python, Java, .NET, PHP, Objective-C, Ruby y ActionScript. En ellistado 2.12 se muestra un ejemplo sencillo de SLICE.
module UCLM {interface Hello {
void puts(string str);};
};
Listado 2.12: Ejemplo de interfaz SLICE
Tanto el cliente como el servidor pueden estar implementados en diferentes lenguajes deprogramación, lo que ofrece una ventaja bastante importante, ya que se puede implementarclientes en diferentes lenguajes sin necesidad de cambiar nada en el servidor.
Servicios
ICE ofrece una serie de servicios que gestionan otras características para propósitos másconcretos:
2. ANTECEDENTES 21
IceStorm
IceStorm [icea] es un servicio que proporciona comunicaciones entre clientes y servi-dores mediante la creación de canales de eventos. En este ámbito se habla de publica-dor y suscriptor en vez de cliente y servidor. Los publicadores envían datos al canalmediante invocaciones remotas que serán enviadas a los suscriptores de dicho canal.De este modo, un único evento de un publicador puede ser enviado a múltiples sus-criptores. Cada canal está identificado unívocamente por un nombre y puede tener a suvez múltiples publicadores y múltiples suscriptores.
IceStorm también soporta manejo de excepciones causadas por un comportamientoinadecuado de la red o por la pérdida de suscriptores.
Los eventos IceStorm son unidireccionales, es decir, el publicador no recibe respuestasdesde los suscriptores.
IceGrid
IceGrid es un servicio de localización y activación para las aplicaciones ICE. Estopermite que un cliente se comunique con un objeto remoto sin saber en qué máquinay en qué puerto está (proxies indirectos).
Una de las características de IceGrid es la activación de los servidores bajo demanda,es decir, cuando un cliente realiza una solicitud a un objeto en el servidor.
IceGrid permite la replicación mediante la agrupación de los adaptadores de objetosde varios servidores en un único adaptador de objetos virtual y el balanceo de carga.Además, soporta interfaces que proporcionan a las aplicaciones un control sobre suactividad y notificaciones acerca de eventos significativos, lo que permite el desarrollode herramientas personalizadas.
IceBox
IceBox es un servidor de aplicaciones que gestiona el arranque y detención de distintoscomponentes de una aplicación.
El servidor IceBox se configura a través de las propiedades de los servicios de la apli-cación. Estos servicios se pueden administrar de forma remota y compartir una interfazcomún que permite una administración centralizada.
IcePatch
IcePatch es un servicio que permite la distribución de actualizaciones de software a losnodos que componen el grid. El servicio comprueba automáticamente la versión quetiene cada nodo y envía las actualizaciones disponibles. Esta comunicación se puederealizar de forma segura utilizando el servicio Glacier2 mencionado más adelante.
2. ANTECEDENTES 22
Glacier2
Glacier2 es un servicio de firewall1 que permite una comunicación segura entre clien-tes y servidores a través de tráfico encriptado.
Freeze
Freeze ofrece un servicio de persistencia que le permite guardar el estado de los objetosICE en una base de datos con muy poco esfuerzo. Freeze puede recuperar automática-mente bajo demanda los objetos de la base de datos y actualizarla cuando cambia elestado de un objeto.
2.3.2 CORBACommon Object Request Broker Architecture (CORBA) [COR] es un estándar definido
por Object Management Group (OMG) para la programación de aplicaciones distribuidas.CORBA es una de las arquitecturas actualmente más extendida. Permite que los componentespuedan estar escritos en diferentes lenguajes y ejecutarse en diferentes máquinas. El modelocliente-servidor de CORBA (figura 2.11) es muy parecido al de ICE. Se utilizan interfaces IDL
para la comunicación entre dos o más aplicaciones.
Figura 2.11: Arquitectura CORBA
Una parte esencial de la arquitectura CORBA es el Object Request Broker (ORB) que seencarga de facilitar la comunicación entre objetos, es decir, es el encargado de enviar lasinvocaciones realizadas por los clientes y de retornar las repuestas a los mismos.
El estándar CORBA especifica un protocolo de transporte llamado General Inter-ORB Pro-tocol (GIOP) para las comunicaciones entre varios componentes ORBs e Internet Inter-ORBProtocol (IIOP) es el protocolo utilizado para redes TCP/IP.
Existen muchas implementaciones del estándar CORBA tanto privativas como libres. Algu-nos ejemplos son TAO [TCO10], OpenFusion CORBA [OPC] y ORBit2 de GNOME [GNO04].
1Sistema que permite bloquear los accesos no autorizados, así como permitir los autorizados.
2. ANTECEDENTES 23
2.3.3 RMIJava Remote Method Invocation (RMI) [Inc11] es el middleware de comunicación entre
objetos distribuidos de Java que permite invocar un método de un objeto que está sobre otramaquina virtual. RMI emplea TCP/IP y serialización de objetos para serializar y deseriali-zar los argumentos y valor de retorno de los métodos remotos. También utiliza los protocolosHTTP y FTP para el intercambio de clases. La interfaz entre el cliente y el servidor se especifi-ca mediante clases abstractas definidas en java. Esto implica que los clientes y los servidorestienen que estar desarrollados en Java.
Su funcionamiento básico es el siguiente:
Los servidores utilizan el rmiregistry para registrar los objetos que serán accesibles pa-ra el resto del entorno. Utilizando un sistema de nombres propio de RMI, denominadoRMIs simple naming facility, el servidor es capaz de ubicar el objeto al que el clientese ha referido en la invocación remota.
Un objeto registrado en el rmiregistry (el equivalente a un sirviente en ICE) deberáimplementar al menos la interfaz definida por el middleware Remote.
El rmiregistry le da al cliente una referencia a un objeto que puede utilizar de la mismaforma que si el objeto fuera uno localmente definido.
La principal desventaja de este middleware es la limitación que supone tener que imple-mentar los clientes y el servidor en Java. Por esa razón se descartó su uso en este proyecto.
2.4 Distributed Universal Objects (DUO)DUO (Distributed Universal Object) [Vil09a] es un modelo de información creado por
el grupo ARCO para definir el comportamiento de los dispositivos involucrados en una redtípica de sensores y actuadores. Este modelo está basado en un conjunto de interfaces que ho-mogeneiza el acceso y simplifica la interacción remota con los dispositivos para aprovecharal máximo las posibilidades de los mismos.
module DUO {module IBool {
interface R { ["freeze:read", "ami"] idempotent bool get(); };interface W { ["freeze:write", "ami"] void set(bool v, Ice::Identity
oid); };};module IByte {
interface R { ["freeze:read", "ami"] idempotent byte get(); };interface W { ["freeze:write", "ami"] void set(byte v, Ice::Identity
oid); };};
};
Listado 2.13: Fragmento del módulo DUO
2. ANTECEDENTES 24
En el listado 2.13 se muestran algunos de los submódulos que componen DUO. Comopuede observarse, cada uno de ellos implementa dos interfaces: R (Readable) y W (Writa-
ble).
La interfaz R proporciona acceso al estado del dispositivo mediante el método get(). Porejemplo, el funcionamiento de un sensor de presencia, podría modelarse a través de la inter-faz ::DUO::IBool::R, de manera que invocando a dicho método get(), los clientes puedanobtener un valor (verdadero o falso) según el sensor detecte o no detecte presencia.
La interfaz W permite a los clientes modificar el estado o valor del objeto remoto mediantesu método set(value, identity). A través de la interfaz ::DUO::IBool::W podría mode-larse, por ejemplo, una bombilla, y así, invocando el método set con el valor true o false,pueda encenderse o apagarse remotamente. Este método cuenta con otro parámetro, que esla identidad del objeto que lo invoca.
Lo habitual es que un sensor se modele utilizando la interfaz escalar R del módulo corres-pondiente al tipo de dato manejado por el sensor, y por otro lado, los actuadores se modelenutilizando la interfaz W.
Algunos dispositivos ofrecerán ambas posibilidades (sensor y actuador) y por tanto imple-mentarán ambas interfaces, de manera que se pueda consultar su estado y también modifi-carlo. En este caso, será el programador el que defina una tercera interfaz que herede de lasdos primeras, como por ejemplo la que se muestra en el listado 2.14.
module myBooleanModule{interface RW extends DUO::IBool::R, DUO::IBool::W {};
}
Listado 2.14: Ejemplo de interfaz compuesta por interfaces básicas de DUO
2.4.1 Module ActiveLos objetos Activos cuentan con un Observador, es decir, otro objeto distribuido que ob-
serva su estado y al que notifica cualquier cambio que se produce en él. Para permitir estaasociación, el objeto dispone de una referencia a su observador que puede ser modificadasi se quiere. Cuando sea preciso, el objeto invocará el método set() de su observador paracomunicar su nuevo estado. Por tanto es necesario que el observador implemente una inter-faz compatible con la del objeto observado. Los observadores de un objeto pueden ser otroobjeto o un canal de eventos.
En el Listado 2.15 aparecen las interfaces proporcionadas por DUO para los objetos acti-vos. Estas interfaces se limitan a una de lectura que, al ser invocada, devuelve el observadordel propio objeto, y otra de escritura para poder asignarle un nuevo observador.
2. ANTECEDENTES 25
module Active {interface R {
["ami"] Object∗ getObserver();};interface W {
["ami"] void setObserver(Object∗ observer);};
};
Listado 2.15: Interfaz del módulo DUO para los objetos activos
2.4.2 Module ContainerLos contenedores son grupos o colecciones de objetos. Los motivos para crear un grupo
de objetos pueden ser muy diversos: por proximidad de los dispositivos, por similitud en sufuncionalidad, por formar grupos a partir de los elementos que satisfacen un criterio dado,etc. El módulo DUO::Container proporciona un mecanismo básico para crear colecciones yjerarquías de actores.
module Container {exception AlreadyExistsException { string key; };exception NoSuchKeyException { string key; };interface RW;interface R { ["freeze:read", "ami"] idempotent ObjectPrxDict list();
};interface W {
["freeze:write", "ami"]void link(string key, Object∗ value) throws
AlreadyExistsException;["freeze:write", "ami"]
void unlink(string key) throws NoSuchKeyException;["freeze:write", "ami"]
Container::RW∗ create(string key) throws AlreadyExistsException;["freeze:write", "ami"]
void destroy();};interface RW extends R,W {};
};
Listado 2.16: Slice de los objetos contenedores
La interfaz DUO::Container::R (listado 2.16) ofrece un diccionario de objetos cuyas cla-ves son cadenas de texto que indican las referencias a los objetos que integran el grupo ocontenedor. Estos objetos pueden estar situados en cualquier parte, no tienen porqué tenerrelación alguna con el actor contenedor.
La interfaz DUO::Container::W ofrece métodos para manipular la lista de objetos quecomponen el contenedor. El método link() registra un nuevo objeto en el contenedor. Elmétodo unlink() elimina un registro. Para crear un nuevo contenedor dentro de otro sepuede utilizar create(). Y por último, el método destroy() se utiliza para eliminar uncontenedor hijo y la asociación con el padre.
2. ANTECEDENTES 26
Existe una tercera interfaz RW debido a que los contenedores que devuelve el métodocreate() deben implementar R y W.
2.5 Abstract Service Discovery (ASD)El servicio ASD [Vil09b][Ang10] fue creado por el grupo ARCO para implementar un
sistema de anunciamientos y descubrimientos de servicios. En el listado 2.17 se muestra lainterfaz de los objetos que esperan recibir anunciamientos.
module ASD {interface Listener {
idempotent void adv(Object∗ prx);idempotent void bye(Ice::Identity oid);
};};
Listado 2.17: Slice del módulo ASD
Cuando un objeto se anuncia mediante la llamada al método adv, donde facilita su proxy,se entiende que ese objeto o dispositivo está funcionando y es accesible.
Normalmente, el proceso de anunciamiento se realiza a través de un canal de eventosllamado ASDA y el publicador del canal implementa la interfaz DUO::Listener mostrada enel listado.
El objeto que envía anunciamientos puede utilizar bye() para informar a los observadoresque dejará de estar accesible.
33Objetivos
Para delimitar el alcance del proyecto, se detallan a continuación los objetivos, tanto ge-nerales como específicos, que permitirán comprender y entender la finalidad que se persiguecon el mismo.
3.1 Objetivo generalEl objetivo principal del proyecto es crear una herramienta flexible para la exploración
del entorno, desde la que podamos gestionar cualquier recurso accesible por red: sensores yactuadores, y también los servicios asociados a ellos: eventos, colecciones, servicios, etc. Sepretende poder interactuar con todos los elementos que compongan nuestra red a través deinternet, con independencia del disposivo empleado y su localización.
3.2 Objetivos específicosSe distinguen los siguientes objetivos específicos:
3.2.1 Estudio del desarrollo de aplicaciones distribuidas mediante el middle-ware orientado a objetos ZeroC Ice
La comunicación entre los diversos objetos que configuren la red que queremos explorarse realizará a través del middleware ZeroC Ice [ICEb], por tanto se hace indispensable laperfecta comprensión del funcionamiento de dicho middleware. Para alcanzar este objeti-vo se realizarán pequeños ejemplos prácticos que permitan comprender la estructura de lascomunicaciones entre publicadores y suscriptores.
3.2.2 Estudio y comparativa de las tecnologías existentes para la comunica-ción cliente/servidor a través de la web
Se realizará un estudio comparativo de las diferentes maneras de comunicación cliente-servidor a través de la web (AJAX, Polling, Long Poling, Websockets) que nos permita selec-cionar la tecnología que más se adecúe a nuestros objetivos de optimización de los recursosconsumidos por la herramienta.
27
3. OBJETIVOS 28
3.2.3 Estudio de los diferentes frameworks de pruebas disponibles para eldesarrollo de aplicaciones web
Se realizará un estudio de los distintos frameworks disponibles que permitan ejecutar prue-bas unitarias contra motores Javascript [JS] de navegadores reales con objeto de encontrarel que más de adecúe a las necesidades específicas del proyecto.
3.2.4 Programación de un servidor genérico capaz de recibir informaciónde los objetos distribuidos independientemente del controlador al quese asocien y de transmitirla al cliente web y viceversa
El pilar fundamental de este proyecto es el desarrollo de un servidor web en Python queactúe de intermediario entre los objetos distribuidos de la red y el usuario final. Este servi-dor actuará como controlador de todos los eventos que se intercambiarán entre los distintoscomponentes de la herramienta.
3.2.5 Aplicación web de monitorización que permita representar de maneraversátil los objetos que conforman la red y visualizar los eventos decomunicación entre ellos
Se desarrollará una aplicación web con las tecnologías HTML5 y jQuery [JQU] para poderinteractuar remotamente con los objetos registrados en la red, visualizar sus estados,los even-tos de comunicación entre ellos, el registro de nuevos elementos, etc. Dicha aplicación serácompletamente dinámica y flexible, e independiente del dispositivo o navegador que utilicepara conectarse al servidor.
44Método de trabajo y herramientas
En esta sección se describen brevemente la metodología de desarrollo empleada, así comolas herramientas software y hardware utilizadas para la elaboración del proyecto.
4.1 Metodología de trabajoDesde el inicio de este proyecto quedan especificados los requisitos fundamentales que
debe satisfacer el sistema. Estos requisitos se dividen en tareas que compondrán las diferentesiteraciones del desarrollo. El resultado de cada iteración se irá añadiendo a los requisitossatifechos en las iteraciones anteriores. Es por esto que la metodología de desarrollo utilizadahaya sido el Prototipado Incremental, complementado con la metodología TDD.
4.1.1 Prototipado IncrementalEl Prototipado Incremental [Som06] se basa en la generación de varios modelos parcia-
les ejecutables del sistema, expuestos a los comentarios del usuario, refinándolos a través delas distintas versiones hasta alcanzar el producto final. El hecho de que el cliente reciba losprototipos funcionales ayuda a comprobar el cumplimiento de todos los requisitos, pudiendoa su vez modificarlos o añadir alguno nuevo.
El esquema general de esta metodología se muestra en la figura 4.1 [Som06]. En cadaiteración, se definen nuevas funcionalidades del sistema, se describen más detalladamente yse desarrollan. El prototipo obtenido se integra en el sistema y se entrega al cliente.
Las ventajas de utilizar esta metodología se pueden resumir en:
Los clientes no tienen que esperar a que se entregue el sistema completo para poderutilizarlo y sacarle provecho. El primer prototipo satisface los requisitos más críticosy se puede utilizar el sistema inmediatamente.
Como las principales funcionalidades se entregan en las primeras iteraciones, son laparte del sistema sobre el que más pruebas se realizan, aumentando la fiabilidad yrobustez del sistema.
El desarrollo de prototipos intermedios hace más fácil determinar si los nuevos requi-sitos planteados en las posteriores iteraciones son correctos y viables.
29
4. MÉTODO DE TRABAJO Y HERRAMIENTAS 30
Figura 4.1: Diagrama de flujo del prototipado incremental
El riesgo de errores es muy bajo y los fallos son localizados y solucionados más rápi-damente. En cada iteración no sólo se prueba el prototipo realizado en ese momento,se vuelven a pasar las pruebas de las iteraciones anteriores para asegurar que el nuevoprototipo cumple también con las funcionalidades ya desarrolladas.
A pesar de las ventajas que proporciona el hecho de que el cliente participe activamentedurante todo el proceso de desarrollo, también puede acarrear alguna desventaja, como quelos requisitos varíen continuamente por las nuevas funcionalidades que el cliente vaya de-mandando. Este inconveniente puede dar lugar a un mantenimiento más costoso debido a loscambios en las especificaciones.
4.1.2 Desarrollo Dirigido por PruebasEl Desarrollo Dirigido por Pruebas, del inglés Test Driven Development (TDD) es una
práctica de programación ágil basada en la relización de las pruebas antes de la propia escri-tura del código a probar.
El algoritmo TDD se limita a tres pasos:
Escritura de la prueba para uno y sólo uno de los requisitos.
Implementación del código que satisfaga la prueba.
Refactorización del código obtenido hasta el momento para eliminar duplicidades.
Esta técnica cuenta con mútiples ventajas respecto a técnicas más tradicionales. Destacan-do entre ellas:
El código implementado es el mínimo necesario para satisfacer un requisito. No haycódigo innecesario.
Los errores se detectan y localizan muy fácilmente.
Se obtiene un código altamente reutilizable.
4. MÉTODO DE TRABAJO Y HERRAMIENTAS 31
El tiempo dedicado a depuración desaparece.
Gracias a estas ventajas, desde el inicio del proyecto se optó por esta técnica para llevar acabo la su implementación.
4.2 Herramientas4.2.1 Lenguajes de ProgramaciónPython - lenguaje de programación interpretado, multiparadigma, orientado a objetos y
multiplataforma. Empleado para la implementación del servidor web, los modelos ylos controladores de los objetos [PYT].
HTML - lenguaje de marcado para el desarrollo de páginas web utilizado para la imple-mentación de las vistas [HTM].
JavaScript - lenguaje de programación interpretado, orientado a objetos, que se utiliza prin-cipalmente para el lado del cliente en aplicaciones web [JS].
4.2.2 Aplicaciones de DesarrolloZeroC Ice - middleware de comunicación orientado a objetos desarrollado por la empresa
ZeroC [ICEb].
GNU Emacs - editor de texto utilizado para la programación y documentación del proyec-to [EMA].
Eclipse - entorno de programación [ECL] utilizado para la realización de las pruebas unita-rias del código JavaScript mediante el plugin jsTestDriver [JTD].
Mercurial - sistema de control de versiones multiplataforma empleado durante todo el desa-rrollo del proyecto [MER].
Atheist - framework de pruebas utilizado para la elaboración de las pruebas de integracióndel proyecto [ATH11].
Dia - herramienta de propósito general destinada a la creación de diagramas, utilizado parala creación de los diagramas que se muestran en la documentación final [dia].
GNU Make - herramienta para la generación automática de ejecutables [SMS06].
4.2.3 DocumentaciónLATEX - lenguaje de marcado de documentos de carácter técnico y científico, utilizado para
la elaboración de este documento [CLM+03].
BibTex - herramienta para generar las listas de referencias de documentos escritos conLATEX.
4. MÉTODO DE TRABAJO Y HERRAMIENTAS 32
4.2.4 Gestión de proyectoRedmine - Aplicación web para la gestión de proyectos. Mediante esta herramienta se han
establecido las tareas a realizar a lo largo del ciclo de vida del proyecto [RED12].
4.2.5 Recusos HardwareProcesador: Intel Core 2 Quad CPU Q6600 @ 2.40GHz x4
Memoria: 3,9 GiB
55Desarrollo del proyecto
En este capítulo se describe la planificación y el desarrollo completo del proyecto. Seexponen cada uno de los requisitos y el diseño de las soluciones encontradas a cada uno deellos en las diferentes iteraciones. Asimismo, se detallan las pruebas realizadas para validarel cumplimiento de dichos requisitos.
5.1 Especificación de requisitosComo ya se señaló en la sección 3.1, el objetivo principal del proyecto es crear una he-
rramienta flexible para la exploración del entorno, desde la que podamos gestionar cualquierrecurso accesible por red: sensores y actuadores, y también los servicios asociados a ellos:eventos, colecciones, servicios, etc.
Se definen por tanto los siguientes requisitos:
Conociendo el proxy de un objeto se podrá inspeccionar y modificar su estado.
El servidor enviará a los clientes cambios de estado de un objeto automáticamente, sinque el usuario tenga que solicitar una actualización.
Cada objeto se podrá representar con varias vistas diferentes. Será decisión del usuarioelegir cuál quiere emplear en cada momento.
Se podrán visualizar en la misma página web tantos objetos como se quiera.
Un objeto podrá estar representado en el sistema con varios modelos diferentes.
El usuario podrá seleccionar el modelo del objeto con el que desee trabajar.
Desde el navegador se podrá modificar el observador de un objeto activo.
La página principal estará dividida en dos paneles para facilitar la visualización devarios objetos a la vez.
El sistema debe poder mostrar contendedores de objetos.
El usuario podrá añadir desde el navegador cualquier objeto a un contenedor.
Debe poder visualizarse la lista de canales activos en el sistema a través del gestor decanales de IceStorm.
33
5. DESARROLLO DEL PROYECTO 34
Se podrá visualizar el canal de anunciamientos, obteniendo en tiempo real la lista delos objetos que se van anunciando.
Desde la vista de un contenedor o del canal de anunciamientos también se podrá abrirla vista de otro objeto.
5.2 Casos de usoAnalizando detenidamente los requisitos se obtienen los casos de uso que tendrá el siste-
ma. La figura 5.1 muestra el diagrama de dichos casos de uso.
Figura 5.1: Diagrama de Casos de Uso
A continuación se describen más detalladamente cada uno de esos casos de uso.
Inspeccionar un objeto simpleDado un proxy a un objeto introducido por parte del usuario en el navegador, el servi-dor web será capaz de identificar dicho objeto en la red de objetos distribuidos, crearsu modelo (u obtenerlo si el modelo se creó con anterioridad), y devolver la vista orepresentación de dicho objeto al navegador con información del estado actual.
5. DESARROLLO DEL PROYECTO 35
Cualquier cambio en el estado objeto se debe mostrar automáticamente en los clientesque lo estén inspeccionando.
Actualizar estado de un objetoLos objetos representados en el navegador podrán ser susceptibles de cambios en suestado por parte del usuario.
Cambiar de vista de un objetoEl sistema debe dar soporte al usuario para que pueda seleccionar el tipo de vista conel que desea inspeccionar un objeto.
Obtener propiedades de un objetoTodos los objetos ICE implementan la interfaz ::Ice::Object, a través de la cual puedenobtenerse sus propiedades específicas. El sistema debe ser capaz de representar unobjeto a través de un modelo genérico que proporcione estas características.
Cambiar de modelo de un objetoUn mismo objeto, en función de las distintas interfaces que implemente, puede serrepresentado en el sistema con varios modelos diferentes. Será elección del usuarioseleccionar el modelo de representación de un objeto en cualquier momento para poderrealizar unas acciones u otras en función de las permitidas por cada modelo.
Asignar un nuevo observador para un objeto activoLos objetos activos poseen observadores que reciben sus cambios de estado. El sistemadebe permitir la actualización de estos observadores.
Inspeccionar objeto contenedorLos contenedores son objetos especiales que agrupan varios objetos en su interior (con-tenedores o no). Se debe poder representar este tipo de objetos en el navegador.
Añadir objeto a un contenedorEl usuario debe poder configurar los contenedores presentes en el sistema añadiendonuevos objetos a los mismos.
Visualizar lista de canales activosEl sistema deberá conocer y ser capaz de listar los canales de comunicación entreobjetos activos en un determinado momento.
Subscripción al canal de anunciamientosEl canal de anunciamientos es un canal especial en el que los objetos se registran paraanunciar su presencia en el sistema. Éste debe permitir la subscripción para la posteriorexploración del contenido de dicho canal.
5. DESARROLLO DEL PROYECTO 36
5.3 DiseñoEstudiados los requisitos e identificados los diferentes casos de uso, se procede a la fase
de diseño del sistema. Por su naturaleza, este proyecto se ajusta perfectamente al patrón dearquitectura Modelo Vista Controlador (MVC). La figura 5.2 muestra un esquema sencillode este patrón.
Figura 5.2: Patrón de arquitectura Modelo Vista Controlador [MVC11]
Los Modelos serán la representación interna de los objetos físicos en el sistema. Un mismoobjeto podrá estar representado por varios modelos diferentes que implementen distintasinterfaces para poder interactuar con él.
Las diferentes páginas web con las que el usuario podrá interactuar serán las Vistas delsistema. Cada uno de los modelos podrá a su vez ser representado por distintas vistas, y seráelección del usuario la vista con la que trabajar en cada momento.
Por último, los Controladores estarán integrados en el servidor web, que será el enlace en-tre los objetos físicos y los usuarios por medio de los modelos y las vistas respectivamente.El servidor se encargará de procesar las peticiones de los usuarios y proporcionales la in-formación que necesiten de los distintos objetos suministrándoles las vistas asociadas a susmodelos.
5.4 ImplementaciónEl desarrollo de este proyecto está dividido en diferentes iteraciones. En cada una de estas
iteraciones se van añadiendo nuevas funcionalidades que aportarán las operaciones necesa-rias hasta llegar al sistema o prototipo final.
5.4.1 Modelo y vista de objetos simplesAnálisis y Diseño
La función básica del sistema es poder inspeccionar y modificar el estado de los objetosdistribuidos que componen una red a través de internet. Se deben crear los modelos que
5. DESARROLLO DEL PROYECTO 37
representarán los tipos de objetos más básicos (booleanos y enteros), unas vistas simplespara la representación visual al usuario, y un servidor web que recoja las peticiones de losclientes y las traslade a los modelos de los objetos.
La figura 5.3 muestra el diagrama de secuencia de este proceso. A partir del proxy de unobjeto, el sistema debe ser capaz de crear un modelo que represente dicho objeto y devolveral usuario una vista con la que pueda interactuar y modificar o consultar su estado a travésde su controlador.
Figura 5.3: Diagrama de secuencia de la creación de un modelo y controlador para un objetoa partir de su proxy
Para que los modelos almacenados en el sistema puedan interactuar con los dispositivos fí-sicos que representan, deben implementar las mismas interfaces que ellos. En el caso concre-to de este proyecto, se utiliza un modelo de información denominado Distributed UniversalObjects (DUO), introducido en la sección 2.4.
module DUO {
module IBool {interface R { ["freeze:read", "ami"] idempotent bool get(); };interface W { ["freeze:write", "ami"] void set(bool v, Ice::Identity
oid); };};
module IByte {interface R { ["freeze:read", "ami"] idempotent byte get(); };interface W { ["freeze:write", "ami"] void set(byte v, Ice::Identity
oid); };};
};
Listado 5.1: Interfaces implementadas por los modelos booleano y entero
5. DESARROLLO DEL PROYECTO 38
En el SLICE de DUO (Anexo A.1) se listan las interfaces que implementan los objetos quese tratarán de representar. Los modelos booleano y entero implementan respectivamente lasinterfaces de los módulos IBool e IByte. En el listado 5.1 se muestran estos dos módulos.Ambos implementan únicamente dos interfaces: R de lectura y W de escritura, cada una deellas con un único método (get o set respectivamente), para poder consultar o establecer suestado.
Implementación
En primer lugar se lleva a cabo la implementación de las pruebas unitarias necesariasutilizando las herramientas nose [NOS] para las pruebas de los modelos y controladores yjsTestDriver [JTD] para las pruebas de los scripts integrados en las vistas.
El Servidor recibirá desde el navegador la petición de inspección de un objeto, y paraello se le facilitará su proxy. A través de este proxy, el Servidor invocará a una Factoría
de Modelos, que comprobará si ese objeto pertenece ya al sistema, en cuyo caso devolverásu modelo previamente creado, o no, donde creará su modelo correspondiente. Para saberqué modelo le corresponde a cada proxy, se consulta al objeto por sus facetas particulares.Previamente, se habrán registrado en dicha Factoría todos los modelos soportados por elsistema.
En el listado 5.2 se muestra un ejemplo de las pruebas unitarias implementadas para ob-tener el código de la Factoría. En este caso, se muestra una prueba del registro del ModeloBooleano, y otra de la creación de un modelo a partir de un proxy.
class TestModelFactory(TestCase):def test_resgister_BoolModel(self):
ModelFactory.register(BoolModel)self.assertTrue(BoolModel in ModelFactory.models)
def test_create_Model(self):model = ModelFactory.create(proxy)self.assertEquals(model, [’BoolModel’])
Listado 5.2: Ejemplo de pruebas unitarias para la factoría de modelos
Por otro lado, en el listado 5.3 se observan las pruebas para obtener el código inicialde los primeros Modelos, en concreto un modelo Booleano. Si dado un proxy, el modelocorrespondiente puede manejarlo por compatibilidad de interfaces, la Factoría se encargaráde crear un modelo de ese tipo para ese proxy. Estas interfaces son ’::DUO::IBool::R’ y’::DUO::IBool::W’.
Como ya se ha especificado, tras las pruebas unitarias se implementa el código que satis-face dichas pruebas y, por tanto, los primeros requisitos. En el listado 5.4 se detalla el código
5. DESARROLLO DEL PROYECTO 39
class Test_BoolModel(unittest.TestCase):def test_can_manage(self):
self.assertTrue(models.BoolModel.can_manage(’proxy’))
Listado 5.3: Ejemplo de pruebas unitarias para los primeros modelos
de la Factoría de Modelos y del inicial Modelo Booleano, que únicamente cuenta con losmétodos get() y set(value), propios a su naturaleza, y el método can_manage(proxy), que dasoporte a la Factoría para conocer qué modelo es adecuado para representar cada objeto,comprobando si el proxy que se le pasa como argumento implementa las mismas interfacesque el modelo.
class ModelFactory:models = []cache = {}
@classmethoddef register(cls, model):
cls.models.append(model)
@classmethoddef create(cls, proxy):
if proxy in cls.cache:return cls.cache[proxy]
for model_cls in cls.models:if model_cls.can_manage(proxy):
model = model_cls(proxy)cls.cache[proxy] = modelreturn model
class BoolModel():def __init__(self, proxy):
self.proxy = proxy
def get(self):proxy=DUO.IBool.RPrx.checkedCast(self.proxy)return str(proxy.get()).lower()
def set(self, value):proxy=DUO.IBool.WPrx.checkedCast(self.proxy)proxy.set(value == "true", Ice.Identity())
@classmethoddef can_manage(cls, proxy):
typeids = proxy.ice_ids()return ’::DUO::IBool::R’ in typeids or ’::DUO::IBool::W’ in
typeids
Listado 5.4: Código de la Factoría de Modelos y del Modelo Booleano
A continuación se define el tipo de invocación que recibirá el Servidor para saber que elusuario desea inspeccionar un objeto concreto:
server_IP:8090/handler/?proxy=proxy_del_objeto
5. DESARROLLO DEL PROYECTO 40
A partir de esta especificación concreta de URL se realizan las pruebas unitarias que deberásatisfacer el Servidor para ser capaz de obtener el proxy al objeto, invocar a la Factoría
de Modelos y devolver al cliente la vista correspondiente. Posteriormente se implementa elcódigo del servidor inicial, que se detalla en el listado 5.5. Cuando llega una petición deinspección de un objeto, el Servidor invoca a la Factoría de Modelos para crear u obtener elmodelo del objeto. A continuación se registra dicho modelo en el adaptador de objetos paraque pueda recibir invocaciones remotas, y se invoca a la Factoría de Vistas. Esta otra factoríacumple la misma función que la de modelos pero con las vistas finales. Para cada modelo seobtiene la vista que mejor le puede representar en el navegador.
class ObjectProxyHandler(web.RequestHandler):def get(self):
path = self.request.arguments.get(’proxy’)[0]proxy = Server.ic.stringToProxy(path)model = models.ModelFactory.create(proxy)model.setup(Server.adapter)view = views.ViewFactory.create(model)pag = view.get_template()nam = str(proxy.ice_getIdentity().name)self.render(pag, name=nam, href=proxy)
class Server(Ice.Application, web.Application):def run(self, args):
Server.ic = ic = self.communicator()Server.adapter = ic.createObjectAdapterWithEndpoints(’
InspectioAdapter’, ’default’)Server.adapter.activate()app = web.Application([
(r"/handler/", ObjectProxyHandler),])
app.listen(8090)self.shutdownOnInterrupt()ioloop.IOLoop.instance().start()
Listado 5.5: Código inicial del Servidor
Para facilitar al usuario el tener que componer manualmente la URL de petición al Ser-vidor, se diseña una página inicial a la que se accede a través de la dirección IP de dichoServidor y el puerto en el que está escuchando (http://serverIP:8090). Esta página cuentaúnicamente con un cuadro de texto y un botón, para que el usuario introduzca el proxy delobjeto en el primero y realice la petición al hacer clic en el segundo. El script asociado aesta página inicial compondrá la URL con el formato y el parámetro requerido, y realizará lapetición.
El siguiente paso es definir el comportamiento de la vista respecto del modelo. Es decir,qué ocurrirá cuando el usuario desee actualizar o realizar un cambio de estado del objetodesde el navegador. Un ejemplo de las pruebas unitarias realizadas con este fin se detalla enel listado 5.6. El diseño inicial de la vista booleana simplemente cuenta con un checkbox y
5. DESARROLLO DEL PROYECTO 41
dos botones para actualizar o asignar un nuevo estado al objeto, mientras que el de la vistade un objeto entero, muestra un textbox donde introducir manualmente el valor que se lequiere otorgar al objeto, y donde se carga el valor que devuelve el servidor tras una peticiónde actualización.
QueueTest = AsyncTestCase("QueueTest");QueueTest.prototype.setUp = function() {
$("body").append("<input type=’checkbox’ id=’stateDevice’ model=’BoolModel’ name=’Hello1’ " +
"href=’Hello1 −t:tcp −h 127.0.0.1 −p 8889’/>" +"<button class=’button’ id=’upButton’ name=’Hello1’
onClick = refresh\_state(name)>Actualizar</button> "+
"<button class=’button’ id=’setButton’ name=’Hello1’onClick = set\_state(name)>Asignar</button>");
};
QueueTest.prototype.testGetTrue = function(queue) {queue.call(’Paso 1: hacer la llamada al refresh’, function() {
$(’#upButton’).click();});queue.call(’Paso 2: esperar un segundo’, function(callbacks) {
var myCallback = callbacks.add(function() { });
window.setTimeout(myCallback, 1000);});queue.call(’Paso 3: comprobar que el valor es true’, function() {
assertTrue($(’#stateDevice’).is(’:checked’));});
};};
Listado 5.6: Ejemplo de pruebas unitarias sobre el script de la vista del modelo booleano
function set_resource() {var ws = new WebSocket(’ws://localhost:8080/inspect−element/?proxy=’+
$(’#stateDevice’).attr(’href’));ws.onopen = function() {
ws.send(’set:’ + $(’#stateDevice’).is(’:checked’));};ws.onmessage = function (message) {
var data = message.data;$(’#stateDevice’).attr(’checked’, data==’true’);};
};
Listado 5.7: Código del script de una vista para un modelo booleano
Como se explicó en la sección 2.1.4, la implementación de la comunicación entre las vistasy los modelos se realiza a través de WebSockets. Por tanto, el Controlador será un objeto deeste tipo que se creará tras la primera interacción del usuario con la vista del modelo quehaya solicitado al servidor. El listado 5.7 muestra un ejemplo de cómo funciona este tipode objetos desde el lado del cliente. En concreto, qué ocurre cuando el usuario hace clic en
5. DESARROLLO DEL PROYECTO 42
el botón de asignar un estado. Se define el nuevo WebSocket creando una URL a partir delproxy del objeto que se está inspeccionando, y se envía una cadena de caracteres que indicael método a invocar seguido del valor que desea asignarse.
Por su parte, en el servidor, tras las pruebas oportunas, se añade un nuevo manejador paraatender las llamadas desde el navegador al controlador del modelo ya creado y representa-do:
(r/inspect-element/", controllers.ControllerFactory(Server.ic)),
Este nuevo manejador, tras la petición de apertura del WebSocket pasa el control a laFactoría de Controladores que crea el controlador para esa vista y ese modelo, o lo invocapara que realice una petición o actualización del modelo correspondiente en el caso de queya estuviera creado (listado 5.8).
class ControllerFactory:def __init__(self, ic):
self.ic = ic
def create(self, ∗args):return Websocket(self.ic, ∗args)
def __call__(self, ∗args):return self.create(∗args)
class Websocket(websocket.WebSocketHandler):def __init__(self, ic, ∗args):
websocket.WebSocketHandler.__init__(self,∗args)path = self.request.arguments.get(’proxy’)[0]proxy = ic.stringToProxy(path)self.model = models.ModelFactory.create(proxy)self.model.set_controller(self)
def on_message(self, msg):method, param = msg.split(’:’)if method == ’get’:
status = self.model.get()self.write_message(status)
else:self.model.set(param)
Listado 5.8: Factoría de Controladores y controlador inicial
Cuando el Controlador recibe un mensaje, analiza su estructura para determinar qué ac-ción debe realizar sobre el modelo. Como ya se ha comentado, en este punto del desarrollolos mensajes entre la Vista y el Controlador se limitan a una cadena de caracteres donde seespecifica el método (get o set) y el parámetro o valor necesario (en el caso del set).
5. DESARROLLO DEL PROYECTO 43
5.4.2 Modelo y vista de objetos activosAnálisis y Diseño
Para que un controlador pueda actualizar la vista de un modelo cada vez que éste sufreuna modificación sin necesidad de que el usuario solicite una actualización desde el nave-gador, es necesario que el modelo implemente la interfaz ::DUO::Active (sección 2.4.1) yesté subscrito al observador del dispositivo físico que representa, que como ya se explicópuede ser otro objeto o un canal de eventos. Además, el propio modelo debe contar con unmecanismo de actualización que se encargue de transmitir los datos recibidos al controladorpara que a través del WebSocket envíe asíncronamente dichos datos a la vista. La Figura 5.4representa el diagrama de secuencia de este proceso.
Figura 5.4: Diagrama de secuencia de actualización de la vista de un objeto Activo
En esta iteración se dará soporte a todo este proceso automático, y se creará un nuevomodelo (Modelo Activo) con su propia vista, en la que se le facilitará al usuario la posibilidadde conocer el proxy al Observador del objeto y de establecer un nuevo observador si lodesea.
El análisis de los requisitos pone de manifiesto la necesidad de utilizar un servicio deeventos que de soporte a la comunicación entre los objetos y sus observadores, y permita lasubscripción de los modelos a dichos observadores. El servicio que nos proporciona todasestas funcionalidades es IceStorm.
En la sección 2.3.1 se introdujo brevemente el servicio IceStorm de publicación y subs-cripción para aplicaciones ICE.
Un objeto indica su interés en recibir mensajes subscribiéndose a un topic. Un publicadorutiliza el proxy al topic para enviar sus mensajes, y estos llegan a todos los subscriptores dedicho topic (Figura 5.5). El servicio IceStorm soporta cualquier número de topics, creadosdinámicamente y distinguidos por un nombre único.
5. DESARROLLO DEL PROYECTO 44
Figura 5.5: Arquitectura de IceStorm
Implementación
Se divide esta iteración por tanto en dos partes diferentes.
Subscripción del modelo al observador del objeto
Para alcanzar el primer objetivo de esta nueva iteración, el primer paso es conseguirque tras la creación de un nuevo modelo a través de un proxy, éste se subscriba alobservador del objeto.
A continuación, tras el desarrollo de las pruebas pertinentes, se define una clase Liste-
ner para cada modelo, que implementa la misma interfaz que él susceptible de recibircambios (por ejemplo la interfaz IBool.W en el caso de los objetos booleanos con sumétodo set(value)). El listado 5.9 muestra el código de una de estas clases Listener.
Al inicializar una instancia de esta clase, se le asigna una función callback. En estecaso esa llamada corresponde a una notificación al controlador. Cuando el dispositivomodifique su estado a través de un set, publicará esa modificación en su observador,y de ahí se difundirá a todos los elementos que estén subscritos y, en concreto, alListener, que a través del callback invocará al WebSocket para que actualice la vista.
class IBoolListener(DUO.IBool.W):def __init__(self, cb):
self.cb = cb
def set(self, value, identity):self.cb(value)
Listado 5.9: Clase Listener para el modelo booleano
Cuando el servidor proceda a la creación de un modelo, junto a él se creará su listener,añadiéndolo al adaptador de objetos para que pueda recibir invocaciones remotas. Acontinuación se subscribe este Listener al observador del dispositivo para poder recibirtodas las modificaciones que se realicen sobre él en tiempo real. El listado 5.10 muestrala función que realiza todo este proceso.
5. DESARROLLO DEL PROYECTO 45
Sabemos que los observadores por defecto de los dispositivos que implementan lainterfaz ::DUO::Active son canales de eventos, así que tras la llamada al método ge-tObserver(), que devuelve una referencia a un Objeto, se realiza la conversión paraobtener el proxy a ese canal, y se subscribe el Listener a él.
def setup(self, adapter):if self.listener is not None:
returnself.listener = adapter.addWithUUID(IBoolListener(self.notify))self.active = DUO.Active.RPrx.checkedCast(proxy)observer = self.active.getObserver()topic = observer.ice_facet("topic")topic = IceStorm.TopicPrx.uncheckedCast(topic)topic.subscribeAndGetPublisher(None, self.listener)
Listado 5.10: Creación del Listener y subscripción al observador del modelo
En este punto de la implementación, el usuario ya no necesita solicitar manualmenteuna actualización de la vista para comprobar si el objeto ha cambiado su estado o no.Gracias al controlador, cuando se produzca cualquier cambio, éste será notificado enel navegador en tiempo real.
Creación del modelo y vista para objetos activos
Por otro lado, es requisito de esta iteración la creación de un modelo especial pararepresentar los Objetos Activos que implemente las interfaces que permiten consultarel observador y asignar uno nuevo, que son ::DUO::Active::R y ::DUO::Active::Wrespectivamente (ver listado 5.11).
module Active {interface R {
["ami"] Object∗ getObserver();};interface W {
["ami"] void setObserver(Object∗ observer);};
};
Listado 5.11: Slice de los objetos activos
La Vista para este nuevo modelo únicamente precisa mostrar el observador, y un text-box donde el usuario pueda introducir el proxy al objeto que quiera establecer comonuevo observador del objeto.
Ahora, un mismo objeto puede estar representado por varios modelos diferentes, debidoa que, como se ha visto, las distintas interfaces no son incompatibles, de manera que undispositivo puede verse como una instancia de un modelo booleano y un modelo activo a lavez. Este hecho da lugar al replanteamiento del formato de las URL para solicitar la vista de
5. DESARROLLO DEL PROYECTO 46
un objeto al servidor, ya que depende del modelo con el que se desee trabajar, éste devolveráal cliente una u otra.
Se define por tanto un nuevo formato de URL:
server_IP:8090/handler/?proxy=proxy_del_objeto&model=modelo_del_objeto
Donde, además del proxy que se desea inspeccionar, se especifica el modelo concretocon el que se quiere trabajar en función de si el objetivo es consultar o modificar el estadodel dispositivo (en cuyo caso se elegiría el Modelo Booleano o el Modelo Entero), o si loque se desea es conocer el observador de dicho dispositivo o asignarle uno nuevo (ModeloActivo).
Cuando el Servidor reciba una petición por parte del usuario, a partir del proxy creará,gracias a la Factoría, una lista de modelos compatibles con las interfaces del objeto al quehace referencia ese proxy, y en función del modelo que el usuario haya solicitado, devolveráuna vista u otra.
En el caso de que el usuario sólo conozca el proxy al objeto, pero no sepa con certeza lasinterfaces que implementa, y por tanto, los modelos con los que el sistema puede represen-tarlo, puede hacer la petición indicando que el modelo que desea recibir sea el modelo pordefecto:
server_IP:8090/handler/?proxy=proxy_del_objeto&model=default
el Servidor, en ese caso, devolverá el modelo establecido como tal en el sistema.
Desde la página principal a la que el usuario puede acceder indicando únicamente la di-rección del servidor y el puerto, siempre que se busca un objeto por su proxy, el modelodevuelto es el modelo por defecto.
5.4.3 Serialización JSON en ambos sentidosAnálisis y Diseño
A medida que el número de modelos aumenta en el sistema, cada uno con sus propiasinterfaces, se hace necesario definir un protocolo para el formato e intercambio de los datos,que hasta ahora se limita a una cadena de caracteres compuesta por el método a invocar y losargumentos necesarios en su caso.
El formato seleccionado para llevar a cabo esta tarea es JavaScript Object Notation (JSON),subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML,altamente difundido en los medios de programación por su simplicidad.
En esta iteración se requiere que los modelos y las vistas sean capaces de comunicarse conel controlador a través de mensajes codificados en JSON, todos ellos con la misma estructura,
5. DESARROLLO DEL PROYECTO 47
permitiendo la estandarización de la comunicación.
Implementación
Para la comunicación Vista-Controlador se define el formato de mensaje descrito en ellistado 5.12, donde se indican el modelo del objeto a invocar, la función que desea ejecutarsey los argumentos de dicha función en caso de necesitarlos.
{’model’ : ’object_model’,’method’ : ’function_to_invoke’,’param’ : ’function_arguments’
}
Listado 5.12: Formato de mensaje para el intercambio de información en el sistema
Cuando el Controlador recibe un mensaje a través del WebSocket, en primer lugar deco-difica dicho mensaje para obtener el Modelo con el que la vista está interactuando y delegardirectamente en él el procesamiento de los datos recibidos. La función que se encarga de estadecodificación se detalla en el listado 5.13.
def unmarshall(msg):message = json.loads(msg)method = message["method"]param = message["param"]model = message["model"]return method, param, model
Listado 5.13: Función que recibe un mensaje en JSON y lo decodifica
En sentido inverso, cuando un modelo invoca al controlador para que actualice la vis-ta, codifica los datos en un mensaje similar al anterior que se transmite por el WebSoc-ket y se decodifica al llegar al cliente de manera trivial gracias a la función de JavaScriptJSON.parse().
5.4.4 División de la página principal en dos panelesAnálisis y Diseño
Una de las características del sistema final es que permita al usuario interactuar con variosobjetos a la vez sin necesidad de tener abiertas múltiples páginas web en el navegador (unapor cada dispositivo).
Para alcanzar este objetivo, se diseña una nueva página principal cuyo contenido central sedivide en dos paneles, donde se cargarán las vistas de los objetos que se vayan solicitando.Para que cada panel pueda albergar las vistas de varios dispositivos a la vez, cada una deellas se cargará en una pestaña.
5. DESARROLLO DEL PROYECTO 48
Implementación
El listado 5.14 muestra un fragmento de la estructura de la nueva página principal. Losnombres de los objetos cargados se añaden a las listas de dispositivos, y las vistas se carganen los paneles asociados a esas listas.
<div id="principal"><div id="tabs−1">
<ul id="devices−1"><!−− Lista de dispositivos en el panel de la izquierda −−></ul><div id = "tabcontent−1"><!−− Vistas de los objetos en el panel de la izquierda −−></div>
</div><div id="tabs−2">
<ul id="devices−2"><!−− Lista de dispositivos en el panel de la derecha −−></ul><div id = "tabcontent−2"><!−− Vistas de los objetos en el panel de la derecha −−></div>
</div></div>
Listado 5.14: Fragmento de la plantilla HTML de la página principal
El aspecto final de pestañas seleccionables se consigue mediante la definición de hojas deestilo en cascada (Cascading Style Sheets (CSS)).
Un mismo dispositivo se carga en ambos paneles a la vez, lo que genera duplicidad deidentificadores en una misma página. Este problema se soluciona añadiendo un sufijo a cadaidentificador que se carga en la página principal.
5.4.5 Modelo y vista de objetos genéricosAnálisis y Diseño
Todos los objetos ICE, independientemente de las interfaces que implementen, tienen unaserie de propiedades o atributos que los diferencian e identifican de manera única en el sis-tema. Esto se debe a que todos ellos implementan por defecto la interfaz ::Ice::Object.
Se desea poder representar cada elemento con un Modelo Objeto que permita acceder atodas las propiedades inherentes a dicho objeto. La Vista de este modelo representará en unatabla esos atributos.
Implementación
Se define el Modelo Objeto, que implementa la interfaz ::Ice::Object (listado 5.15). Estemodelo es sólo de lectura, ya que las operaciones que proporciona su interfaz únicamentesirven para descubrir propiedades del objeto, y no para modificarlas o cambiar su estado.Por tanto, se implementa una vista compuesta únicamente por la plantilla HTML donde se
5. DESARROLLO DEL PROYECTO 49
cargará la información correspondiente, sin necesidad de añadirle funcionalidad adicional nisoporte para la apertura de un WebSocket.
interface Object {idempotent void ice_ping();idempotent bool ice_isA(string typeID);idempotent string ice_id();idempotent StrSeq ice_ids();// ...
};
Listado 5.15: Parte del Slice de los objetos ICE [ICEb]
5.4.6 Soporte para el cambio de modelos y de vistasAnálisis y Diseño
Como se ha explicado anteriormente, un mismo objeto puede representarse en el sistemamediante varios tipos de modelos en función de las interfaces que implemente. En esta ite-ración se debe dar soporte para la selección, por parte del usuario, del modelo con el quedesea trabajar desde cualquier vista con la que esté interactuando, sin necesidad de realizaruna nueva petición al servidor indicando explícitamente el nuevo modelo.
Además, uno de los objetivos principales de este proyecto es que la herramienta finalsea completamente flexible e interactiva, de manera que el sistema debe proporcionar alusuario varias vistas diferentes por cada modelo para que el usuario seleccione la que más leconvenga, o con la que pueda trabajar más cómodamente.
Implementación
En primer lugar se procede a la creación de varias plantillas HTML diferentes para losmodelos booleano y entero. La funcionalidad ha de ser la misma para cada vista, sea cual seala que se esté utilizando en un momento dado, por tanto los scripts desarrollados hasta ahorase integran en las nuevas proporcionando los mismos servicios.
Una vez más se requiere la modificación del formato de URL para añadir un nuevo pará-metro, el de la vista seleccionada:
server_IP:8090/handler/?proxy=proxy_del_objeto&model=modelo_del_objeto&view=vista_seleccionada
De manera análoga a como se explicó en la sección 5.4.2 con los modelos, el sistema tienedefinidas unas vistas por defecto para cada modelo. Así, si el usuario no conoce el nombre decada vista, o le resulta indiferente con cuál empezar a trabajar, simplemente tiene que indicaren la petición ’view=default’.
Se añade a cada vista una lista seleccionable donde se carga la lista completa de vistas dis-ponibles para ese modelo, de manera que cuando el usuario seleccione alguna diferente a la
5. DESARROLLO DEL PROYECTO 50
que está visualizando en ese instante, automáticamente se realice una petición al servidor.
Para proporcionar soporte al cambio de modelos, el procedimiento es prácticamente idén-tico. Se provee a las vistas de una lista desplegable con los modelos disponibles para unobjeto, de manera que si el usuario selecciona alguno diferente del actual, se construirá unanueva petición al servidor indicando el proxy, el nuevo objeto y la vista por defecto de esemodelo.
Si la petición de un objeto se realiza desde la página principal a través del textbox, dondeúnicamente se introduce el proxy al objeto, el script asociado a la página construirá la URL
de la petición solicitando tanto el modelo como la vista por defecto.
5.4.7 Modelo y vista para contenedores de objetosAnálisis y Diseño
En esta iteración se debe crear un modelo para representar contenedores de objetos des-critos en la sección 2.4.2, y una vista para poder visualizarlos desde el navegador.
Además, se debe proporcionar al usuario la posibilidad de añadir nuevos objetos a uncontenedor ya creado.
Para poder llevar a cabo esta iteración, se requiere de un nuevo servicio que dé soporte ala creación de Contenedores de dispositivos. Este servicio se llama ContextService y estádesarrollado por el grupo ARCO.
Básicamente, lo que hace este servicio es crear un sirviente que implementa las interfacesdel módulo Container definida en el Slice de DUO (ver anexo A.1). A partir del proxy aeste sirviente se pueden crear y destruir contenedores, y listar, añadir y eliminar objetos acontenedores ya creados.
Implementación
En primer lugar se crea el Modelo Container que implementa las interfaces R, W y RW delmódulo DUO::Container (Listado5.16) y se definen en él las funciones de dicho módulo:
link(key, object): enlaza un nodo hijo a un contenedor.
unlink(key): elimina un nodo hijo del contenedor.
create(key): crea un nuevo nodo contenedor dentro del existente.
destroy(): elimina un contenedor y la asociacion con el padre.
list(): devuelve la lista de nodos hijo.
Se crea una vista sencilla en HTML donde se representa el contenedor que se quiere ins-peccionar en forma de árbol, donde el nodo raíz es el propio contenedor y los nodos hijosson los elementos que lo integran. Estos hijos pueden ser a su vez otro contenedor, u objetos
5. DESARROLLO DEL PROYECTO 51
module Container {interface RW;interface R { ["freeze:read", "ami"] idempotent ObjectPrxDict list();
};interface W {
["freeze:write", "ami"]void link(string key, Object∗ value) throws
AlreadyExistsException;["freeze:write", "ami"]
void unlink(string key) throws NoSuchKeyException;["freeze:write", "ami"]
Container::RW∗ create(string key) throws AlreadyExistsException;["freeze:write", "ami"]
void destroy();};interface RW extends R,W {};
};
Listado 5.16: Slice del módulo DUO::Container
de cualquier otro tipo. La funcionalidad básica de esta vista es visualizar todos los elemen-tos del contenedor y poder cargar en la interfaz principal cualquiera de ellos haciendo clicsobre su nombre, sin necesidad de realizar la petición manualmente. Por tanto, conociendoel proxy a un contenedor, el usuario tiene la capacidad de acceder a múltiples objetos sinnecesidad de conocer nada más de ellos que su nombre.
Además se define al contenedor, dentro de la vista, como objeto droppable, de manera quearrastrando hacia él el proxy de otro objeto, este lo recoja y envíe una petición al Servidorpara que añada dicho objeto a la lista de sus hijos.
5.4.8 Modelo y vista para el Topic Manager y el canal de anunciamientosAnálisis y Diseño
El sistema debe permitir al usuario obtener una lista de canales de eventos disponibles enla red distribuida. Esto es posible gracias al gestor de canales del servicio IceStorm. Estegestor se llama Topic Manager e implementa la interfaz ::IceStorm::TopicManager. Lasoperaciones más importantes que se pueden realizar con él son:
create(string name) : crea un nuevo canal.
retrieve(string name): devuelve un canal específico.
retrieveAll(): devuelve la lista completa de canales.
Por otro lado, el Canal de Anunciamientos es un tipo especial de canal (ver sección 2.5),en el que los objetos se registran al darse de alta en una red de objetos distribuidos. En elListado 5.17 se muestra la interfacez que implementa este tipo especial de topic. Cuentaprincipalmente con una función adv(proxy), que invocan los objetos para anunciarse a travésde su proxy.
5. DESARROLLO DEL PROYECTO 52
module ASD {interface Listener {
idempotent void adv(Object∗ prx);idempotent void bye(Ice::Identity oid);
};
};
Listado 5.17: Slice del canal de anunciamientos
En esta última iteración se debe crear un modelo para representar internamente al TopicManager y una vista en la que poder visualizar la lista completa de canales registrados en unmomento dado, pudiendo cargar la vista de alguno de ellos para acceder a su contenido.
Para poder acceder al contenido de un topic, o lo que es lo mismo, para poder visualizar loseventos que los publicadores envían al canal, y más concretamente, para poder inspeccionaren tiempo real los anunciamientos de los objetos en el canal de anunciamientos, se debecrear un modelo que represente el canal, y una vista en la que se carguen automáticamentelos proxies de los objetos que se registren para poder desde ella cargarlos en el navegador.
Implementación
Modelo y vista del Topic Manager
Se define un nuevo modelo en el sistema, el Modelo TopicManager. A través del proxyal gestor de canales, se creará la instancia de este modelo para poder comprobar la listade topics en un momento dado.
La Vista de este modelo se limita a una plantilla HTML con una lista de los canales.Cuando el usuario haga seleccione el nombre de alguno de ellos y pulse el botóncorrespondiente de carga, automáticamente se construirá una petición al Servidor paradicho canal, cargándose en el navegador para poder inspeccionar los eventos que seenvíen a él.
Además, cuando el usuario arrastre el proxy de un objeto sobre el nombre de algunode los canales, automáticamente quedará subscrito a ese canal.
Modelo y vista del canal de anunciamientos
Como ya se ha explicado, el canal de anunciamientos es un tipo de canal especial queimplementa la interfaz ::IceStorm::Topic.
Para que cuando un objeto se registre en este canal, el modelo pueda comunicárseloal controlador, éste debe estar subscrito a dicho canal. De manera análoga a la sección5.4.2 con los objetos activos, se define una clase Listener que implementa la interfaz::ASD::Listener (listado 5.18). Cuando el Servidor cree la instancia del modelo delcanal de anunciamientos, se creará su listener, que se subscribirá al canal para recibirtodas las invocaciones que se realicen sobre él mediante la llamada adv. Este listener
5. DESARROLLO DEL PROYECTO 53
tendrá como callback la invocación al controlador para que pueda actualizar la vistaen tiempo real.
class TopicListener(ASD.Listener):def __init__(self, cb):
self.cb = cb
def adv(self, prx, current=None):self.cb(prx)
Listado 5.18: Clase Listener del canal de anunciamientos
La vista del canal de anunciamientos es similar a la del Topic Manager. Cuenta conuna lista seleccionable que se actualiza automáticamente, gracias al WebSocket, cadavez que el canal recibe un nuevo anunciamiento. A partir de esta lista, el usuario podrácargar en el navegador la vista de un objeto anunciado simplemente seleccionandosu proxy y haciendo clic sobre el botón de carga. De esta manera se simplifican laspeticiones de nuevos objetos a inspeccionar, ya que el usuario no necesita conocer nisiquiera los proxies a los objetos de la red. Podrá inspeccionarlos automáticamentecuando se vayan anunciando en este canal.
66Resultados
En esta sección se detallará el sistema final obtenido tras el desarrollo explicado en lasección 5.4 y las aplicaciones del mismo. Asimismo, se analizará el esfuerzo de desarrollodel proyecto y del tiempo dedicado al mismo, y se realizará una estimación del coste totalque ha supuesto su realización.
6.1 Aplicaciones de la herramientaEl objetivo principal de este proyecto era obtener una herramienta capaz de monitorizar y
controlar objetos de una red distribuida a través de internet con independencia de las tecnolo-gías empleadas por el usuario final. Esto se ha conseguido desacoplando la implementacióndel sistema de cualquier tipo de Sistema Operativo o dispositivo concreto, pudiendo trabajarcon la herramienta desde cualquier navegador web que soporte WebSockets, con indepen-dencia de las características del terminal.
A continuación se detallan las aplicaciones facilitadas por el sistema.
6.1.1 Inspección y control de dispositivos remotosPartiendo de una red de objetos distribuidos, el usuario será capaz de monitorizar el estado
o valor de cada uno de ellos y tendrá la posibilidad de modificarlo remotamente interactuandode manera sencilla desde las vistas o páginas web que los representan.
Objetos simples
Los dispositivos soportados por el sismema pertenecen a dos tipos:
Objetos booleanos: su estado puede tener dos únicos valores (true o false).
Objetos enteros: su estado o valor varía en un rango entre 0 y 255.
El usuario que previamente haya cargado en su navegador la vista correspondiente a undispositivo de cualquiera de estos tipos podrá visualizar los cambios en su estado en tiemporeal o modificarlo personalmente cuando desee (imagen 6.1).
54
6. RESULTADOS 55
Figura 6.1: Vistas básicas de un objeto entero (izquierda) y otro booleano (derecha)
Contenedores
El sistema soporta además la inspección de contenedores de objetos. El usuario será capazde comprobar qué elementos o dispositivos forman parte de un contenedor concreto, y podráañadir nuevos objetos al mismo (imagen 6.2).
Figura 6.2: Vistas básicas de un objeto entero (izquierda) y un contenedor del que formaparte (derecha)
Objetos activos
La herramienta final da soporte al usuario para poder consultar el observador de un objetoactivo y asignarle uno nuevo. Esta aplicación es útil si se desea difundir un cambio de estadoentre dispositivos del mismo tipo (ver imagen 6.3 izquierda).
6. RESULTADOS 56
Figura 6.3: Vistas básicas de un Modelo Activo (izquierda) y de un Modelo Objeto (derecha)
Propiedades generales de los objetos
El usuario podrá también consultar en cualquier momento propiedades específicas de undeterminado dispositivo, como su Identidad, su Proxy o las interfaces que implementa (verimagen 6.3 derecha).
6.1.2 Monitorización de canales de eventosLos dispositivos remotos se comunican entre sí y con el sistema a través de canales de
eventos. El usuario cuenta con la facilidad que le proporciona la herramienta para monitorizary subscribirse a algunos de los canales más representativos.
Topic Manager
Como se explicó en la sección 5.4.8, a través de la vista del Topic Manager el usuariopodrá conocer la lista de canales de eventos activos en un determinado momento. Podrá a suvez, cargar la vista de alguno de esos canales para inspeccionar los eventos o mensajes quele van llegando (imagen 6.4 izquierda) y subscribir un objeto a cualquier canal arrastrandoel proxy sobre su nombre.
Canal de Anunciamientos
Si el usuario no conoce el proxy de los objetos que componen la red, el sistema le propor-ciona la posibilidad de monitorizar el canal de anunciamientos, donde se irán añadiendo losproxies a los dispositivos que se vayan anunciando cuando su vista esté cargada. De esta ma-nera el usuario podrá acceder a multitud de objetos según vayan incorporándose al sistemasin necesidad de conocer nada de ellos (imagen 6.4 derecha).
6. RESULTADOS 57
Figura 6.4: Vistas del TopicManager (izquierda) y del Canal de Anunciamientos (derecha)
6.2 Recursos y costesA continuación, se muestra un resumen de las líneas de código fuente asociadas a los
lenguajes de programación que se han utilizado en el desarrollo de este proyecto (ver cua-dro 6.1).
Language Files Comment CodeHTML 34 13 2651Python 37 142 1824Javascript 34 259 1418CSS 7 17 230Total 112 431 6123
Cuadro 6.1: Líneas de código por lenguaje de programación
En el cuadro 6.2 se detallan el número de líneas por componente del sistema, así comoel número de líneas dedicadas a las pruebas y a los ejemplos que se realizaron durante elestudio de viabilidad de las distintas tecnologías y herramientas empleadas.
Para la obtención de estos datos, se ha utilizado la herramienta libre cloc, que analizatodos los ficheros existentes de un directorio en particular, y muestra, de una manera clara,el número total de líneas de código, incluyendo información adicional como el número deficheros y de comentarios entre otros.
6. RESULTADOS 58
Componente Lenguaje Líneas de códigoServidor Python 166Modelos Python 258Vistas Python 69
HTML 2078Javascript 866CSS 230
Pruebas Python 771Javascript 132
Ejemplos Python 560HTML 573Javascript 420
Total 6123
Cuadro 6.2: Líneas de código por componente
En el listado 6.1 se muestra una estimación del esfuerzo realizado en el desarrollo de esteproyecto. Estos datos se han obtenido con la herramienta sloccount [Whe], que analiza losficheros de un directorio dado y emplea el modelo COCOMO para obtener la estimación deltiempo y los costes necesarios para desarrollar el sistema.
Total Physical Source Lines of Code (SLOC) = 6,123Development Effort Estimate, Person−Years (Person−Months) = 1.36 (16.27)(Basic COCOMO model, Person−Months = 2.4 ∗ (KSLOC∗∗1.05))Schedule Estimate, Years (Months) = 0.60 (7.21)(Basic COCOMO model, Months = 2.5 ∗ (person−months∗∗0.38))Estimated Average Number of Developers (Effort/Schedule) = 2.25Total Estimated Cost to Develop = $ 183,103(average salary = $56,286/year, overhead = 2.40).
Listado 6.1: Estimación de los costes del proyecto
6.2.1 RepositorioEl código del proyecto se encuentra alojado en bitbucket.org [bit], que es un servicio de
alojamiento basado en web para proyectos. Para descargar el repositorio se ejecuta la si-guiente sentencia en un terminal:
$ hg clone https://bitbucket.org/arco_group/pfc.inspectio
Este servicio permite utilizar Mercurial [MER] como sistema de control de versiones. Loque permite visualizar todos los cambios realizados en cada actualización, permitiendo elcorrecto seguimiento del desarrollo del proyecto.
77Conclusiones y trabajo futuro
En este capítulo se describen los objetivos alcanzados durante la elaboración de este pro-yecto. Además, se realizan una serie de propuestas como trabajo futuro para mejorar e incre-mentar la funcionalidad del modelo presentado en este documento.
7.1 Objetivos alcanzadosUna vez finalizado el desarrollo del proyecto, se puede observar que se han alcanzado los
resultados previstos tras la consecución de los diferentes objetivos propuestos. Se ha logradoobtener un sistema que permite al usuario explorar y gestionar los dispositivos de una reddistribuida a través de internet.
El hecho de que el acceso al sistema se realice a través de un navegador, hace posible quepueda trabajarse con los objetos y canales que conforman dicha red distribuida con indepen-dencia del dispositivo que se esté empleando (PC, tablet, smartphone...) y de la tecnologíaque implemente dicho dispositivo (Sistema Operativo, navegador, etc).
Además, el hecho de dar soporte para el cambio de modelos y vistas para cada elementoen tiempo real, enriquece el uso del sistema, haciéndolo completamente personalizable porel usuario final.
Al haber desarrollado una herramienta genérica y flexible los campos de aplicación quepueden verse beneficiados por el uso de este sistema son muy variados, desde controlar redesdomóticas a pequeña escala hasta formar parte de múltiples sistemas de control y vigilanciade amplia cobertura.
7.2 Trabajo futuroA pesar de que se han cubierto las funcionalidades básicas en cuanto a la representación
y visualización de los objetos básicos definidos por el modelo DUO y de los eventos en elCanal de Anunciamientos, a continuación se detallan una serie de propuestas para mejorar yampliar la funcionalidad del sistema:
Soporte para el resto de modelos descritos en las interfaces de DUO, tales comoel IString, IFloat o IByteSeq, entre otros (ver Anexo A.1). El desarrollo de nuevos
59
7. CONCLUSIONES Y TRABAJO FUTURO 60
modelos que implementen otras interfaces no contempladas en este proyecto supondríauna ampliación considerable de la funcionalidad del sistema, al proporcionar al usuarionuevas funciones a ejecutar sobre los dispositivos.
Ampliar el número de plantillas y vistas para cada modelo. Para poder ofreceral usuario un entorno completamente personalizable, podrían desarrollarse multitudde vistas diferentes para cada tipo de modelo además de ofrecerse la posibilidad demodificar las interfaces visuales para conseguir que se adecúen mejor a cada usuariofinal.
Añadir funcionalidades a las vistas desarrolladas. Para dinamizar más aún la inter-acción del usuario con las vistas finales, se podrían añadir funcionalidades por ejemplo:
• Permitir la creación de nuevos objetos contenedores con los objetos ya registra-dos desde el navegador.
• Añadir la posibilidad de crear nuevos topics o canales desde la vista del TopicManager.
Soporte para la creación y el control de objetos compuestos. Un objeto compuestoes similar a un contenedor, con la peculiaridad de que todos sus elementos imple-mentan las mismas interfaces. Se podría interactuar con todos a la vez, haciéndolodirectamente sobre el nodo raíz.
Desarrollo de una aplicación de escritorio o para dispositivos móviles para interactuarcon la red distribuida en el caso de que el usuario prefiera estos entornos de trabajo.
ANEXOS
AASlices
Aunque a lo largo de este documento se han ido listando fragmentos de los Slices relacio-nados con el desarrollo de las distintas iteraciones, se muestran aquí los ficheros completoscon el fin de completar la documentación.
A.1 Slice de DUO// −∗− mode: c++; coding: utf−8 −∗−
#ifndef DUO_ice#define DUO_ice
#include <Ice/BuiltinSequences.ice>#include <Ice/Identity.ice>
module DUO {
module Pulse {interface W { ["freeze:write", "ami"] void set(Ice::Identity oid); };
};
module IBool {interface R { ["freeze:read", "ami"] idempotent bool get(); };interface W { ["freeze:write", "ami"] void set(bool v, Ice::Identity
oid); };};
module IByte {interface R { ["freeze:read", "ami"] idempotent byte get(); };interface W { ["freeze:write", "ami"] void set(byte v, Ice::Identity
oid); };};
module IInt {interface R { ["freeze:read", "ami"] idempotent int get(); };interface W { ["freeze:write", "ami"] void set(int v, Ice::Identity
oid); };};
module ILong {interface R { ["freeze:read", "ami"] idempotent long get(); };interface W { ["freeze:write", "ami"] void set(long v, Ice::Identity
oid); };};
module IFloat {interface R { ["freeze:read", "ami"] idempotent float get(); };
62
A. SLICES 63
interface W { ["freeze:write", "ami"] void set(float v, Ice::Identityoid); };
};
module IString {interface R { ["freeze:read", "ami"] idempotent string get(); };interface W { ["freeze:write", "ami"] void set(string v, Ice::
Identity oid); };};
module IByteSeq {interface R { ["freeze:read", "ami"] idempotent Ice::ByteSeq get();
};interface W { ["freeze:write", "ami"] void set(Ice::ByteSeq v, Ice::
Identity oid); };};
module IObject {interface R { ["freeze:read", "ami"] idempotent Object∗ get(); };interface W { ["freeze:write", "ami"] void set(Object∗ v, Ice::
Identity oid); };};
module Active {
interface R {["ami"] Object∗ getObserver();
};
interface W {["ami"] void setObserver(Object∗ observer);
};
};
dictionary<string, Object∗> ObjectPrxDict;
module Container {exception AlreadyExistsException { string key; };exception NoSuchKeyException { string key; };
interface RW;interface R { ["freeze:read", "ami"] idempotent ObjectPrxDict list();
};interface W {
// Add and remove external items["freeze:write", "ami"]
void link(string key, Object∗ value) throwsAlreadyExistsException;
["freeze:write", "ami"]void unlink(string key) throws NoSuchKeyException;
// Create new colocated Container children["freeze:write", "ami"]
Container::RW∗ create(string key) throws AlreadyExistsException;
// Destroy ∗this∗ object["freeze:write", "ami"]
void destroy();};interface RW extends R,W {};
A. SLICES 64
};};
#endif
Listado A.1: Slice del paquete DUO
A.2 Slice del módulo ASD// −∗− mode: c++; coding: utf−8 −∗−
#include <Ice/Identity.ice>
module ASD {
interface Listener {idempotent void adv(Object∗ prx);idempotent void bye(Ice::Identity oid);
};
};
Listado A.2: Slice del módulo ASD
BBPruebas
Como se indicó en la sección 4.1.2, el desarrollo del proyecto ha seguido la metodologíaTDD, donde las pruebas cobran un protagonismo especial, al ser el punto de partida parallegar a implementar toda funcionalidad de manera robusta y fiable, y con la obtención delcódigo mínimo que satisface todos los requisitos.
A continuación se detallan las pruebas realizadas para la consecución de los diferentescasos de uso del sistema.
B.1 Registro y creación de modelosLa base del sistema es crear una representación virtual de un dispositivo físico para po-
der interactuar con él. Partiendo del proxy o referencia a dicho dispositivo, la Factoría de
Modelos debe encargarse de llevar a cabo este proceso.
Se realizan por tanto pruebas que comprueben el registro satisfactorio de nuevos tipos demodelos, y la creación de modelos de diferentes tipos de objetos.
B.1.1 Registro de un nuevo modeloPara poder analizar un proxy y crear un modelo que implemente sus mismas interfaces,
antes la Factoría debe tener un registro de todos los modelos soportados por el sistema.
Dado un nuevo modelo, se registra en la Factoría, y posteriormente se comprueba que,efectivamente, ha pasado a formar parte del registro general de modelos.
B.1.2 Creación de un modelo dado un proxyComo se ha explicado a lo largo de este documento, un dispositivo puede implementar
diferentes interfaces que se traducen en diferentes modelos internos de representación. LaFactoría ha de ser capaz de crear tantos modelos compatibles con el objeto como modeloscompatibles tenga registrados.
Dado - un proxy a un objeto que no está representado en el sistema.
Cuando - un cliente solicita la creación del modelo para ese proxy.
Entonces - la factoría recorre la lista de modelos registrados en el sistema y crea una ins-
65
B. PRUEBAS 66
tancia de cada uno de ellos que sea compatible con el proxy.
De la misma manera que cada objeto o dispositivo es único en una red distribuida, losmodelos compatibles que lo representen internamente en el sistema también han de serlo(un modelo por cada interfaz diferente). Por tanto, la Factoría de modelos debe llevar uncontrol de los modelos ya creados para distintos objetos, de manera que si un nuevo clientese interesa en trabajar con él, el modelo con el que interactúe sea el mismo que utilizan elresto de usuarios.
Dado - un proxy a un objeto que ya está representado en el sistema.
Cuando - un cliente solicita la creación del modelo para ese proxy.
Entonces - la factoría devuelve el mismo modelo.
B.2 Consulta y modificación del estado de un objetoLos objetos o dispositivos físicos que componen la red distribuida deben recibir las invo-
caciones de los modelos que los representan para consultar o modificar su estado.
B.2.1 Consulta del estadoUna vez creado un modelo para un dispositivo, se crean pruebas que determinen que las
invocaciones sobre los modelos se traducen en invocaciones al dispositivo remoto.
Dado - un modelo de un objeto.
Cuando - se invoca su método get.
Entonces - se obtiene el mismo valor que presenta el dispositivo en ese momento.
B.2.2 Modificación del estadoDe manera análoga a la anterior, debe comprobarse que cuando se invoca la función per-
tinente de un modelo para establecer un nuevo estado, esta invocación sea recibida por elobjeto remoto.
Dado - un modelo de un objeto.
Cuando - se invoca su método set con un valor concreto.
Entonces - el dispositivo recibe la invocación y modifica su estado con el valor asignado enel set.
B.3 Creación e invocación del Listener en objetos activosTal como se explicó en la sección 5.4.2, los modelos de los objetos activos cuentan con un
Listener subscrito al observador del dispositivo remoto, de manera que cuando éste modificasu estado invoca a este Listener para que notifique al controlador o controladores dichocambio.
B. PRUEBAS 67
B.3.1 Invocación del Listener por un objeto activoSe comprueba que cuando un objeto activo cambia su estado, el Listener recibe una invo-
cación con ese cambio.
Dado - un modelo de un objeto y su listener creado y subscrito al observador del objeto.
Cuando - de manera asíncrona el dispositivo cambio de estado.
Entonces - el listener recibe una invocación con ese cambio.
B.3.2 Comprobación de que el Listener es un singletonDado que un modelo de un objeto es un singleton, el listener asociado a él debe ser también
una instancia única.
Dado - un modelo de un objeto y su listener creado y subscrito.
Cuando - se intenta crear un nuevo listener.
Entonces - el modelo devuelve al usuario la misma instancia creada anteriormente.
B.3.3 Invocación del controlador por parte del ListenerCuando un Listener recibe una invocación, su cometido es notificarlo al controlador o
controladores del objeto para que actualicen las vistas.
Dado - un modelo de un objeto y su listener creado y subscrito.
Cuando - de manera asíncrona el dispositivo cambio de estado.
Entonces - se comprueba que todos los controladores del modelo han recibido la notifica-ción del cambio.
B.4 Obtención y asignación de un nuevo observador en objetos acti-vos
El Modelo Activo permite consultar el Observador de un objeto y asignarle uno nuevo. Secomprueba que tanto la consulta como la asignación se realizan correctamente.
B.4.1 Obtención del ObservadorDada - una instancia del modelo activo de un objeto.
Cuando - se invoca su método getObserver().
Entonces - el proxy obtenido es el mismo que el del observador del propio objeto.
B.4.2 Asignación de un nuevo ObservadorDada - una instancia del modelo activo de un objeto.
Cuando - se invoca su método setObserver(proxy) con el proxy de un objeto que imple-menta sus mismas interfaces.
B. PRUEBAS 68
Entonces - se comprueba, realizando un get, que el observador es el mismo que acaba deasignarse.
B.5 Inspección y modificación de un objeto contenedorEn la sección 5.4.7 se describieron los Objetos Contenedores. A continuación se describen
las pruebas realizadas para este tipo especial de objetos compuestos.
B.5.1 Obtención de los hijos de un contenedorSe realizan pruebas que garanticen que se obtienen todos los elementos que conforman el
contenedor desde las vistas.
Dado - un objeto contenedor y una instancia del modelo que lo representa.
Cuando - se invoca el método list() del modelo.
Entonces - la lista obtenida debe coindicidir con los nodos hijos del objeto remoto.
B.5.2 Creación de un nuevo contenedor dentro de otroEl Modelo Contenedor debe permitir la creación de contendores dentro de él mismo.
Dado - un objeto contenedor y una instancia del modelo que lo representa.
Cuando - se invoca el método create(Nombre) para crear un nodo hijo.
Entonces - se comprueba que el nodo se ha insertado dentro de la lista de hijos y que estehijo pertence al modelo contenedor.
B.5.3 Enlace de un objeto a un contenedorLos contenedores están compuestos por un grupo de objetos que se asocian a él como
hijos. Se comprueba que el modelo contenedor permite la inclusión de más obetos en su listade nodos hijos.
Dado - un objeto contenedor y una instancia del modelo que lo representa.
Cuando - se invoca el método link(proxy) con el proxy de un objeto de cualquier tipo quepertenece al sistema.
Entonces - se comprueba que el nodo se ha insertado dentro de la lista de hijos.
B.5.4 Desenlazar un objeto de un contenedorLos objetos que forman parte de un contenedor pueden dejar de hacerlo sin necesidad de
que desaparezcan del sistema.
Dado - un objeto contenedor y el proxy de uno de sus nodos hijo.
Cuando - se invoca el método unlink(nombre, proxy) con el nombre y el proxy de un objetode cualquier tipo que pertenece su lista de hijos.
B. PRUEBAS 69
Entonces - se comprueba que el nodo se ha eliminado de la lista de hijos.
B.5.5 Destruir un objeto contenedorCuando se destruye un objeto contenedor desaparece del sistema.
Dado - una instancia de un objeto contenedor hijo.
Cuando - se invoca el método destroy() de la propia instancia.
Entonces - al comprobar si ese objeto está incluido en la lista de nodos hijos de su padre, selanza una excepción porque el objeto ya no existe.
B.6 Gestión de canales con el modelo Topic ManagerEl Topic Manager es el gestor de canales proporcionado por IceStorm. Se detallan a con-
tinuación las pruebas realizadas para la construcción de su modelo en el sistema.
B.6.1 Listado de los canales registradosPara comprobar que el modelo es capaz de obtener todos los canales registrados en el Topic
Manager, y así poder listarlos en la vista correspondiente se realiza la siguiente prueba.
Dado - la instancia del modelo Topic Manager, se crean varios canales con el método crea-te(nombre).
Cuando - se realiza una llamada al método retrieveAll().
Entonces - la lista de canales obtenidos coincide con la de canales creados previamente.
B.6.2 Creación y listado de un nuevo canalSi durante la interacción del usuario con el sistema se registra algún nuevo canal en el
Topic Manager, este debe ser capaz de listarlo junto a los canales ya registrados previamen-te.
Dado - la instancia del modelo Topic Manager, se crea un canal con el método create(’Nombre’).
Cuando - se realiza una llamada al método retrieve(’Nombre’).
Entonces - el resultado de la consula es afirmativo.
B.6.3 Petición de un canal que no existeEl sistema debe ser capaz de avisar cuando se solicite un canal que no existe, de la misma
manera que actúa cuando se solicita un objeto que no existe.
Dado - la instancia del modelo Topic Manager.
Cuando - se realiza una llamada al método retrieve(’Nombre’), solicitando un canal que noexiste.
Entonces - el resultado de la consula es un mensaje de error.
B. PRUEBAS 70
B.7 Eventos en el canal de anunciamientosEl Canal de Anunciamientos es un tipo de canal especial, como ya se describió en la sec-
ción 5.4.8. Básicamente es un modelo más de objeto activo, por tanto las pruebas se realizansobre su Listener para comprobar que el sistema notifica correctamente los anunciamientosal controlador.
Dado - la instancia del modelo del canal de anunciamientos.
Cuando - un objeto externo se anuncia mediante la invocación al método adv.
Entonces - el listener recibe una invocación con ese anunciamiento y lo notifica a los con-troladores.
B.8 Peticiones al ServidorEl Servidor, parte central del sistema, es que el que recibe todas las peticiones desde las
vistas. Debe ser capaz de atender todas ellas correctamente, y delegar el procesamiento delos mensajes que lleguen mediante los controladores para invocar a los modelos y modificarlas vistas según corresponda.
B.8.1 Petición de la página principalCuando el servidor reciba una petición sin nigún tipo de argumento, debe devolver al
usuario la página principal para que pueda comenzar a trabajar desde ella.
Dada - una petición HTTP compuesta únicamente por la dirección IP del servidor y el puertoen el que escucha.
Cuando - el servidor recibe la petición.
Entonces - se comprueba que la página enviada de vuelta corresponde con la principal.
B.8.2 Petición de la vista de un objetoEl usuario, si conoce el proxy del objeto, puede solicitar su vista introduciendo la URL
bien formada de manera manual en el navegador, o mediante el textbox habilitado para elloen la página principal. Si el proxy corresponde a un objeto, el servidor devolverá la vistaasociada por defecto al cliente.
Dada - una url bien formada con todos sus argumentos (el proxy a un objeto, el modelo y lavista).
Cuando - el servidor recibe y procesa la petición.
Entonces - se comprueba que la página enviada de vuelta corresponde con la vista asociadaa ese modelo.
B. PRUEBAS 71
B.8.3 Petición mal formadaSi el usuario introduce una URL mal formada, el servidor debe responder con un mensaje
que avise de este hecho.
Dada - una URL mal formada con ausencia de alguno o todos los argumentos.
Cuando - el servidor recibe y procesa la petición.
Entonces - se comprueba que la página enviada de vuelta contiene el mensaje de error queinforma del fallo.
B.8.4 Petición de un proxy mal formadoPuede ocurrir que la URL de peticón esté bien formada y cuente con todos los argumentos,
pero que el proxy no esté bien formado o no corresponda a ningún objeto. En este caso elservidor, como en el caso anterior, debe avisar al usuario de que el dispositivo no se encuentraactivo o el proxy es erróneo.
Dada - una URL bien formada pero con un proxy erróneo.
Cuando - el servidor recibe y procesa la petición.
Entonces - se comprueba que la página enviada de vuelta contiene el mensaje de error queinforma del fallo.
B.8.5 Petición de cambio de vistaYa se ha explicado que para un mismo modelo el sistema cuenta con diferentes vistas que
el usuario puede solicitar en cualquier momento. El cambio se realiza mediante la selecciónen una lista de la nueva vista. El servidor, cuando reciba la nueva petición, devolverá la vistasolicitada.
Dada - una URL bien formada a partir de la petición de un cambio de vista desde el navega-dor.
Cuando - el servidor recibe y procesa la petición.
Entonces - se comprueba que la página enviada de vuelta corresponde con la vista solicitadaen la url.
B.8.6 Petición de cambio de modeloDe manera análoga a la anterior, el usuario puede solcitar un cambio de modelo en cual-
quier momento desde el navegador, seleccionando el nuevo en una lista. Se realizará portanto una nueva petición al servidor que deberá responder con la vista por defecto del nuevomodelo solicitado.
Dada - una URL bien formada a partir de la petición de un cambio de modelo desde elnavegador.
B. PRUEBAS 72
Cuando - el servidor recibe y procesa la petición.
Entonces - se comprueba que la página enviada de vuelta corresponde con el modelo soli-citado y su vista por defecto.
B.9 Pruebas de integraciónPor último se realiza una prueba de integración donde intervienen todos los componentes
que integran el sistema.
En esta prueba intervienen los siguientes componentes:
Dos dummies que representan dos dispositivos que implementan las interfaces DUO
del módulo IBool y del módulo Active (ver Anexo A.1).
Un dummy que representa un dispositivo que implementa las interfaces DUO del mó-dulo IByte y del módulo Active.
El servidor web.
Varios clientes que modifican el estado de los dummies asíncronamente.
El navegador web Chromium.
El objetivo de esta prueba es comprobar que al interactuar directamete desde el nave-gador, los scripts de las diferentes páginas web trabajan correctamente enviando los datospertinentes al servidor, y que el sistema los procesa correctamente hasta hacerlos llegar a losdispositivos finales. Se comprueba que los cambios de estado desde la vista de un modelobooleano y de un modelo byte llegan a sus dispositivos, y además se realiza una prueba deestablecimiento de un nuevo observador a uno de los dispositivos booleanos, añadiéndoledesde la vista el proxy al otro dispositivo de prueba booleano, y comprobando después queeste proceso se ha realizado con éxito.
Del mismo modo, se comprueba que el funcionamiento en sentido inverso también es elesperado, modificando asíncronamente los estados de los dispositivos y comprobando queestos cambios se traducen en actualizaciones de los elementos en las vistas pertinentes en ellado del navegador.
CCManual de usuario
En esta sección se describirán las diferentes opciones disponibles para el usuario, desde elacceso a la página web principal, hasta las diferentes posibilidades de inspección e interac-ción que le ofrece el sistema y cómo puede llevarlas a cabo.
C.1 Configuración y arranque del servidorAntes de poner en marcha el servidor, hay que tener en cuenta los siguientes requisitos.
C.1.1 Paquetes necesariosPara la instalación y configuración se necesitan los siguientes paquetes:
zeroc-ice
istaf
duo
libcontextservice
Los primeros paquetes son necesarios para lanzar correctamente los servicios IceStorme Istaf, útiles en el sistema para gestionar todos los canales de eventos entre modelos ydispositivos.
Para la creación de los modelos, el sitema necesita los Slices de DUO, configurados tras lainstalación del paquete que lleva el mismo nombre. Además, la librería libcontextservice dasoporte a la creación de contenedores de objetos.
C.1.2 Arranque del servidorTras la instalación de todos los paquetes necesarios, para poner en marcha el servidor hay
que llevar a cabo la siguiente secuencia de operaciones.
Poner en marcha los servicios IceStorm e Istaf es tan simple como ejecutar la siguientesentencia:
$ duo−istaf
73
C. MANUAL DE USUARIO 74
A continuación se debe lanzar el servicio Icebox, al que se deberá facilitar el archivo deconfiguración requerido para que el servicio ContextService trabaje adecuadamente. Desdeel directorio raíz del proyecto:
$ icebox −−Ice.Config=config/icebox−contextService.cfg
Por último, desde ese mismo directorio, se arranca el servidor:
$ python inspectio/server.py
A partir de aquí el sistema está en marcha y el servidor escucha en el puerto 8090 de lamáquina, a la espera de las peticiones por parte del usuario desde su navegador.
C.2 Acceso remoto al sistemaPara acceder al sistema de manera remota, el usuario simplemente ha de contar con un
dispositivo con conexión a internet y un navegador web que soporte WebSocket (Chrome,Safari, Mozilla, etc.).
El sistema, que estará configurado y arrancado, será accesible en su dirección IP y en elpuerto 8090. Por tanto, para obtener la página de inicio, el usuario simplemente tendrá queescribir en la barra de dirección de su navegador esta IP seguida de dos puntos y el puerto.
C.3 Inspección de un dispositivo remotoSi el usuario conoce el proxy a un objeto remoto particular, bastará con escribirlo en el
textbox de la parte superior de la página y hacer clic en botón Search (imagen C.1), paraque el sistema le devuelva el modelo y vista por defecto para dicho objeto. En el caso deque el proxy contenga algún error, o que el sistema sea incapaz de encontrar el dispositivoo no pueda acceder a él en un momento determinado, avisará al usuario con un mensaje deerror.
Figura C.1: Búsqueda de un nuevo dispositivo por proxy
Si todo ha ido bien, se añadirá una pestaña a cada uno de los paneles que conforman lapágina con el nombre o identidad del objeto. Haciendo clic sobre ellas se desplegará la vistadevuelta por el servidor.
C. MANUAL DE USUARIO 75
C.3.1 Objetos booleanosLa Vista por defecto de un objeto booleano cuenta con un checkbox en el centro del panel
que mostrará el estado actual del objeto (imagen C.2 izquierda). Para cambiar el estado, elusuario simplemente ha de hacer clic sobre él. Cuando el dispositivo cambie su estado pormotivos ajenos, el sistema actualizará automáticamente la vista.
Figura C.2: Distintas vistas para un objeto booleano
En la parte inferior de la imagen C.2, se pueden apreciar dos listas desplegables diferentes.La primera sirve para cambiar el modelo con el que se desea trabajar, y la segunda paracambiar el tipo de vista para el mismo modelo. Simplemente con seleccionar un elemementode la lista diferente al actual, el sistema cargará en el panel en que se esté interactuando lavista solicitada.
El funcionamiento de las distintas vistas es idéntico aunque el elemento con el que inter-actúe el usuario sea diferente. En la parte derecha de la imagen C.2 se muestra una vistaalternativa para el modelo booleano, que presenta un switch donde se puede cambiar el esta-do seleccionando cualquiera de las dos posibilidades (Enable o Disable).
C.3.2 Objetos enterosUn objeto entero cuenta con un estado o valor numérico en un rango de 0 a 255. Por
tanto, la vista de este tipo de objetos permite conocer este valor o modificarlo introduciendouno nuevo y pulsando Enter o el botón Validate. En la imagen C.3 se muestran dos vistasdiferentes para este tipo de dispositivos.
De manera análoga a los objetos booleanos, desde las vistas de los objetos enteros sepuede cambiar el modelo o la vista seleccionando la opción deseada de alguna de las listasdesplegables inferiores.
C. MANUAL DE USUARIO 76
Figura C.3: Distintas vistas para un objeto entero
C.3.3 ContenedoresLos contenedores de objetos se muestran en el sistema como un árbol, donde el nodo raíz
es el propio contenedor, y sus hijos son los elementos que lo forman (panel derecho de lafigura C.4). Desde esta vista, el usuario tiene la posibilidad de cargar la vista de un objeto hijosimplemente haciendo clic sobre su nombre. Este hijo, como el resto de objetos, se añadiráa la lista de pestañas y su vista estará disponible en ambos paneles principales. Por tanto,conociendo el proxy a un objeto de este tipo, el usuario tiene acceso a todos los elementosque lo forman sin necesidad de conocer nada de ellos.
Figura C.4: Vista de un objeto booleano (izquierda) y un contenedor (derecha)
Además de cargar nuevos objetos desde la vista de un contenedor, el usuario tiene la po-
C. MANUAL DE USUARIO 77
sibilidad de añadir hijos al mismo arrastrando el proxy del objeto seleccionado y soltándolosobre el contenedor. En la imagen C.4 se puede ver esta funcionalidad en proceso, mientrasque en la imagen C.5 se observa el resultado.
Figura C.5: Objeto booleano añadido al contenedor de la derecha
C.3.4 Objetos activosLos objetos activos se cargan en la página principal con el modelo por defecto asignado
por el sistema. Para poder consultar el observador de estos objetos o asignarle uno nuevo,el usuario debe seleccionar el ActiveModel de la lista desplegable de modelos. La vista queobtendrá del objeto es la que aparece en la figura C.6.
Para establecer un nuevo observador al objeto, basta con introducir el proxy de este nuevoobservador en el textbox central (manualmente o arrastrándolo desde otro panel) y pulsar elbotón Validate.
Figura C.6: Vista del Modelo Activo
C. MANUAL DE USUARIO 78
C.3.5 Propiedades generales de un objetoSi el usuario desea conocer las propiedades específicas de un objeto determinado, como
por ejemplo las interfaces que implementa, debe seleccionar el ObjectModel de la lista co-rrespondiente. Se cargará entonces en el panel seleccionado una tabla con estas propiedadesparticulares (imagen C.7).
Figura C.7: Vista del un Modelo Objeto
C.4 Acceso al Topic ManagerEl Topic Manager es el gestor de canales del sistema, y conociendo su proxy el usuario
puede acceder a toda la lista de canales activos en el sistema.Su vista cuenta con una lista deelementos seleccionables que representa todos esos canales. Para cargar alguno de ellos enla página principal, simplemente se ha de seleccionar el canal deseado y hacer clic sobre elbotón Load Topic (imagen C.8 izquierda).
Figura C.8: Acceso al TopicManager (izquierda) y al Canal de Anunciamientos (derecha)
C. MANUAL DE USUARIO 79
C.5 Acceso al Canal de AnunciamientosEl usuario puede acceder a la vista del Canal de Anunciamientos a través de su proxy,
si lo conoce, o a través de la vista del Topic Manager (imagen C.8). Este canal especial sepresenta en el sistema con el nombre ASDA. Una vez cargada su vista, el usuario podrá irvisualizando en tiempo real los anunciamientos que se vayan registrando.
Cada dispositivo que se anuncie se añadirá a la lista seleccionable de objetos, similar a lalista de canalas que muestra la vista del Topic Manager. Desde aquí el usuario podrá cargarlas vistas de estos dispositivos cuando se vayan registrando en el sistema. Únicamente debeseleccionar su nombre en la lista y pulsar el botón Load device.
DDContenido del CD adjunto
El código fuente desarrollado se incluye en el CD que acompaña a este documento. Pormotivos de extensión, únicamente se han listado fragmentos en secciones concretas paraexplicar alguna funcionalidad o prueba específica.
El contenido de dicho CD se encuentra organizado en diferentes directorios que se detallana continuación:
inspectio/: en este directorio se encuentra todo el código fuente que hace posible quese ejecute el sistema. Además, cuenta con un subdirectorio templates, donde se ubicanlas distintas plantillas HTML, y que a su vez contiene otros subdirectorios:
• templates/js: aquí se encuentran los scripts en JavaScript asociados a las distintasplantillas HTML.
• templates/css: en este directorio se almacenan los ficheros .css donde se definenlos estilos de las plantillas HTML.
• templates/pixmaps: imágenes que forman parte de las distintas plantillas HTML.
config/: aquí se encuentran los archivos de configuración necesarios para el manejodel servicio IceStorm.
doc/: directorio donde se localizan los archivos binarios que generan la documenta-ción. Divido a su vez en dos subdirectorios:
• anteproyecto/: los archivos binarios que generan el anteproyecto.
• memoria/: archivos que generan la presente documentación.
test/: directorio que contiene todas las pruebas realizadas durante el desarrollo delproyecto, tanto las unitarias, como las de integración.
Tal y como se especificó en la sección 6.2.1, el contenido del CD puede descargarse delrepositorio online, que se encuentra ubicado en la dirección:
https://bitbucket.org/arco group/pfc.inspectio/.
80
Bibliografía
[AJA] Ajax: A New Approach to Web Applications. url: http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications.
[Ang10] Cleto Martín Angelina. IcePick: Compilador modular extensible para desarro-llo de objetos distribuidos empotrados de bajo coste. Proyecto Fin de Carrera,Escuela Superior de Informática (UCLM), 2010.
[ard] Arduino. url: http://www.arduino.cc/es/.
[Ash] Kevin Ashton. That ’Internet of Things’ Thing. url: http://www.rfidjournal.com/article/view/4986.
[ATH11] David Villa Alises. Atheist’s, testing framework, 2011. url: http://arco.esi.uclm.es/~david.villa/atheist/html/.
[bit] Atlassian Bitbucket. url: https://bitbucket.org/.
[blu] Bluetooth. url: http://www.bluetooth.com/Pages/Bluetooth-Home.aspx.
[CLM+03] B. Cascales, P. Lucas, J.M. Mira, A.J. Pallarés, y S. Sánchez-Pedreño. El libro
de LATEX. Prentice Hall, edición 1a, 2003.
[COM] Alex Russell. Comet: Low Latency Data for theBrowser. url: http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/.
[COM08] Dave Crane Phil McCarthy. Comet and Reverse Ajax: The Next-GenerationAjax 2.0, 2008.
[COR] Object Management Group. The Common Object Request Broker: Architectureand Specification. url: http://www.corba.org/.
[dia] Dia a drawing program. url: http://projects.gnome.org/dia/.
[ECL] The Eclipse Foundation open source community. Eclipse IDE for JAVA EEDevelopers. url: https://www.eclipse.org/.
81
BIBLIOGRAFÍA 82
[EMA] GNU Emacs. url: http://www.gnu.org/software/emacs/.
[GIT] Github: Build software better, together. url: https://github.com/.
[GNO04] GNOME. ORBit2, 2004. url: http://projects.gnome.org/ORBit2/.
[goo] Google Maps. url: https://maps.google.es/.
[HTM] HTML, The Publishing Language of the World Wide Web. url: http://www.w3.org/html/.
[icea] IceStorm de ZeroC Ice. url: http://www.zeroc.com/icestorm/index.html.
[ICEb] Internet Communications Engine, Zeroc. url: http://www.zeroc.com.
[Inc11] Sun Microsystems Inc. Java Remote Method Invocation (Java RMI),2011. url: http://java.sun.com/javase/6/docs/technotes/guides/rmi/index.html.
[ipv] IPv6.com. url: http://www.ipv6.com/.
[JQU] jQuery. url: http://jquery.com/.
[JS] JavaScript. url: http://www.w3schools.com/js/.
[JTD] jsTestDriver, Remote javascript console. url: http://code.google.com/p/js-test-driver/.
[JUT] Hazem Saleh. JavaScript Unit Testing. Your comprehensive and practical guideto efficiently performing and automating JavaScript unit testing.
[MER] Mercurial: Work easier, Work faster. url: http://mercurial.selenic.com/.
[MVC11] Feifan Zhou. Design Patterns: Model-View-Controller,2011. url: http://cupsofcocoa.com/2011/08/13/design-patterns-model-view-controller/.
[nik] Nike+. url: http://nikeplus.nike.com/plus/.
[NOS] Testing with nose. url: http://readthedocs.org/docs/nose/en/latest/testing.html.
[OPC] OpenFusion CORBA from PrismTech. url: http://www.prismtech.com/openfusion/technologies/corba.
[pac] Cosm (Pachube). url: https://cosm.com/.
[PHA] PhantomJS. url: http://phantomjs.org/.
BIBLIOGRAFÍA 83
[PLP] Padmashree Kadaba Sampathkumar. Implementing Web messaging: ConnectAjax clients to near-real-time data with WebSphere Application Server Com-munity Edition. url: http://www.ibm.com/developerworks/websphere/techjournal/1008 sampathkumar/1008 sampathkumar.html.
[PYT] Python Programming Language. url: http://www.python.org/.
[qr] QR Code.com. url: http://www.qrcode.com/en/.
[QU] QUnit: A JavaScript Unit Testing framework. url: http://qunitjs.com/.
[RED12] Redmine, project management web application, 2012. url: http://www.redmine.org/.
[smaa] SmartSantander. url: http://www.smartsantander.eu/.
[smab] SmartThings. url: http://smartthings.com/.
[SMS06] R.M. Stallman, R. McGrath, y P.D. Smith. GNU Make: A program for directing
recompilation (Version 3.81). Free Software Foundation., 2006.
[Som06] I. Sommerville. Ingeniería del software. Addison Wesley, edición 7a, 2006.
[SSE] HTML5 Server-Sent Events. url: http://www.w3schools.com/html/html5 serversentevents.asp.
[tal] Tales of Things. url: http://www.talesofthings.com/.
[TCO10] Real-Time CORBA with TAO (The ACE ORB), 2010. url: http://www.cs.wustl.edu/~schmidt/TAO.html.
[Tel] Fundación Telefónica. ¿Qué es una Smart City? url: http://smartcity-telefonica.com/?p=373.
[Tin] Ruth Gamero Tinoco. ¿Por qué son necesarias las Smart Cities? url: http://blogthinkbig.com/por-que-son-necesarias-las-smart-cities/.
[vdv] Vista Data Vision. url: http://vistadatavision.com/.
[Vil09a] David Villa. Infraestructura para la integración de redes de sensores y actua-dores en entornos inteligentes. Tesis doctoral, Escuela Superior de Informática(UCLM), 2009.
[Vil09b] F. J. Villanueva. Despliegue eficiente de entornos inteligentes basado en redesinalámbricas. Tesis doctoral, Escuela Superior de Informática (UCLM), 2009.
[Whe] David A. Wheeler. SLOCCount. url: http://www.dwheeler.com/sloccount/.
Este documento fue editado y tipografiado con LATEXempleando la clase arco-pfc que se puede encontrar en:
https://bitbucket.org/arco group/arco-pfc
[Respeta esta atribución al autor]