Coleta Móvel de Dados em dispositivos Android: um estudo sobre a arquitetura do projeto Maritaca. Leonardo Betto Sueoka

Transcrição

1 Coleta Móvel de Dados em dispositivos Android: um estudo sobre a arquitetura do projeto Maritaca Leonardo Betto Sueoka

2 Coleta Móvel de Dados em dispositivos Android: um estudo sobre a arquitetura do projeto Maritaca Leonardo Betto Sueoka Trabalho de conclusão de curso apresentado ao Instituto de Ciência e Tecnologia UNIFESP, como parte das atividades para obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Dr. Arlindo Flavio da Conceição São José dos Campos SP Março, 2013

3

4 Coleta Móvel de Dados em dispositivos Android: um estudo sobre a arquitetura do projeto Maritaca Leonardo Betto Sueoka Trabalho de conclusão de curso apresentado ao Instituto de Ciência e Tecnologia UNIFESP, como parte das atividades para obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Dr. Arlindo Flavio da Conceição Banca Examinadora: Prof. Dr. Arlindo Flavio da Conceição Prof. Dr. Ezequiel Roberto Zorzal Prof. Dr. Luiz Eduardo Galvão Martins Aprovado em:

5

6 Aos meus pais, pelo amor, dedicação e pelo eterno incentivo.

7 Agradecimentos Agradeço à minha família e meus amigos Mathias, Scott, Vivian, Konishi e Marcio, pois com vocês minha vida universitária foi mais divertida. A minha namorada Cássia Vieira de Oliveira pelas palavras de incentivo e por estar sempre presente. Ao membros da equipe Maritaca, sempre prestativos para ajudar. Agradeço também ao meu orientador Arlindo Flavio da Conceição e a todos meus professores, pois eles ajudaram a formar o que sou hoje.

8 Resumo AColeta de dados é um campo com muito espaço para o uso de dispositivos móveis, como os smartphones Android. O projeto Maritaca tem como objetivo o desenvolvimento de uma infraestrutura para um sistema distribuído de coleta móvel de dados (CMD), com base em formulários digitais, na qual três componentes se destacam: a aplicação do dispositivo Android, os serviços web para gerenciamento dos formulários e os repositórios de dados. Este trabalho está focado no estudo da arquitetura do Maritaca e no desenvolvimento colaborativo da componente Android. Este trabalho gerou como resultados a criação de novas funcionalidades para a componente móvel Android, assim como a avaliação e um caso de uso do sistema. Palavras-chave: TCC, Android, Coleta Móvel de Dados, Sistemas Distribuídos. i

9 Abstract THe data collection is a field with a large space for mobile devices, such as the Android smartphones. The Maritaca project aims the development of an infrastructure for a mobile data collection (MDC) distributed application, based in digital forms, in wich three components are highlighted: Android application, form management web services and the databases. This work is focused on study the Maritaca s architecture and collaborative development of Android component. This work has produced results as the creation of new features for the Android mobile component, as well as evaluation and a case of use of the system. Keywords: TCC, Android, Mobile Data Collection, Distributed Systems. ii

10 Sumário Resumo Abstract Lista de Figuras Lista de Tabelas Lista de Acrônimos i ii vi vii viii 1 Introdução Objetivos Organização do Texto Android e a Máquina Virtual Dalvik Histórico Histórico das Versões Arquitetura Fragmentação A Máquina Virtual Dalvik Arquivos.dex Trabalhos Relacionados à Coleta Móvel de Dados MIT App Inventor Nokia Data Gathering (NDG) Open Data Kit (ODK) doforms Considerações Finais Ferramentas e Ambiente de Desenvolvimento Distribuído Eclipse JUnit iii

11 4.3 Android SDK Plugin ADT Git SourceForge Arquitetura do Maritaca Visão Geral Servidor Repositórios de Dados Sistema Móvel MVC no Sistema Móvel Engine Funcionalidades do Sistema Utilização Recursos do Formulário Digital Compartilhamento de Informações Relatórios Implantação do Maritaca Ambiente de Desenvolvimento Implantação no Servidor Aplicação Android Contribuições no Código Question Slider Passos da Implementação Serviço de Notificações Passos da Implementação Menu Settings Passos da Implementação Problemas Reportados Estudo de Caso Cenário Formulário Resultados Conclusões Considerações Finais Contribuições Trabalhos Futuros Referências Bibliográficas 50 A Especificação de Formulário no Arquivo XML 54 iv

12 B Classe Question 56 v

13 Lista de Figuras 2.1 Arquitetura do Sistema (Google Inc., 2012b) Distribuição Atual de Versões - Março de 2013 (Google Inc., 2012b) Comparativo entre arquivos.dex e.class (Ehringer, 2010) Página inicial do Maritaca no SourceForge Componentes do Maritaca Componentes do Maritaca Relacionamento entre as componentes do MVC na Engine Estrutura de Classes de Question Estrutura de classes do Comparison Tela de login Tela principal Criação de formulários Autenticação e tela principal do aplicativo móvel Exemplos de questões no aplicativo móvel Interface para elaboração de relatórios Menu de acesso aos relatórios Modos de importar projetos no Eclipse Customização da componente Seek Bar Notificação de novos dados coletados Fluxograma do sistema de notificações Tela Settings Questões do formulário Bandejão Relatório gerado a partir dos dados coletados no formulário Bandejão Respostas do formulário Bandejão incluindo arquivos de imagens vi

14 Lista de Tabelas 2.1 Comparação do tamanho em bytes entre aquivos Jar e Dex (Bornstein, 2008) Políticas de compartilhamento de dados no Maritaca Arquivo de configuração configuration.properties vii

15 Lista de Acrônimos AAC ANR API BCC BCT BMC CDMA CMD CRUD CVS DVCS DVM GFS HDP HTML HTTP IDE JavaME JavaSE JDK JPEG JSF JSR JVM Maritaca MIT MPEG MVC NDG NFC ODK OHA Advanced Audio Coding Application Not Responding Application Programming Interface Bacharelado em Ciência da Computação Bacharelado em Ciência e Tecnologia Bacharelado em Matemática Computacional Code Division Multiple Access Coleta Móvel de Dados Create, Read, Update, Delete Concurrent Version System Distributed Version Control System Dalvik Virtual Machine Google File System Health Device Profile Hypertext Markup Language Hypertext Transfer Protocol Integrated Development Environment Java Mobile Edition Java Standart Edition Java Development Kit Joint Photographic Experts Group Java Server Faces Java Specification Request Java Virtual Machine MARitaca Is a Tool to create Cellular phone Applications Massachusetts Institute of Technology Moving Picture Experts Group Model, View, Controller Nokia Data Gathering Near Field Communication Open Data Kit Open Handset Alliance viii

16 PNG REST SaaS SDK SMS SQL VCS XML WAR Portable Network Graphics Representional State Transfer Software as a Service Software Development Kit Short Message Service Structured Query Language Version Control System extensible Markup Language Web application ARchive ix

17 CAPÍTULO 1 Introdução Obter informações de diferentes localidades, armazená-las e analisá-las, na maioria das vezes ainda são processos manuais. As informações coletadas são muitas vezes transcritas para formulários impressos e depois arquivadas, consumindo espaço e recursos. A coleta de dados praticada com formulários impressos é suscetível a erros humanos, assim como qualquer procedimento manual, dessa forma, é natural que a coleta de dados a partir de dispositivos móveis se sobressaia como uma solução viável para automatizar esse processo. Dispositivos móveis como celulares, tablets e smartphones são aparelhos cada vez mais presentes na vida das pessoas. De acordo com a Anatel, no ano de 2010 o Brasil havia ultrapassado a marca de um celular por habitante, o que significa mais de 190 milhões de dispositivos móveis em território nacional (Anatel, 2010). Com um aumento expressivo, o Brasil fechou o ano de 2012 com 261 milhões de linhas móveis (Anatel, 2013). Desse montante aproximadamente 27 milhões são os chamados smartphones (Google e MediaCT, 2012). Um smartphone, ou celular inteligente, é um pequeno computador com diversos instrumentos como sensores, câmeras, conectividade sem fio, GPS (Global Positioning System) e uma tela sensível ao toque. Apesar de muitos recursos, os smartphones possuem limitações como alimentação por bateria, memória principal e armazenamento em disco reduzidos. O Android é uma plataforma baseada no Linux desenvolvida especificamente para smartphones. O Android é um projeto open source, ou seja, possui o código aberto, mantido pela Open Handset Alliance (OHA) que é formada por um grupo de grandes empresas, lideradas pela Google, interessadas 1

18 Capítulo 1. Introdução 2 na evolução dessa plataforma. De acordo com dados do final de 2012, 69,7% da parcela do mercado pertence ao Android (Gartner Inc., 2013). A adoção de dispositivos móveis inteligentes e o abandono do uso de formulários impressos na Coleta Móvel de Dados (CMD) pode gerar uma grande economia de material (pranchetas, folhas de papéis e tintas para impressão etc.), além de importantes benefícios ambientais. Por exemplo, o custo ambiental de uma folha de escritório, considerando todo o processo desde cultivo e retirada da árvore, produção de papel e eliminação de resíduos, é de 20,9 gramas de emissão de dióxido de carbono na atmosfera. E a cada 80 mil e 500 folhas de papéis não fabricadas uma árvore é salva (Jadkowski, 2012). Apenas a praticidade de utilizar smartphones para CMD aliada as suas vantagens econômicas e ambientais já justificariam sua implementação. Mas além desses benefícios, eles possibilitam o uso de recursos multimídia como fotos, áudio e vídeo. Tais recursos tornam muito mais ricas tanto a interação dos usuários quanto a qualidade das informações presentes nos formulários digitais, pois a apresentação da informação ocorre de maneira multissensorial, estimulando mais os sentidos humanos do que um texto comum. O projeto Maritaca (MARitaca Is a Tool to create Cellular phone Applications) busca suprir as necessidades de automatizar o processo de CMD provendo uma infraestrutura baseada na nuvem para criação de aplicativos móveis para smartphones Android. Esses aplicativos representam os formulários digitais. O Maritaca proporciona uma interface web interativa para a concepção do formulário e o gerenciamento das informações coletadas. O projeto possui três vertentes principais: a aplicação móvel Android, os serviços web e os repositórios de dados. O foco deste trabalho é estudar a arquitetura do Maritaca com ênfase na componente móvel Android e colaborar com seu desenvolvimento. 1.1 Objetivos O objetivo deste trabalho é estudar a arquitetura da componente móvel Android do projeto Maritaca, como ela interage com as outras componentes e colaborar com seu desenvolvimento em um ambiente distribuído e open source. Também faz parte do escopo integrar a equipe de desenvolvedores do projeto, assim como explorar as funcionalidades do sistema em uma situação real. Pode-se listar os seguintes objetivos específicos: Estudar, avaliar e testar, por meio de um estudo de caso, a arquitetura do projeto Maritaca; Implementar os seguintes itens na componente Android: Um tipo de questão do formulário digital: o slider;

19 Capítulo 1. Introdução 3 Um sistema de notificações que informa ao usuário a quantidade de novas coletas realizadas por outros usuários que compartilham o mesmo formulário; Uma interface na qual o usuário pode definir configurações sobre o intervalo de sincronização com o servidor. br. Para mais informações sobre o projeto Maritaca acesse Organização do Texto Este trabalho está organizado em nove capítulos. O Capítulo 2 disserta sobre o histórico do Android e esclarece os principais conceitos e características dessa plataforma e de sua máquina virtual chamada Dalvik. O Capítulo 3 compara o Maritaca com outros trabalhos com objetivos e funcionalidades similares. As ferramentas colaborativas utilizadas no desenvolvimento do Maritaca são listadas e descritas no Capítulo 4. O Capítulo 5 apresenta a arquitetura aplicada no desenvolvimento do sistema com foco no sistema móvel. O Capítulo 6 expõe as características funcionais do sistema e pode ser usado como tutorial para sua utilização. A implantação do módulo servidor e móvel é descrita no Capítulo 7. O Capítulo 8 apresenta as principais contribuições para a componente móvel. O Capítulo 9 apresenta um caso de uso do sistema e comenta sobre o potencial da ferramenta e, por fim, o Capítulo 10 discorre sobre as lições aprendidas, considerações finais e trabalhos futuros.

20 CAPÍTULO 2 Android e a Máquina Virtual Dalvik A plataforma Android (Google Inc., 2013) é um sistema operacional para dispositivos celulares com alto poder computacional, conhecidos como smartphones. A capacidade de processamento é melhorada a medida que a demanda por tal capacidade aumenta e esse crescimento tende a aumentar ao longo dos anos. Usuários cada vez mais exigentes e aplicações cada vez mais complexas e sofisticadas surgirão. O objetivo dessa plataforma é prover um sistema aberto, no qual os desenvolvedores de aplicações possam usar quaisquer recursos disponíveis para cada aparelho, inclusive os utilizados pelas aplicações internas, aproveitando ao máximo o que eles têm a oferecer. Este capítulo discorre sobre o histórico, arquitetura, desafios e a máquina virtual da plataforma Android. 2.1 Histórico A Google adquiriu uma startup chamada Android Inc., em 2005, com o objetivo de entrar no mercado de dispositivos móveis. Os principais nomes da Android Inc. eram Andy Rubin (considerado o criador do Android), Rich Miner, Nick Sears, e Chris White (Hashimi et al., 2009). Andy Rubin é hoje é vice-presidente de plataformas móveis da Google. Em 2007, um grupo de empresas, liderado pela Google, chamado de Open Handset Alliance foi criado para gerenciar e criar novas diretrizes para a plataforma Android. A OHA é uma 4

21 Capítulo 2. Android e a Máquina Virtual Dalvik 5 aliança comercial composta por muitas das maiores e bem sucedidas empresas do mundo. Seus membros representam toda a cadeia comercial de dispositivos móveis, incluindo fabricantes de chips, fabricantes de celulares, desenvolvedores de software e provedores de serviço (Conder e Darcey, 2012). Além disso, é objetivo da OHA garantir que o projeto tenha código aberto e assim reagir mais rapidamente e de forma inovadora as exigências do mercado (Open Handset Alliance, 2012). Em novembro de 2007, foi divulgada uma versão pré-lançamento do Android SDK (Software Development Kit) e já em 2008 foi lançado o primeiro aparelho baseado na plataforma Android, o T-Mobile G1. Poucos dias depois a versão 1.0 do Android SDK foi lançada e em outubro de 2008 a Google tornou o código fonte da plataforma Android aberto sob a licença Apache (Hashimi et al., 2009). A partir desse momento, muitas fabricantes começaram a produzir dispositivos Android em 2009 e início de A plataforma ganhou mercado rapidamente e no final de 2010 o Android tornou-se líder de mercado, ganhando espaço de plataformas competitivas como o BlackBerry da RIM, o ios da Apple e o Windows Mobile (Conder e Darcey, 2012) Histórico das Versões Várias versões do Android foram lançadas desde seu início, agregando novos recursos e funcionalidades. Atualmente o Android encontra-se na versão 4.2 Jelly Bean. O histórico da evolução das versões, assim como as principais mudanças e suas datas de lançamento são listadas abaixo (Google Inc., 2012b): Fevereiro de 2009: Versão inicial; 1.5 (Cupcake) - Abril de 2009 Nova API, refinamentos da interface de usuário, melhorias de desempenho, atualização do Kernel do Linux para a versão (Donut) - Setembro de 2009 Nova API, aperfeiçoamento da interface de usuário, atualização do Kernel do Linux para a versão , suporte para resoluções e densidades de telas, suporte para CDMA, API para reconhecimento de gestos e uma engine de texto-para-fala. 2.0, 2.1 (Éclair) - Outubro de 2009 Nova API, aperfeiçoamento da interface de usuário, melhoria na renderização de gráficos, bluetooth 2.1,

22 Capítulo 2. Android e a Máquina Virtual Dalvik (Froyo) - Maio de 2010 Nova API, aperfeiçoamento da interface de usuário, novo framework de mídia, novas funcionalidades para o bluetooth, atualização do Kernel do Linux para a versão (Gingerbread) - Dezembro de 2010 Nova API, aperfeiçoamento da interface de usuário, suporte para NFC (Near Field Communications), mudanças na Dalvik e atualização do Kernel do Linux para a versão , 3.1, 3.2 (Honeycomb) - Fevereiro de 2011 As melhorias das versões do Android Honeycomb são focadas em adaptações para os tablets. Nova API, aperfeiçoamento da interface de usuário. 4.0, 4.0.1, 4.0.3, (Ice Cream Sandwich) - Outubro de 2011 Nova API, aperfeiçoamento da interface de usuário, novos recursos multimídia, novos tipos de conectividade como o Wi-Fi Direct e Bluetooth Health Device Profile (HDP). 4.1, 4.2 (Jelly Bean) - Julho de 2012 Melhorias de segurança, otimizações na Dalvik, evolução do software da câmera e bluetooth, melhora no suporte ao NFC (Android Beam) e reprodução de áudio com baixa latência. 2.2 Arquitetura O Android é composto por uma pilha de software que inclui um Sistema Operacional, Middleware e aplicações chave (Google Inc., 2012b). A arquitetura do Android é composta pelas componentes mostradas na Figura 2.1. Essa pilha é composta por cinco camadas: Aplicações, Framework para Aplicações, Bibliotecas juntamente com a Android Runtime e Kernel do Linux. A camada de Aplicações é o conjunto de todos os aplicativos instalados no dispositivo e que são escritos com uma sintaxe similar ao do Java. Estes são todos os aplicativos nativos indispensáveis (tais como navegador de internet, cliente de correio eletrônico, aplicativo para gerenciar SMS, calendário, contatos etc.) e os aplicativos que o usuário pode instalar pela Google Play (Google Inc., 2012b). Na camada Application Framework, estão todas as API s disponibilizadas no SDK do Android para desenvolver aplicações ricas utilizando os diversos recursos presentes nesse sistema operacional, como: Views: são usadas para construir a interface com o usuário (telas da aplicação);

23 Capítulo 2. Android e a Máquina Virtual Dalvik 7 Figura 2.1: Arquitetura do Sistema (Google Inc., 2012b). Content Providers: possibilitam que aplicações troquem informações entre si; Resource Manager: permite acesso a arquivos externos como gráficos, arquivos de layout e de internacionalização; Notification Manager: provê a capacidade de gerar notificações personalizadas na barra de status; Activity Manager: gerencia o ciclo de vida das aplicações e o fluxo de navegação. A camada de bibliotecas representa um conjunto de bibliotecas escritas em C e C++ que possuem funcionalidades específicas e muito usadas pela camada acima. Nessa camada encontram-se bibliotecas para execução de mídia altamente otimizadas para dispositivos com recursos limitados (Brahler, 2010), como codificadores e decodificadores para execução e gravação de vídeo (H264, MPEG4), áudio (MP3, AAC, AMR) e imagens (JPEG, PNG). Inclui-se nessas bibliotecas o SQLite (SQLite Community, 2013), pacotes para renderização 2D e 3D, entre outros (Google Inc., 2012b). Já a Runtime Android possui bibliotecas chaves do Java, além da DVM (Dalvik Virtual Machine) que será mais detalhada na Seção 2.4 (Google Inc., 2012b). Na camada de mais baixo nível, há o Kernel Linux na versão 2.6 modificado para atuar em aspectos fundamentais do sistema como gerenciamento do consumo de energia, memória,

24 Capítulo 2. Android e a Máquina Virtual Dalvik 8 processos, rede e segurança. Além de operar também como intermediária entre o hardware e as outras camadas da pilha (Google Inc., 2012b). 2.3 Fragmentação Um tema que gera muita discussão entre usuários e fabricantes do Android é o problema de fragmentação. O Android continua evoluindo rapidamente desde seu início e, com isso, muitas versões foram lançadas. Existem diversas versões deste sistema operacional instalados em diversos modelos de smartphones de diversas marcas, desde a antiga versão 1.5 lançada em abril de 2009, também chamada de Cupcake, até recém-lançada versão 4.2, chamada de Jelly Bean. A discussão se dá pela incompatibilidade das versões que estão sendo efetivamente utilizadas pelos usuários, ou seja, existem dispositivos Android ativos em todas as suas versões. De acordo com a Figura 2.2, aproximadamente 44% dos dispositivos ativos possuem as versões do Android Gingerbread, 28,6% possuem as versões do Ice Cream Sanduich, 15,5% possuem as versões mais recente do Jelly Bean e também 7,5% possuem versão 2.2 Froyo. De fato, há uma fragmentação de versões no Android. O grande problema da fragmentação é que as versões antigas não desfrutam de todas as novas funcionalidades das versões mais atuais, além disso, os desenvolvedores de aplicativos priorizam o suporte de seus produtos para as versões mais recentes. Ou seja, os usuários que possuem smartphones com Android desatualizado não possuem acesso aos aplicativos que exigem as versões mais recentes instaladas. Por um lado existe o aspecto negativo, que é a fragmentação, mas pelo outro há o aspecto positivo que é a evolução rápida e constante do sistema. Figura 2.2: Distribuição Atual de Versões - Março de 2013 (Google Inc., 2012b).

25 Capítulo 2. Android e a Máquina Virtual Dalvik 9 Fabricantes vendem seus smartphones e tablets com determinadas versões do Android e fica sob seu juízo a atualização desses aparelhos quando são lançadas novas versões. Porém, desenvolver pacotes de atualização gera despesas e geralmente apenas os aparelhos mais populares os recebem. Note que o aparelho precisa ter poder de processamento suficiente para executar as versões mais novas, ou seja, os aparelhos mais antigos dificilmente receberão atualizações do Android. 2.4 A Máquina Virtual Dalvik Grande parte do sucesso de uma plataforma para smartphones se dá pela sua capacidade de cativar desenvolvedores de aplicativos dessa plataforma. A Google escolheu o Java para ser a linguagem primária do Android pela grande comunidade de desenvolvedores e pela relativa facilidade de utilização. Apesar disso, a Dalvik não é uma verdadeira plataforma Java. O Android usa uma implementação alternativa e mais limitada da biblioteca padrão do Java, na qual grande parte das bibliotecas principais do JavaSE estão presentes. Alguns dos motivos da Google decidir criar sua própria máquina virtual não padronizada foram os problemas apresentados pelo JavaMe, problemas burocráticos no licenciamento de novas funcionalidades do Java pelo JSR (Java Specification Request), desempenho, segurança, entre outros (Maker, 2011). O objetivo da plataforma Android é abranger a maior quantidade possível de dispositivos, desde os mais antigos de baixa capacidade até os mais atuais de alta capacidade. Essa intenção faz com que os dispositivos obsoletos imponham que a plataforma seja eficiente o suficiente para que tais dispositivos sejam capazes de executá-la. A execução do Android precisa suportar condições como baixa capacidade de processamento, baixa capacidade da memória RAM, nenhum espaço para swap, funcionamento à bateria, diversos modelos de dispositivos e execução segura de aplicativos (Ehringer, 2010). Dados todos esses requisitos a DVM foi projetada para usar o mínimo dos recursos do sistema. Múltiplas instâncias da Dalvik são executadas simultaneamente. Este fato ocorre porque cada aplicação Android representa um processo sendo executado, o qual possui uma instância da DVM. Dessa maneira, os processos ficam bem isolados, criando uma forte barreira entre as aplicações (Maker, 2011) Arquivos.dex Na plataforma Java padrão, um arquivo.java é compilado pela JVM (Java Virtual Machine) e o resultado disso é o bytecode Java no arquivo.class correspondente. Por exemplo, um arquivo

26 Capítulo 2. Android e a Máquina Virtual Dalvik 10.java possui uma classe pública, uma classe estática interna e três classes anônimas o resultado da compilação serão 5 arquivos.class que serão lidos em tempo de execução pela JVM (Ehringer, 2010). Apesar da linguagem de desenvolvimento do Android ser o Java, isso não acontece da mesma forma nos dispositivos móveis. Na plataforma Android os arquivos.class continuam sendo gerados, porém a ferramenta chamada dx os converte para a extensão.dex (Dalvik Executable) e são esses arquivos que são executados pela DVM. A função da dx além de converter é otimizar o uso de memória e o espaço em disco, alocando vários.class em apenas um.dx (Ehringer, 2010). Os arquivos.dex otimizam espaço de armazenamento contendo dados únicos, ou seja, não há repetição de informações. Por exemplo, se várias classes fazem referência a uma string constante de caracteres, esse objeto existe apenas uma vez nos arquivos.dex e suas múltiplas ocorrências são apenas ponteiros para esse objeto (Brahler, 2010). As constantes como strings, campos, variáveis, classes, interfaces, e nomes de métodos são armazenadas em pools de constantes. Um pool é um conjunto de recursos inicializados e prontos para serem usados. Na Figura 2.3 são exibidos os pools de constantes em azul. Temos que cada arquivo.class possui seu próprio pool heterogêneo de constantes que agrupa todas as constantes em um só lugar. Em contrapartida, o arquivo.dex, que contém várias classes, possui vários pools de constantes organizados e compartilhados (Ehringer, 2010). Na Tabela 2.1 os arquivos.dex apenas com as otimizações citadas no parágrafo anterior possuem menor tamanho em bytes que os arquivos.jar comprimidos. Tabela 2.1: Comparação do tamanho em bytes entre aquivos Jar e Dex (Bornstein, 2008). Bibliotecas do Sistema App Navegador App Alarme Sem compressão (100%) (100%) (100%) Compressão Jar (50%) (49%) (52%) Arquivo Dex sem compressão (48%) (44%) (44%)

27 Capítulo 2. Android e a Máquina Virtual Dalvik 11 Figura 2.3: Comparativo entre arquivos.dex e.class (Ehringer, 2010).

28 CAPÍTULO 3 Trabalhos Relacionados à Coleta Móvel de Dados Existem projetos com objetivos e funcionalidades semelhantes ao do Maritaca e que tiverem seu desenvolvimento iniciado em paralelo. Este capítulo analisa esses projetos e os compara ao Maritaca. 3.1 MIT App Inventor O MIT App Inventor (MIT, 2013) era um projeto da Google que foi descontinuado em agosto de 2011 e teve seu código disponibilizado. O MIT (Massachusetts Institute of Technology) com o apoio da Google criou um centro para estudo sobre tecnologias móveis, cujo objetivo principal é dar continuidade ao desenvolvimento do App Inventor para Android. O App Inventor constrói uma aplicação sem a necessidade do usuário ter conhecimento de programação. O projeto consiste principalmente de duas aplicações: o App Inventor Design e o App Inventor Blocks Editor. Semelhante a tela de criação de formulários do Maritaca, o App Inventor Design possui uma interface intuitiva na qual os componentes são arrastáveis e o usuário os posiciona na tela da sua aplicação facilmente. O App Inventor Blocks Editor tem a função de associar eventos para cada componente adicionado. O App Inventor possui uma 12

29 Capítulo 3. Trabalhos Relacionados à Coleta Móvel de Dados 13 interessante funcionalidade que permite ao usuário ver em seu dispositivo móvel a sua aplicação sendo montada em tempo real, desde que o dispositivo esteja conectado em seu computador. O AppInventor é uma aplicação com um escopo generalista, voltado para usuários interessados em criar suas próprias aplicações. Já o Maritaca tem um escopo específico: a Coleta Móvel de Dados. 3.2 Nokia Data Gathering (NDG) O Nokia Data Gathering (Nokia Corp., 2013b) é um projeto de código aberto desde 2010 e tem como objetivo a automatização da coleta móvel de dados. Funciona com a criação de questionários e o envio dos mesmos para os agentes de campo que acessam os formulários através de seus celulares por uma conexão sem fio. As respostas são enviadas à central, que as armazena. É possível exportar as informações coletadas para formatos mais manejáveis, tais como planilhas. O NDG é utilizado na prática em alguns projetos sociais. Em Manaus, no estado do Amazonas, juntamente com a Secretaria de Estado de Saúde (SUSAM), o NDG foi usado para a coleta de informações pertinentes as famílias atingidas pela dengue, ajudando no combate à doença. Tanto o NDG quanto o Maritaca possuem escopos semelhantes. Uma diferença importante é que o NDG está disponível apenas para a plataforma Java ME e Windows Phone, que possuem parcelas reduzidas de mercado. 3.3 Open Data Kit (ODK) O projeto ODK (ODK Community, 2013) possui código aberto e é composto por um conjunto de ferramentas que auxiliam na criação e gerenciamento da coleta móvel de dados. Entre eles estão: Build, Collect e Aggregate. A Build consiste de uma interface web que possibilita a criação de formulários interativamente, inclusive com perguntas multimídia, como áudio, vídeo e imagens. A Collect é uma aplicação para Android que realiza a coleta de dados nos dispositivos móveis Android. A Aggregate gerencia as informações coletadas através dos formulários que podem ser exportadas para formatos mais usuais, como planilhas. Outras ferramentas que são desenvolvidas pelo ODK são o Form Uploader, Briefcase, Validate e o XLS2XFORM. O Maritaca e o ODK possuem objetivos diferentes apesar de terem a CMD como escopo. Enquanto o Maritaca oferece uma infraestrutura para a criação de formulários e gereciamento das informações coletadas, o ODK é basicamente um conjunto de API s e padrões que podem

30 Capítulo 3. Trabalhos Relacionados à Coleta Móvel de Dados 14 ser usados por outros projetos. Alguns dos projetos que usam o ODK são: FormHub, Epi- Surveyor, Group Complete, KoBo Toolbox, ViewWorld, PhiCollectUm e o doforms, que será apresentado na próxima seção. 3.4 doforms O doforms (doforms Inc., 2013) é um projeto cuja proposta é similar ao Maritaca, porém possui código proprietário. O doforms é baseado no projeto ODK, portanto ambos possuem grandes semelhanças. A aplicação para dispositivos móveis é multiplataforma permitindo dispositivos ios, Android e BlackBerry. É possível usar o sistema gratuitamente com algumas restrições, como cota máxima de dados de 200 MB e somente usar a aplicação móvel para um único dispositivo. Outra restrição é que somente alguns tipos de questões podem ser usadas para montar formulários para usuários com contas gratuitas. Da mesma forma que o NDG e o Maritaca, as respostas coletadas dos questionários no doforms são enviadas para um servidor. A partir disso, o usuário é capaz de gerenciar esses dados e enviar novos formulários para os dispositivos dos agentes coletores. As principais diferenças entre o doforms e o Maritaca é que o primeiro se trata de uma solução paga e multiplataforma enquanto que o objeto de estudo deste trabalho apresenta uma solução aberta e exclusiva para a plataforma Android. 3.5 Considerações Finais Os trabalhos que mais se assemelham tanto no objetivo quanto nos serviços disponibilizados é o doforms e o NDG. O doforms e o Maritaca apresentam contextos diferentes visto que o Maritaca apresenta uma solução aberta, enquanto que para usar o doforms com todas suas funcionalidades é necessário custear uma taxa mensal. Apesar disso, o doforms apresenta uma solução multiplataforma para sua aplicação móvel, que é um benefício considerável. O NDG aparenta ser a solução mais madura dentre as citadas, pois possui registros de sua utilização em situações significativas. Além do caso citado na Seção 3.2, ele foi posto em prática no Kenya e na África Oriental (Nokia Corp., 2013a). Como já explanado anteriormente uma desvantagem notável é a aplicação móvel do NDG estar disponível para plataformas pouco utilizadas.

31 CAPÍTULO 4 Ferramentas e Ambiente de Desenvolvimento Distribuído Uma das grandes vantagens de se trabalhar em grupo é a paralelização das tarefas de um determinado projeto, pois teoricamente quanto mais mão de obra mais rápido o projeto é concluído. No entanto, no âmbito de desenvolvimento de software existem algumas variáveis que não tornam essa afirmação tão simples. São necessárias ferramentas para alinhar conhecimento, documentar os códigos fontes gerados, um repositório online que todos tenham acesso, IDE de desenvolvimento, controle de versão, entre outras ferramentas. As seções a seguir descrevem as ferramentas utilizadas neste trabalho. 4.1 Eclipse Eclipse é uma IDE (Integrated Development Environment) de código aberto e robusta para a plataforma Java, porém possui diversos plugins que adicionam funcionalidades para a codificação em outras linguagens. No caso de desenvolvimento para Android, a linguagem de programação padrão possui sintaxe similar a da linguagem Java, mas são necessárias outras ferramentas e bibliotecas da API para que seja possível utilizar toda a capacidade do aparelho celular (Eclipse Foundation, 2012). 15

32 Capítulo 4. Ferramentas e Ambiente de Desenvolvimento Distribuído JUnit JUnit é uma biblioteca de código aberto criada por Kent Beck e Erich Gamma que visa facilitar o processo de teste de código. O processo de teste de software é parte indispensável no desenvolvimento de qualquer aplicação porque é ele que indica possíveis falhas ou erros presentes no código fonte. Ou seja, a qualidade do software a ser produzido está fortemente ligada a cobertura dos testes (Neto, Aristides V. P., 2009). O JUnit automatiza esse processo executando todos os testes escritos pelo desenvolvedor e gerando, ao final, um relatório intuitivo indicando quais testes passaram e quais não passaram. 4.3 Android SDK O Android SDK (Software Development Kit) provê as ferramentas e bibliotecas necessárias para desenvolver, testar e depurar novas aplicações (Google Inc., 2012b) Plugin ADT O plugin ADT (Android Development Tools) disponível para o Eclipse, juntamente com o Android SDK dá acesso ao usuário as bibliotecas de qualquer versão do Android liberada, facilitando o desenvolvimento de uma aplicação para uma versão específica. Inclui também um emulador do próprio sistema, assim é possível o desenvolvedor depurar suas aplicações que estão em fase de desenvolvimento, outra opção é exportá-las para um arquivo.apk e instalá-las em um smartphone Android (Google Inc., 2012a). 4.4 Git O Git é sistema de controle de versão, ou VCS (Version Control System), utilizado neste trabalho e também amplamente utilizado pelo mercado. Os VCS s funcionam armazenando um histórico das modificações que foram feitas em um conjunto de arquivos sendo possível voltar da sua versão atual para qualquer outra versão específica nesse histórico. Além do Git, existem outros VCS s ainda muito utilizados atualmente como o CVS (Concurrent Version System) e o SVN (Subversion). Entre as principais funcionalidades do Git estão retomar arquivos para um estado específico, recuperar projetos inteiros para um estado específico, comparar mudanças ao longo do tempo,

33 Capítulo 4. Ferramentas e Ambiente de Desenvolvimento Distribuído 17 verificar e registrar as alterações e quem foi o autor dessas mudanças, entre outras funcionalidades. Por ter toda essa flexibilidade, o Git é muito popular desde os desenvolvedores de softwares que trabalham sozinhos até as grandes corporações (Chacon e Aljord, 2009). O Git se enquadra no conceito de DVCS (Distributed Version Control System), que é um sistema de controle de versões distribuído. Cada desenvolvedor é potencialmente tanto um hub como um node, ou seja, todo desenvolvedor pode contribuir com seu código para outros repositórios e manter um repositório público no qual outros desenvolvedores podem basear seu trabalho e começar a contribuir também. Essa flexibilidade do Git permite que várias configurações de fluxo de trabalho sejam usadas de acordo com a necessidade do projeto (Chacon e Aljord, 2009). 4.5 SourceForge O SourceForge é uma entidade que tem como seu principal objetivo o sucesso dos projetos de código aberto. Provê ferramentas para a gerência do código fonte, documentação, fórum de discussão e status do projeto. A página inicial do Maritaca no SourceForge é mostrada na Figura 4.1. Atualmente, o projeto Maritaca está hospedado no SourceForge através do endereço https: //sourceforge.net/projects/maritaca/ e seu código fonte está disponível para download por meio de um repositório Git. Ferramentas como o fórum de discussão entre os desenvolvedores é muito utilizado e facilita a comunicação quando os envolvidos no projeto não estão fisicamente no mesmo lugar. Assim como o wiki que é a documentação de conceitos já definidos, tutoriais, ambiente de desenvolvimento, entre outros.

34 Capítulo 4. Ferramentas e Ambiente de Desenvolvimento Distribuído 18 Figura 4.1: Página inicial do Maritaca no SourceForge.

35 CAPÍTULO 5 Arquitetura do Maritaca O projeto Maritaca é hospedado utilizando uma arquitetura de computação em nuvem, ou seja, todo seu código é executado e os dados são armazenados remotamente em servidores disponíveis para acesso pela Internet. Dessa maneira, as informações geradas pelos usuários nos dispositivos móveis estão disponíveis em quaisquer computador com acesso a grande rede, através de um navegador (Armbrust et al., 2010). Esse tipo de solução é escalável, ou seja, é possível contratar ou liberar rapidamente mais servidores equilibrando a demanda de requisições e os recursos disponíveis do sistema, caso a quantidade de usuários do sistema aumente ou diminua consideravelmente. O Maritaca implementa um modelo de serviço chamado de SaaS (Software as a Service), que é um modelo associado a aplicações baseadas na computação em nuvem que disponibilizam seus serviços ao usuário via um navegador web. O conceito deste modelo se traduz na mudança de paradigma no âmbito de comércio e distribuição de software. No olhar de um cliente, ao invés de comprar a licença de um software e instalá-lo em seus computadores, ele concorda em usar a aplicação que será hospedada pela empresa que desenvolve e comercializa o software, dando ao comprador flexibilidade para alternar fornecedores e evitar problemas com manutenção (Dubey e Wagle, 2007). A arquitetura do Maritaca é composta por várias componentes que possuem funções específicas e que interagem entre si. A Figura 5.1 mostra os principais elementos e suas interações com os usuários do sistema no ciclo de coleta e persistência de informações. Basicamente o 19

36 Capítulo 5. Arquitetura do Maritaca 20 usuário cria o aplicativo que corresponde a um formulário digital no sistema web do Maritaca e o instala em um dispositivo móvel Android. O coletor usa a aplicação no seu dispositivo para adquirir e enviar às informações coletadas ao servidor do Maritaca. Os dados são salvos nos repositórios de dados e estão disponíveis para consulta ou download. No decorrer deste capítulo, serão vistas informações sobre a arquitetura, tecnologias e metodologias usadas em todos os componentes da solução. Figura 5.1: Componentes do Maritaca. 5.1 Visão Geral A arquitetura do projeto possui três grandes pilares: sistema móvel, servidor web e as bases de dados. A Figura 5.2 mostra de modo geral como essas componentes interagem. A componente mobile devices representa os dispositivos móveis Android e é onde este trabalho está concentrado. Trata-se de uma aplicação Android que tem como principal funcionalidade a execução dos formulários, que são especificados através de arquivos XML, gerados no portal Maritaca. As requisições feitas da aplicação móvel para o servidor são encapsuladas pelo framework OAuth (OAuth Community, 2013), usado para aumentar a segurança do sistema no que diz respeito a autenticação dos usuários. A componente móvel e suas interações serão descritas na Seção 5.2. O desenho modular do maritaca define que as camadas de apresentação (Presentation Layer), a camada de negócios (Business Layer), a camada de Web Services e a camada de acesso as bases de dados (Data Acess) sejam independentes e separadas. A modularidade reduz a complexidade de sistemas, facilita futuras manutenções, mudanças no código e agiliza a implementação

37 Capítulo 5. Arquitetura do Maritaca 21 Figura 5.2: Componentes do Maritaca. do software pormitindo o desenvolvimento paralelo em diferentes partes do sistema (Pressman, 2006). Tanto o código escrito para o servidor quanto o código escrito para o dispositivo móvel são códigos Java. Mas em uma situação hipotética, o código usado no servidor poderia ser escrito em outra linguagem visto que a comunicação entre o dispositivo móvel e o servidor ocorre via web services, o que dispensa o uso da mesma linguagem de programação. Note que se outra linguagem de programação fosse usada, provavelmente algumas tecnologias empregadas no sistema atual teriam de ser trocadas por outras compatíveis com a linguagem escolhida.

38 Capítulo 5. Arquitetura do Maritaca Servidor Os serviços e funcionalidades web do sistema estão incorporados no servidor de aplicações web open source JBossAS ( Logo, o servidor agrupa as camadas de apresentação, negócio, acesso ao banco de dados e web services. Quando um usuário cria seu formulário o sistema constrói uma aplicação Android correspondente ao formulário criado. O arquivo XML contendo as especificações do formulário é embutido dentro da aplicação. Dessa forma, cada aplicação criada corresponde a apenas um formulário. O usuário pode criar diversos formulários e cada um será uma aplicação diferente. Os web services foram implementados usando o modelo REST (Representional State Transfer) através do framework RESTEasy (JBoss Community, 2013). O REST é um modelo idealizado de como a internet deveria funcionar. Este modelo de interações de aplicações web se tornou a base da arquitetura moderna da internet (Fielding e Taylor, 2002). Este estilo arquitetural é uma abstração do básico do protocolo HTTP (Hypertext Transfer Protocol) e consiste em conceitos ao invés de sintaxes e detalhes técnicos (Schreier, 2011). Todas as funcionalidades do sistema que envolvem envio e recebimento de mensagens de correio eletrônico são implementadas pelo no sistema com o framework de código aberto RabbitMQ (VMware Inc., 2013). A camada de apresentação representa as telas que são apresentadas ao usuário. As páginas de gerenciamento de formulários foram desenvolvidas com tecnologias altamente utilizadas e reconhecidas pelo mercado e pela comunidade de desenvolvedores como JSF (Java Server Faces) (Oracle Corp., 2013b), Jquery (The jquery Foundation, 2013) e HTML 5 (W3C, 2010) Repositórios de Dados São usados duas bases de dados com propósitos diferentes: o Cassandra (The Apache Software Foundation, 2013a) e o Hadoop (The Apache Software Foundation, 2013b). O Cassandra é um sistema de banco de dados distribuído open source criado pela Apache Software Foundation. Ele é dito No-SQL, ou seja, não utiliza a predominante arquitetura relacional para banco de dados (Strauch et al., 2011). O Cassandra foi desenvolvido para gerenciar grandes quantidades de dados, provendo um serviço com alta disponibilidade e sem pontos de falha (Lakshman e Malik, 2010). É utilizado por grandes empresas como Google, Facebook e Amazon. O Cassandra é usado no Maritaca para armazenar os dados estruturados em XML das respostas dos formulários. O acesso ao banco de dados Cassandra se dá pela API Hector (Hector Community, 2013). Ela fornece bibliotecas de alto nível para realizar diversos tipos de procedimentos na base de

39 Capítulo 5. Arquitetura do Maritaca 23 dados que vão desde operações básicas de CRUD (Create, Read, Update, Delete) até controle do pool de conexões. O Hadoop é também um projeto open source da Apache Software Foundation que inclui implementações de um sistema de arquivos distribuído, MapReduce baseado no GFS (Google File System) e outros projetos de MapReduce (Borthakur et al., 2011). Neste projeto ele é usado para armazenar modelos de dados não estruturados, principalmente arquivos, como áudio, vídeo, imagens e executáveis Android (arquivos com extensão apk). 5.2 Sistema Móvel Depois de criar ou editar um formulário a partir de um navegador web, o formulário pode ser preenchido no dispositivo móvel no qual os dados coletados serão armazenados temporariamente no banco de dados local. O módulo móvel no Maritaca corresponde ao aplicativo para Android e é responsável por gerenciar e coletar as respostas dos questionários MVC no Sistema Móvel O Sistema Móvel do Maritaca segue o padrão de projeto MVC (Model, View, Controller) que é largamente utilizado na indústria de software. Trata-se da separação clara de cada um de seus componentes: O Model é o módulo no qual se encontram as regras de negócio da aplicação juntamente com suas entidades. A View é a tela de interface com o usuário. É nessa componente que os dados são visualizados pelo usuário e onde ele interage com o sistema. O Controller é responsável por intermediar os dois componentes anteriores. Ele basicamente pega os dados gerados da comunicação do usuário com a View e os entrega para o Model processar, o mesmo ocorre no sentido inverso. A grande vantagem desse padrão de projeto é tornar o sistema modular, sendo cada camada independente da outra. Isso nos leva a facilidade de manutenção, por exemplo, se for necessária uma mudança nos cálculos de uma aplicação, o desenvolvedor precisa apenas alterar o Model. Analogamente, se for necessária uma mudança de design na tela de visualização, é apenas lá que o desenvolvedor vai realizar a mudança (Eric Freeman, 2007).

40 Capítulo 5. Arquitetura do Maritaca 24 No cenário do sistema móvel, é no Model que estão concentradas as regras de negócio, ou seja, as implementações do funcionamento de cada questão, validações e comparações. A View é composta pelas telas do sistema. No Android, as telas são definidas por arquivos XML nos quais estão estabelecidos o posicionamento das componentes como texto, botão, checkbox, entre outros. Quem implementa a ação desses componentes é o Controller, que no contexto do Android são suas Activities. A Figura 5.3 mostra como esses componentes se relacionam. Figura 5.3: Relacionamento entre as componentes do MVC na Engine Engine Toda a comunicação entre dispositivo móvel e servidor ocorre via web services e, sendo mais específico, quando essa comunicação envolve questionários ou respostas de questionários ela transmite informações que representam arquivos XML. Esses arquivos precisam ser lidos e transformados em objetos Java que representam uma pergunta no questionário. Ocorre o mesmo no sentido inverso, um objeto Java que representa uma resposta é transformado em um arquivo XML e é enviado ao servidor. As manipulações dos arquivos XML são realizadas pela Engine. Ou seja, a Engine é responsável por receber dados que descrevem um questionário e retornar objetos Java que são efetivamente as questões implementadas. A Engine implementa o padrão de projeto Interpreter. Este padrão define que dado uma linguagem, é possível determinar uma representação para ela por intermédio de um interpretador que usa essa representação para processar sentenças da linguagem (Gamma et al., 1994). O conceito fundamental do Interpreter na Engine é apresentar um conjunto hierárquico de classes que representa a especificação de um formulário, que por sua vez representa a linguagem a ser interpretada. O arquivo XML, ou a especificação de formulários, é a linguagem a ser interpretada e a Engine é o interpretador.

41 Capítulo 5. Arquitetura do Maritaca 25 Cada tipo de questão do formulário digital é representada por uma hierarquia de classes, cuja superclasse é a classe Question. Essa superclasse possui atributos e métodos que são comuns as subclasses. Essa estrutura de classes pode ser vista na Figura 5.4. O responsável por processar o XML e gerar os objetos definidos pelas subclasses de Question é o Parser. Figura 5.4: Estrutura de Classes de Question. Parser A leitura de formulários é feita baseada em um conjunto de classes que representam o arquivo XML. O formulário em si é representado pela classe Form, seus elementos são compostos pela classe Questions e os atributos dos elementos são representados pelas classes Comparison e Clause. A modelagem dessas classes foi feita utilizando annotations, providas pelo framework Simple (Simple Community, 2013), que facilita a implementação e melhora a legibilidade do código. O Simple também auxilia na serialização dos arquivos XML de respostas dos formulários. O trabalho de manusear as entidades citadas acima é responsabilidade das classes utilitárias XMLFormParser, XMLAnswerParser e XMLAnswerListParser. Essas classes são referenciadas na camada de negócio do sistema móvel. As respostas dos formulários são transmitidas da unidade móvel Android para o servidor através de grandes strings de caracteres, encapsuladas em requisições HTTP, que representam seus respectivos arquivos XML. Comparison Um formulário com perguntas sequenciais nem sempre é interessante para determinados conjuntos de perguntas. Essa funcionalidade é passível de ser implementada em um formulário digital e consiste de apresentar uma ou mais perguntas dependendo da resposta de uma pergunta anterior. Por exemplo, a pergunta: Você ingere bebidas alcoólicas? só deverá aparecer

42 Capítulo 5. Arquitetura do Maritaca 26 se a pergunta anterior: Qual é a sua idade?, obter uma resposta dizendo que o interrogado tem mais de 18 anos. Essa funcionalidade está representada por um atributo no XML do formulário de perguntas e que pode ter as seguintes comparações: igual, maior, maior ou igual, menor e menor ou igual. Cada comparação é representada por uma classe e todas elas estendem a classe abstrata Clause, conforme mostra a Figura 5.5. Figura 5.5: Estrutura de classes do Comparison.

43 CAPÍTULO 6 Funcionalidades do Sistema O Maritaca oferece ao usuário uma interface simples e intuitiva para a criação de formulários, geração de aplicações e coleta de dados. Basicamente, são necessários três passos para que um ciclo de coleta de dados se complete: 1. Pelo navegador de internet, o usuário cria o questionário. O sistema construirá a aplicação Android e o disponibilizará para download. 2. A aplicação é instalada no dispositivo Android; 3. O usuário coleta as informações e envia as respostas ao servidor. Esse capítulo detalha as funcionalidades que o sistema oferece e ao mesmo tempo é um guia para sua utilização. 6.1 Utilização O endereço de acesso do Maritaca é Para utilizar o sistema, é necessário efetuar um cadastro simples e depois se logar, como mostra a Figura 6.1. Caso o usuário já tenha uma conta de usuário da Google, Yahoo ou do Facebook é possível utilizá-la através da tecnologia OpenID (OpenID Foundation, 2012). 27

44 Capítulo 6. Funcionalidades do Sistema 28 Figura 6.1: Tela de login. Após a autenticação, o usuário é levado para a página principal do sistema, onde são listados todos os formulários criados por ele e os compartilhados, conforme mostra a Figura 6.2. Há um menu com aba Groups na parte superior, o qual permite o gerenciamento de grupos de usuários. Figura 6.2: Tela principal.

45 Capítulo 6. Funcionalidades do Sistema 29 Ao clicar no botão New Form o usuário é levado para a tela de criação de formulários. O painel da esquerda contém os tipos de pergunta que o usuário pode adicionar ao seu formulário, como uma pergunta em forma de texto, uma foto, um vídeo, uma data, localização por GPS, entre outras. As perguntas são componentes HTML 5 arrastáveis (drag and drop), dessa forma o usuário pode adicionar um desses itens simplesmente arrastando-o para o centro da tela. No exemplo da Figura 6.3 o formulário possui quatro perguntas. Figura 6.3: Criação de formulários. Após salvar o formulário, a criação do aplicativo para Android começa automaticamente de forma assíncrona. Depois de criado, o usuário pode fazer o download do aplicativo e instalá-lo no seu dispositivo Android. Após a instalação, o aplicativo exige uma autenticação do usuário, da mesma forma que quando acessado através do navegador. A interface principal mostrada na Figura 6.4 é composta por um menu que corresponde ao formulário criado anteriormente. Para coletar informações deste formulário basta selecionar a opção Collect. As próximas sequências de telas correspondem às perguntas criadas previamente na interface web do Maritaca. A Figura 6.5 ilustra as questões do formulário criado anteriormente. As telas de questionário são divididas de forma que na região superior fiquem localizados o título do formulário, uma barra de progresso, um botão de ajuda e um botão de cancelar. O restante da tela é ocupado pela questão e sua resposta. O usuário pode realizar quantas coletas forem necessárias para um mesmo formulário. Depois dos dados serem coletados, o usuário pode enviar essas informações para os servidores do Maritaca e acessá-las na sua conta via interface web.

46 Capítulo 6. Funcionalidades do Sistema 30 Figura 6.4: Autenticação e tela principal do aplicativo móvel. Figura 6.5: Exemplos de questões no aplicativo móvel. 6.2 Recursos do Formulário Digital Os questionários podem ser criados utilizando vários tipos de recursos. A interface web do Maritaca disponibiliza perguntas dos seguintes tipos: texto, seleção múltipla (checkbox), numeral, data, múltipla escolha (combobox e radiobox), foto, áudio, vídeo, GPS, código de barras, controle deslizante (slider) e desenho. O Maritaca está em constante desenvolvimento e existem planos para adicionar mais tipos de perguntas. Uma grande vantagem do sistema é sua arquitetura modular que facilita a adição de novas componentes. Por exemplo, todos os tipos de questões estão agrupados em um pacote de classes independente, dessa forma, para criar um novo tipo de questão, basta criar novas classes que representam o tipo de questão desejado. É importante salientar que é necessário estender a classe abstrata Question que define como os métodos devem ser implementados. Cada questão do formulário digital do Maritaca possui propriedades importantes que deixam o sistema mais robusto para o uso na CMD. Cada questão pode ter seu valor padrão inicial, um

47 Capítulo 6. Funcionalidades do Sistema 31 valor mínimo e um valor máximo definidos na etapa da criação do formulário. Também há a possibilidade de tornar uma pergunta obrigatória ou mantê-la opcional. Outra funcionalidade que merece destaque é a capacidade do desvio do fluxo normal da sequência das perguntas através de algumas condicionais, tais como: igual, menor, maior, menor ou igual e maior ou igual. Ou seja, é possível ir pra alguma questão específica do questionário a partir da questão atual, obviamente que a mudança da sequência depende da resposta. Uma propriedade útil das questões é o campo ajuda. Trata-se de um campo texto que complementa a descrição da questão e pode ser acessado a partir de um botão na região superior do aplicativo móvel. 6.3 Compartilhamento de Informações O nível de compartilhamento dos formulários e suas respostas podem ocorrer em três graus: privado, público e compartilhado. No compartilhamento privado, o formulário só está acessível ao seu criador (owner). No público, o formulário é acessível para todos. O nível compartilhado de um formulário ocorre quando o seu criador convida outros usuários para acessá-lo. Esse nível possui duas ramificações: Hierárquico: Os usuários convidados não podem acessar as respostas coletadas de outros convidados. Apenas o criador do formulário consegue ver todas as respostas; Social: Ao contrário do item anterior, tanto os usuários convidados quanto o criador conseguem acessar todas as respostas coletadas. A Tabela 6.1 sintetizou os tipos de permissões de acesso (leitura e escrita dos dados coletados) para o criador do formulário e seus convidados, de acordo com o grau de compartilhamento. Tabela 6.1: Políticas de compartilhamento de dados no Maritaca. Formulário Resposta Privado Comp. Hierárquico Comp. Social Público Leitura Criador Criador e Convidados Criador e Convidados Todos Escrita Criador Criador Criador Criador Leitura Criador Criador Criador e Convidados Todos Escrita Criador Criador e Convidados Criador e Convidados Criador

48 Capítulo 6. Funcionalidades do Sistema Relatórios A geração automática de relatórios é uma funcionalidade que está em desenvolvimento, porém não pode deixar de ser mencionada. Ela permite que a partir das informações coletadas e das perguntas selecionadas pelo usuário seja gerado um relatório contendo gráficos de pizza ou barras e organizar os dados em forma de tabelas. Por enquanto os relatórios são gerados apenas com questões de seleção múltipla como checkbox e radiobox. A Figura 6.6 exibe a tela de criação de relatórios em que o relatório (coluna central) contém duas questões do formulário (coluna da esquerda). É possível criar e editar vários relatórios para um mesmo formulário. Para acessá-los, basta abrir o menu de opções do formulário desejado, exibido na Figura 6.7, e clicar na opção Edit Report ou View Report, na página principal do Maritaca. Figura 6.6: Interface para elaboração de relatórios. Figura 6.7: Menu de acesso aos relatórios.

49 CAPÍTULO 7 Implantação do Maritaca Este capítulo destaca os passos para a implantação do sistema e configuração do ambiente de desenvolvimento. 7.1 Ambiente de Desenvolvimento A preparação do ambiente de desenvolvimento consiste na instalação e configuração das ferramentas e bibliotecas utilizadas no desenvolvimento de um sistema. O sistema operacional recomendado para o desenvolvimento do Maritaca é o Ubuntu versão As ferramentas usadas no desenvolvimento juntamente com suas páginas oficiais são listadas abaixo: JDK (Java Development Kit) versão 6: java/javase/downloads/index.html; Eclipse IDE para Java EE: Plugin maven para Eclipse: Android SDK: Plugin ADT: html; 33

50 Capítulo 7. Implantação do Maritaca 34 Cassandra Tomcat 7 Apache Maven: Apache Ant: Git: RabbitMQ: Note que para o Eclipse poder ser executado, o JDK 6 precisa ser instalado primeiro. 7.2 Implantação no Servidor Após todos os itens da seção anterior serem instalados e devidamente configurados, é necessário fazer o download do código fonte do Maritaca que está disponível na página do Maritaca no SourceForge. O seguinte comando deve ser executado no terminal do Linux: $ git clone git://git.code.sf.net/p/maritaca/code maritaca-code Após a execução do comando, a pasta contendo o código fonte estará no diretório corrente. O módulo servidor é divido em quatro projetos: business, persistence, web e webservices. O módulo móvel possui um único projeto: o maritaca-mobile. O arquivo de configuração configuration.properties é essencial para a implantação do projeto. Ele pode ser criado em qualquer diretório contanto que sua localização seja fixada por meio da variável de ambiente MARITACA_CONFIG_PATH. Esse arquivo é exibido na Tabela 7.1. Antes de iniciar o servidor é necessário configurar o Cassandra. Primeiro deve-se subir o serviço no terminal executando o seguinte arquivo, localizado na pasta de instalação do Cassandra: $ sudo./bin/cassandra Usando outro terminal é preciso criar o keyspace do Maritaca, executando os seguintes comandos:

51 Capítulo 7. Implantação do Maritaca 35 Tabela 7.1: Arquivo de configuração configuration.properties. Propriedade maritaca_mobile_path android_sdk_path maritaca_uri_server filesystem_path http_uri_server ffmpeg_path tmp_directory cluster_addr Exemplo /home/user/workspace/maritaca/client/ /opt/android/android-sdk-linux /var/www/hadoop_mounted/user/seu-usuario /usr/local/bin/ffmpeg /tmp/ localhost:9160 $./bin/cassandra-cli -h localhost create keyspace Maritaca; exit; Para configurar o RabbitMQ execute os seguintes comandos: $ sudo rabbitmqctl add_user maritaca maritaca $ sudo rabbitmqctl add_vhost Maritaca $ sudo rabbitmqctl set_permissions -p Maritaca maritaca ".*" ".*" ".*" Há um projeto chamado rabbit-consumer na pasta services. O projeto deve ser compilado com o maven através do comando: $ mvn clean package Um arquivo JAR referente ao projeto será gerado. Deve-se executá-lo através do comando: $ java -jar rabbit-consumer-1.0.jar O servidor de aplicações Tomcat pode ser iniciado através de um script localizado na pasta bin que fica no diretório onde foi instalado o Tomcat. Dentro desta pasta, basta executar o comando: $./catalina.sh run

52 Capítulo 7. Implantação do Maritaca 36 Após o servidor ser inicializado a interface web do Tomcat pode ser acessada por meio do endereço O próximo passo é compilar o projeto servidor e gerar um arquivo WAR (Web application ARchive) que representa a aplicação web do Maritaca a ser implantada no servidor. O projeto é compilado com a ferramenta maven, executado no terminal e na pasta server do projeto, por meio do comando abaixo: $ mvn clean install -Dmaven.test.skip=true O arquivo WAR pode ser encontrado dentro da pasta target do projeto web no módulo servidor. É esse arquivo que deve ser implantado no servidor. O maven possui plugins extras que se instalados permitem que logo após o projeto ser compilado, o arquivo WAR construído é automaticamente implantado no servidor. Existem outras maneiras como utilizar a interface web do servidor e fazer o upload do próprio arquivo WAR. Após a implantação o módulo servidor do Maritaca pode ser acessado através do endereço Aplicação Android Se o plugin ADT e o Android SDK foram instalados corretamente, dois ícones devem aparecer no Eclipse: o Android SDK Manager e o Android Virtual Device Manager. O primeiro se trata de um gerenciador das API s do Android assim como algumas ferramentas. O projeto Maritaca pode ser compilado a partir da API 7, portanto se faz necessária a instalação de uma API igual ou superior. O Android Virtual Device Manager é um gerenciador de dispositivos virtuais que emulam um smartphone Android. Pode-se criar vários dispositivos virtuais, cada um com sua respectiva versão do Android e atributos como memória principal e resolução de tela. Se a versão do Ubuntu instalada é 64 bits, então a instalação da biblioteca ia32-libs se faz necessária para trabalhar com o Android SDK. O módulo móvel do Maritaca depende de outro projeto: o ActionBarSherlock (http: //actionbarsherlock.com/). No projeto ele está nomeado como library e está no mesmo diretório do maritaca-mobile. O código fonte do módulo móvel Android está dentro da pasta maritaca-mobile. Para adicionar o projeto ao Eclipse é necessário importa-lo pelo menu File -> Import ou clicando com o botão direito no Package Explorer -> Import conforme mostra a Figura 7.1. Após esse passo, surge um menu com vários tipos de projetos. Deve-se escolher um projeto do tipo Android como fonte. Lembre-se de importar tanto o library quanto o maritaca-mobile.

53 Capítulo 7. Implantação do Maritaca 37 Figura 7.1: Modos de importar projetos no Eclipse. Após importado, o projeto pode ser visualizado no Package Explorer. Todas as classes, arquivos de layout, bibliotecas adicionais e arquivos de configuração podem ser acessados. Para executar o projeto basta clicar com o botão direito no projeto e selecionar Run As -> Android Application. O dispositivo virtual criado anteriormente será iniciado e a aplicação instalada e executada.

54 CAPÍTULO 8 Contribuições no Código Este capítulo apresenta as principais contribuições, por mim realizadas, no código fonte do sistema móvel do projeto Maritaca. Foram desenvolvidas três funcionalidades principais: a implementação do tipo de questão slider, um serviço de notificação de novos dados enviados e a tela de configuração ou settings. Esses três itens cobrem campos diferentes tanto da arquitetura do Maritaca quanto da API do Android, abrangendo tópicos como a criação de telas por arquivos XML, consultas e inserções de dados através do SQLite, uso do sistema de notificação e de alarme do Android, implementação da classe Question, entre outros. 8.1 Question Slider O Slider no Maritaca é a implementação da Seek Bar presente na API do Android. Com essa componente é possível selecionar um valor em um intervalo (geralmente de zero a cem) movendo horizontalmente o indicador da barra. O menor valor está no limite da esquerda assim como o maior está no limite da direta. A Figura 8.1(b) mostra a Seek Bar da API do Android e a Figura 8.1(a) mostra o Slider do Maritaca. 38

55 Capítulo 8. Contribuições no Código 39 (a) Slider Maritaca. (b) Seek Bar Android. Figura 8.1: Customização da componente Seek Bar Passos da Implementação A classe abstrata Question, mostrada no Apêndice B, define quais métodos os tipos de questões devem implementar. Essa classe é fundamental no contexto do sistema, pois todas as manipulações que a Engine faz para criar os objetos, que correspondem as questões no formulário, são feitas com base nos seus métodos. Para desenvolver o Slider foi necessário implementar os seguintes métodos abstratos: public abstract ComponentType getcomponenttype(); Este método retorna o tipo do componente ou questão a ser implementada. ComponentType é um Enum, ou seja, uma classe estruturada de tal forma que seus dados sejam imutáveis (Sierra e Bates, 2005). É nessa classe que estão definidos todos os tipos de questões com um respectivo identificador, inclusive o slider. public abstract Object getvalue(); Retorna o valor adquirido pela questão. No caso do slider é retornado um valor numérico, mas caso fosse um questão do tipo texto, este método retornaria uma string de caracteres. public abstract View getlayout(controlleractivity activity); Este método retorna o Slider customizado. O slider é montado a partir da seek bar juntamente com seu esquema de posicionamento da componente na tela. Com o slider foi criada uma componente de texto que mostra o valor atual do slider e o atualiza caso o usuário mude. public abstract boolean validate(); A validação da questão é feita quando o usuário avança ou retrocede no formulário no menu de coleta. Um tipo de validação é a verificação da obrigatoriedade da resposta, ou seja, a resposta da questão não pode ser vazia. O slider implementa este tipo de validação. public abstract void save(view answer); A implementação deste método ocorre da mesma forma que o item anterior, porém o método salvar é executado antes, pois no contexto do sistema é necessário salvar o valor selecionado pelo usuário para poder executar a validação.

56 Capítulo 8. Contribuições no Código Serviço de Notificações Um serviço no Android, representado pela classe Service, é uma componente de aplicação que tem como função realizar operações prolongadas que não interferem com o usuário ou prover funcionalidades para outras aplicações. Os serviços não são processos ou threads adicionais, ou seja, são executados no mesmo processo da aplicação a qual pertencem. A classe IntentService estende Service e é usada para lidar com tarefas assíncronas, ou seja, ela cria threads para processar o que foi requisitado e depois elimina a thread (Google Inc., 2012b). O serviço de notificações é composto por uma IntentService que faz uma requisição HTTP para o servidor acessando um web service que retorna uma resposta que contém a quantidade de novas coletas enviadas ao servidor, a partir de uma data, por outros coletores para o formulário em questão. Se houverem novas coletas a própria IntentService lança uma notificação, como a ilustrada na Figura 8.2. Essa funcionalidade é útil quando existem vários coletores para um mesmo formulário. Figura 8.2: Notificação de novos dados coletados Passos da Implementação Criação do Serviço O serviço é representado pela classe NotificationService que estende IntentService. Essa classe é responsável por criar a notificação e gerenciar a requisição e sua resposta HTTP. Caso a resposta do web service retorne um inteiro maior que zero, uma notificação é gerada indicando o número de novas coletas, caso contrário, uma notificação é gerada indicando que nenhuma coleta foi enviada ao servidor. O NotificationService é chamado assim que a tela de menu é construída. Quem faz a chamada é a classe AlarmManager que provê acesso a sistema de alarmes do Android e permite agendar a execução do serviço, que é feita repetidamente e em intervalos de tempo definidos

57 Capítulo 8. Contribuições no Código 41 pelo usuário. A tela de configuração, melhor detalhado na Seção 8.3, inclui opções para ligar ou desligar o serviço de notificação e determinar o intervalo de tempo que a sincronização com o servido é realizada. Tratamento da Requisição e Resposta A requisição é feita criando um objeto que representa uma requisição HTTP e o enviando. A criação da requisição envolve a passagem de parâmetros de dois parâmetros a partir da URL: a identificação do formulário e a data da última sincronização. Depois que a requisição foi enviada cabe ao servidor recebê-la e tratá-la. O servidor usa o RESTEasy (JBoss Community, 2013) que implementa a especificação JAX-RS (Oracle Corp., 2013a) e provê uma biblioteca para web services RESTful, facilitando seu uso. O servidor está configurado para filtrar as requisições feitas aos web services e encaminhá-las para seu respectivo método de implementação. Este método faz uma busca no banco de dados que retorna uma lista de formulários enviados ao servidor, por outros usuários, a partir da data recebida como parâmetro. Com essa lista em mãos, basta retornar seu tamanho. O resultado é encapsulado em um objeto que corresponde ao uma resposta HTTP e é enviada de volta ao NotificationService. A Figura 8.3 representa a sequência dos eventos e chamadas do sistema de notificações. Figura 8.3: Fluxograma do sistema de notificações.

58 Capítulo 8. Contribuições no Código Menu Settings A partir do menu principal há um botão com opção de ir para tela de configurações ou Settings. As opções de configuração nessa tela fazem referência a seção anterior, logo, ela contém um botão no qual é possível ativar ou desativar a sincronização com o servidor do sistema de notificações. Caso esse botão for habilitado, a escolha do intervalo de tempo de sincronização também será. A Figura 8.4 apresenta a tela com suas respectivas componentes. Figura 8.4: Tela Settings Passos da Implementação A criação de telas, ou interfaces de usuário, no Android ocorre pela representação de seus componentes com seus respectivos atributos por um arquivo XML. No arquivo que representa a interface da Figura 8.4 existem alguns componentes a serem destacados: O Toggle Button, que alterna entre ativada e desativada a sincronização do sistema de notificações; A Seek Bar, responsável por determinar o intervalo de sincronização em minutos. Note que esta componente só estará habilitada de o botão do item anterior também estiver; O botão Save Settings que persiste as configurações no banco de dados local do dispositivo móvel.

59 Capítulo 8. Contribuições no Código 43 Para armazenar as preferências do usuário, foi necessário criar uma tabela no banco de dados local. Cada linha desta tabela armazena se o Toggle Button está ativado ou não, o intervalo de sincronização e o usuário a quem pertence essas opções. A API do Android fornece algumas classes que facilitam a manipulação de tabelas no banco de dados local SQLite. Para manipular os dados dessa tabela foram implementados métodos para inserção, atualização e consulta desses dados. A inserção ocorre quando não existem dados na tabela e o usuário pressiona o botão Save Settings. A atualização ocorre da mesma forma, porém somente quando existem dados na tabela. As consultas são feitas na própria tela Settings, no momento de sua criação, para carregar as componentes com os valores salvos anteriormente, e também no AlarmManager para pegar o valor do intervalo de sincronização. 8.4 Problemas Reportados Os problemas encontrados no sistema podem ser adicionados na página de notificação de bugs no SourceForge do Maritaca ( Os problemas encontrados e submetidos são listados a seguir: O aplicativo móvel não abre em versões do Android 4.0 ou superior. Esse problema ocorre quando requisições HTTP são executadas na thread principal da aplicação, o que pode acarretar em ANR (Application Not Responding) (Google Inc., 2012b). A página referente ao bug é Caso o coletor não tiver acesso à internet ele não consegue coletar dados. A Seção 9.3 descreve como este problema foi encontrado. A página referente ao bug é sourceforge.net/p/maritaca/bug/53/; Quando uma questão do tipo Picture é enviada ao servidor com uma foto grande (2 MBytes) o a aplicação para de responder, gerando um aviso de ANR.

60 CAPÍTULO 9 Estudo de Caso A fim de avaliar o funcionamento do sistema em modo de produção, este capítulo apresenta os resultados da CMD usando o Maritaca em um cenário real. 9.1 Cenário A Universidade Federal de São Paulo campus São José do Campos iniciou suas atividades em 2007 com apenas um curso, cinquenta alunos e dez docentes. Com um evolução rápida, no ano de 2012 possuía cerca de mil alunos e oitenta docentes distribuídos entre três cursos e três turnos diferentes. Para atender esse público, o campus possui uma cantina e um restaurante universitário (criado em 2011), sendo que o último possui parte do valor da refeição subsidiado pela universidade. As refeições são oferecidas em dois horários, no almoço a partir das doze horas até às catorze horas e no jantar a partir das dezoito horas até às vinte horas. O Maritaca foi usado nesse cenário para coletar informações sobre a satisfação dos usuários do restaurante universitário durante 15 dias. 44

61 Capítulo 9. Estudo de Caso Formulário As imagens da Seção 6.1 demonstram a construção da aplicação Bandejão, a mesma utilizada nessa demonstração. O formulário digital é composto pelos seguintes itens: Qual o seu nome? Figura 9.1(a); Qual o seu curso? Figura 9.1(b); Qual a data da refeição? Figura 9.1(c); Qual sua satisfação? Figura 9.1(d); Foto da refeição. Figura 9.1(e). (a) Pergunta não obrigatória do tipo texto. (b) Pergunta obrigatória do tipo (c) Pergunta obrigatória do tipo RadioButton com as opções BCC, data. BCT ou BMC. (d) Pergunta obrigatória do tipo RadioButton com as opções ótimo, Picture. (e) Questão não obrigatória do tipo bom, regular, ruim. Figura 9.1: Questões do formulário Bandejão.