diseño e implementación de un sistema para la monitorización de

Proyecto Final de Carrera

Diseo e implementacin de un sistema

para la monitorizacin de aplicaciones mviles

Autor:

Irene Garca Flores

Departamento de Arquitectura de Computadores

Universitat Politcnica de Catalunya (UPC)

Director:

Jordi Riera Molina

Director ponente:

Beatriz Otero Calvio

3

Agradecimientos

A mis padres, a quienes les debo todo.

Colaboraciones

NexTReT, S.L.

4

ndice general

1. Resumen 71.1. Castellano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2. Catal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3. English . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2. Introduccin 132.1. Contexto del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1. Usos ms representativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1. Objetivos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2. Objetivos especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3. Descripcin global del sistema 193.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2. Descripcin de las caractersticas funcionales . . . . . . . . . . . . . . . . . . . . . 21

3.2.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2. Mdulos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3. Descripcin de las caractersticas tcnicas . . . . . . . . . . . . . . . . . . . . . . . 253.3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.2. Diagrama de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4. Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4.1. Actividades fuera del alcance del proyecto . . . . . . . . . . . . . . . . . . . 28

4. Mdulo de intercomunicacin entre agente y mvil 294.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2. Fase de investigacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.2. Desarrollo de la bsqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.3. Conclusiones de la bsqueda . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5. Agente 475.1. Fase de diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.1. Diagramas UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2. Resultado del desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2.1. Estructura del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2.2. Anlisis del cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6. Web Service 716.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.2. Resultado del desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2.1. Agente: funcin sendURLAndGetNodeResponse de la clase WebService.java 746.2.2. Web Service: cmo interpretar una peticin . . . . . . . . . . . . . . . . . . 746.2.3. Agente y Web Service: funciones relacionadas con la inicializacin del agente 74

5

6 NDICE GENERAL

6.2.4. Agente y Web Service: funciones relacionadas con el envo de resultados a laBase de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7. Base de datos 937.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957.2. Diagrama de base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

8. Evaluacin de la solucin 998.1. Control de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018.2. Explotacin de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

9. Conclusiones nales 1119.1. Puntos fuertes del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Glosario de trminos y acrnimos 117

ndice de guras 119

Bibliografa 121

Anexos 123

A. MonkeyRunner: script dump.py 125

B. MonkeyRunner: Funcin dump del script ViewClient.py 131

C. Agente: Diagrama de ujo 137

D. Agente: Diagrama de clases 141

E. Agente: Contenido archivo CongAgente.properties 145

F. Diagrama de la Base de Datos 149

G. Procedimiento MASM: Plataforma Robot 153

H. Procedimiento MASM: Requisitos Terminal Mvil 165

I. Procedimiento MASM: Grabar Tests Sikuli 179

J. Procedimiento MASM: Aadir calendario a un test 187

Captulo 1

Resumen

7

CAPTULO 1. RESUMEN 9

1.1. Castellano

Hoy en da los telfonos mviles son un complemento indispensable en nuestras vidas. Utili-zamos todo tipo de aplicaciones, pero entre todas ellas existen unas muy concretas que debido asu naturaleza son ms propensas a tener problemas: las aplicaciones interactivas, aquellas que secomunican con un servidor del que se descargan parte del contenido que muestran. Gracias a ellasconsultamos la cuenta bancaria, descargamos cupones de descuento o compramos entradas de cine.

Curiosamente en las situaciones en las que utilizamos esas aplicaciones necesitamos nalizar lagestin con celeridad y, adems, no disponemos de ningn ordenador, con lo que dependemos to-talmente de la aplicacin mvil. En consecuencia, si sta no responde, el resultado es adverso tantopara el usuario como para la entidad que distribuye la aplicacin, que tendr prdidas inmediatasy a corto plazo: inmediatas debidas a la cantidad de usuarios que hayan dejado de generar ingre-sos durante el corte del servicio y a corto plazo si usuarios frustrados dejan de utilizar la aplicacin.

En ese contexto, NexTReT, la empresa en la que actualmente trabaja la autora de este PFC, viola manera de ofrecer a esas entidades una solucin con la que mantener operativas sus aplicacionesmviles el mximo tiempo posible: monitorizndolas. Para ello la mejor opcin era disponer de unproducto propio, con lo que se plante a la autora de este proyecto la oportunidad de disearlo ydesarrollarlo. El resultado de ese trabajo es el servicio que hoy en da NexTReT comercializa conel nombre de MASM.

MASM es un sistema de monitorizacin de aplicaciones mviles que comprueba la disponibilidadde las mismas desde el punto de vista del usuario. El funcionamiento global de la solucin consisteen seguir de forma cclica los siguientes pasos:

1. Realizar una serie de pasos concretos en la aplicacin mvil (al conjunto de pasos le llama-remos test o circuito). Esos pasos podran ser, por ejemplo: abrir la aplicacin (paso 1),escoger una opcin dentro de la aplicacin (paso 2), introducir unas credenciales para accedera una vista concreta (paso 3), comprobar que la vista ha cargado correctamente (paso 4) ycerrar la aplicacin (paso 5).

2. Enviar a una pgina web, a la que llamaremos Reporting Web, todos los resultados obtenidosde esa ejecucin.

3. En caso de que el test no nalice correctamente (por ejemplo, el paso 4 falla porque la vistano ha terminado de cargar en el tiempo mximo establecido), enviar una alerta al clienteinformando con detalle el tipo de error que est teniendo la aplicacin.

Para conseguir ese resultado, en primer lugar se realiz un diseo funcional que se tuvo encuenta para el posterior diseo tcnico. En esas fases previas se deni el diagrama completo de laarquitectura, cuyos elementos principales son los siguientes:

Agente: core del sistema. Se encarga de ejecutar los tests sobre las aplicaciones mviles paradespus enviar los resultados a la Base de Datos.

Web Service: intermediario entre agente y Base de Datos.

Base de Datos: almacena toda la informacin relativa a los tests, a sus ejecuciones y a losusuarios de la web.

Reporting Web: pgina web a la que el cliente puede acceder en todo momento para conocerel estado de sus aplicaciones mviles tanto en tiempo real como de forma histrica.

Alertas: encargadas de avisar al cliente en caso de que la aplicacin no funcione.

Tal y como se proyect el sistema, la idea es que en caso de aadir futuras funcionalidades stasrecaigan en el agente, aplicacin de escritorio Java J2SE. Por ese motivo, su desarrollo se centren obtener un cdigo eciente, escalable y modular.

10 CAPTULO 1. RESUMEN

1.2. Catal

Avui dia els telfons mbils sn un complement indispensable en les nostres vides. Utilitzemtot tipus d'aplicacions, per entre totes elles existeixen unes molt concretes que a causa de la sevanaturalesa sn ms propenses a tenir problemes: les aplicacions interactives, aquelles que es comu-niquen amb un servidor del que es descarreguen part del contingut que mostren. Grcies a ellesconsultem el compte bancari, descarreguem cupons de descompte o comprem entrades de cinema.

Curiosament en les situacions en les quals utilitzem aquestes aplicacions necessitem nalitzarla gesti amb celeritat i, a ms, no disposem de cap ordinador, amb el que depenem totalment del'aplicaci mbil. En conseqncia, si aquesta no respon, el resultat s advers tant per a l'usuaricom per a l'entitat que distribueix l'aplicaci, que tindr prdues immediates i a curt termini:immediates degudes a la quantitat d'usuaris que hagin deixat de generar ingressos durant el talldel servei i a curt termini si usuaris frustrats deixen d'utilitzar l'aplicaci.

En aquest context, NexTReT, l'empresa en la qual actualment treballa l'autora d'aquest PFC,va veure la manera d'oferir a aquestes entitats una soluci amb la qual mantenir operatives lesseves aplicacions mbils el mxim temps possible: monitoritzant-les. Per fer-ho la millor opci eradisposar d'un producte propi, amb el que es va plantejar a l'autora d'aquest projecte l'oportunitatde dissenyar-ho i desenvolupar-ho. El resultat d'aquest treball s el servei que avui dia NexTReTcomercialitza amb el nom de MASM.

MASM s un sistema de monitoratge d'aplicacions mbils que comprova la disponibilitat de lesmateixes des del punt de vista de l'usuari. El funcionament global de la soluci consisteix a seguirde forma cclica els segents passos:

1. Realitzar una srie de passos concrets en l'aplicaci mbil (al conjunt de passos li anomenaremtest o circuit). Aquests passos podrien ser, per exemple: obrir l'aplicaci (pas 1), escolliruna opci dins de l'aplicaci (pas 2), introduir unes credencials per accedir a una vistaconcreta (pas 3), comprovar que la vista ha carregat correctament (pas 4) i tancar l'aplicaci(pas 5).

2. Enviar a una pgina web, a la qual anomenarem Reporting Web, tots els resultats obtingutsd'aquesta execuci.

3. En cas que el test no nalitzi correctament (per exemple, el pas 4 falla perqu la vista no haacabat de carregar en el temps mxim establert), enviar una alerta al client informant ambdetall el tipus d'error que est tenint l'aplicaci.

Per aconseguir aquest resultat, en primer lloc es va realitzar un disseny funcional que es vatenir en compte per al posterior disseny tcnic. En aquestes fases prvies es va denir el diagramacomplet de l'arquitectura, els elements principals de la qual sn els segents:

Agent: core del sistema. S'encarrega d'executar els tests sobre les aplicacions mbils perdesprs enviar els resultats a la Base de Dades.

Web Service: intermediari entre agent i Base de Dades.

Base de dades: emmagatzema tota la informaci relativa als tests, a les seves execucions i alsusuaris de la web.

Reporting Web: pgina web a la qual el client pot accedir en tot moment per conixer l'estatde les seves aplicacions mbils tant en temps real com de forma histrica.

Alertes: encarregades d'avisar al client en cas que l'aplicaci no funcioni.

Tal com es va projectar el sistema, la idea s que en cas d'afegir futures funcionalitats aquestesrecaiguin en l'agent, aplicaci d'escriptori Java J2ES. Per aquest motiu, el seu desenvolupament esva centrar a obtenir un codi ecient, escalable i modular.

CAPTULO 1. RESUMEN 11

1.3. English

Today mobile phones are an essential accessory to our lives. We use all kinds of applications,but among them there are some very specic that due to their nature are more likely to haveproblems: interactive applications, those that communicate with a server which content showing isdownloaded. Thanks to them we are able to consult the bank account, download discount coupons,or buy cinema tickets.

Curiously, in the situations in which we use these applications, we need to nish the processquickly and also we do not have any computer, so we totally depend on the mobile application.Consequently, if it does not respond, the result is both adverse for the user and the entity thatdistributes the application, which will have immediate and short-term losses: due to the amountof users who did not generate income during the cutting of the service and short-term if frustratedusers stop using the application.

In this context, NexTReT, the company where the author of this PFC currently works, sawthe way to oer a solution to those entities to keep operating their mobile applications as long aspossible: by monitoring them. To do this, the best option was to have an own product. This is howthe author of this project started to design and develop it. The result of this work is a service thatNexTReT currently marketed under the name of MASM.

MASM is a monitoring system of mobile applications that checks the availability of them fromthe point of view of the user. The overall working of the solution is to follow cyclically the followingsteps:

1. To carry out a series of concrete steps in the mobile application (we will call test or circuitto the set of steps). These steps could be, for example, open the application (step 1), choosean option within the application (step 2), enter credentials to access a concrete view (step3), make sure the view is correctly loaded (step 4) and close the application (step 5).

2. To send to a website, which we will call Reporting Web, all the results of that execution.

3. If the test does not complete successfully (for example, step 4 fails because the view has notnished loading in maximum time set), to send an alert to the client reporting in detail typeof error that is having the application.

To achieve this result, rstly a functional design which was taken into account for the subsequenttechnical design was designed. In these previous phases the complete diagram of the architectureis dened, which the main elements are:

Agent: core system. Is responsible for executing the tests on mobile applications and thensend the results to the Database.

Web Service: intermediary between agent and Database.

Database: stores all information relative to the tests, to their executions and to the users ofthe website.

Reporting website: web page that the client can access at any time to know the status of theirmobile applications both in real time and historical form.

Alerts: responsible to notify the client if the application does not work.

According to how the system was designed, the idea is that if future features are added, thisfall on the agent, Java J2SE desktop application. For that reason, its development was focused onobtaining an ecient, scalable and modular code.

12 CAPTULO 1. RESUMEN

Captulo 2

Introduccin

13

CAPTULO 2. INTRODUCCIN 15

2.1. Contexto del proyecto

En los ltimos aos hemos visto cmo los smartphones se han incorporado a nuestras vidashasta el punto que los utilizamos para cualquier situacin cotidiana como comprar entradas decine, descargar cupones de descuento, consultar la cuenta bancaria, realizar una transferencia, etc.Ese tipo de uso requiere de una disponibilidad inmediata de la aplicacin mvil correspondiente, yaque de no ser as esperaramos a realizar la operacin en un ordenador. En consecuencia, las aplica-ciones mviles deben funcionar en el momento en el que las necesitamos ya que sino dejaramos deusarlas, provocando as una prdida en el negocio de quien las proporciona. No obstante, para queeso sea posible, las empresas que distribuyen las aplicaciones deberan conocer su disponibilidaden tiempo real para actuar en caso necesario, pero el problema actual que tienen es precisamentela falta de control al respecto.

Existen numerosas soluciones que monitorizan la disponibilidad de servidores, routers, switches,anchos de banda, bases de datos, etc., pero que esa monitorizacin no detecte ninguna anomalano asegura que el usuario nal de una pgina web o una aplicacin mvil disponga del recurso queest solicitando. Para ello es necesario disponer de una monitorizacin adicional que compruebeprecisamente ese uso nal. Para el caso de las pginas webs se pueden encontrar muchas solucionescon las que monitorizar su disponibilidad, ya que este sector ya ha sido explotado durante aos,pero el caso de las aplicaciones mviles es totalmente diferente.

Si bien es cierto que se pueden encontrar distintas herramientas con las que realizar tareas detesting durante el desarrollo de una aplicacin mvil, no ocurre lo mismo con la posibilidad con-trolar su comportamiento una vez implementada. Esto ltimo es realmente importante y necesarioen el caso de aplicaciones mviles interactivas (aquellas que se comunican con un servidor del quedescargan parte del contenido que muestran) ya que, por muy bien que se hayan programado,pueden fallar por muchos motivos debido a su naturaleza.

Precisamente ese tipo de aplicaciones mviles son las que utilizamos en situaciones como lascomentadas al inicio, con lo que, si por un lado se ha visto la necesidad de que el usuario no percibaun problema en ese tipo de aplicacin y, por otro lado, la no despreciable probabilidad de que esoocurra, la necesidad de monitorizar esas aplicaciones es evidente.

En ese contexto se inici este Proyecto Final de Carrera (PFC). La empresa NexTReT, dondeactualmente trabaja la autora de este proyecto, tras analizar las soluciones existentes en el mercadovio una oportunidad de abrirse camino en la monitorizacin de aplicaciones mviles. Las opcionesde la competencia, adems de escasas, requeran de un esfuerzo econmico considerable debido alos complejos sistemas que utilizaban, con lo que, con una opcin alternativa de precio competi-tivo, NexTReT podra conseguir su objetivo. As fue como a la autora de este proyecto le llegla oportunidad de disear y desarrollar una solucin que desempaara esa funcin. Se acept elreto y tras muchos meses de trabajo se lleg a lo que hoy en da NexTReT est ofreciendo con elnombre comercial de MASM.

2.1.1. Usos ms representativos

El sistema de monitorizacin de aplicaciones mviles que se ha desarrollado en este PFC vadirigido a cualquier tipo de organizacin, nacional o internacional, que preste sus servicios onlinea travs de plataformas de movilidad. Se pueden destacar las siguientes:

Administracin pblica en todos sus niveles.

Compaas de eCommerce de todos los sectores.

Sector nanciero.

Compaas de nicho de Internet con soluciones particularmente adaptadas a la movilidad.

16 CAPTULO 2. INTRODUCCIN

2.2. Objetivos del proyecto

2.2.1. Objetivos generales

Desde el punto de vista acadmico, al inicio de este PFC el objetivo era disear e implementarun sistema de monitorizacin de aplicaciones mviles robusto y ecaz, centrndose en conseguir laoptimizacin de cada uno de los elementos a desarrollar.

Por otro lado, desde el punto de vista comercial, la nalidad de iniciar este proyecto fue conse-guir una solucin de monitorizacin de aplicaciones mviles orientada a mejorar la competitividadde las empresas en el mbito del comercio electrnico. Para ello esta solucin deba detectar erroresy cadas de servicios mviles en tiempo real con el objetivo de avisar a los responsables de la misma.De esa forma, la actuacin es inmediata y la afectacin a los usuarios reales de la aplicacin, mnima.

2.2.2. Objetivos especcos

Teniendo en cuenta que la autora de este PFC ha estudiado Ingeniera Superior de Telecomu-nicaciones, plantear un proyecto de programacin ha sido todo un reto, puesto que la experienciaen diseo y desarrollo de aplicaciones Java, as como en diseo de Bases de Datos relacionales eranula. As, a cada uno de los objetivos que se mencionarn a continuacin se tendra que sumar quela autora se tuvo que familiarizar en primer lugar con las plataformas.

Dejando a un lado los primeros objetivos fundamentales de la autora, para lograr las ambiciosasaspiraciones iniciales, se deban alcanzar cada uno de los siguientes objetivos:

Enumerar todas las caractersticas funcionales del sistema.

Especicar los requisitos de cada uno de los mdulos funcionales.

Disear el diagrama de la arquitectura necesario (tanto hardware como software) para satis-facer las funcionalidades anteriores.

Ordenar por preferencia las funcionalidades denidas para decidir con qu prioridad imple-mentarlas.

Estudiar las particularidades de cada uno de los elementos necesarios:

- Mvil:

* Decidir a qu Sistemas Operativos mviles se les dar prioridad a la hora de encon-trar una solucin compatible: denir los indispensables y los complementarios.

* Estudiar una solucin para mantener el mvil operativo las 24h del da.* Analizar las opciones de conexin a Internet del mvil.

- Comunicacin entre ordenador y aplicacin mvil:

* Investigar las herramientas existentes.* Estudiar la compatibilidad de esas herramientas con el proyecto a desarrollar.* Decidir la tecnologa a utilizar.

- Agente:

* Decidir con qu lenguaje de programacin desarrollarlo.* Disear un diagrama de ujo de la aplicacin en el que detallar todos los pasos quedebe realizar.

* Disear un diagrama de clases de la aplicacin en el que detallar todas las clases yfunciones necesarias.

* Denir toda la informacin que el agente debe reportar.* Realizar un estudio de las libreras necesarias teniendo en cuenta las funcionalidadesde la aplicacin.

CAPTULO 2. INTRODUCCIN 17

* Disear y desarrollar la parte grca del agente en base a las necesidades de comu-nicacin del usuario con el agente.

* Integrar la tecnologa de comunicacin escogida entre ordenador y aplicacin mvil.* Establecer un mtodo de comunicacin entre agente y Web Service.* Estudiar cmo controlar los posibles errores de la aplicacin, tanto los de cdigocomo los de comunicacin con el resto de elementos de la arquitectura.

- Web Service:

* Denir cmo comunicarse con el agente.* Denir cmo comunicarse con la Base de Datos.* Averiguar cmo desplegar la aplicacin en un servidor.

- Base de Datos:

* Escoger el gestor de la Base de Datos.* Denir las tablas relacionales necesarias.* Denir los campos necesarios en cada tabla.* Denir qu campos sern auto-incrementales, as como cules tendrn la posibilidadde ser nulos y cules no.

* Disear un diagrama de la Base de Datos en el que relacionar todos los elementospensados.

Como se ver en el captulo 3, el sistema completo de monitorizacin de aplicaciones mvilescontiene ms elementos de los anteriormente comentados. No obstante, tal y como se menciona enlas secciones 3.2.2.1 y 3.3.2.1, la autora de este PFC no ha realizado todos ellos, de ah que losobjetivos se centren en las implementaciones de la autora.

2.3. Estructura de la memoria

Este documento se ha estructurado en 9 captulos, tras los cuales hay una serie de apartados quecomplementan toda la informacin anterior. A continuacin se razona la estructura de la memoria:

Captulo 1: Resumen.

El primer captulo de este documento resume en 3 idiomas, castellano, cataln e ingls,el objetivo de realizar este PFC, el trabajo desempeado para conseguirlo y los resultadosnales obtenidos.

Captulo 2: Introduccin.

En este captulo se inicia realmente la explicacin, ya que el captulo 1 tan slo resumetoda la informacin que se detalla en el documento. As, el captulo 2 constituye la introduc-cin de la memoria, razonando en primer lugar el porqu realizar este proyecto en la situacinactual, para, a continuacin, enumerar los objetivos propuestos para que el proyecto tengasentido.

Captulo 3: Descripcin global del sistema.

En este captulo se describe el sistema global a desarrollar. As, el lector se puede hacerun esquema general de todo lo necesario en un sistema de monitorizacin de aplicacionesmviles, de forma que el seguimiento de los siguientes captulos es ms sencillo.

Captulo 4: Mdulo de intercomunicacin entre agente y mvil.

Tras describir de forma general el sistema de monitorizacin, empiezan una serie de captulosen los que se detallan algunos de los elementos de dicho sistema. El captulo 4 concretamentese centra en la investigacin que se hizo para encontrar una tecnologa con la que comunicarsecon aplicaciones mviles.

18 CAPTULO 2. INTRODUCCIN

Captulo 5: Agente.

Una vez se hall el mtodo de comunicacin con aplicaciones mviles, deba desarrollarseun agente que fuera el encargado de ejecutar circuitos continuamente sobre esas aplicacionesy, tras ello, enviar los resultados. Todo ese procedimiento se detalla en el captulo 5.

Captulo 6: Web Service.

Como intermediario entre los agentes y la Base de Datos se implement un Web Service.En el captulo 6 se detalla su desarrollo.

Captulo 7: Base de datos.

Para almacenar toda la informacin relativa a la monitorizacin es necesario disponer deuna Base de Datos. En el captulo 7 se explica la lgica del diagrama de Base de Datosrelacional que se dise.

Captulo 8: Evaluacin de la solucin.

Para que el sistema de monitorizacin goce de alta disponibilidad, es necesario disponerde elementos que as lo faciliten. En el captulo 8 se explican las medidas preventivas toma-das. Por otro lado, este captulo de evaluacin de la solucin tambin describe la explotacinde resultados que se lleva a cabo a partir de los datos obtenidos por los agentes.

Captulo 9: Conclusiones nales.

Tras explicar todo el trabajo realizado en este proyecto, en el captulo 9 se resalta el va-lor de la solucin obtenida, as como los trabajos futuros que mejoraran el sistema.

Anexos.

En la seccin de anexos se adjuntan documentos que complementan la informacin descritaen los anteriores captulos. La mayora de anexos se mencionan desde la propia memoria,no obstante, los anexos G, H, I y J son procedimientos que la autora ha realizado para queotras personas de NexTReT dispongan de documentacin gestionar el servicio de MASM.Puesto que explican detalles que en la memoria no se mencionan, se ha considera interesanteincluirlos como anexos.

Captulo 3

Descripcin global del sistema

19

CAPTULO 3. DESCRIPCIN GLOBAL DEL SISTEMA 21

3.1. Introduccin

Como se ha comentado en el captulo anterior, al inicio del presente proyecto el desconocimientosobre cmo conseguir el sistema deseado era total, con lo que se pens cmo disearlo a nivel globalpara despus pensar en cmo realizar cada mdulo individualmente. Esta primera fase fue la msimportante del proyecto, ya que de ella dependa que la solucin fuera escalable y able.

En primer lugar, se ide un diagrama de ujo funcional en el que se detall lo que deba realizarel sistema. A partir de ste, se dise un diagrama de la arquitectura de la solucin con el queconseguir las funcionalidades descritas en el diagrama anterior. Para ello se deba tener en cuentaque la arquitectura deba ser escalable, es decir, capaz de albergar tantos terminales mviles ycircuitos como fuera necesario.

En este captulo se detallan los primeros pasos de este PFC, los que corresponden a las fasesde anlisis funcional y diseo tcnico.

3.2. Descripcin de las caractersticas funcionales

3.2.1. Objetivo

Al realizar este proyecto se buscaba una solucin con la que medir la experiencia de usuariode aplicaciones mviles mediante transacciones sintticas, emulando un usuario que continuamenteestuviera usando la aplicacin para comprobar su funcionamiento.

Para conseguir esta monitorizacin, el sistema debe realizar continuamente una serie de accio-nes predeterminadas en la aplicacin mvil, comprobando si la respuesta obtenida es la esperaday, en caso de no serlo, enviar una alerta noticando el problema. Todos los resultados, adems, sedeben mostrar en una pgina web.

Figura 3.1: Realizar acciones sobre una aplicacin mvil para comprobar su funcionamiento

De forma esquemtica el sistema debera seguir el diagrama de ujo funcional que se muestraen la imagen 3.2.

3.2.2. Mdulos funcionales

Desde un punto de vista funcional, la plataforma debera presentar una estructura de mdulosy funcionalidades como la que se expone en la imagen 3.3, donde los cuadros con discontinuidadseran opcionales.

22 CAPTULO 3. DESCRIPCIN GLOBAL DEL SISTEMA

Figura 3.2: Diagrama de ujo funcional de MASM.

A continuacin se detalla cada uno de ellos tal y como se pensaron al iniciar el proyecto y,posteriormente, se comentar cules se han realizado y cules han quedado para trabajos futuros.

Estacin de monitorizacin

Este mdulo es el corazn del sistema, gestiona a otros mdulos permitiendo la reproduccinde los tests y la captacin de medidas. Ejecuta automticamente la secuencia de todos los tests apartir del calendario denido en el Scheduler (ver imagen 3.3) y los repite cclicamente, tomandomediciones y generando alarmas.

El sistema no requiere de ningn conocimiento del funcionamiento de la aplicacin mvil msall del que pueda tener un usuario, no es necesario conocer su cdigo fuente ni ningn dato con-dencial de la misma, tan slo se requiere tener la aplicacin instalada.

Durante la ejecucin de un circuito se comprueba el resultado de un paso antes de pasar alsiguiente. Para ejecutar un paso es necesario que el anterior se haya completado correctamente, encaso contrario, el test acaba donde ha fallado y captura la imagen del mvil en ese instante. Lascapturas de error son una parte fundamental en la explotacin de resultados.

Grabador de scripts

Es el encargado de la grabacin y conguracin de los tests. Dicha grabacin se realiza inter-actuando manualmente con el mvil, de forma que los pasos que se hacen manualmente (clicar,seleccionar, desplazarse, etc.) se guardan automticamente en forma de cdigo. Este cdigo se vacreando en tiempo real a medida que se navega en la aplicacin mvil y de forma transparenteal usuario. As, esta utilidad es de tipo User Friendly ya que permite crear nuevos circuitos sinnecesidad de conocer la forma con la que MASM interacta con el mvil, con lo que la grabacinde tests es un paso trivial dentro del sistema de monitorizacin. Una vez creados, los circuitos sepueden modicar para adaptarlos a las necesidades del entorno cambiante.

Al crear un nuevo test el usuario, adems de realizar las acciones en la aplicacin mvil quedenen dicho test, debe seleccionar el robot(o robots) en el que se ejecutar el test y el cliente alque corresponde. De esta forma, el grabador organiza los scripts creados en una estructura lgicaa diferentes niveles de agrupacin permitiendo que el mdulo Data Warehouse obtenga esa infor-macin. La representacin grca de esa estructura se muestra en la imagen 3.4.


Figura 3.3: Mdulos funcionales de MASM.

Scheduler

Permite seleccionar el calendario de ejecucin de los tests estableciendo las franjas temporalesde funcionamiento. De esta forma, siguiendo el orden de una lista de reproduccin , el schedulercontrola si el test est dentro o no del periodo de validacin y, si lo est, empieza a ejecutarse,mientras que en caso contrario no se ejecuta y pasa a mirarse el siguiente test de la lista.

Por defecto se asigna que los tests se reproduzcan todos los das del ao a todas horas y con lafrecuencia mxima que permita la capacidad del robot considerando los tests que tenga denidos.De forma opcional se puede congurar un calendario personalizado: das concretos del ao, delmes, de la semana, horas concretas del da, periodo mnimo entre ejecuciones, etc.

Alarmas

Alertan ante cualquier error producido en las transacciones de la aplicacin mvil o al detectaruna baja calidad de la aplicacin segn los niveles denidos en el SLA. Existen varios modos deenviar esa informacin:

Mensajes emergentes.

Se muestran en la estacin de monitorizacin.

Envo de e-mail o SMS.

Este tipo de alarmas son congurables por el usuario, permitindole elegir el rangohorario en el que desea que ser informado de las incidencias.

Data Warehouse

El mdulo Data Warehouse permite guardar los datos en un volumen de informacin razonableagrupada en funcin del tiempo y tipo de test.


Figura 3.4: Estructura lgica con la que se organizan los tests de MASM.

Alta disponibilidad

Frente a una cada de la conexin al servidor de base de datos remoto, este mdulo graba losresultados en una base de datos local y al recuperar la conexin los traspasa al servidor de base dedatos. Con esto se consigue no perder resultados en circunstancias anmalas.

Reporting

El componente de reporting online es de utilidad tanto para el cliente como para NexTReTcomo proveedor del servicio de monitorizacin. La explotacin de los datos se muestra en diversosformatos, de forma que la web tiene varios apartados principales:

Panel de estado: Es lo primero que ve un usuario al acceder a la web. El panel de estadose trata de una lista de los tests contratados con unos indicadores visuales que resumen elresultado de los mismos en las ltimas ejecuciones. La visualizacin es del estilo a la que semuestra en la imagen 3.5.

Desde el propio panel de estado podr accederse a un test en concreto haciendo clic sobre l.De esta forma obtenemos informacin ms detallada sobre el mismo tanto en forma de grcacomo de tabla. Los datos se muestran en diversos formatos como grcas, tablas, pdfs, etc.y se clasican de distintas formas: tiempo visual, disponibilidad en muestras, disponibilidaden tiempo, lista de errores, capturas de errores, etc.

Desde el Reporting se podr consultar, administrar y denir las alarmas para todos losusuarios dados de alta en nuestra aplicacin.

Permitir crear grcos predenidos con las consultas ms usuales que se realicen, congu-rando los parmetros que sean de ms utilidad para cada usuario.

Incluir una ayuda que facilitar el aprendizaje y la familiarizacin con la aplicacin web.

3.2.2.1. Funcionalidades realizadas en el proyecto

Las funcionalidades mencionadas en la seccin anterior son las que en su da se pensaron comodeseables, pero de momento no todas ellas se han realizado. A continuacin se detalla el estadoactual de los mdulos funcionales y cules de ellos los ha realizado la autora de este PFC:

Estacin de monitorizacin.

Este mdulo lo ha realizado ntegramente la autora de este PFC.


Figura 3.5: Panel de estado del Reporting web de MASM.

Grabador de scripts.

Este mdulo no se ha realizado, queda pendiente como trabajo futuro.

Scheduler


Alarmas.

Este mdulo est hecho, pero no lo ha realizado la autora de este PFC.

Data Warehouse.


Alta disponibilidad.

Este mdulo no se ha realizado, queda pendiente como trabajo futuro.

Reporting.

Este mdulo est hecho, pero no lo ha realizado la autora de este PFC.

3.3. Descripcin de las caractersticas tcnicas

3.3.1. Introduccin

Para conseguir las funcionalidades deseadas se ha creado un software, al que llamamos agente,que es el encargado de ejecutar tests sobre dispositivos mviles. A partir de estas ejecuciones serecogen mtricas de disponibilidad y tiempo de respuesta de la aplicacin mvil desde el puntode vista del usuario. Estas mtricas se envan a un Web Service para ser almacenadas en la Basede Datos. Mediante otro mdulo se analizan los datos obtenidos y en caso de haberse producidoalgn problema en el uso de la aplicacin, automticamente se enva una alerta al responsabledel servicio. Esta herramienta tiene, adems, la capacidad de generar resmenes automatizados einformes a medida, con lo que se puede consultar online el estado general del servicio a travs delos ltimos resultados disponibles.

3.3.2. Diagrama de la arquitectura

Para conseguir los objetivos mencionados se pens en una arquitectura basada en el diagramasimplicado que se muestra en la imagen 3.6.

A continuacin se mencionan brevemente algunos elementos de la arquitectura.

Los terminales mviles, objeto de automatizacin, acceden a las aplicaciones en red tantopor WiFi como por 3G.


Figura 3.6: Diagrama de la arquitectura MASM.

Se requiere de servidores fsicos en los que se virtualiza un cierto nmero de robots en cadauno. En estos servidores se tienen conectados los dispositivos mviles objeto de las pruebas.Como se explica ms adelante, el nmero de robots a desplegar en cada servidor puede verselimitado segn el tipo de conexin por la que se opte entre el robot y el terminal mvil.

Cada robot es un Sistema Operativo Windows virtual en el que se despliega un solo agente.En la fase de explotacin de la herramienta se ve a estos robots en la nube y se accede a ellosremotamente.

El core del sistema es una aplicacin de escritorio desarrollada en Java J2SE llamada agenteque acta de modo sistemtico ejecutando sobre terminales mviles diferentes circuitos pre-viamente establecidos y guardados como scripts. En estos circuitos estn denidos los pasosa realizar dentro de la aplicacin mvil.

La comunicacin entre agente y terminal mvil puede realizarse por USB o por WiFi, mientrasque la interaccin con la aplicacin mvil se hace por reconocimiento de imagen.

La arquitectura tambin debe disponer de un Web Service y una Base de Datos. En cadaejecucin de un test, el agente comprueba los resultados del mismo y recoge una serie demtricas con los tiempos de respuesta y/o los errores producidos. Estos datos se envan alWeb Service, que es el encargado de recibir y tratar peticiones de la aplicacin y realizar lastareas pertinentes contra la Base de Datos, donde se almacena la informacin relativa a lostests. El Web Service se ha desarrollado en Java J2EE, mientras que para el almacenamientode datos se ha utilizado una BBDD SQL en la que se almacenan los datos con un StoredProcedure que se encarga de agrupar los resultados con temporalidad hora / da / semana /mes para su posterior explotacin.

Mediante otro mdulo se analizan los datos obtenidos para, en caso de detectarse cualquieranomala en la aplicacin, enviar en tiempo real una alerta informando de la indisponibilidad.El sistema de alarmas es congurable y puede escogerse qu tipo de aviso se preere pararecibir la alarma (correo electrnico, SMS, etc.). En la alerta se incorpora un texto en el quese detalla qu servicio concreto est fallando y con qu error, lo que facilita la recuperacindel mismo. Este servicio de gestin y envo de alertas se ha desarrollado en Java.

Otra parte fundamental del sistema completo de monitorizacin es la herramienta de reportingweb, desarrollado en Java J2EE, que permite consultar online los datos obtenidos por elagente. Se desarrollar en Java J2EE.


3.3.2.1. Componentes realizados en el proyecto

En la seccin anterior se ha visto los elementos de la arquitectura necesarios para realizar elsistema de monitorizacin. Obviamente se han realizado todos ellos ya que sino no habra monito-rizacin, pero a continuacin se detalla cules los ha realizado la autora de este PFC:

Terminales mviles.

La preparacin de los terminales mviles (instalacin del software necesario) la ha realizadontegramente por la autora de este PFC.

Mdulo de intercomunicacin entre agente y terminal mvil.

Realizado ntegramente por la autora de este PFC.

Agente.


Robot.

La preparacin de las mquinas virtuales (instalacin del software necesario) la ha realizadontegramente por la autora de este PFC.

Web Service


Base de Datos.


Reporting.

No lo ha realizado la autora de este PFC.

Alarmas.

No lo ha realizado la autora de este PFC.

3.4. Alcance del proyecto

El objetivo a alcanzar era obtener una solucin de monitorizacin de aplicaciones mviles ro-busta y ecaz, centrndose en conseguir los requisitos funcionales ya mencionados. Para ello sellevaron a cabo una serie de tareas encaminadas a cumplir cumplir la totalidad de los requerimien-tos. Las actividades que se realizaron para el desarrollo e implantacin del sistema se describen acontinuacin:

Anlisis funcional

Durante la fase funcional se recogieron los requisitos exactos del sistema, incluyendo el con-tenido visual tanto del agente como del Reporting Web. Para ello, se realizaron reuniones con loscompaeros de NexTReT para denir a partir de los requisitos generales, los detalles de cada fun-cionalidad.

Diseo tcnico

Una vez denidos los requisitos, fue preciso realizar el diseo tcnico del sistema concretandola solucin tcnica que se aplicara para cada funcionalidad.


Investigacin

Debido a las caractersticas de este PFC, fue necesario documentarse e investigar sobre cmoresolver los retos tecnolgicos que supona el sistema que se quera realizar.

Desarrollo

La fase de desarrollo constituy las actividades necesarias para conseguir las funcionalidadesdetalladas en la fase de anlisis, aplicando para ello el diseo tcnico denido. Para el desarrollodel agente, core del sistema, se fueron incorporando nuevas funcionalidades de forma progresivallevando a cabo las validaciones necesarias, de forma que en su nalizacin se tuviera la garantade que se cumplan los objetivos funcionales denidos.

3.4.1. Actividades fuera del alcance del proyecto

Los procesos descritos anteriormente son aquellos que formaron parte de la creacin del sistemade monitorizacin de aplicaciones mviles, es decir, los que se han realizado en este PFC.

Las actividades que se describen a continuacin son las que NexTReT tiene previsto realizar apartir de tener las primeras ventas de este sistema. Se considera de inters para el lector comen-tarlas.

Despliegue en produccin

El proceso de puesta en funcionamiento consistir en la implantacin en un entorno de pro-duccin del nuevo sistema con todas las funcionalidades desarrolladas. Durante el despliegue secontemplan como mnimo dos entornos diferentes:

Un entorno de preproduccin para cada cliente con datos reales de ejecuciones de un solocircuito. Se crear un usuario para que el cliente pueda acceder al Reporting Online y asvisualizar los resultados en todos sus formatos.

Un entorno de produccin (independiente por cliente), real.

Ampliacin de funcionalidades

Se prev que el sistema est en constante evolucin. Como primer objetivo, se estudiar am-pliar la versatilidad a un mayor nmero de terminales mviles. Esto es, obtener accesibilidad deinteraccin con Sistemas Operativos mviles no tan comunes como Windows Mobile y BlackBerry.

Captulo 4

Mdulo de intercomunicacin entreagente y mvil

29

CAPTULO 4. MDULO DE INTERCOMUNICACIN ENTRE AGENTE Y MVIL 31

4.1. Introduccin

Con la arquitectura de la solucin ya pensada, destacaba un mdulo especialmente crtico porser el ms innovador de este PFC, el que deba realizar la automatizacin de acciones sobre elterminal mvil. As, la siguiente fase consisti en averiguar cmo resolverlo. Este captulo se centraprecisamente en exponer el resultado de ese estudio.

La fase de investigacin de este proyecto fue una etapa complicada ya que se jaron unos objeti-vos muy ideales que, a medida que el estudio avanzaba, parecan menos asequibles. Era importanteno descartar ninguna opcin a la ligera, puesto que de la decisin que se tomara en esta fase de-pendera tanto la abilidad como el mantenimiento de la herramienta. Es por ello que se dedicun tiempo considerable a analizar las distintas posibilidades para estar seguros de escoger la msadecuada.

4.2. Fase de investigacin

4.2.1. Objetivos

El propsito de la fase de investigacin era encontrar una forma de realizar acciones sobre apli-caciones mviles cumpliendo los requisitos que se citan a continuacin:

Indispensables:

Tecnologa compatible con terminales iOS.Debido a una estrategia comercial de NexTReT, desde un primer momento el pro-yecto se enfoc en conseguir una solucin para terminales iOS.

Factible sin conocer el cdigo de la aplicacin mvil.Este proyecto se inici con la nalidad de obtener un sistema capaz de monitorizaraplicaciones mviles de terceros, con lo que no se tendra acceso al cdigo de laaplicacin.

Deseables:

Tecnologa compatible tanto con terminales iOS como Android.Si bien es cierto que la bsqueda deba centrarse en encontrar una solucin paraterminales iOS, tambin se estudiaron las opciones para Android, ya que a cortoplazo la herramienta se expandira a Android y la situacin ideal sera encontraruna solucin compatible con ambos Sistemas Operativos.

Factible sin realizar ninguna accin en el terminal mvil.Puesto que de conseguirlo sera un elemento diferenciador frente a soluciones exis-tentes, inicialmente se buscaba una tecnologa con la que no hiciera falta modicarel terminal mvil, es decir, que pudiera ejecutarse en terminales venidos de fbrica,sin necesitar acceso root ni realizar jailbreak.

Interaccin con la aplicacin mvil por objeto.Inicialmente se prefera una tecnologa basada en objetos, frente a la deteccin porimagen, puesto que los objetos siempre son accesibles aunque no se vean visualmenteen la pantalla del dispositivo.

Sencilla creacin y modicacin de tests.Pensando en el futuro mantenimiento de la herramienta, sera conveniente encon-trar una forma con la que realizar tests de forma sencilla, es decir, que cualquierpersona ajena al proyecto y sin conocimientos tcnicos pudiera hacerlos siguiendoun pequeo manual.

32 CAPTULO 4. MDULO DE INTERCOMUNICACIN ENTRE AGENTE Y MVIL

4.2.2. Desarrollo de la bsqueda

En la investigacin concretamente se buscaba una API, un framework o una librera que sir-viera de capa de abstraccin entre el terminal mvil y el Java. A continuacin se presentarn lasherramientas ms relevantes que se encontraron, se compararn y se expondrn las razones de laeleccin de una de ellas.

4.2.2.1. UI Automation

Instruments es una aplicacin de escritorio para Mac OS X que proporciona Apple como partede Xcode (IDE de desarrollo de aplicaciones iOS). Instruments es una herramienta de rendimiento,anlisis y testing de cdigo OS X e iOS. En la versin de Xcode 4 se aadi una nueva funcionalidada Instruments llamada Automation que permite realizar testing GUI en simuladores y dispositivosiOS. Con la incorporacin de esta herramienta, se pueden automatizar casos de prueba escritos enJavaScript utilizando las APIs de UI Automation que proporciona Apple.

Automation viene con un editor de cdigo y dispone de un grabador que facilita la tarea descripting. La interfaz grca es tal como se muestra en la imagen 4.1.

Figura 4.1: UI Automation: Interfaz grca de Automation.

Anlisis de los scripts

Los scripts de esta herramienta se escriben utilizando las clases JavaScript que proporcionaApple y cuya informacin puede encontrarse en la referencia bibliogrca [1]. Basndose en la


presencia de ciertos elementos UI o su valor (id del objeto), estos scripts se pueden usar paracomprobar si la aplicacin se est comportando de acuerdo a las expectativas.

El primer paso es tener una referencia de la aplicacin a la que se quiere acceder. Para ellodeben aadirse las siguientes lneas de cdigo al inicio del test:

target = UIATarget.localTarget();application = target.frontMostApp();

En la primera lnea, UIATarget es la vista principal de la aplicacin mvil que se ejecuta en eldispositivo o el simulador. Acta como una especie de proxy, es el objeto con el que se interacta pa-ra realizar acciones sobre el terminal como jugar con los controles de volumen, mover el dispositivoo realizar gestos de usuario. En la segunda lnea, el objeto application da acceso a la estructura dealto nivel de la aplicacin, a cosas como la barra de navegacin, las pestaas y la ventana principal.

En la imagen 4.2 puede verse un script GUI muy simple que genera eventos aleatorios en unaaplicacin de iPad. Bsicamente simula tocar distintas posiciones de la pantalla del terminal, dondelas posiciones vienen determinadas por una funcin matemtica que genera nmeros aleatorios.

Figura 4.2: UI Automation: Ejemplo de script que genera eventos aleatorios.

En el ejemplo anterior se simula tocar posiciones de pantalla (mTarget.tap(x:xPos,y:yPos)),pero tambin se puede interactuar con objetos concretos si la aplicacin tiene botones u otros ele-mentos. Para ello, se obtiene el elemento y entonces se interacta con l. Por ejemplo, el cdigo dela imagen 4.3 clicara sobre el elemento llamado Equation library, accesible en la vista rootViewde la aplicacin.

Con esta herramienta se pueden simular una variedad de movimientos y gestos, por ejemplo:

tap()

tapAndHold(Number duration)


Figura 4.3: UI Automation: Ejemplo de lnea de script que obtiene los elementos de una aplicacin.

doubleTap()

twoFingerTap()

touchWithOptions(Object options)

dragInsideWithOptions(Object options)

ickInsideWithOptions(Object options)

scrollToVisible()

Automatizacin de scripts

Esta herramienta puede servir de capa de abstraccin de forma sencilla, ya que los scripts pue-den ejecutarse desde la lnea de comandos. La nomenclatura del comando es la siguiente:

instruments -w numeroSerieTerminalReal -t rutaAutomationTemplate rutaAplicacin-e UIASCRIPT rutaScript -e UIARESULTSPATH rutaResultados

Donde:

instruments: comando que hace referencia al programa Instruments.

-w : Con este argumento se especica que el script se va a ejecutar sobre un dispositivo real.A continuacin, separado por un espacio en blanco, se escribe el nmero de serie del terminal.

-t : Con este argumento se especica la funcionalidad de Instruments que se va a utilizar, eneste caso Automation. A continuacin, separado por un espacio en blanco, se escribe la rutadonde se encuentra el archivo Automation.tracetemplate en el Mac.

En el siguiente argumento se especica la ruta de la aplicacin dentro del terminal mvil.

-e UIASCRIPT : Con este argumento se especica la ruta de ordenador donde est el scripta ejecutar.

-e UIARESULTSPATH : Con este argumento se especica la ruta de ordenador donde dejarlos logs del script.

Para comprobar si esta herramienta era til para el proyecto, se dispona de un Mac OS X10.7 y un iPad 3 para realizar las pruebas. Se encontraron las correspondientes rutas y se lanzel comando. La ruta de Mac donde se encuentra el archivo Automation.tracetemplate dependede la versin de Xcode instalada, mientras que para encontrar la ruta en la que se encontrabanlas aplicaciones del iPad, se instal un programa que permita explorar el contenido del terminal.En este caso pretenda ejecutarse un script sobre la aplicacin de La Caixa y las rutas eran lassiguientes:

rutaAutomationTemplate: /Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate

rutaAplicacin: /laCaixa.app/laCaixa


Al ejecutar el comando se consigui abrir la aplicacin, pero no se realizaba ninguna de lasacciones que se haban escrito en el script. De hecho, si se ejecutaba el comando sin el parmetro-e UIASCRIPT, es decir, sin especicar el script que se quera ejecutar, ocurra exactamente lomismo, se abra la aplicacin y nada ms. Viendo esto, pareca que por algn motivo el script nose comunicaba con la aplicacin mvil.

Dicho script se haba escrito manualmente, con lo que otra prueba que se hizo fue intentarcrearlo con el grabador del que dispone Automation. Con este grabador, si todo va bien, mientrasse realizan acciones manualmente sobre la aplicacin mvil, en tiempo real se van creando lneas decdigo JavaScript que equivalen a los gestos que se hacen. Esto, en cambio, no ocurra en nuestrocaso. De nuevo se vea un problema de comunicacin con la aplicacin mvil.

Se hizo una ltima prueba que veric las sospechas anteriores. Se realiz una pequea apli-cacin iOS con Xcode, se compil, se instal en el iPad y se comprob que sobre esa aplicacinno haba ningn problema. El grabador realizaba su funcin correctamente y los scripts que selanzaban se ejecutaban con normalidad.

As, tras el estudio realizado, se lleg a la conclusin de que la herramienta UI Automation sloes til en el caso de disponer del cdigo de la aplicacin mvil. Se investig al respecto y se vioel porqu: Apple hace rmar las aplicaciones iOS con un certicado y, para que los scripts de UIAutomation se puedan comunicar con una aplicacin, se debe ejecutar un build especial que linqueel certicado del que se dispone con el certicado con el que cre la aplicacin.

Pros y Contras de la herramienta

Pros:

El JavaScript es sencillo de aprender. Aplicable a simulador y terminal real. Soporta todo tipo de gestos. Tiene soporte de la comunidad de Apple. Permite ejecutar comandos nativos como el comando de shell ImageMagick as como

otros scripts para comparar imgenes, con lo que puede combinarse con deteccin deimagen.

Contras:

Slo disponible en Mac OS X. Slo disponible para aplicaciones iOS. Para ser utilizado en un terminal iOS fsico se necesita tener el cdigo de la aplicacin.

Compatibilidad con el PFC

Esta herramienta es muy potente, pero no se puede usar si el cdigo de la aplicacin es de untercero, lo cual es un requisito indispensable para este proyecto. Por tanto, se descarta.

4.2.2.2. Monkey

Monkey es una herramienta de lnea de comandos disponible en el SDK de Android capazde generar movimientos de usuario pseudo-aleatorios tanto en emuladores como en terminalesAndroid. Incluye bastantes opciones que se pueden clasicar como sigue:

Opciones de conguracin bsica, como determinar el nmero de eventos a realizar.

Limitaciones operacionales, como restringir el test a un slo package, es decir, a una solaaplicacin mvil.


Tipos de eventos y frecuencia de los mismos.

Opciones de depuracin.

Cuando se ejecutaMonkey, genera y enva eventos al sistema. Tambin observa el sistema sobreel que est ejecutndose y busca tres condiciones:

Si Monkey se limita a uno o varios packages previamente jados, vigila si hay intentos denavegar a otros packages y los bloquea.

Si la aplicacin sobre la que se ejecuta Monkey se cuelga o recibe algn tipo de excepcin nocontrolada, Monkey para y reporta el error.

Uso bsico de la herramienta

Como se ha comentado, es una herramienta que se ejecuta desde la lnea de comandos. Lasintaxis bsica es la siguiente:

adb shell monkey [opciones]

Si no se especica ninguna opcin, Monkey enva eventos a cualquier (y a todos) los packagesinstalados en el dispositivo/emulador. A continuacin se muestra un ejemplo tpico con el que seabrir una aplicacin concreta y sobre ella se ejecutarn 500 eventos aleatorios:

adb shell monkey -p nombre.de.package -v 500

Puede encontrarse ms informacin sobre la herramienta en la referencia bibliogrca [2].


Pros:

Sencillez del uso.

Contras:

Slo til para Android. Slo genera eventos aleatorios, no pueden especicarse cules.


Esta herramienta suele utilizarse para realizar pruebas de estrs a aplicaciones mviles en fasede desarrollo. En ese mbito reside su utilidad, pero no sirve para el objetivo del proyecto, con loque queda descartada.

4.2.2.3. MonkeyRunner

El SDK de Android consiste en una serie de herramientas para desarrollar y realizar pruebassobre aplicaciones mviles Android. Una de estas herramientas esMonkeyRunner, capaz de realizaracciones UI programadas sobre terminales Android sin necesidad de acceso root.

El Sistema Operativo mvil Android dispone de una aplicacin pre-instalada llamada Monkey.MonkeyRunner se ejecuta desde el ordenador, crea una conexin socket con Monkey con la ayudade Android Debug Bridge (ADB) y enva comandos a Monkey, quien es el que realmente ejecutalas acciones en el dispositivo.


Anlisis de la herramienta

La herramienta MonkeyRunner puede usarse con Python o con Java. Durante la investigacinprincipalmente se estudi su versin en Python, pero son equivalentes.

MonkeyRunner con Python

Para ejecutar un script deMonkeyRunner, tan slo debe enviarse la siguiente lnea de comandos:

monkeyrunner nombreScript.py

A continuacin se comentarn las lneas de cdigo ms importantes de estos scripts y el estudiorealizado con respecto a esta herramienta.

En primer lugar es necesario denir el target del script, es decir, sobre qu terminal se va aejecutar y concretamente en qu aplicacin. Para ello se escriben las siguientes lneas de cdigo:

device = MonkeyRunner.waitForConnection()package = nombrePackageAplicacinactivity = nombreActivityAplicacinrunComponent = package + '/' + activitydevice.startActivity(runComponent)

La primera lnea sirve para conectarse con el terminal Android enchufado por USB al orde-nador (ms adelante se har un inciso al respecto) y las siguientes lneas sirven para seleccionarla aplicacin con la que se quiere interactuar. Para ello se debe escribir el nombre del package yde una Activity de la aplicacin. Es importante mencionar que las aplicaciones Android tienenun nico package, pero pueden tener varias Activitys, es decir, varias ventanas. Para conocer esosnombres, existe una aplicacin Android llamada Package Manager Ad con la que se puede ver elpackage y las Activitys de las aplicaciones instaladas en el mvil. Durante el estudio se realiza-ron pruebas sobre la aplicacin de La Caixa, as que las las lneas de cdigo quedaron de esta forma:

device = MonkeyRunner.waitForConnection()package = ès.lacaixa.mobile.android.newwapicon'activity = ès.lacaixa.mobile.android.newwapicon.SplashActivity'runComponent = package + '/' + activitydevice.startActivity(runComponent)

Cabe destacar que en la primera lnea se asume que slo hay un terminal conectado. En casode tener varios, podra utilizarse el comando adb devices disponible en el SDK de Android paraescoger uno de ellos. Un ejemplo de cmo hacerlo sera el cdigo que se muestra en la imagen 4.4, enel que se escoge el primer terminal que aparece en la lista. Obviamente esto se podra personalizary escoger el terminal, por ejemplo, por el nmero de serie.

Una vez denido el target del script, ya se puede comenzar a interactuar con l. Algo comn essimular la accin de clicar sobre un objeto de la aplicacin mvil. Para ello habra dos formas dehacerlo:

Enviando las coordenadas (x,y) de la pantalla del mvil, por ejemplo:device.touch(225, 182, MonkeyDevice.DOWN_AND_UP)

Especicando el tipo de objeto, por ejemplo:device.press(`KEYCODE_MENU', MonkeyDevice.DOWN_AND_UP)

El string MonkeyDevice.DOWN_AND_UP es el tipo de accin que se va a realizar, mientrasque el string `KEYCODE_MENU' del segundo caso es el tipo de objeto con el que se va a inter-actuar.


Figura 4.4: MonkeyRunner: Cmo escoger uno de los mviles conectados por USB.

Al contrario de lo que ocurra con UI Automation, conMonkeyRunner s podemos comunicarnoscon los objetos de la aplicacin a pesar de no tener el cdigo de la misma. Para ello se debe conocerel tipo de objeto con el que se quiere interactuar, pero eso no es trivial. A priori el tipo de objetose conoce realizando prueba y error, con el tiempo que ello conlleva, sobretodo teniendo en cuentatodos los tipos de objeto que existen (en la referencia bibliogrca [3] pueden verse todos ellos). Esevidente que este camino no es viable, con lo que se buscaron otras formas de encontrar los objetos.

1. Mediante uiautomatorviewer.

El SDK de Android dispone de una herramienta grca llamada uiautomatorviewer conla que se puede escanear y analizar los componentes UI de una aplicacin Android. Enla imagen 4.5 se muestra el resultado de la prueba que se realiz de esta herramientasobre la aplicacin de La Caixa. Como puede verse, este programa tiene dos partes di-ferenciadas: la vista de la pantalla del dispositivo y los elementos UI hallados en esavista. Si se selecciona uno de los elementos (parte derecha de la imagen), se resalta dichoelemento con un marco rojo (parte izquierda de la imagen).

Como se aprecia en la imagen, en este caso la aplicacin tiene una WebView (elementoresaltado en la imagen) que uiautomatorviewer ve como un todo. Con esto pudo com-probarse que uiautomatorviewer es incapaz de discernir entre los elementos dentro deWebViews. Con lo cual, puesto que esta herramienta no puede diferenciar todos los ob-jetos que pueden tener las aplicaciones, qued descartada como utilidad para el proyecto.

2. Mediante AndroidViewClient.

Existe una extensin de MonkeyRunner llamada AndroidViewClient que le proporcio-na una visin de ms alto nivel para que el scripting sea ms sencillo. Se descarg laextensin y se realizaron pruebas.

En dicha extensin se encontr un script interesante llamado dump.py (Anexo A) quedetecta los elementos UI de la pantalla del mvil y les asigna un nombre a cada uno(ìd/no_id/1',ìd/no_id/2',ìd/no_id/3', etc.). Con este script se abra una posibilidad:a pesar de no tener el cdigo de una aplicacin, se podra ejecutar este script, parsearsu salida para conocer el nombre que le ha asignado a un objeto X que nos interesara yas interactuar con dicho objeto a partir del nombre asignado.

Para comprobar si realmente el script era de utilidad, se lanz con la pantalla del mvilen el mismo punto en el que se ve en la imagen 4.5. El resultado fue el que se muestraen la imagen 4.6.


Figura 4.5: MonkeyRunner: Interfaz de Usuario capturada por uiautomatorviewer.

Figura 4.6: MonkeyRunner: Resultado ejecucin script dump.py.

Comparando las imgenes 4.5 y 4.6 se llega a la conclusin de que el script dump.pyextrae exactamente los mismos elementos que la herramienta uiautomatorviewer. Estoes debido a que, como puede verse en la lnea 127 del anexo A, el script dump.py utilizala funcin dump() de la clase ViewClient que, como puede verse en la lnea 29 del anexoB, a su vez utiliza el comando uiautomator dump del SDK de Android. Dicho comandoes el mismo sobre el que se sustenta la herramienta uiautomatorviewer y por eso obte-nemos el mismo resultado.

En conclusin, el script dump.py tambin tuvo que descartarse puesto que tena el mis-mo problema con las WebViews que uiautomatorviewer.

3. Mediante EasyDevice.

Se encontr otra extensin interesante de MonkeyRunner, en este caso una librera lla-mada EasyDevice que sirve para interactuar con los objetos de la aplicacin mediantesu id. A continuacin se muestra un ejemplo del uso de esta librera:

device = MonkeyRunner.waitForConnection()easy_device = EasyMonkeyDevice(device)easy_device.touch(By.id(ìd/nameId'),MonkeyDevice.DOWN_AND_UP)

Con el uso de esta librera, una vez conocidos (o asignados) los nombres de los ob-jetos de la aplicacin mvil, ya se puede interactuar con ella. No obstante, los nombresno se conocen porque no se dispone del cdigo de la aplicacin y, la asignacin de stos


se ha visto anteriormente que no est resuelta, con lo que slo por esto ya podra des-cartarse esta opcin. A ello se suma el hecho de que EasyDevice slo puede ejecutarsesobre terminales de desarrollo, con lo que para un mvil comercial no sirve.

En conclusin, no se encontr ninguna forma de conseguir que la creacin de scripts se pudierahacer de forma rpida, sencilla y/o automatizada. Se encontraron atajos interesantes para detectarlos objetos, pero ninguno de ellos aplicaba totalmente. As, la nica va con la que poder interac-tuar con todos ellos era la inicial, prueba y error con el tipo de objeto.

MonkeyRunner con Java

MonkeyRunner tambin puede ejecutarse desde Java, no obstante, el estudio es equivalente alde Python, as que simplemente se comenta como curiosidad.

El SDK de Android proporciona archivos .jar que pueden incluirse en proyectos Java. Son lossiguientes:

ddmlib.jar

ddms.jar

jython.jar

monkeyrunner.jar

sdklib.jar

En la imagen 4.7 se muestra un ejemplo del cdigo que se utilizara en Java. La primera lneade cdigo inicializa el ADB y las siguientes lneas se entienden por s solas.

Figura 4.7: MonkeyRunner: Ejemplo de test escrito en Java.



Pros:

No es necesario conocer el cdigo de la aplicacin. Muchas de las funciones se pueden utilizar en terminales comerciales. Capaz de realizar tests en varios dispositivos a la vez. Aplicable a simulador y terminal real. El lenguaje es sencillo de aprender. Existe mucha documentacin en Internet.

Contras:

Slo aplicable a terminales Android. Los scripts son muy personalizados y conlleva mucho tiempo realizarlos.


Esta herramienta puede parecer interesante puesto que aporta una comunicacin por objetocon las aplicaciones an sin tener acceso al cdigo de las mismas, pero es importante pensar en elmantenimiento del sistema completo que se va a realizar en este proyecto. No es admisible que larealizacin de los tests sea tediosa. Este proceso debe ser lo ms sencillo y rpido posible, ya quesino se perdera mucho tiempo para cada test que solicitara un cliente, lo cual no sera nada con-veniente para NexTReT ni para el empleado que tenga esa tarea. Es por ello que MonkeyRunnerse descarta en ese investigacin.

4.2.2.4. MonkeyTalk / FoneMonkey

MonkeyTalk, anteriormente conocido como FoneMonkey, es una herramienta open source dise-ada para ayudar a los desarrolladores y a los controles de calidad de aplicaciones mviles iOS yAndroid.

La plataforma consiste en dos componentes principales: el IDE de MonkeyTalk y los agentesde MonkeyTalk. El IDE es una herramienta basada en Eclipse con la que grabar, editar, ejecutar yadministrar tests. En la referencia bibliogrca [4] se explica como congurar Eclipse para poderutilizarlo como IDE de MonkeyTalk. Por otro lado, los denominados agentes son libreras para iOSy Android que deben conectarse con la aplicacin mvil.

Como puede verse en la documentacin facilitada en [5], esta herramienta lo que hace es utilizarcomo capa de abstraccin UI Automation en el caso de iOS yMonkeyRunner en el caso de Android,para unicar ambos Sistemas Operativos en un nico lenguaje de testing.


Puesto que MonkeyTalk se basa en UI Automation y en MonkeyRunner, si se descartaron estasopciones anteriormente, MonkeyTalk tambin queda descartada.

4.2.2.5. Frank

Frank es una herramienta open source para realizar testing UI de aplicaciones iOS. Frank uti-liza Cucumber [6] y JSON, a travs de los cuales se pueden escribir tests y ejecutarlos contra unaaplicacin iOS. Frank tambin incluye un inspector de aplicaciones llamado Symbiote con el quese puede obtener informacin detallada de la aplicacin que se est ejecutando.


Los scripts de Frank son muy sencillos de realizar. En la imagen 4.8 se muestra un ejemplo enel que se navega entra las distintas ventanas de una aplicacin.

Figura 4.8: Frank: Ejemplo de script.


Pros:

Viene con Symbiote, con lo que no slo puede realizar testing UI sino que puede obtenerinformacin detallada de la aplicacin en ejecucin.

Puede grabar un vdeo mientras realiza el test. Aplicable tanto a simulador como a terminal fsico. Tiene un lenguaje muy sencillo.

Contras:

Escasa posibilidad de gestos. Para utilizarse en un terminal iOS fsico es necesario tener el cdigo de la aplicacin

mvil.


Dado que requiere del cdigo de la aplicacin iOS, se descarta esta herramienta.

4.2.2.6. Appium

Appium es un framework open source que realiza testing de aplicaciones iOS. Bsicamente loque hace es utilizar UI Automation como capa de abstraccin para despus escribir los tests concomandos propios. No aporta nada distinto a UI Automation, con lo que qued descartado.

4.2.2.7. Native Driver

Native Driver ha derivado del proyecto Appium. Es un framework que engloba tanto iOS comoAndroid, con lo que se puede interactuar con ambos Sistemas Operativos con un mismo lenguaje,pero dado que proviene de Appium, la parte iOS tiene el problema de necesitar el cdigo de laaplicacin. En conclusin, tambin se descarta esta solucin.

4.2.2.8. Robotium

Robotium es un framework open source para automatizar tests para aplicaciones Android. Sepuede usar tanto en aplicaciones de las que se disponga el cdigo como en aplicaciones de las queslo se tenga el .apk y los detalles de la implantacin se desconozcan.

Se estudiaron las posibilidades de esta herramienta y se descart ya que slo serva para An-droid y no aportaba nada distinto que no se hubiera visto con MonkeyRunner.


4.2.2.9. UISpec

UISpec es un framework Behavior Driven Development (BDD) para iOS que proporciona unasolucin para automatizar testing UI del cual se puede encontrar ms informacin en la referenciabibliogrca [7]. En lo que se reere a la investigacin, se descart por requerir el cdigo de laaplicacin mvil.

4.2.2.10. Keep it Functional (KIF)

KIF es un framework open source desarrollado por la compaa square. Permite desarrollartests en Objective C sobre aplicaciones iOS en un simulador iPhone o iPad. Para ello se integranlos tests en el IDE de desarrollo Xcode y se ejecutan desde ah.

Esta herramienta se descart puesto que slo es til en simuladores iOS, adems, requiere co-nocer la estructura del cdigo de la aplicacin.

4.2.2.11. Sikuli

Despus de descartar las herramientas anteriores, se presenta la solucin por la que nalmentese opt. Durante la fase de investigacin se encontr una herramienta llamada Sikuli capaz derealizar testing UI mediante reconocimiento de imgenes.

Sikuli permite realizar acciones automatizadas sobre cualquier cosa que sea visible en la pan-talla del ordenador. Adems, es compatible tanto con Windows como con Mac OS X.

Anlisis de la herramienta

En la imagen 4.9, extrada de la referencia bibliogrca [9], pueden verse los mdulos que hacenposible la herramienta.

Figura 4.9: Sikuli: Diagrama de la herramienta.


Sikuli Script

Sikuli Script es una librera Jython y Java que automatiza interaccin GUI usando patronesde imagen para dirigir eventos de teclado y ratn del ordenador. El core de Sikuli Script es unalibrera Java que consiste en dos partes:

java.awt.Robot : efecta eventos de teclado y ratn en la posicin adecuada.

Motor C++ basado en OpenCV : busca los patrones de imagen en la pantalla del ordenador.

El motor C++ est conectado a Java mediante Java Native Interface (JNI). Por encima de lalibrera Java, existe una capa Jython para el usuario nal que realiza los scripts, con una serie decomandos fcilmente comprensibles.

Estructura de un script de Sikuli

Un script de Sikuli(un archivo .sikuli) es un directorio que contiene un archivo .py y todaslas imgenes .png que se mencionan en el archivo .py. El cdigo del script .py puede modi-carse en cualquier editor de texto, pero si se hace desde el IDE de Sikuli, ste crea un archivoextra .html que tambin se crea en el directorio .sikuli. Este ltimo archivo .html no aporta nadaen cuanto a la ejecucin de los tests, simplemente aporta una forma diferente de visualizar el script.

El IDE de Sikuli

El IDE de Sikuli permite editar y compilar los scripts. Integra una funcionalidad para capturarimgenes y un editor de texto personalizado para facilitar la tarea de escritura de los scripts. Enla imagen 4.10 se muestra el IDE de Sikuli en un Windows XP.

Figura 4.10: Sikuli: IDE de Sikuli.

Para ejecutar un script de Sikuli, el IDE de Sikuli crea un org.python.util.PythonInterpretery automticamente enva una serie de cabeceras (como los mdulos Jython de Sikuli y la ruta


del directorio .sikuli) al intrprete. Una vez establecidas estas cabeceras, se ejecuta el archivo .pymediante PythonInterpreter.execle().

Realizacin de scripts

El archivo .py del directorio .sikuli es el que contiene el cdigo de las acciones que debe realizarSikuli. Como se ha comentado anteriormente, dicho archivo puede modicarse directamente en uneditor de texto o mediante el IDE de Sikuli. El resultado del script ser exactamente el mismo, tanslo cambia la interfaz grca que el usuario tiene al escribirlo. Por ejemplo, en las imgenes 4.11y 4.12 puede verse el mismo cdigo, en la primera sera desde el IDE de Sikuli y en la segundadesde Notepad ++.

Figura 4.11: Sikuli: Ejemplo script desde el IDE de Sikuli.

Figura 4.12: Sikuli: Ejemplo script desde un editor de texto.

Cmo encaja Sikuli en el proyecto

Sikuli automatiza acciones sobre la pantalla de un ordenador con lo que, si se obtuviera laimagen de un mvil en el ordenador, tambin podra automatizar acciones sobre la pantalla de unmvil. Para ello tan slo quedara enviar esas acciones al mvil. Todo esto se resuelve con una cone-xin VNC entre el ordenador y el mvil, donde el primero acta de cliente y el segundo de servidor.

En este sentido se estudi si esto era posible y se encontr lo siguiente:

Terminales iOS:

La compaa Apple es muy restrictiva con segn qu acciones se quieren realizar sobreterminales iOS y, en este caso, no permite subir aplicaciones de tipo servidor VNC a AppStore. No obstante, si se realiza Jailbreak al dispositivo es posible encontrar este tipode aplicaciones en Cydia, el equivalente a App Store una vez se ha realizado Jailbreak.Concretamente existe una aplicacin llamada Veency que realiza esta funcin.

Terminales Android:

La mayora de aplicaciones Android que sirven como servidor VNC requieren accesoroot en el mvil, pero existe una aplicacin de pago disponible en Play Store llamadaVNCLite que no lo necesita.


Pros:

No requiere ningn tipo de conocimiento del cdigo de la aplicacin. El lenguaje de los scripts es muy sencillo.


Aplicable a todo tipo de Sistemas Operativos mviles. Se puede ajustar el grado de exactitud de la imagen de referencia con la imagen obtenida

en la pantalla.

Contras:

Una imagen no se detecta si, a pesar de ser la misma que la imagen de referencia, eltamao o la resolucin es diferente.

En el caso de dispositivos iOS, es necesario realizar Jailbreak.

4.2.3. Conclusiones de la bsqueda

Durante la fase de investigacin se consider que la ltima herramienta mencionada, Sikuli, erala que mejor se poda adaptar a este PFC. Si bien es cierto que con ella no se cumplen todos losobjetivos que se haban propuesto, s gran parte de ellos.

Como objetivo indispensable se haba jado encontrar una tecnologa compatible con iOS. Puesbien, con Sikuli no slo se obtiene compatibilidad con iOS sino tambin con Android y con cual-quier Sistema Operativo mvil.

Otro objetivo indispensable era que la herramienta fuera til sin conocer el cdigo de la aplica-cin. Obviamente Sikuli lo es ya que no interacta en ningn caso con el cdigo, sino simplementecon la imagen que obtiene en la pantalla del ordenador.

De entre los requisitos deseables que se haban mencionado, a parte de la compatibilidad tantocon iOS y Android que ya se ha comentado, no ha sido posible evitar el acceso root a los terminales.En el caso de Android s que se puede evitar si se utiliza la aplicacin de pago VNCLite, pero alos terminales iOS se les tendra que realizar un Jailbreak para utilizar Sikuli.

Por otro lado, en un principio se buscaba una herramienta que interactuara con las aplicacionespor objeto porque se consider que sera ms sencillo de esa forma, pero nalmente se vio que eseobjetivo complicaba las cosas. En el caso de iOS, simplemente no es posible realizarlo sin tener elcdigo de la aplicacin, mientras que en Android s puede hacerse, pero se ha visto que no de unaforma sencilla. En este sentido, nalmente no se interactuar con la aplicacin por objeto sino porimagen.

Por otro lado, otro objetivo deseable era que la creacin y modicacin de los scripts fuerasencilla. Con Sikuli no slo es sencilla sino que visualmente se entiende perfectamente las accionesque realiza el test.

En conclusin, despus de un largo periodo de investigacin acerca de las herramientas decomunicacin con terminales mviles existentes, se encontr una manera de solventar el hndicapmediante una solucin que nada tiene que ver, a priori, con aplicaciones mviles, pero que aplicadade forma inteligente cumple perfectamente el cometido.

Captulo 5

Agente

47

CAPTULO 5. AGENTE 49

5.1. Fase de diseo

Tras la investigacin que se ha detallado en el captulo anterior, se inici el desarrollo msimportante de este PFC, el software denominado agente. ste se desarroll en Java J2SE dada laoportunidad de reutilizacin y la versatilidad de libreras de objetos de este lenguaje. Precisamen-te con el objetivo de aprovechar esas caractersticas propias del Java as como para realizar unabuena planicacin del cdigo, se disearon diagramas Unied Modeling Language (UML) previosal propio desarrollo de la aplicacin.

5.1.1. Diagramas UML

UML es un lenguaje grco para visualizar, especicar y documentar cada una de las partesque comprende el desarrollo de software. As, la realizacin de diagramas UML sirve para repre-sentar visualmente las reglas de creacin, estructura y comportamiento de un grupo relacionado deobjetos y procesos, as como para mantener gilmente las especicaciones ante cambios y nuevasactualizaciones de la arquitectura.

A continuacin se comentarn los diagramas UML que se realizaron en este PFC, en los que sedetall qu deba realizar la aplicacin Java y cmo deba hacerlo a nivel de cdigo.

5.1.1.1. Diagrama de ujo

En primer lugar se ide un diagrama de ujo en el que plasmar los pasos que deba realizarla aplicacin Java a desarrollar. Cabe mencionar la diferencia entre el diagrama de ujo que seexpondr a continuacin y el previamente mostrado en la imagen 3.2. ste ltimo resume de formageneral las funcionalidades del sistema completo de monitorizacin englobando todos los elementosde la arquitectura del sistema, mientras que el diagrama de ujo al que se reere esta seccindescribe exclusivamente el ujo a seguir del cdigo Java, es decir, incluyendo tan slo el agente yel Web Service.

En el anexo C puede verse el diagrama de ujo realizado. El estado inicial corresponde al mo-mento en que se abre el programa, a partir del cual empieza su inicializacin. Durante ese procesose muestra un mensaje de bienvenida indicando que la aplicacin se est cargando. Mientras tantose realizan una serie de acciones necesarias para la monitorizacin. Esto es bsicamente identicarel robot en el que se ejecuta el agente y descargar los correspondientes tests. Para ello el usuariohabr escrito previamente el nombre del robot en un archivo de tipo properties y a partir de stela aplicacin identica los tests de dicho robot y los descarga de un servidor. Esta descarga serealiza una nica vez, en la inicializacin, para posteriormente reproducirlos de forma cclica. Encaso de que el usuario quisiera cambiar la identicacin del robot o actualizar de alguna forma lalista de tests (por ejemplo, aadiendo uno nuevo), tendra que reiniciarse la aplicacin para quereconociera los cambios.

Una vez terminada la inicializacin, el mensaje de bienvenida desaparece y se abre el programaen estado de espera. En el momento en que el usuario pulsa el botn play, la ejecucin de testscomienza siguiendo el orden de una lista. Para ello en primer lugar es necesario comprobar si altest le toca ejecutarse, es decir, como parte de la conguracin de un test es posible seleccionar,por ejemplo, horas en concreto en las que el test se ejecuta, con lo que es necesario comprobar si lahora en la que se realiza esa comprobacin est dentro del calendario especco del test. En casoarmativo, lo siguiente es saber en qu terminal mvil debe ejecutarse para abrir una conexinVNC con el mismo. Dicha conexin se realiza en dos fases, primero se redirecciona el puerto TCPlocal de la mquina al del mvil y despus se abre un cliente VNC al puerto TCP local, es decir,conectando con localhost. Se decidi hacerlo de esta forma para que la conexin entre la mquinay el mvil fuera va USB y no por WiFi para ser as ms rpida y estable.

50 CAPTULO 5. AGENTE

Una vez abierta la conexin VNC, se ejecuta el test correspondiente y se realizan las accionespertinentes para poder ver su resultado con posterioridad. Por un lado se actualiza el archivo delogs del test. En este archivo pueden verse todos los pasos que ha realizado el script, incluso siha tenido un error de cdigo. Este archivo es relevante en caso de detectarse una anomala en laejecucin del test ya que se detalla todo lo que ha hecho y en qu punto ha fallado.

Por otro lado, a partir de la salida del script (la que se ha escrito a su vez en el archivo delogs anterior), se extraen datos relevantes como pueden ser los pasos que se han realizado, en qumomento (con precisin de milisegundos), el nombre de las capturas realizadas y si el test ha -nalizado correctamente o no. Todos estos datos se procesan y se envan donde corresponden. Lascapturas al servidor y FTP y todo lo dems a la Base de Datos.

Adems del ujo que se acaba de comentar, en el diagrama del anexo C tambin se contemplancasos anmalos en los que se producen errores de diferente tipo, ya que de no tenerlos en cuentala aplicacin fallara en tiempo de ejecucin o se perderan resultados, dependiendo del tipo de error.

5.1.1.2. Diagrama de clases

A partir del diagrama de ujo anterior, se realiz el correspondiente diagrama de clases. Enl se pens cmo realizar en cdigo Java todas las funcionalidades y los estados descritos en eldiagrama de ujo. Para ello se estudiaron las posibilidades de simplicacin y reutilizacin delcdigo, siendo el resultado el que se muestra en el anexo D.

La estructura del cdigo se divide en distintas clases Java, cada una de las cuales tiene un sen-tido como tal y una serie de funcionalidades. A continuacin se citan todas las clases que contieneel agente razonando la existencia de cada una de ellas.

Principal.java

Esta clase contiene el mtodo main(), con lo que es la primera que se utiliza al iniciar la apli-cacin. As, se encarga de realizar toda la fase de inicializacin que se detalla en el diagramade ujo del anexo C, de forma que instancia muchas de las otras clases para despus pasarlasy que stas no sean nuevamente instanciadas.

ArchivosProperties.java

Esta clase es la encargada de gestionar los archivos .properties que se utilizan en la aplicacin,que en este caso son dos, uno de conguracin y otro de lenguaje. El primero correspondea un archivo que se encuentra en una ruta local de la mquina, de forma que el usuariopuede modicarlo en un editor de texto. Su sentido reside en proporcionar la posibilidad decongurar elementos externos al cdigo y que el usuario puede querer cambiar, tales como elnombre del robot asignado a la mquina y las IP's tanto del Web Service como del servidorFTP. En el anexo E puede verse un ejemplo del contenido de este archivo.

El otro archivo .properties forma parte del proyecto Java y contiene una serie de literales apartir de los cuales denir las cadenas de caracteres que tiene la aplicacin. La creacin deeste archivo se hizo con la idea de, en caso de querer cambiar el idioma del programa, crearotro con los mismos literales cambiando tan slo el idioma de la denicin. Por ejemplo, unalnea de dicho archivo podra ser la siguiente:

whatToWriteWhenTestsAreStopped = Pulse el botn PLAY para iniciar las ejecuciones

CAPTULO 5. AGENTE 51

En la versin inglesa esa misma lnea sera de la siguiente forma:

whatToWriteWhenTestsAreStopped = Press PLAY button to start executions

Con la utilizacin de este tipo de archivos de lenguaje se evita utilizar cadenas de caracteresconstantes, de forma que para cambiar el idioma de la aplicacin tan slo habra que apuntaral archivo correspondiente, siendo todo el cdigo el mismo.

ParteGracaAgente.java

Esta clase contiene todo el cdigo relacionado con el display del agente, tanto la ventana deinicio en la que se muestra que se est cargando el programa, como la interfaz del agente ytodos los mensajes de informacin o de error que puedan ir apareciendo.

ServidorFTP.java

Esta clase es la encargada de comunicarse con el servidor FTP. La comunicacin puede sertanto de subida como de bajada. Por ejemplo, siguiendo el diagrama de ujo del anexo C,durante la inicializacin del programa es necesario descargar los tests del robot, es decir,archivos .sikuli. Por otro lado, segn ese mismo diagrama, despus de cada ejecucin de untest deben enviarse las capturas, con lo que en ese caso la comunicacin ser de subida.

Robot.java

Esta clase se utiliza para contener las caractersticas del robot que forma la mquina en laque se ejecuta el agente. Cada robot contiene una lista de tests a ejecutar, por ello esta clasetiene una relacin de 1 a 1. . . * con la clase Test.java.

La existencia de la clase Robot.java es un claro ejemplo de programacin orientada a objetos,ya que mediante el objeto Robot el resto de clases acceden a todos los tests y a sus calendarios.

Test.java

Esta clase dene a un test de los que el agente reproduce. Cada test tiene ciertas carac-tersticas tales como el id que tiene en la Base de Datos, su nombre, el terminal mvil enel que se reproduce, el nmero de reintentos, etc. Una caracterstica importante de un testes su calendario, es decir, la ventana de tiempo en la que se ejecuta. Este concepto tienesuciente entidad como para requerir de una clase propia, en este caso, CalendarioTest.java.La relacin con esta clase es de 1 a 1 ya que un test tiene un nico calendario.

CalendarioTest.java

Esta clase contiene toda la informacin relativa al intervalo de tiempo en el que debe repro-ducirse un test. El nivel de personalizacin es muy alto, puede denirse lo siguiente:

Da del ao en el que comenzar las ejecuciones.

Da del ao en el que nalizar las ejecuciones.

Hora del da de inicio.

Hora del da de n.

Das de la semana concretos.

52 CAPTULO 5. AGENTE

Das del mes concretos.

Frecuencia de ejecucin (por ejemplo, cada 5 minutos).

As, con esta clase se controla si a un test le toca ejecutarse en un momento determinado.

WebService.java

Esta clase se utiliza para la comunicacin con el Web Service, necesaria tanto para obtenerinformacin de la Base de Datos como para enviarla.

GestionEjecucionesTests.java

Esta clase ejerce la funcin de scheduler, es decir, controla el orden de ejecucin de los testssiguiendo una lista denida. Si a un test le toca ejecutarse, tambin se encarga de realizar esaejec

diseño e implementación de un sistema para la monitorización de

Documents