desarrollo de un cloud connector para iosii resumen los servicios en la nube y las ventajas que...
TRANSCRIPT
Urko Nalda Gil
Juan José Olarte Larrea
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2014-2015
Título
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
Desarrollo de un Cloud Connector para iOS
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015
publicaciones.unirioja.esE-mail: [email protected]
Desarrollo de un Cloud Connector para iOS, trabajo fin de gradode Urko Nalda Gil, dirigido por Juan José Olarte Larrea (publicado por la Universidad de
La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a lostitulares del copyright.
Facultad de Ciencias, Estudios Agroalimentarios e Informática
TRABAJO FIN DE GRADO
Grado en Ingeniería Informática
Desarrollo de un Cloud Connector para iOS
Alumno:
Urko Nalda Gil
Tutores:
Juan José Olarte Larrea
Logroño, Julio de 2015
ii
Resumen
Los servicios en la nube y las ventajas que estos proporcionan están cada vezmás extendidos. Internet se está convirtiendo en una pieza fundamental enel día a día de millones de personas. Digi International es una empresa queaprovecha todas las ventajas de internet para ofertar los mejores serviciosa sus usuarios centrándose en permitir conectar multitud de dispositivoscotidianos a la red para tener un control absoluto sobre ellos.
Este proyecto trata de llevar más allá dichos servicios para que los desa-rrolladores puedan vincular dispositivos que corren sobre el sistema ope-rativo iOS con la nube, ofreciéndoles una librería que permita programaríntegramente en el lenguaje Objective-C.
Abstract
Nowadays Cloud Computing has spread through the world. Internet is afundamental part for many people. Digi International is a company that of-fers the best services to their users and allows them to connect many every-day devices to network. In this way the user is able to monitor the devicesand control them from the cloud.
The aim of this project is to develop a new library for iOS programmersand allow them to link iOS devices to the cloud, offering an Objective-Clibrary.
Índice general
I Introducción 1
1 Introducción 2
1.1 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Conceptios básicos . . . . . . . . . . . . . . . . . . . . . . . . . 3
II Desarrollo del proyecto 5
2 Análisis 6
2.1 Planificación general . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Descomposición en fases . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Descomposición en tareas . . . . . . . . . . . . . . . . . . . . . 8
2.4 Estructura de descomposición de trabajo . . . . . . . . . . . . . 10
2.5 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . 13
3 Diseño 15
3.1 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . 15
iv
ÍNDICE GENERAL v
3.2 Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Diseño del plan de pruebas . . . . . . . . . . . . . . . . . . . . 18
4 Implementación 20
4.1 Tecnologías utilizadas . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Librerías empleadas . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Aspectos generales de la implementación . . . . . . . . . . . . 23
5 Testeo 32
5.1 Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . 34
6 Gestión 35
6.1 Seguimiento del proyecto . . . . . . . . . . . . . . . . . . . . . 35
III Conclusiones 37
7 Conclusiones 38
7.1 Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2 Ampliaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Referencias 40
Parte I
Introducción
1
Capítulo 1
Introducción
En la presente memoria se recogen los aspectos relacionados con el proyec-to de desarrollo de la librería Cloud Connector para iOS. Se trata de unalibrería que permitirá a los usuarios de la plataforma Device Cloud desarro-llar aplicaciones que interaccionen con dicha plataforma en el lenguaje deprogramación Objective-C.
Este proyecto ha sido llevado a cabo por Urko Nalda Gil con el soportede la empresa Digi International.
1.1 Antecedentes
Digi Device Cloud
Digi Device Cloud es una plaforma de gestión de dispositivos y servicios dedatos en la nube que permite conectar un dispositivo a cualquier aplicación,en cualquier momento y en cualquier lugar. Entre las muchas funciones queincluye Device Cloud, una de las más destacadas es la capacidad para mo-nitorizar el estado del dispositivo y mantener comunicación en tiempo realcon el mismo.
2
Capítulo 1. Introducción 3
Para las futuras referencias a esta plataforma utilizaremos el nombre De-vice Cloud.
Cloud Connector
Cloud Connector es un paquete de desarrollo de software que se utilizapara gestionar la comunicación y el intercambio de información entre undispositivo y el Device Cloud. El Cloud Connector permite conectar de for-ma ininterrumpida el dispositivo y la nube con el objetivo de utilizar lascaracterísticas del Device Cloud. La figura 1.1 muestra la estructura de lacomunicación con el Device Cloud.
Figura 1.1: Esquema de conexión entre dispositivos y Device Cloud
1.2 Conceptios básicos
Device ID: se trata de un número de 16 bytes que no cambia a lo largodel ciclo de vida del dispositivo y lo hace único desde el punto de vista delDevice Cloud. Puede ser generado de varias formas, a partir de la MAC deldispositivo, a partir del IMEI/MEID, del ESN o generado automáticamentepor el Device Cloud.
4 1.2. Conceptios básicos
Vendor ID: es un número de 32 bits asignado por el Device Cloud paraidentificar al fabricante de un producto. El dispositivo no está restringido ala cuenta a la que pertenece el Vendor ID.
Device Type: es una cadena de caracteres, elegida como nombre y queidentifica de forma única el modelo del dispositivo de cara al Device Cloud.Si el Device Cloud encuentra dos dispositivos con el mismo Device Type yen el mismo Vendor ID interpreta que son el mismo y, en ese caso, todoslos datos enviados a ese Vendor ID y con ese Device Type llegarán a ambosdispositivos.
Device Cloud URL: es necesario para distinguir a qué servidor se ha deconectar la aplicación.
Parte II
Desarrollo del proyecto
5
Capítulo 2
Análisis
2.1 Planificación general
A la hora de realizar la planificación del proyecto se tuvo en cuenta todo lodesarrollado y aprendido durante el período de prácticas. La fecha de iniciodel proyecto fue concretamente el 2 de febrero de 2015.
El método de desarrollo utilizado es el método en cascada con sus dife-rentes fases.
Para estructurar el desarrollo del producto, se comenzó realizando unadefinición detallada del alcance del proyecto.
Alcance del proyecto
El proyecto consistirá en la realización de un Cloud Connector en el lenguajeObjective-C que permita a los usuarios programar aplicaciones para iOScapaces de interaccionar con los servicios ofrecidos por la plataforma degestión de dispositivos y servicios de datos Digi Device Cloud.
6
Capítulo 2. Análisis 7
Caracterización del producto
Para el desarrollo de la librería se utilizará el entorno de desarrollo integra-do Xcode y dicha librería proporcionará métodos para gestionar, entre otrascosas:
• Conexión de dispositivos
• Envío de datos
• Recepción de datos
• Desconexión de dispositivos
La librería contendrá dos partes, una parte programada en Objective-Cy otra en C:
• Lenguaje Objective-C: corresponde con la parte de alto nivel de la li-brería, es a la que tendrá acceso el usuario y proporciona las clases ymétodos para interaccionar con el Device Cloud.
• Lenguaje C: es la parte de bajo nivel, gestiona todo el intercambio dedatos con la aplicación y el usuario se mantendrá ajeno a su ejecución.
Para el desarrollo del proyecto se utilizará una api existente desarrolladaen C con una implementación para el sistema operativo Linux. No obstanterequiere de una adaptación para un correcto funcionamiento en iOS.
2.2 Descomposición en fases
Al haber tomado la decisión de realizar un desarrollo en cascada, es necesa-rio determinar las diferentes fases que atravesará el proyecto.
Fase de formación: en esta primera fase se llevará a cabo una iniciación allenguaje de programación Objective-C, hasta ahora desconocido. Tambiénse realizará una formación en la estructura del Device Cloud y una introduc-ción básica en el Cloud Connector de C programado para Linux. Tambiénse comenzará una etapa de integración en la empresa y sus herramientas dedesarrollo.
8 2.3. Descomposición en tareas
Fase de análisis: la fase de análisis comenzará con una definición más con-creta del sistema. Se determinarán las diferentes partes del proyecto, así co-mo las distintas tareas que se han de realizar para llevar a cabo el mismo. Seconcretarán los requisitos funcionales y no funcionales del Cloud Connec-tor.
Fase de diseño: esta es la fase en la que se realizará el diseño estructuraldel Cloud Connector. Se tomarán las decisiones sobre las clases a implemen-tar, así como la concreción de su funcionalidad inicial. Por otro lado tambiénen esta fase se diseñará el plan de pruebas a utilizar una vez se implementela librería.
Fase de implementación: en esta fase se realizará la implementación delCloud Connector a partir del trabajo realizado anteriormente. Se desarro-llarán todos los apartados de la biblioteca, reestructurando los contenidosexistentes y modificando las secciones necesarias.
Fase de testeo: en esta fase se llevará a cabo el plan de pruebas diseñadoen la fase de diseño, con la correspondiente corrección de los errores encon-trados.
2.3 Descomposición en tareas
El siguiente paso de la planificación consiste en la descomposición del pro-yecto en tareas, estructurándolas en fases y asignando una estimación tem-poral apropiada a cada una de ellas.
La lista de tareas determinadas para el desarrollo del producto junto conel tiempo de dedicación estimado se puede ver en la tabla 2.1.
Capítulo 2. Análisis 9
ID Tarea Descripción Tiempoestimado
Fase de formación
01 Aprendizaje dellenguaje
Periodo de familiarización con el lenguaje de progra-mación Objective-C 35h.
02 Análisis de li-brería C
Estudio de la estructura de la librería base desarrolla-da en C 25h.
Fase de análisis
03 Planificacióndel proyecto Definición del alcance del proyecto, sus tareas, etc. 15h.
04 Descripción derequisitos
Recopilación de requisitos funcionales y no funciona-les del Cloud Connector 5h.
Fase de diseño
05 Diseño de es-tructura Diseño de la estructura interna del Cloud Connector 20h.
Fase de implementación
06 Adaptación pa-ra iOS
Adaptación de la librería base desarrollada en C parael sistema operativo iOS 20h.
07Desarrollode conexión-desconexión
Desarrollo del apartado de conexión-desconexión dela librería 15h.
08 Desarrollo deenvío de datos
Desarrollo del apartado de envío de datos de la libre-ría 20h.
09Desarrollo derecepción dedatos
Desarrollo del apartado de envío de datos de la libre-ría 15h.
Fase de testeo
10 Aplicación detesteo
Desarrollo de una aplicación para la realización depruebas de la librería 25h.
11 Corrección deerrores
Corrección de errores hallados a partir de la aplicaciónde pruebas 20h.
Gestión
12 Reuniones Reuniones con el equipo de trabajo 15h.
13 Seguimientodel proyecto Seguimiento del estado del proyecto 30h.
14 Memoria Desarrollo de la memoria 40h.
Total 300h.
Tabla 2.1: Lista de tareas plainificadas.
10 2.4. Estructura de descomposición de trabajo
2.4 Estructura de descomposición de trabajo
La figura 2.1 muestra la estructura de descomposición de trabajo del pro-yecto. Se ha estructurado por fases, donde los nodos padre muestran cadauna de las fases mientras que los hijos muestran las tareas asociadas a cadauna de ellas.
Capítulo 2. Análisis 11
iOS
Clo
udC
onne
ctor
Form
ació
nA
nális
isD
iseñ
oIm
plem
enta
ción
Test
eoG
esti
ón
Apr
endi
zaje
del
leng
uaje
Aná
lisis
delib
rerí
a
Plan
ifica
ción
del
proy
ecto
Des
crip
ción
dere
quis
i-to
s
Dis
eño
dees
truc
tura
Ada
ptac
ión
para
iOS
Des
arro
llode co
nexi
ón-
desc
onex
ión
Des
arro
llode
enví
ode
dato
s
Des
arro
llode
rece
p-ci
ónde
dato
s
Apl
icac
ión
dete
steo
Cor
recc
ión
deer
rore
s
Reu
nion
es
Segu
imie
nto
del
proy
ecto
Mem
oria
Figura 2.1: Estructura de descomposición de trabajo del proyecto.
12 2.5. Requisitos funcionales
2.5 Requisitos funcionales
La figura 2.2 muestra el diagrama de casos de uso relativos al Cloud Con-nector. No se describirán todos por falta de espacio.
Objective-C Cloud ConnectorObjective-C Cloud Connector
Establecer descripción
Establecer Vendor-ID
Establecer servidor
Conectar dispositivo
Desconectar dispositivo
Enviar lista de Data Points
Registrar callback
Eliminar callback
Aplicación
Figura 2.2: Diagrama de casos de uso del Cloud Connector
Capítulo 2. Análisis 13
Casos de uso
En la tabla 2.2 se muestra la descripción de uno de los casos de uso: enviarlista de data points.
Caso de uso Enviar lista de data points
Objetivo Enviar una lista de data points al Device Cloud
Actor Aplicación
Precondiciones
1. El dispositivo debe estar conectado al Device Cloud.
Descripción del proceso
1. La aplicación pasa al sistema una lista de data points.
2. El sistema recorre la lista de data points y los ordena en función de sudata stream.
3. El sistema crea una colección de data points con todos los data points dela lista.
4. El sistema envía al Device Cloud la colección de data points.
Extensiones
1.1. La lista de data points contiene otro tipo de objetos.
3.1. Un data stream contiene data points con tipos distintos.
3.2. Un data point no tiene data stream asociado.
Tabla 2.2: Descripción del caso de uso “enviar lista de data points”.
2.6 Requisitos no funcionales
Requisitos tecnológicos
• El Cloud Connector debe estar disponible para, al menos, cualquiersistema operativo posterior a iOS 6.
• Cualquier aplicación que utilice el Cloud Connector requerirá de ac-ceso a Internet para su funcionamiento. En cualquier otro caso la co-municación con el Device Cloud será imposible.
14 2.6. Requisitos no funcionales
• Gran parte del rendimiento de la librería dependerá de la calidad dela conexión a internet, no obstante el propio Cloud Connector no su-pondrá un cuello de botella para el rendimiento.
Requisitos de seguridad
• La librería proporcionará un sistema de control de integridad para evi-tar daños ante un uso indebido del sistema, ya sea consciente o incons-cientemente.
• El Cloud Connector debe cumplir unos requisitos mínimos de dispo-nibilidad, en los que se garantice que el acceso que proporciona la li-brería estará disponible la mayor parte del tiempo.
Capítulo 3
Diseño
El apartado de diseño recoge todas las decisiones tomadas, así como lasmetodologías empleadas, para tratar de alcanzar una estructura de softwarecorrecta.
Uno de los factores más importantes a considerar en el desarrollo delCloud Connector es el hecho de que todas las clases programadas enObjective-C harán uso embebido de diferentes partes de la librería escritaen C. No obstante, cualquier aplicación que utilice el Cloud Connector, sólotendrá acceso a las clases y métodos en Objective-C.
3.1 Arquitectura del sistema
El Cloud Connector de Objective-C es una librería que se estructurará entres partes. La figura 3.1 muestra de forma esquemática la estructura.
En primer lugar, el apartado de más alto nivel es el que ofrece al desa-rrollador todos los métodos de Objective-C para poder gestionar de formacompleta la interacción con el Device Cloud. Esta es la parte de la libreríadisponible para terceros desarrolladores y les permite abstraerse totalmentedel funcionamiento interno. Este primer nivel se llamará Objccimp y en suinterior utilizará una parte del Cloud Connector de C.
15
16 3.2. Modelo de datos
Tipos de comunicación:
• Desarrollador←→ Objccimp: lenguaje Objective-C
• Objccimp←→ ccapi: lenguaje C
El siguiente nivel es la parte externa del Cloud Connector de C, recibeel nombre de ccapi y es independiente del sistema operativo en el que seejecute. Ofrece al desarrollador los métodos para comunicarse con el DeviceCloud.
Tipos de comunicación:
• Objccimp←→ ccapi: lenguaje C
• ccapi←→ ccimp: lenguaje C
El último nivel del Cloud Connector es el apartado que implementa lainteracción entre el Cloud Connector de C y el sistema operativo oportuno.Ofrece una implementación adaptada del ccapi. Esta parte del Cloud Con-nector de C es la que ha debido ser ajustada a las condiciones de iOS.
Tipos de comunicación:
• ccapi←→ ccimp: lenguaje C
• ccimp←→ Sistema Operativo: lenguaje C
3.2 Modelo de datos
Esta sección recoge información general sobre el tipo de datos intercambia-dos con el Device Cloud.
Al hablar del Device Cloud es necesario mencionar el concepto de da-ta stream. Los data streams permiten el almacenamiento y la visualizaciónde datos a lo largo del tiempo. Virtualmente, cualquier tipo de dato puedeser almacenado y se pueden crear gráficos en tiempo real para monitorizarcualquier dispositivo.
Capítulo 3. Diseño 17
Figura 3.1: Diagrama de la arquitectura del sistema.
Dentro de un data stream se puede realizar cualquier tipo de búsqueda ytodos los datos contenidos en el data stream pueden agruparse en intervalosde tiempo.
Data points
Los data points representan el valor de un data stream en un momento con-creto de tiempo y, de forma opcional, en una localización determinada. Paraque la información contenida en un data point esté completa, éste debe per-tenecer necesariamente a un data stream, que encapsula metadatos comunesa todos los data points contenidos en él.
Data streams
Como se mencionó anteriormente, el tipo de data stream define la informa-ción común a todos los data points que contiene, como son:
• Stream ID (nombre otorgado en el Device Cloud).
• Tipo (float, integer, string, etc.).
• Unidades (oC, km/h, segundos, etc.).
18 3.3. Diseño del plan de pruebas
Data point collection
Un data point collection, o colección de data points, consiste en un grupo dedata points, de uno o varios data streams, que se encuentran pendientes paraser enviados a su data stream correspondiente del Device Cloud. Cuando seenvía una colección de data points, cada data point de la colección es enviadoa su data stream correspondiente en la misma transacción, lo que minimizael uso de la red.
3.3 Diseño del plan de pruebas
Con el objetivo de realizar un plan de pruebas de calidad para el Cloud Con-nector, a la hora de diseñarlo se decidió llevar a cabo dos tipos de pruebas:
• Pruebas de unidad
• Pruebas de integración
Pruebas de unidad
Las pruebas de unidad se irán realizando a lo largo del desarrollo de la apli-cación con el objetivo de comprobar la corrección de las diferentes partes dela librería. Se llevarán a cabo sobre cada módulo: establecimiento de cone-xión, desconexión, envío de datos, recepción de datos, etc.
Pruebas de integración
Las pruebas de integración se llevarán a cabo al finalizar la librería. Paraello se programará una pequeña aplicación que interaccione con el DeviceCloud haciendo uso del Cloud Connector para probar su funcionamiento.
Todas las pruebas realizadas en la fase de testeo se documentarán me-diante una tabla como la que muestra la tabla 3.1.
Capítulo 3. Diseño 19
Prueba Nombre de la prueba.
Descripción Descripción de la prueba.
Resultado Resultado de la prueba CORRECTO/INCORRECTO
Comentarios Comentarios sobre la prueba.
Tabla 3.1: Plantilla para la documentación de pruebas
Capítulo 4
Implementación
Este capítulo recoge todos los detalles relacionados con la implementacióndel Cloud Connector. Se hará mención a las tecnologías utilizadas, las libre-rías empleadas para el desarrollo de la aplicación, etc.
4.1 Tecnologías utilizadas
Esta sección trata de resumir los aspectos más importantes de las tecnolo-gías utilizadas.
iOS
Como se indicó anteriormente en los requisitos no funcionales, el CloudConnector se va a desarrollar para que sea utilizado sobre aplicaciones quecorran sobre el sistema operativo iOS 6 o posterior. No obstante, es posibleque aplicaciones desarrolladas para sistemas operativos anteriores puedantambién hacer un uso correcto de la librería.
iOS es un sistema operativo móvil desarrollado por la empresa AppleInc. y distribuido exclusivamente para dispositivos Hardware de dicha em-
20
Capítulo 4. Implementación 21
presa. Por tratarse de un sistema operativo con una distribución limitada alos dispositivos Apple, es sencillo desarrollar aplicaciones y librerías que seadapten bien a todos ellos.
El lenguaje de programación utilizado para la mayoría de las aplicacio-nes desarrolladas para iOS es Objective-C y es éste el lenguaje escogido parala librería a desarrollar (no obstante habrá partes escritas en C para aprove-char el Cloud Connector ya existente en este lenguaje).
4.2 Librerías empleadas
A continuación se muestran las librerías empleadas para la implementacióndel Cloud Connector.
CCAPI
En varios apartados anteriores se menciona un Cloud Connector para Cdesarrollado por la empresa. Este Cloud Connector recibe el nombre deCCAPI y se encuentra en fase de desarrollo, por lo que en muchos momen-tos, la falta de documentación y algunos errores han hecho que la adapta-ción del Cloud Connector para iOS fuera costosa.
En lo relativo a la implementación de bajo nivel, se ha utilizado la libre-ría casi en su totalidad, haciendo un uso más que considerable del materialproporcionado por la empresa. No obstante, la parte de la librería que con-tiene el código de interacción con el sistema operativo ha tenido que seradaptada para su correcto funcionamiento en iOS.
ZLib
Por defecto, el Cloud Connector escrito en C utiliza una compresión pa-ra minimizar la cantidad de datos a enviar tanto desde el dispositivo al
22 4.3. Estructura del proyecto
Device Cloud, como desde el Device Cloud al dispositivo. El algoritmode compresión utilizado se encuentra en una librería externa, gratuita yde código abierto llamada ZLib y que puede ser obtenida en el enlacehttp://www.zlib.net.
4.3 Estructura del proyecto
Este apartado muestra todos los aspectos relativos a la estructura del pro-yecto. No se describen los archivos y carpetas generados automáticamentepor Xcode para el proyecto.
Carpeta ccapi: es la carpeta que contiene la estructura base del Cloud Con-nector de C, es común en todas las implementaciones del Cloud Connectory no debe ser modificada. Se trata de la librería que debe ser adaptada pos-teriormente en función del sistema operativo en el que se va a ejecutar.
Figura 4.1: Carpeta ccapi.
Carpeta ccimp: esta carpeta contiene el código en el que la librería baseccapi es adaptada al sistema operativo. Originalmente contenía una imple-mentación para Linux que ha sido modificada para ser ejecutada sobre iOS.
Capítulo 4. Implementación 23
Figura 4.2: Carpeta ccimp.
Carpeta objccimp: esta última carpeta contiene todas las clases Objective-C que manejará cualquier usuario que quiera utilizar el Cloud Connectorpara desarrollar una aplicación que interaccione con el Device Cloud.
Figura 4.3: Carpeta objccimp.
4.4 Aspectos generales de la implementación
Esta sección recoge todos los detalles más destacados del desarrollo delCloud Connector. Se hablará de los cambios más importantes realizados so-
24 4.4. Aspectos generales de la implementación
bre la implementación para Linux del Cloud Connector de C y de detallesde la implementación en Objective C de la librería.
Una parte de la implementación ha consistido en el desarrollo de funcio-nes con cabecera Objective-C que hacen uso de parte del Cloud Connectorde C. No obstante, una gran parte del código en C interacciona con las clasesdesarrolladas en Objective-C.
A continuación se muestran las partes más importantes de la implemen-tación, con los problemas surgidos y la solución desarrollada.
Sincronización mediante semáforos
El núcleo del Cloud Connector de C (la parte de más bajo nivel) requierela implementación de un sistema de sincronización para ejecutarse. A lahora de adaptar el Cloud Connector a un sistema operativo concreto, esnecesario ajustar ese apartado de la librería. El objetivo es construir objetosque adquieran una parte del código, la bloqueen, la liberen posteriormentey puedan ser finalmente destruidos.
Aunque esta sección se puede implementar con cualquier sistema de sin-cronización disponible en el sistema operativo sobre el que se ejecutará elCloud Connector (semáforos, eventos, etc.), la implementación para Linuxutiliza la librería unnamed semaphores de Posix.
Unnamed semaphores
Los semáforos anónimos (unnamed semaphores) pueden ser interpretados co-mo simples “contadores” que indican el estado de un recurso determinado.Este “contador” es una variable protegida que no puede ser accedida direc-tamente por el usuario. El funcionamiento de un semáforo es simple, si elsemáforo es mayor que 0 el recurso está disponible, mientras que si el se-máforo es 0 o menor entonces el recurso está ocupado. En el caso de nuestralibrería, no será necesario que el semáforo tome valores superiores a 1.
Capítulo 4. Implementación 25
La librería de semáforos anónimos de Posix sitúa los semáforos en regio-nes de memoria compartidas entre los distintos hilos (también entre proce-sos, aunque no es necesario para nuestras necesidades) de la aplicación y deesta forma se puede desarrollar la sincronización entre ellos.
El Cloud Connector de C requiere implementar varias funciones que ges-tionen la sincronización de la aplicación. En primer lugar, la función encar-gada de inicializar un nuevo semáforo es la siguiente:
ccimp_status_t ccimp_os_syncr_create(ccimp_os_syncr_create_t * constdata)
El nuevo semáforo será de tipo sem_t y para inicializarlo la función uti-liza el siguiente método:
int sem_init(sem_t *sem, int pshared, unsigned int value)
El estado inicial del semáforo será 0 y se almacena en el struct de tipoccimp_os_syncr_create_t pasado como parámetro.
La siguiente función de la aplicación es la encargada de adquirir el se-máforo:
ccimp_status_t ccimp_os_syncr_acquire(ccimp_os_syncr_acquire_t *const data)
En el caso de que el semáforo esté abierto, es decir, con valor 1, entoncesbloqueará el semáforo. En cambio, si el semáforo está cerrado esperará du-rante un tiempo máximo (que se especifica en la aplicación) mientras siguetratando de adquirirlo. Para esto, la función realiza una llamada a uno delos siguientes métodos mostrados a continuación:
int sem_wait(sem_t *sem)int sem_trywait(sem_t *sem)
El método a ejecutar depende de varias condiciones y ambos métodosreciben el sémaforo en el parámetro de tipo sem_t recibido.
26 4.4. Aspectos generales de la implementación
La tercera función del Cloud Connector es la encargada de liberar el se-máforo cuando ya hayamos terminado de trabajar. La cabecera de la funciónes la siguiente:
ccimp_status_t ccimp_os_syncr_release(ccimp_os_syncr_release_t *const data)
El método de la librería de Posix que utilizará se muestra a continuación:
int sem_post(sem_t *sem)
Por último, el Cloud Connector implementa una última función que seencarga de destruir finalmente el semáforo. La cabecera de la función es:
ccimp_status_t ccimp_os_syncr_destroy(ccimp_os_syncr_destroy_t *const data)
En su interior, la destrucción del semáforo se lleva a cabo mediante eluso del método siguiente:
int sem_destroy(sem_t *sem)
iOS & semaphores
Al portar el Cloud Connector de C para el sistema operativo iOS surge unproblema debido a que éste no implementa la librería de los semáforos anó-nimos de Posix. Por este motivo, esta parte de la implementación existentepara Linux debe ser adaptada. Tras estudiar varias alternativas de sincro-nización, se decidió implementar este apartado utilizando otra librería desemáforos, también proporcionada por Posix y que recibe el nombre de na-med semaphores.
El funcionamiento interno de los semáforos con nombre es similar al des-crito en el apartado anterior, pero los métodos de creación y destrucción son
Capítulo 4. Implementación 27
diferentes. A continuación se presentan los métodos proporcionados en lalibrería de semáforos con nombre:
//Inicializar y abrir un nuevo semáforosem_t *sem_open(const char *name, int oflag, ...)
//Bloquear un semáforoint sem_wait(sem_t *sem)int sem_trywait(sem_t *sem)
//Desbloquear un semáforoint sem_post(sem_t *sem)
//Cerrar un semáforo con nombreint sem_close(sem_t *sem)
//Borrar un semáforo con nombreint sem_unlink(const char *name);
Para crear los semáforos con nombre, se han utilizado nombres númeri-cos y se ha realizado mediante una variable numérica global, que inicia en0 y que aumenta tras cada apertura de un semáforo.
Implementación de recepción de datos
Recepción de datos mediante el Cloud Connector de C
Una aplicación que utilice el Cloud Connector de C puede recibir datos des-de el Device Cloud. Para ello, es el propio Device Cloud quien debe iniciaruna petición de envío utilizando un target y los datos a enviar.
Cuando el Cloud Connector recibe una petición desde el Device Cloud,revisa los targets registrados y, en caso de que alguno coincida con el tar-get de la petición, el Cloud Connector aceptará la recepción de los datos yejecutará a modo de callbacks las funciones que se indicaron en el momen-to del registro del target. No obstante, es necesario mencionar que el CloudConnector dispone de unas funciones por defecto (asociadas en el momen-to de inicialización del Cloud Connector) que se comportarán como callbacks
28 4.4. Aspectos generales de la implementación
cuando se reciban datos para targets no registrados. Este detalle jugará unpapel importante para implementar la recepción de datos en Objective-C.
Las funciones indicadas cuando la aplicación registra un target son laparte más importante del proceso de recepción de datos desde el DeviceCloud ya que son dichas funciones las que procesan la recepción y envíanuna respuesta a la nube. Para entender dicho proceso se mostarán unas par-tes del código.
Supongamos que la conexión se ha realizado adecuadamente. El primerpaso consiste en realizar el registro de un target. Para ello ejecutamos la si-guiente función:
ccapi_receive_error_t ccapi_receive_add_target(char const * consttarget, ccapi_receive_data_cb_t const data_cb,ccapi_receive_status_cb_t const status_cb, size_t constmax_request_size)
Sin tener en cuenta el tipo devuelto, que consiste en un simple enum queindica el tipo de error recibido al ejecutar el registro, vamos a analizar losparámetros.
1. El primero indica el nombre del target a registrar (puede ser un nombreya registrado).
2. El segundo parámetro es una función que se comportará a modo decallback de datos, se trata de una función de doble dirección. Primeroproporciona al usuario la información enviada desde el Device Cloud(información de recepción) y por otro lado el usuario puede realizaruna respuesta a la nube (información de respuesta). El tipo de la fun-ción debe ser el siguiente:
typedef void (*ccapi_receive_data_cb_t)(char const * consttarget, ccapi_transport_t const transport,ccapi_buffer_info_t const * const request_buffer_info,ccapi_buffer_info_t * const response_buffer_info);
Es esta función la que se ejecutará en el momento en el que se recibauna petición de envío de datos desde el Device Cloud para el target
Capítulo 4. Implementación 29
que estamos registrando en el primer parámetro. Los parámetros de lafunción que actúa como callback de datos son los siguientes:
(i) Target para el que se realizó el envío desde el Device Cloud.
(ii) Protocolo de transporte mediante el cual se realizó la petición (eneste caso se realizará siempre mediante el protocolo TCP).
(iii) Buffer en el que se almacena la información recibida.
(iv) Buffer en el que el usuario almacenará la información que seráenviada a modo de respuesta.
3. El tercer parámetro es de nuevo un callback, en este caso un callbackde estado que se ejecutará cuando el proceso de recepción se hayacompletado. En la mayor parte de los casos se utilizará para liberarlos recursos utilizados a lo largo de todo el proceso de recepción pa-ra gestionar la respuesta. También permite comprobar si la respuestaha sido recibida por la nube correctamente. El tipo de la función queactúa como callback de estado es el siguiente:
typedef void (*ccapi_receive_status_cb_t)(char const * consttarget, ccapi_transport_t const transport,ccapi_buffer_info_t * const response_buffer_info,ccapi_receive_error_t receive_error);
Los parámetros de esta función son:
(i) Target para el que se realizó el envío desde el Device Cloud.
(ii) Protocolo de transporte mediante el cual se realizó la petición (eneste caso se realizará siempre mediante el protocolo TCP).
(iii) Buffer en el que el usuario almacenará la información que seráenviada a modo de respuesta.
(iv) Un enum que contiene el error recibido al enviar la respuesta delcallback de datos al Device Cloud.
4. El cuarto y último parámetro indica el tamaño máximo de los datos arecibir.
30 4.4. Aspectos generales de la implementación
Cómo afrontar la recepción de datos en Objective-C
Uno de los objetivos principales del desarrollo del Cloud Connector enObjective-C es evitar que el desarrollador que haga uso de la librería ten-ga que recurrir a la programación de fragmentos de código escritos en C.El problema surge a la hora de que la librería permita registrar funcionesObjective-C a modo de callbacks haciendo uso por debajo del Cloud Con-nector de C, registrando targets con sus respectivas funciones C.
Para solucionar esta situación se ha recurrido al uso de blocks (bloques),que consisten fragmentos de código que pueden ser utilizados en métodosy funciones como si se tratara de valores.
En primer lugar se ha definido un bloque que recibe dos parámetros, elprimero de tipo NSString* y el segundo de tipo NSString**. En este bloquese procesará la información recibida y la respuesta a enviar.
typedef void (^requestCallback)(NSString*, NSString**);
El primer parámetro hará referencia a los datos recibidos, mientras que elsegundo contendrá un puntero a la referencia de los datos a enviar. El obje-tivo de este puntero es permitir modificar la respuesta desde el interior delbloque y que cambie el contenido de la respuesta exterior.
El siguiente paso consiste en permitir que la clase CloudConnector pue-da almacenar los bloques de código asociados a un target. Para ello, la clasedispondrá del siguiente objeto:
@property (strong, nonatomic) NSMutableDictionary* blocks;
Este diccionario contendrá como claves la lista de targets registrados conuna lista de callbacks asociados a cada target. Para registrar un target y uncallback asociado, la clase CloudConnector dispone del siguiente método:
- (void) registerBlock: (requestCallback) blockwithTarget: (NSString *) target
Capítulo 4. Implementación 31
El primer parámetro es el bloque con la estructura definida anteriormen-te y el segundo el target con el que asociarlo.
Lo siguiente que se ha necesitado es una función privada, que hará depuente entre el Cloud Connector de C y el de Objective-C. Esta función ten-drá la cabecera de las funciones de C que se utilizan como callbacks en elCloud Connector de C y se registrará como callback de datos por defecto, esdecir, el callback que se ejecuta en las peticiones de envío asociadas a targetssin registrar.
La cabecera de esta función es la siguiente:
static void callBlocks(char const * const target, ccapi_transport_tconst transport, ccapi_buffer_info_t const * constrequest_buffer_info, ccapi_buffer_info_t * constresponse_buffer_info)
Su objetivo es realizar la conversión de los datos recibidos desde el De-vice Cloud a datos de Objective-C para posteriormente ejecutar una últimafunción que se encarga de ejecutar los bloques registrados para el target de-terminado. En este momento surge el problema de cómo invocar los méto-dos de la clase CloudConnector que contiene la lista de targets registradoscon sus bloques, desde una función de C que no puede referirse a la instan-cia a ese objeto.
Para solucionarlo, se ha definido un puntero global que, en el constructordel CloudConnector, se referencia al objeto construído. De esta forma, desdela función de C, podemos acceder a dicho puntero que referencia al objetoy es a través de ese puntero como podemos invocar los métodos de la claseCloud Connector.
Llegados a este punto disponemos de una última función que se encargade ejecutar todos los bloques asociados a un target. Esta es la función queserá llamada desde callblocks y su cabecera es la siguiente:
- (void) callBlocksWithTarget: (NSString *)targetrequest: (NSString *)request
andResponse: (NSString **)response
Capítulo 5
Testeo
En este capítulo se presenta todo lo relacionado con la fase de testeo y la eje-cución del plan de pruebas diseñado. Se ha realizado para ello una pequeñaaplicación que hace uso de la librería.
5.1 Pruebas unitarias
En este apartado, la aplicación implementada utiliza gran parte de la libreríabase escrita en C, haciendo solamente uso de las partes del Cloud Connectorpara iOS que se quieren probar.
Prueba 1.- Establecer conexión
Prueba Establecer conexión
Descripción Se trata de establecer una conexión directa con el DeviceCloud con el objetivo de ver conectado el dispositivo en lanube.
Resultado El sistema indica que el estado actual es “Conectado” y lanube muestra un dispositivo conectado. CORRECTO
Comentarios Para alcanzar el estado “Conectado” se han debido ajustarcorrectamente los parámetros de conexión.
32
Capítulo 5. Testeo 33
Prueba 2.- Realizar desconexión
Prueba Realizar desconexión
Descripción Una vez establecida la conexión con el Device Cloud, se de-be probar que la librería realizad adecuadamente una des-conexión.
Resultado Tras realizar la conexión, el dispositivo se desconecta ade-cuadamente de la nube y ningún dispositivo aparece conec-tado. CORRECTO
Comentarios Es necesario que el estado del dispositivo sea “Conectado”.
Prueba 3.- Envío de datos
Prueba Envío de datos
Descripción El objetivo es realizar envíos de datos a la nube.
Resultado El Device Cloud recibe los datos enviados y los almacenaadecuadamente. CORRECTO
Comentarios Para realizar el envío es necesario que el estado del dispo-sitivo sea “Conectado”.
Prueba 4.- Recepción de datos
Prueba Recepción de datos
Descripción El objetivo es recibir datos de la nube.
Resultado El Device Cloud envía los datos al dispositivo. CORREC-TO
Comentarios Para realizar la recepción es necesario que el estado del dis-positivo sea “Conectado”.
34 5.2. Pruebas de integración
5.2 Pruebas de integración
Se va a realizar una única prueba de integración en la cual una pequeñaaplicación desarrollada completamente en el lenguaje Objective-C haga usode la librería y realice progresivamente las siguientes tareas:
1. Conexión al Device Cloud
2. Envío de datos
3. Recepción de datos
4. Acceso al sistema de archivos
5. Desconexión del Device Cloud.
Prueba 6.- Prueba de integración
Prueba Prueba de integración
Descripción Prueba de integración en la que se realizarán varias tareashaciendo uso del Cloud Connector desarrollado.
Resultado Todas las tareas se realizan adecuadamente y el dispositivofinalmente queda desconectado. CORRECTO
Comentarios El resultado obtenido es el esperado.
Capítulo 6
Gestión
6.1 Seguimiento del proyecto
La tabla 6.1 muestra la comparación entre los tiempos estimados y emplea-dos.
Desviaciones significativas
A continuación se muestra una lista con las tres tareas con desviaciones másimportantes:
• Análisis de librería C (40 %): el análisis del Cloud Connector de C pre-senta un significativo desvío del 40 %, esto se debe a la necesidad deanalizar y entender en profundidad una librería desarrollada por laempresa pero que no había sido completada en su totalidad. No dispo-nía de una documentación completa y en ocasiones no fue fácil com-prender su funcionamiento.
• Adaptación para iOS (50 %): la adaptación para iOS del Cloud Con-nector de C fue más costosa de lo esperado ya que aparecieron partescomplejas que conllevaron atascos en su desarrollo.
35
36 6.1. Seguimiento del proyecto
• Desarrollo de recepción de datos (66 %): este apartado de la librería esel que presenta la desviación más sinificativa alcanzando un 66 %. Losmotivos principales están explicados en la sección 4.4.
Aunque se han mostrado las tres desviaciones positivas más importan-tes, algunas tareas como la planificación o el seguimiento se han realizadoen un tiempo menor del planificado.
ID Tarea Tiempoestimado
Tiempoempleado Desviación
01 Aprendizaje del lenguaje 35h. 35h. 0 %
02 Análisis de librería C 25h. 35h. 40 %
03 Planificación del proyecto 15h. 10h. -33 %
04 Descripción de requisitos 5h. 5h. 0 %
05 Diseño de estructura 20h. 15h. -25 %
06 Adaptación para iOS 20h. 30h. 50 %
07 Desarrollo de conexión - desco-nexión 15h. 10h. -33 %
08 Desarrollo de envío de datos 20h. 25h. 25 %
09 Desarrollo de recepción de datos 15h. 25h. 66 %
10 Aplicación de testeo 25h. 20h. -20 %
11 Corrección de errores 20h. 15h. -25 %
12 Reuniones 15h. 15h. 0 %
13 Seguimiento del proyecto 30h. 20h. -33 %
14 Memoria 40h. 45h. 12 %
Total 300h. 305h. 1,67 %
Tabla 6.1: Tabla de comparación de tiempos.
Parte III
Conclusiones
37
Capítulo 7
Conclusiones
7.1 Resultado
Tras haber finalizado el proyecto en el tiempo estimado podemos concluirque el resultado ha sido satisfactorio. En este periodo ha sido posible apren-der y familiarizarse con el lenguaje de programación Objective-C y dominarel entorno de desarrollo X-Code. Por otro lado, se ha profundizado en el len-guaje C al tener que adaptar la librería existente.
En lo que se refiere al objetivo principal, se ha cumplido claramente yaque se ha obtenido una librería capaz de proporcionar un sistema de ges-tión de la conexión entre un dispositivo con sistema iOS y el Device Cloudhaciendo uso únicamente del lenguaje de programación Objective-C.
Por otro lado, los objetivos más concretos como la conexión de dispo-sitivos, el envío de datos a la nube, la recepción y procesamiento de datosdesde el Device Cloud y la desconexión de dispositivos, también se hanconseguido cumplir con éxito.
Los demás objetivos del proyecto, los que se refieren a la planificación,análisis, gestión, etc. han sido alcanzados satisfactoriamente. Han sido esosapartados del desarrollo los que han permitido obtener los resultados en eltiempo adecuado y de una forma completa.
38
Capítulo 7. Conclusiones 39
7.2 Ampliaciones
Pese a haber alcanzado los resultados previstos, el Cloud Connector paraiOS todavía permite realizar ampliaciones, tanto en funcionalidad como enotro tipo de apartados. Algunas de las ampliaciones son las siguientes:
• Gestión del sistema de archivos: trata de permitir al usuario accedery modificar el sistema de archivos del dispositivo desde el DeviceCloud. Para ello puede utilizar internamente el Cloud Connector pa-ra C y ofrecer métodos y clases en Objective-C para la funcionalidadrequerida.
• Documentación para el Cloud Connector: redactar una documenta-ción más completa y adecuada para que el desarrollador que utilice lalibrería pueda consultar los detalles específicos del Cloud Connectorpara iOS.
• Manual de usuario: escribir un pequeño manual de usuario donde sepuedan leer ejemplos de uso del Cloud Connector y de este modo te-ner un punto de inicio para los nuevos desarrolladores que utilicen lalibrería.
Referencias
[1] S. Stevenson, Cocoa and Objective-C. O’Reilly, 2010.
[2] D. Mark, J. Nutting y J. LaMarche, Beginning iPhone 4 Development.Apress, 2011.
[3] J. Bucanek, Learn iOS 8 App Development. Apress, 2014.
[4] Guía de Digi sobre Cloud Connector for Java SE:
• http://ftp1.digi.com/support/documentation/html/90001415/90001415-13_A/index.html
[5] V. Shukla (24 de mayo de 2007) Semaphores in Linux:
• http://www.linuxdevcenter.com/pub/a/linux/2007/05/24/semaphores-in-linux.html
[6] iOS Developer Library:
• https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html
40