DESENVOLVIMENTO DE APLICATIVO MÓVEL MULTIPLATAFORMA INTEGRADO AO SISTEMA DE ALERTA DE CHEIAS DA BACIA DO ITAJAÍ

Tamanho: px
Começar a partir da página:

Download "DESENVOLVIMENTO DE APLICATIVO MÓVEL MULTIPLATAFORMA INTEGRADO AO SISTEMA DE ALERTA DE CHEIAS DA BACIA DO ITAJAÍ"

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIA DA COMPUTAÇÃO BACHARELADO DESENVOLVIMENTO DE APLICATIVO MÓVEL MULTIPLATAFORMA INTEGRADO AO SISTEMA DE ALERTA DE CHEIAS DA BACIA DO ITAJAÍ CARLOS EDUARDO DE SOUZA BLUMENAU /2-05

2 CARLOS EDUARDO DE SOUZA DESENVOLVIMENTO DE APLICATIVO MÓVEL MULTIPLATAFORMA INTEGRADO AO SISTEMA DE ALERTA DE CHEIAS DA BACIA DO ITAJAI Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação Bacharelado. Prof. Dalton Solano dos Reis, M.Sc. - Orientador BLUMENAU /2-05

3 DESENVOLVIMENTO DE APLICATIVO MÓVEL MULTIPLATAFORMA INTEGRADO AO SISTEMA DE ALERTA DE CHEIAS DA BACIA DO ITAJAÍ Por CARLOS EDUARDO DE SOUZA Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Dalton Solano dos Reis, M.Sc. Orientador, FURB Prof. Nome do professor, Titulação FURB Prof. Nome do professor, Titulação FURB Blumenau, 14 de novembro de 2012

4 Dedico este trabalho a todos os que me apoiaram durante o decorrer deste curso, especialmente aos meus amigos, à minha família e aos meus professores.

5 AGRADECIMENTOS A todos que contribuíram de forma direta ou indiretamente na minha evolução acadêmica e profissional durante esta etapa da minha vida. Aos que contribuíram para a realização deste trabalho. Aos meus amigos, pelo apoio sempre presente nos momentos difíceis. Ao meu orientador, pela confiança e apoio na realização deste trabalho. À minha família, com quem aprendi o valor do trabalho e da honestidade. Aos professores e funcionários do Departamento de Sistemas e Computação, pelo excelente trabalho que faz deste curso uma referência na região.

6 A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original. Albert Einstein

7 RESUMO Este trabalho apresenta o desenvolvimento de um aplicativo multiplataforma que informa em um mapa interativo os últimos dados registrados pelo sistema de alerta de cheias da bacia do Itajaí, e permite registrar ocorrências adversas em situação de emergência. É composto por um aplicativo cliente desenvolvido no framework Titanium SDK, que faz deploy para as plataformas Android e ios. Os registros das estações são capturados periodicamente e mantidos em base de dados própria. As ocorrências são registradas com as informações de latitude e longitude obtidas através do recurso de geolocalização do dispositivo e imagem obtida da galeria de mídias digitais. As ocorrências são divulgadas na rede social Facebook e armazenadas em base de dados própria. Durante a evolução deste trabalho, o framework é apresentado através de conceitos e utilização de suas funcionalidades. Palavras-chave: Computação móvel. Multiplataforma. Desenvolvimento web. Monitoramento e alerta.

8 ABSTRACT This work presents the development of a multiplatform application which informs on an interactive map the latest registered data by the Itajaí basin flood alert system, and allows recording adverse occurrences in an emergency situation. It consists of a client application developed in Titanium Framework SDK that deploys to Android and ios platforms. The records of the stations are periodically captured and maintained in its own database. The occurrences are registered with the latitude and longitude information obtained through the geolocation device resource and image obtained from the gallery of digital media. The occurrences are reported in the social network Facebook and stored in its own database. During the evolution of this work, the framework is presented through concepts and use of their features. Key-words: Mobile computing. Multiplatform. Web development. Monitoring and alerting.

9 LISTA DE ILUSTRAÇÕES Figura 1 Interface da tela do aplicativo Acqua que exibe o mapa com a localização dos sensores, obtida do aplicativo executado em um iphone Figura 2 Interface da tela do aplicativo Acqua que exibe as informações do sensor selecionado no mapa, obtida do aplicativo executado em um ipad e um iphone.. 23 Figura 3 Interface do aplicativo Climatempo Mobile no iphone Figura 4 Diagrama de casos de uso Quadro 1 Caso de uso Efetuar login no Facebook Quadro 2 Caso de uso Visualizar histórico recente da estação Quadro 3 Caso de uso Visualizar últimas ocorrências Quadro 4 Caso de uso Relatar ocorrência Quadro 5 Caso de uso Visualizar localização atual Quadro 6 Caso de uso Atualizar base local de registros das estações Quadro 7 Caso de uso Atualizar base local de ocorrências Quadro 8 Caso de uso Recuperar registros recentes das estações do sistema de alerta Quadro 9 Caso de uso Cadastrar nova ocorrência Figura 5 Diagrama de classes do pacote App.API Figura 6 Diagrama de classes do pacote App.Controllers Figura 7 Diagrama de classes do pacote App.Models Figura 8 Diagrama de classes do pacote App.UI Figura 9 Diagrama de classes do servidor Figura 10 Diagrama de sequência Atualizar base local de registros das estações Figura 11 Diagrama de sequência Relatar ocorrência Figura 12 MER do aplicativo cliente Figura 13 MER do aplicativo servidor Figura 14 Camadas do ambiente de desenvolvimento Figura 15 Fluxo de desenvolvimento no Titanium Studio Quadro 10 Primeiro trecho do arquivo tiapp.xml... 51

10 Figura 16 Organização dos arquivos do projeto Quadro 11 Inicialização do banco de dados do aplicativo cliente na classe App.API.Registro_Movel Quadro 12 Trecho do método select_ultimos() da classe App.API.Ocorrencia em que as informações são recuperadas Quadro 13 Trecho de código do método atualizar_registros() da classe App.API.Registro_Movel que representa comunicação com o servidor Quadro 14 Arquivo facebook.js Quadro 15 Trecho de código do arquivo coletar.php Quadro 16 Função get_json(string) do arquivo include/funcoes.php Quadro 17 Trecho de código do arquivo coletar.php Quadro 18 Método set_atributos(array) da classe Registro Quadro 19 Classe PDOConnectionFactory Quadro 20 Trecho de código da classe OcorrenciaDAO com método select_ultimos() Quadro 21 Trecho de código do webservice definido no arquivo cadastrar_ocorrencia.php Quadro 22 Método insert(object) da classe OcorrenciaDAO Figura 17 Tela de abertura (esquerda) e tela principal do aplicativo (direita) Figura 18 Telas do processo para visualização das informações e histórico de registros das estações Figura 19 Telas do processo para visualização das informações e histórico de registros das estações Figura 20 Postagem da ocorrência no grupo TCC Carlos Souza acessado via navegador de internet Mozilla Firefox para computador Figura 21 Telas do processo para login no Facebook Figura 22 Telas do processo para relatar ocorrência Figura 23 Cenário do sistema Figura 24 Configuração DNS do servidor do sistema de alerta Figura 25 Tela principal em dispositivo Android (esquerda) e no simulador do iphone com ios 5.1 (direita)... 84

11 Figura 26 Janela de alerta e botão do Facebook em simulador Android 2.2 (esquerda), em um dispositivo Android (centro) e no simulador do iphone com ios 5.1 (direita) Figura 27 Mapa em simulador do ipad com ios 5.1 (esquerda) e em um dispositivo ipad com ios (direita) Figura 28 Galeria de imagem em dispositivo Android (esquerda) e no simulador do iphone com ios 5.1 (direita) Figura 29 Componente indicador de atividade em dispositivo Android (esquerda), dispositivo Android (centro) e no simulador do iphone com ios 5.1 (direita) Quadro 23 Comparativo de funcionalidades entre os trabalhos correlatos LISTA DE TABELAS Tabela 1 Estatísticas de retorno de requisições simultâneas ao registro das estações do servidor Tabela 2 Estatísticas de retorno de requisições simultâneas ao registro de ocorrências do servidor... 89

12 LISTA DE SIGLAS ADSL Asymmetric Digital Subscriber Line ADT Android Development Tools API Application Programming Interface CEOPS CEntro de OPeração do Sistema de alerta da bacia do Itajaí CSS Cascading Style Sheets DNAEE - Departamento Nacional de Águas e Energia Elétrica DNS Domain Name System DRY Don t Repeat Yourself DSN Data Source Name FURB Universidade Regional de Blumenau GNU Gnu is Not Unix GPS Global Position System HTML HyperText Markup Language HTTP HyperText Transfer Protocol IDE Integrated Development Environment J2ME Java 2 Micro Edition JSON JavaScript Object Notation MER Modelos de Entidades e Relacionamentos MVC Model-View-Controller NICBR Núcleo de Informação e Coordenação do ponto BR PDA Personal Digital Assistant PDO Php Data Object PHP Php Hypertext Preprocessor

13 RF Requisito Funcional RNF Requisito Não Funcional SC Santa Catarina SDK Software Development Kit SI Sistema de Informação SO Sistema Operacional SQL Structured Query Language TCC Trabalho de Conclusão de Curso UML Unified Modeling Language URL Uniform Resource Locator Wi-Fi Wireless Fidelity XML - extensible Markup Language

14 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA CEOPS E O SISTEMA DE ALERTA DA BACIA DO ITAJAÍ SISTEMA DE INFORMAÇÕES PARA APOIAR O SISTEMA DE ALERTA DA BACIA DO ITAJAÍ APLICATIVO MÓVEL MULTIPLATAFORMA Experiência móvel e usabilidade Frameworks multiplataforma PhoneGap Titanium Mobile SDK TRABALHOS CORRELATOS Aplicação mobile marketing com comunicação bluetooth focada em bares e restaurantes Acqua Climatempo Mobile DESENVOLVIMENTO DO APLICATIVO MÓVEL AMBIENTE DE DESENVOLVIMENTO REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ESPECIFICAÇÃO Casos de uso Efetuar login no Facebook Visualizar histórico recente da estação Visualizar últimas ocorrências Relatar ocorrência Visualizar localização atual Atualizar base local de registros das estações Atualizar base local de ocorrências Recuperar registros recentes das estações do sistema de alerta Cadastrar nova ocorrência... 35

15 3.3.2 Classes do aplicativo cliente Pacote App.API Pacote App.Controllers Pacote App.Models Pacote App.UI Classes do servidor Diagramas de sequências Diagrama de sequência atualizar base local de registros das estações Diagrama de sequência relatar ocorrência Banco de dados IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Arquivo tiapp.xml Organização dos arquivos do projeto Persistência no aplicativo cliente Comunicação do aplicativo cliente com o aplicativo servidor Comunicação do aplicativo cliente com servidor do Facebook Comunicação do aplicativo servidor com servidor do sistema de alerta Persistência no aplicativo servidor Recebimento de dados no aplicativo servidor Operacionalidade da implementação Tela de abertura e tela principal do aplicativo Visualizar informações e histórico de registros da estação Visualizar as ocorrências registradas Login no Facebook Relatar ocorrência RESULTADOS E DISCUSSÃO Interface gráfica Testes de disponibilidade do servidor Comparativo dos trabalhos correlatos CONCLUSÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS... 94

16 15 1 INTRODUÇÃO Após as grandes cheias ocorridas no início da década de 1980 na região do vale do Itajaí em Santa Catarina, a Universidade Regional de Blumenau (FURB) criou o CEntro de OPeração do Sistema de alerta da bacia do Itajaí (CEOPS) em 1984, com a missão de implantar um sistema de alerta de cheias (CEOPS, 2010). Segundo Tucci (1998 apud MOMO; SILVA; SEVERO, 2010), um sistema de monitoramento e alerta para eventos meteorológicos extremos tem o objetivo de minimizar os impactos causados. Ainda segundo Andrade (2006), o objetivo dos sistemas de alerta antecipado é informar a população, bem como aos órgãos competentes, da ocorrência de inundações em tempo hábil para evacuar a região. Em 2009, Silva desenvolveu um Sistema de Informação (SI) com o objetivo de disponibilizar os dados das estações telemétricas instaladas em diversos pontos na bacia hidrográfica do rio Itajaí-Açu coletados pelo CEOPS. Estes dados são apresentados de forma gráfica e textual, através de uma página da internet, projetada para acesso via computadores e notebooks. O crescente uso de dispositivos móveis dotados de tecnologias de comunicação sem fio criou novas formas das pessoas interagirem com informações e serviços que antes só eram acessados por meio de computadores fixos, em casa ou no local de trabalho. Junto com estes novos equipamentos, cresceu também a demanda de aplicações e serviços que atendem às suas necessidades. A interação móvel é um novo conceito que aborda a interação do usuário com a mobilidade dos dispositivos móveis (CYBIS; BETIOL; FAUST, 2010, p. 254). Diante do exposto, este trabalho pretende estudar o desenvolvimento de aplicativos para plataformas móveis multiplataforma, ou seja, um aplicativo compatível com diversos dispositivos, seguindo as especificações e recursos do framework 1 Titanium Mobile SDK. Com isso, serão portadas ao ambiente móvel algumas funções do SI já utilizado, acrescentado de algumas novas funcionalidades. 1 Framework é uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica, que pode atingir uma funcionalidade específica, por configuração, durante a programação de uma aplicação.

17 OBJETIVOS DO TRABALHO O objetivo deste trabalho é desenvolver um aplicativo móvel multiplataforma integrado ao sistema de alerta da bacia do Itajaí que disponibilize as informações registradas nas suas estações. Os objetivos específicos do trabalho são: a) disponibilizar um aplicativo cliente com interface gráfica para Android e ios composta por um mapa interativo contendo as últimas informações registradas nas estações, como nível do rio Itajaí-Açu e precipitação; b) permitir que o usuário registre uma ocorrência de um acontecimento adverso em uma possível situação de emergência, informando sua localização obtida via Global Positioning System (GPS) e imagem que comprove tal fato, e que publique na rede social Facebook; c) disponibilizar uma base de dados para armazenamento em infraestrutura própria das informações obtidas do sistema de alerta da bacia do Itajaí; d) disponibilizar um aplicativo servidor que atualize a base de dados de registros das estações a cada período determinado, cadastre as ocorrências informadas pelos usuários, e disponibilize as informações das estações e de ocorrências para atualização dos dados do aplicativo cliente. 1.2 ESTRUTURA DO TRABALHO Este trabalho está estruturado em quatro capítulos. O capítulo dois contém a fundamentação teórica necessária para permitir um melhor entendimento sobre este trabalho. O capítulo três apresenta o desenvolvimento do aplicativo, contemplando os principais requisitos do problema e a especificação contendo os casos de uso, diagramas de classes e sequência. Neste capítulo são apresentadas também as ferramentas utilizadas na especificação e implementação. Por fim, são apresentados os resultados e discussão. O capítulo quatro refere-se às conclusões do presente trabalho e sugestões para trabalhos futuros.

18 17 2 FUNDAMENTAÇÃO TEÓRICA 2.1 CEOPS E O SISTEMA DE ALERTA DA BACIA DO ITAJAÍ Em 1983 a FURB criou o Projeto Crise, com o objetivo de desenvolver e implantar um sistema de alerta da bacia do Itajaí-Açu. Este processo iniciou-se após a cheia do rio Itajaí- Açu que atingiu a cota de 15,34 m. O Projeto Crise apresentou um conjunto medidas das áreas de meteorologia, hidrologia, cartografia e pesquisa operacional, que visava amenizar os impactos causados pelas cheias no vale do Itajaí através de medidas não estruturais, quais se caracterizavam por todos os tipos de intervenções que poderiam ser tomadas de maneira a proporcionar um convívio com as enchentes, reduzindo o impacto e suas consequências (CEOPS, 2010). Após novo evento em 1984, é instalado por intermédio do Departamento Nacional de Águas e Energia Elétrica (DNAEE), o CEOPS, que veio a ser gerenciado pelo Projeto Crise, e que passou a ser a contrapartida, atuando com medidas estruturais e planos de ação e estratégias (CEOPS, 2010). 2.2 SISTEMA DE INFORMAÇÕES PARA APOIAR O SISTEMA DE ALERTA DA BACIA DO ITAJAÍ Silva (2009) desenvolveu um sistema para organizar as informações geradas pela rede de monitoramento da bacia do Itajaí, para auxiliar no processo de tomada de decisão na prevenção de catástrofes ambientais na região do vale do Itajaí. Apresentou também um histórico da implantação do sistema de alerta da bacia do Itajaí gerenciado pelo CEOPS e toda a sua infraestrutura instalada, bem como os eventos registrados por ele. O resultado foi o desenvolvimento de um sistema capaz de fornecer informações sobre as condições atuais aos órgãos competentes e a população. O sistema foi testado em situações reais de enchente no final de setembro de Na ocasião, foram registrados até 3.000

19 18 acessos simultâneos (SILVA, 2009). 2.3 APLICATIVO MÓVEL MULTIPLATAFORMA Nesta seção são abordados os conceitos de uso e desenvolvimento de aplicativos móveis que serão empregados no desenvolvimento do projeto Experiência móvel e usabilidade Segundo Hiltunen (2000 apud CYBIS; BETIOL; FAUST, 2010, p. 254), a experiência do usuário móvel é uma composição de cinco fatores. Utilidade, usabilidade, disponibilidade do serviço, estética e todo o processo off-line, são os componentes que exercem grande influência na opinião geral do usuário sobre o sistema. A utilidade refere-se ao quão vantajoso é optar por esta solução em relação às demais, seja pela localização do usuário, pela disponibilidade de outras opções, pela economia de tempo ou esforço. A usabilidade diz respeito à eficácia, eficiência e satisfação do usuário na realização de seus objetivos com o aplicativo móvel. Por não haver controle sobre a conexão e a área de cobertura das operadoras, a consideração destes fatores frente às ações de recepção ou transmissão de dados consiste o fator da disponibilidade do serviço. A estética refere-se ao apelo visual da aplicação, barreira que está sendo vencida pelos novos modelos de dispositivos dotados de telas coloridas e de maior resolução, que permitem a criação de interfaces mais atraentes ao usuário. O último fator apontado pelo autor é o processo off-line, que complementa a experiência do usuário, através de elementos como a confiança no nome da empresa que fornece o serviço e a segurança dos dados, além de todo o processo de retaguarda, como suporte ao usuário ou a rapidez e a qualidade na entrega de uma mercadoria (CYBIS; BETIOL; FAUST, 2010, p. 255) Frameworks multiplataforma Segundo Minetto (2007, p.17), um framework de desenvolvimento é uma base de

20 19 onde se pode desenvolver algo maior ou mais específico. É uma coleção de códigos-fonte, classes, funções, técnicas e metodologias que facilitam o desenvolvimento de novos softwares. Uma das vantagens mais citadas no uso de frameworks é que, por possibilitar um processo de desenvolvimento onde os programadores devem utilizar as mesmas convenções, classes e bibliotecas, a manutenção no software desenvolvido é mais fácil e possui um custo menor. Outra vantagem da grande parte dos frameworks é o uso do conceito conhecido como não se repita 2, que consiste na automatização de tarefas repetitivas (MINETTO, 2007, p. 18). Os frameworks que suportam o desenvolvimento de aplicativos móveis multiplataforma possibilitam a automatização no desenvolvimento do mesmo programa para diversas arquiteturas, através da programação de um único código fonte (PHONEGAP, 2012). A seguir são apresentados dois frameworks que foram projetados para o desenvolvimento de aplicativos móveis multiplataforma, o PhoneGap e o Titanium Mobile SDK PhoneGap PhoneGap é um framework open source que faz deploy de código desenvolvido em padrões web para dispositivos móveis. Isso significa que PhoneGap pode ser utilizado por desenvolvedores e empresas para aplicações móveis livres, comerciais ou qualquer combinação dessas (PHONEGAP, 2012). Para o desenvolvimento de aplicativos, o código deve ser escrito utilizando JavaScript, HyperText Markup Language 5 (HTML5) e Cascading Style Sheets (CSS). Inicialmente desenvolvido pela Nitobi Software, foi incorporado pela Adobe Systems Incorporated em outubro de 2011 (ADOBE, 2011). As plataformas suportadas pelo PhoneGap são: a) ios: Sistema Operacional (SO) desenvolvido pela Apple voltado aos dispositivos móveis da marca: ipad, iphone e ipod Touch (APPLE, 2012); b) Android: SO open source mantido pela Google. É utilizado em dispositivos móveis 2 Não se repita é proveniente da tradução de Don t Repeat Yourself (DRY) (MINETO, 2007, p.18).

21 20 de diversas marcas (GOOGLE, 2012a); c) BlackBerry OS: SO da empresa BlackBerry, desenvolvido para dispositivos móveis da marca (RESEARCH IN MOTION, 2012); d) webos: SO desenvolvido pela empresa Palm para dispositivos móveis da marca. Atualmente é de propriedade da empresa Hewlett-Packard (HP) (HP, 2012); e) Windows Phone: SO desenvolvido pela empresa Microsoft. É utilizado em dispositivos móveis de diversas marcas (MICROSOFT, 2012); f) Symbian: SO open source que até 2009 foi mantido pela Symbian Foundation. Atualmente é mantido pela empresa Nokia (SYMBIAN FOUNDATION, 2012); g) Bada: SO desenvolvido pela empresa Samsung há mais de 10 anos, é utilizado em dispositivos móveis da marca (SAMSUNG, 2011) Titanium Mobile SDK Titanium Mobile SDK é um framework open source para desenvolvimento de aplicativos web e móveis. Seu objetivo é potencializar a força de trabalho através do uso de linguagens familiares, como JavaScript, HTML5 e CSS (APPCELERATOR, 2012a). Implementa mais de 5 mil APIs de dispositivos e SOs para criar aplicativos nativos que se comportam exatamente como se fossem desenvolvidos nas linguagens de programação designadas para cada plataforma. Por exemplo, nas plataformas desenvolvidas pela Apple a linguagem de programação utilizada é Objective-C. Já na plataforma Android é utilizado a linguagem de programação Java (APPCELERATOR, 2012a). Titanium Mobile SDK está disponível sob a licença Apache 2 (APPCELERATOR, 2012a). De forma resumida, isso significa uma licença perpétua, mundial, não exclusiva, gratuita, livre de royalties. É uma licença de direitos autorais irrevogável para reproduzir ou produzir trabalhos derivados, exibir publicamente, executar publicamente, sublicenciar e distribuir o trabalho e tais trabalhos derivados em código fonte ou objeto de formulário (THE APACHE SOFTWARE FOUNDATION, 2004).

22 TRABALHOS CORRELATOS Existem diversos projetos semelhantes ao trabalho proposto. Dentro eles, foram selecionados três cujas características enquadram-se nas principais áreas de estudo deste trabalho, sendo Aplicação mobile marketing com comunicação Bluetooth focada em bares e restaurantes (FORMENTO, 2009), o aplicativo comercial Acqua (B&M APPLICATIONS, 2012) e o aplicativo comercial Climatempo Mobile (CLIMATEMPO, 2012) Aplicação mobile marketing com comunicação bluetooth focada em bares e restaurantes Este projeto resultou no desenvolvimento de um aplicativo móvel, onde o objetivo central é integrar um Personal Digital Assistants (PDA) a um computador através da tecnologia de rede Bluetooth. Formento (2009) aplicou o conceito de mobilidade neste projeto utilizando em seu desenvolvimento a plataforma Java, através da tecnologia Java 2 Micro Edition (J2ME) (FORMENTO, 2009, p. 59). A Plataforma J2ME oferece um ambiente robusto e flexível para a execução de aplicativos em dispositivos móveis, como celulares, PDA, televisores e impressoras (ORACLE, 2012). O resultado deste trabalho foi um aplicativo multiplataforma, sendo suportado pelos sistemas operacionais da maior parte dos dispositivos móveis disponíveis no mercado Acqua O Acqua é um aplicativo comercial desenvolvido pela B&M Applications para os dispositivos ipad, iphone, ipod e ipod Touch; todos eles da marca Apple (B&M APPLICATIONS, 2012). Basicamente este aplicativo é um sistema de monitoramento que coleta e analisa dados de sensores situados no território do município de Jaraguá do Sul. Uma reprodução da tela que exibe o mapa com a localização dos sensores, obtida do aplicativo executado em um iphone é apresentada na Figura 1.

23 22 Fonte: B&M Applications (2012). Figura 1 Interface da tela do aplicativo Acqua que exibe o mapa com a localização dos sensores, obtida do aplicativo executado em um iphone No processo de análise e coleta de dados são obtidas as seguintes informações em tempo real: temperatura, pressão atmosférica, umidade, índice pluviométrico, direção e velocidade do vento (Figura 2). As principais funções do Acqua são (ACQUA, 2012): a) monitoramento meteorológico completo; b) exibição das medições de nível do rio e chuva através de gráficos dinâmicos; c) alertas preventivos inteligentes; d) integração com Twitter. Sua integração com o Twitter permite o relacionamento e troca de informações em duplo sentido entre o sistema e os visitantes. Os usuários podem autenticar-se via login no sistema ou através de sua conta no Twitter. Após isso, eles podem realizar o upload de fotos recém-capturadas pelo dispositivo, contendo a tag de geolocalização e relatar os acontecimentos imediatos. Com a integração do Acqua com o Twitter, o aplicativo torna-se uma poderosa ferramenta de monitoramento em tempo real, pois qualquer pessoa pode enviar mensagens sobre acontecimentos imediatos, incluindo fotos e vídeos, que serão acompanhados pelos

24 23 órgãos competentes (APPLE, 2011). O Acqua está disponível na versão 1.0 desde a data de 28 de fevereiro de 2012 na Apple Store a um custo de US$ 0,99 (APPLE, 2011). Fonte: B&M Applications (2012). Figura 2 Interface da tela do aplicativo Acqua que exibe as informações do sensor selecionado no mapa, obtida do aplicativo executado em um ipad e um iphone Climatempo Mobile Este aplicativo foi lançado pela Climatempo, empresa do ramo de meteorologia, para as seguintes plataformas: Apple, Android e BlackBerry (CLIMATEMPO, 2012). Seu objetivo é exibir a previsão do tempo atualizada e informações sobre condições meteorológicas atuais de diversas localidades do mundo, reproduzindo nos dispositivos móveis a funcionalidade do portal Climatempo como postar comentários sobre as informações apresentadas, enviar fotos e comentando a situação atual do local onde se encontra o usuário. O aplicativo também é integrado às redes sociais Facebook e Twitter. A imagem publicitária do produto divulgada pelo desenvolvedor é apresentada na Figura 3.

25 Fonte: Climatempo Mobile (2012). Figura 3 Interface do aplicativo Climatempo Mobile no iphone 24

26 25 3 DESENVOLVIMENTO DO APLICATIVO MÓVEL Neste capítulo são abordadas as etapas de desenvolvimento do aplicativo móvel multiplataforma. A primeira seção descreve a instalação dos componentes do ambiente do desenvolvimento. A segunda seção apresenta os principais requisitos do problema trabalhado. A terceira seção descreve a especificação da solução através de diagramas da Unified Modeling Language (UML) e de Modelos de Entidades e Relacionamentos (MER). A quarta seção apresenta a implementação da solução, incluindo os principais trechos do código fonte e exemplos de uso do framework. Por fim, a quinta seção aborda os resultados deste trabalho. 3.1 AMBIENTE DE DESENVOLVIMENTO Considerando as especificações do aplicativo cliente e do servidor, este trabalho foi desenvolvido em dois projetos distintos. Em um projeto o aplicativo cliente foi desenvolvido de forma independente. No outro projeto, o servidor foi desenvolvido de modo a prover suporte para o primeiro, atendendo as funcionalidades demonstradas no aplicativo cliente. O aplicativo cliente foi desenvolvido utilizando o Titanium SDK, framework multiplataforma utilizado para desenvolver a aplicação para Android e ios. Detalhes sobre a instalação do Titanium SDK podem ser obtidos através da referência Appcelerator (2012d). Para a execução do projeto em simulador é necessário utilizar o Android SDK para plataforma Android e Xcode para plataforma ios. Informações sobre a instalação desses componentes e a criação dos dispositivos virtuais podem ser encontradas na referência Appcelerator (2012d). O servidor foi desenvolvido na linguagem de programação Php Hypertext Preprocessor (PHP), no ambiente de desenvolvimento Eclipse. Como servidor de aplicação foi utilizado o Apache HTTP Server. O acesso ao banco de dados foi efetuado através do driver Php Data Object (PDO) para o banco de dados MySQL.

27 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO Os Requisitos Funcionais (RFs) do aplicativo cliente são: a) RF01: permitir ao usuário consultar o último nível registrado do rio Itajaí-Açu e o histórico recente de todas as estações do sistema de alerta de cheias da bacia do Itajaí; b) RF02: permitir ao usuário visualizar um mapa com as estações de medição que, através de marcadores coloridos, informem a localização e a situação atual de cada uma; c) RF03: permitir ao usuário consultar eventos registrados na sua região, com base na localização do GPS de seu dispositivo; d) RF04: permitir ao usuário informar novo evento, enviando foto e a localização do GPS de seu dispositivo; e) RF05: permitir ao usuário efetuar login no Facebook para divulgação de ocorrências; f) RF06: permitir ao usuário atualizar os dados do aplicativo a qualquer momento. Os Requisitos Não Funcionais (RNFs) do aplicativo cliente são: a) RNF01: ser implementado em framework que faça deploy para as plataformas Android e ios; b) RNF02: ser implementado usando a análise orientada a objetos; c) RNF03: ser implementado utilizando o modelo Model-View-Controller (MVC) como padrão de projeto; d) RNF04: ser implementado na linguagem de programação JavaScript. Os requisitos funcionais do aplicativo servidor são: a) RF07: consultar o sistema de alerta de cheias da bacia do Itajaí periodicamente para coletar as informações dos registros das estações monitoradas e gravá-las em base de dados própria; b) RF08: disponibilizar via webservice uma lista com os dez últimos registros de cada estação monitorada pelo sistema de alerta; c) RF09: receber dados via webservice para cadastro de nova ocorrência em base de dados própria; d) RF10: disponibilizar via webservice lista com as cinquenta últimas ocorrências registradas.

28 27 Os requisitos não funcionais do aplicativo servidor são: a) RNF05: persistir os dados em banco de dados MySQL; b) RNF06: ser implementado utilizando linguagem de programação PHP. 3.3 ESPECIFICAÇÃO A especificação deste trabalho foi desenvolvida utilizando diagramas da UML aliados ao MER. Os casos de uso são apresentados através de um diagrama de casos de uso, seguido da descrição do cenário de cada caso de uso. Em seguida, as classes da aplicação cliente e do servidor são apresentadas através de diagramas de classes. Como forma de facilitar a implementação, dois casos de uso foram representados através de diagramas de sequência. Complementando a especificação, as entidades dos bancos de dados do cliente e do servidor são demonstradas através de diagramas MER, que não pertencem ao conjunto de diagramas da UML. A ferramenta utilizada para desenvolvimento dos diagramas da UML foi a Umbrello UML Modeller versão para GNU/Linux. O diagrama MER foi desenvolvido utilizando a ferramenta DB Designer na versão Beta para GNU/Linux Casos de uso A partir da elicitação dos requisitos da aplicação, foram desenvolvidos nove casos de uso. Esses casos de uso objetivam organizar os requisitos em funcionalidades que possam ser executadas de forma simples pelo usuário. Os casos de uso desenvolvidos são desempenhados por três atores. O ator Usuário representa o utilizador do sistema, sendo capaz de interagir através dos casos de uso que apresentam interfaces gráficas. O ator Cliente representa o aplicativo cliente, que interage através de serviços que rodam em segundo plano e não apresentam interface gráfica. O ator Servidor representa o aplicativo servidor, responsável por manter o banco de dados principal e disponibilizar os dados conforme solicitado pelo aplicativo cliente. O diagrama de casos de uso foi desenvolvido observando os padrões da UML. Cada caso de uso foi detalhado em cenários e vinculado a, pelo menos, um RF. Essa vinculação

29 28 objetiva facilitar a identificação do propósito do caso de uso e justificar sua existência. A Figura 4 contém o diagrama de casos de uso. Figura 4 Diagrama de casos de uso

30 Efetuar login no Facebook Deve ser efetuado login no Facebook para permitir o registro de ocorrências e postagem das informações no mural do grupo TCC Carlos Souza no Facebook. O caso de uso Efetuar login no Facebook tem o objetivo de autenticar o usuário através de seu usuário e senha do serviço Facebook. O Quadro 1 contém os cenários do caso de uso Efetuar login no Facebook. UC01. Efetuar login no Facebook: Possibilita ao usuário efetuar login no Facebook e o autoriza a registrar ocorrências. Requisitos atendidos RF05. Para o usuário efetuar login no Facebook, o dispositivo deve estar Pré-condições conectado a internet. 1) o sistema exibe a tela principal com mapa, informações de ocorrências e das estações, botão atualizar, botão relatar ocorrência inativo, botão do zoom para sua localização atual e botão do Facebook, Cenário principal 2) o usuário clica no botão Connect, 3) o sistema abre uma janela solicitando nome de usuário e senha, 4) o usuário digita usuário e senha e clica em login, 5) o sistema conecta-se com o servidor do Facebook solicitando autenticação, enquanto isso exibe mensagem de espera. No passo 5, caso os dados sejam incorretos: Fluxo alternativo 01 1) exibe a tela inicial do sistema. No passo 5, caso seja o primeiro login deste usuário no aplicativo: 1) o sistema exibe janela solicitando permissão ao usuário para Fluxo alternativo 02 instalar o aplicativo TCC Carlos Souza em sua conta no serviço Facebook, 2) o usuário clica em permitir. Dados da autenticação no Facebook armazenado por componentes Pós-condições do framework. Botão para relatar ocorrência torna-se ativo. Quadro 1 Caso de uso Efetuar login no Facebook Visualizar histórico recente da estação O caso de uso Visualizar histórico recente da estação apresenta os detalhes de como o usuário tem acesso a essa informação, que ocorre através de uma janela que abre sobre o mapa próximo a localização da estação, com o objetivo de facilitar o acesso. O Quadro 2 contém os cenários do caso de uso Visualizar histórico recente da estação.

31 30 UC02. Visualizar histórico recente da estação: Permite ao usuário visualizar os dez registros mais recentes da estação. Requisitos atendidos RF01, RF02. O sistema deve ter registros das estações gravadas na base de Pré-condições dados do aplicativo cliente. 1) o sistema exibe a tela principal exibindo no mapa as estações dos registros que estão em sua base de dados, 2) o usuário clica na estação que deseja consultar os registros, 3) o sistema abre uma janela informando o nome da estação, data e Cenário principal hora do registro mais recente e um botão de histórico, 4) o usuário clica no botão de histórico, 5) o sistema abre nova tela com o histórico com os dez registros mais recentes da estação selecionada. Histórico dos dez registros mais recentes da estação exibidos em Pós-condições ordem do mais recente ao mais antigo. Quadro 2 Caso de uso Visualizar histórico recente da estação Visualizar últimas ocorrências O caso de uso Visualizar últimas ocorrências apresenta os detalhes de como o usuário tem acesso a essa informação, que ocorre através de uma janela que abre sobre o mapa próximo a localização da ocorrência, com o objetivo de facilitar o acesso. O Quadro 3 contém os cenários do caso de uso Visualizar últimas ocorrências. UC03. Visualizar últimas ocorrências: Permite ao usuário visualizar as cinquenta ocorrências mais recentes. Requisitos atendidos RF03. O sistema deve ter ocorrências gravadas na base de dados do Pré-condições aplicativo cliente. 1) o sistema exibe a tela principal com mapa exibindo as Cenário principal ocorrências que estão em sua base de dados. No passo 1, o usuário clica na ocorrência: 1) o sistema abre uma janela informando data, hora e o nome do usuário que registrou a ocorrência, Fluxo alternativo 01 2) o usuário clica no botão de informações, 3) o sistema abre nova tela com a foto e informações da ocorrência. Pós-condições Tela com informações da ocorrência exibida ao usuário. Quadro 3 Caso de uso Visualizar últimas ocorrências

32 Relatar ocorrência Para o usuário relatar uma ocorrência, ele deve estar autenticado ao Facebook. Dessa forma, os dados por ele informados ao sistema serão compartilhados no grupo TCC Carlos Souza no Facebook. O Quadro 4 contém os cenários do caso de uso Relatar ocorrência.

33 32 UC04. Relatar ocorrência: Possibilita ao usuário relatar ocorrência Requisitos atendidos RF04. Usuário está logado no Facebook e faz parte do grupo TCC Carlos Pré-condições Souza, imagem da ocorrência está na galeria de imagens do dispositivo e o mesmo está conectado a internet. 1) o sistema exibe a tela principal com mapa, informações de ocorrências e das estações, botão atualizar, botão relatar ocorrência ativo, botão do zoom para sua localização atual e botão do Facebook, 2) o usuário clica no botão de relatar ocorrência, 3) o sistema atualiza os dados de geolocalização e, em seguida, abre uma janela solicitando a descrição da ocorrência, 4) o usuário digita a descrição e clica em Ok, Cenário principal 5) o sistema abre a galeria de imagem para o usuário selecionar a foto relacionada a ocorrência, 6) o usuário clica sobre a foto desejada, 7) o sistema publica dados de geolocalização, descrição e foto da ocorrência no grupo TCC Carlos Souza no Facebook, 8) o sistema recebe retorno do Facebook confirmando postagem, 9) o sistema recupera informações do post no Facebook, 10) o sistema envia para o servidor os dados da ocorrência, 11) o sistema recebe retorno do servidor confirmando registro. No passo 4, o usuário clica em Cancelar: Fluxo alternativo 01 1) o sistema retorna para a tela inicial. No passo 5, o usuário clica em Voltar: Fluxo alternativo 02 1) o sistema retorna para a tela inicial. No passo 8, o sistema recebe retorno do Facebook informando que ocorreu um erro na postagem: 1) o sistema exibe mensagem de erro ocorrido ao registrar a Fluxo alternativo 03 ocorrência, 2) o usuário clica em Ok, 3) o sistema retorna para a tela inicial. No passo 9, o sistema recebe erro no retorno do Facebook: 1) o sistema exibe mensagem de erro ocorrido ao registrar a Fluxo alternativo 04 ocorrência, 2) o usuário clica em Ok, 3) o sistema retorna para a tela inicial. No passo 11, o sistema recebe erro no retorno do servidor: 1) o sistema exibe mensagem de erro ocorrido ao registrar a Fluxo alternativo 05 ocorrência, 2) o usuário clica em Ok, 3) o sistema retorna para a tela inicial. Ocorrência registrada no servidor e informações publicadas no Pós-condições grupo TCC Carlos Souza no Facebook. Quadro 4 Caso de uso Relatar ocorrência

34 Visualizar localização atual O caso de uso Visualizar localização atual apresenta os detalhes de como o usuário tem acesso a essa informação, que é exibida na tela inicial, com um ponto destacado no mapa. O Quadro 5 contém os cenários do caso de uso Visualizar localização atual. UC05. Visualizar localização atual: Permite ao usuário visualizar sua localização atual no mapa. Requisitos atendidos RF03. Pré-condições Os serviços de localização devem estar ativados no dispositivo. 1) o sistema exibe a tela principal com mapa, informações de ocorrências e das estações, botão atualizar, botão relatar ocorrência, botão do zoom para sua localização atual e botão do Cenário principal Facebook, 2) o usuário clica no botão de zoom para sua localização atual, 3) o sistema centraliza o mapa na localização atual, aplica zoom, e adiciona um marcador destacando a localização atual. No passo 3, o sistema encontra um erro em obter a localização atual: Fluxo alternativo 01 1) o sistema utiliza as coordenadas de Blumenau SC, 2) o sistema exibe mensagem de erro ao obter localização para o usuário. Mapa centralizado na localização atual, com zoom próximo do Pós-condições marcador que informa a localização. Quadro 5 Caso de uso Visualizar localização atual Atualizar base local de registros das estações O caso de uso Atualizar base local de registros das estações apresenta os detalhes de como o sistema atualiza sua base local de registros das estações. O Quadro 6 contém os cenários do caso de uso Atualizar base local de registros das estações.

35 34 UC06. Atualizar base local de registros das estações: Define como o sistema deve atualizar os registros das estações em sua base de dados local. Requisitos atendidos RF01, RF02, RF06, RF08. Pré-condições O dispositivo está conectado a internet. 1) o sistema conecta ao servidor via webservice e solicita os dez registros mais recentes de cada estação, Cenário principal 2) o servidor retorna arquivo formato JavaScript Object Notation (JSON) com os registros solicitados, 3) o sistema atualiza a base de dados local. No passo 2, o servidor retorna erro: Exceção 01 1) encerra o caso de uso. Pós-condições Base de dados local de registros das estações atualizada. Quadro 6 Caso de uso Atualizar base local de registros das estações Atualizar base local de ocorrências O caso de uso Atualizar base local de ocorrências apresenta os detalhes de como o sistema atualiza sua base local de registros de ocorrências. O Quadro 7 contém os cenários do caso de uso Atualizar base local de ocorrências. UC07. Atualizar base local de ocorrências: Define como o sistema deve atualizar os registros de ocorrências em sua base de dados local Requisitos atendidos RF03, RF06, RF10. Pré-condições O dispositivo está conectado a internet. 1) o sistema conecta ao servidor via webservice e solicita as cinquenta ocorrências mais recentes cadastradas, Cenário principal 2) o servidor retorna arquivo JSON com as ocorrências, 3) o sistema atualiza a base de dados local. No passo 2, o servidor retorna erro: Exceção 01 1) encerra o caso de uso. Pós-condições Base de dados local de ocorrências atualizada. Quadro 7 Caso de uso Atualizar base local de ocorrências Recuperar registros recentes das estações do sistema de alerta Para disponibilizar as informações necessárias ao aplicativo cliente, o aplicativo servidor deve coletar os registros do sistema de alerta periodicamente. O caso de uso Recuperar registros recentes das estações do sistema de alerta apresenta os detalhes de como o servidor atualiza sua base de dados com os registros mais recentes das estações. O Quadro 8 contém os cenários do caso de uso Recuperar registros recentes

36 35 das estações do sistema de alerta. UC08. Recuperar registros recentes das estações do sistema de alerta: Define como o servidor deve atualizar sua base de dados periodicamente com os registros mais recentes disponibilizados pelo sistema de alerta. Requisitos atendidos RF07. Pré-condições Nenhuma. 1) o servidor conecta ao servidor do sistema de alerta via webservice e solicita os registros das estações, 2) o servidor do sistema de alerta retorna arquivo JSON com os Cenário principal registros, 3) o servidor atualiza grava em sua base de dados os registros coletados. No passo 2, a comunicação com o servidor retorna erro: Exceção 01 1) encerra o caso de uso. Pós-condições Base de dados de registros das estações no servidor atualizada. Quadro 8 Caso de uso Recuperar registros recentes das estações do sistema de alerta Cadastrar nova ocorrência As ocorrências informadas pelos usuários, além de serem compartilhadas no Facebook, também são armazenadas em base de dados do servidor, para disponibilizar as informações necessárias para o aplicativo cliente exibir essa informação ao usuário. O caso de uso Cadastrar nova ocorrência apresenta os detalhes de como o servidor cadastra uma nova ocorrência em sua base de dados. O Quadro 9 contém os cenários do caso de uso Cadastrar nova ocorrência. UC09. Cadastrar nova ocorrência: Define como o servidor deve efetuar o cadastro de uma nova ocorrência que foi informada por um usuário através de comunicação do aplicativo cliente com o servidor via webservice. Requisitos atendidos RF09. Pré-condições Receber dados para cadastro da ocorrência via webservice. 1) o servidor recebe conexão via webservice com informações de nova ocorrência, 2) o servidor verifica se os dados informados são válidos, Cenário principal 3) o servidor grava a nova ocorrência em base de dados própria, 4) o servidor informa o aplicativo cliente do sucesso no cadastro da ocorrência via arquivo JSON. No passo 2, os dados recebidos pelo servidor não são válidos: 1) o servidor informa o aplicativo cliente do não sucesso no Exceção 01 cadastro da ocorrência via arquivo JSON, 2) encerra o caso de uso. Pós-condições Ocorrência registrada no banco de dados do servidor. Quadro 9 Caso de uso Cadastrar nova ocorrência

37 Classes do aplicativo cliente Partindo da definição dos componentes do aplicativo cliente, os mesmos foram organizados em pacotes e classes, de acordo com orientação da documentação do framework Titanium, proximidade das funções e dos tipos de componentes. Os pacotes são definidos através da variável App, que é uma variável global da aplicação que armazena as referências para as classes, entre outras propriedades do aplicativo. Os arquivos das classes são armazenados em diretórios específicos para cada pacote dentro do diretório raiz Resources Pacote App.API O pacote App.API contém as classes que gerenciam os recursos de acesso ao banco de dados local e ao recurso de geolocalização do dispositivo. Os arquivos das classes estão armazenados no diretório Resources/api. A Figura 5 contém o diagrama de classes do pacote App.API. Figura 5 Diagrama de classes do pacote App.API A classe App.API.Geolocalizacao é responsável por acessar o recurso de geolocalização do dispositivo. Possui apenas o método atualizar(), que recupera a informação de latitude e longitude atual do dispositivo através da biblioteca

38 37 Titanium.Geolocation. Essas informações são armazenadas na lista App.localizacao através de dois índices, latitude e longitude. A variável App.localizacao está em escopo global no aplicativo. A classe App.API.Ocorrencia gerencia as conexões para acessar e persistir dados do tipo App.Models.Ocorrencia. O método atualizar_registros() recupera objetos do tipo App.Models.Ocorrencia do servidor via webservice e persiste em banco de dados local. O método select_ultimos() retorna uma lista com todos os registros de ocorrência que estão armazenados na base de dados local. A classe App.API.Registro_Movel gerencia as conexões para acessar e persistir dados do tipo App.Models.Registro_Movel. O método atualizar_registros() recupera objetos do tipo App.Models.Registro_Movel do servidor via webservice e persiste em banco de dados local. O método select_estacao(int) retorna uma lista com todos os registros da estação com o código recebido como parâmetro que estão armazenados na base de dados local. O método select_ultimos() retorna uma lista com todos os registros das estações que estão armazenados na base de dados local Pacote App.Controllers O pacote App.Controllers contém a classe App.Controllers.Controlador que atua como classe controladora do aplicativo no modelo MVC. Essa classe armazena a instância do objeto da tela principal e organiza as funções para atualizar os dados aplicativo e cadastrar novas ocorrências. O arquivo da classe está armazenado no diretório Resources/controllers. A Figura 6 contém o diagrama de classes do pacote App.Controllers. A classe App.Controllers.Controlador gerencia a execução do aplicativo. A classe possui como atributos uma referência para cada classe do pacote App.API, além do objeto que representa a tela inicial do aplicativo. O método iniciar() é executado no início da execução da aplicação. Esse método inicializa os componentes necessários para exibir a tela principal ao usuário. O método registrar_ocorrencia(titanium.blob,string) faz o registro de uma nova ocorrência, quando solicitado pelo usuário. O método atualizar() executa os métodos atualizar_dados() e atualizar_geolocalizacao(). O método atualizar_dados() faz chamadas a métodos dos objetos do pacote App.API responsáveis

39 38 por atualizar a base de dados local. O método atualizar_geolocalizacao() faz chamada ao método atualizar() do objeto da classe App.API.Geolocalizacao, já descrito anteriormente. O método habilitar_relatar_ocorrencia() habilita a funcionalidade da tela principal que permite ao usuário relatar nova ocorrência. O método desabilitar_relatar_ocorrencia() desabilita essa funcionalidade. A execução do aplicativo cria apenas uma instância da classe App.Controllers.Controlador, que fica armazenado em escopo global na variável App.controlador. Figura 6 Diagrama de classes do pacote App.Controllers Pacote App.Models O pacote App.Models contém as classes que definem os modelos de objetos utilizados na aplicação e funções que agem sobre os mesmos. Os arquivos das classes desse pacote estão armazenados no diretório Resources/models. A Figura 7 contém o diagrama de classes do pacote App.Models. A classe App.Models.Registro_Movel representa a declaração de um objeto que armazena as informações de um registro realizado por uma estação do sistema de alerta. A classe App.Models.Ocorrencia representa a declaração de um objeto que armazena as informações de um registro de ocorrência realizado por um usuário. A classe App.Models.Data representa a declaração de um objeto que armazena as informações de uma data. O método to_string() dessa classe retorna a data em formato adequado para leitura pelo usuário.

40 39 Figura 7 Diagrama de classes do pacote App.Models Pacote App.UI O pacote App.UI contém as classes que representam os elementos gráficos que interagem com o usuário. Essas classes contêm instâncias de objetos do pacote Modelo e inicializam através de eventos, algumas rotinas implementadas na classe App.Controllers.Controlador. Os arquivos das classes estão armazenados no diretório Resources/ui. A Figura 8 contém o diagrama de classes do pacote App.UI. Figura 8 Diagrama de classes do pacote App.UI A classe App.UI.Mapa representa a declaração de um objeto que define a tela principal do aplicativo. Os atributos desse objeto consistem em componentes gráficos que interagem com o usuário, além de duas instâncias para classes do pacote App.API, que são utilizadas para acesso às informações que são exibidas ao usuário na tela principal. O método

41 40 iniciar() é executado na instanciação do objeto, e adiciona os componentes gráficos na tela principal. O método carregar_mapa() insere no mapa marcadores com as informações sobre o registro mais recente de cada estação do sistema de alerta. O método carregar_ocorrencias() insere no mapa marcadores com as informações das cinquenta ocorrências registradas mais recentemente. O método posicao_atual(double) aplica o nível de zoom recebido como parâmetro e centraliza o mapa na posição geográfica indicada pela variável App.localizacao. O método habilitar_relatar_ocorrencia() habilita o componente botao_ocorrencia. O método desabilitar_relatar_ocorrencia() desabilita esse mesmo componente. A classe App.UI.Atividade representa a declaração de um objeto gráfico no formato de uma janela, utilizado para indicar ao usuário que o aplicativo está processando alguma solicitação, e que deve ser aguardado alguns instantes. Os atributos desta classe armazenam objetos gráficos nativos do framework Titanium. O atributo activityindicator referencia um objeto do tipo Ti.UI.ActivityIndicator e o atributo win_ios do tipo Ti.UI.Window. Os métodos abrir() e fechar() da classe App.UI.Atividade executam instruções para abrir e fechar a janela de aviso ao usuário. A classe App.UI.Ocorrencia representa a declaração de um objeto gráfico no formato de uma janela, que é exibida quando o usuário deseja realizar o registro de uma ocorrência. Os atributos dessa classe consistem em componentes gráficos que integram a janela que representa. A classe App.UI.Ocorrencia_infos representa a declaração de um objeto gráfico utilizado para exibir as informações básicas de uma ocorrência, quando o usuário clica no marcador correspondente no mapa da tela inicial do aplicativo. Os atributos dessa classe são componentes gráficos e informações utilizadas na composição de seu leiaute, além do objeto do tipo Ti.Map.Annotation que representa o marcador no mapa. A classe App.UI.Ocorrencia_win representa a declaração de um objeto gráfico no formato de uma janela, que é utilizada para exibir ao usuário as informações sobre uma determinada ocorrência. Os atributos dessa classe são componentes gráficos e informações utilizadas na composição de seu leiaute. O método construtor da classe App.UI.Ocorrencia_win recebe como parâmetro um objeto do tipo App.Models.Ocorrencia, que fornece os dados que são informados ao usuário. A classe App.UI.Registro_infos representa a declaração de um objeto gráfico utilizado para exibir as informações básicas da estação, quando o usuário clica no marcador

42 41 correspondente no mapa da tela inicial do aplicativo. Os atributos dessa classe são componentes gráficos e informações utilizadas na composição de seu leiaute, além do objeto do tipo Ti.Map.Annotation que representa o marcador no mapa. A classe App.UI.Registro_win representa a declaração de um objeto gráfico no formato de uma janela, que é utilizada para exibir ao usuário as informações sobre os registros mais recentes de uma determinada estação. Os atributos dessa classe são componentes gráficos e informações utilizadas na composição de seu leiaute. O método construtor da classe App.UI.Registro_win recebe como parâmetro um objeto do tipo App.Models.Registro_Movel, que fornece os dados que são informados ao usuário Classes do servidor Partindo da definição dos objetos deste trabalho, o servidor foi desenvolvido com o propósito de suprir as necessidades apresentadas no aplicativo cliente. Cada serviço necessário no servidor é implementado por scripts que operam como webservices, que processam as requisições recebidas via HyperText Transfer Protocol (HTTP) e efetuam retorno em formato JSON. A Figura 9 apresenta o diagrama de classes do servidor. A classe Registro representa um objeto que armazena as informações referentes ao registro de uma estação do sistema de alerta. A classe Registro_Movel representa o objeto de um registro de uma estação composto somente pelas informações que são necessárias para a aplicação cliente. A classe Ocorrencia representa o objeto com as informações de uma ocorrência relatada por um usuário. A classe PDOConnectionFactory é responsável por estabelecer a conexão com o banco de dados, e disponibilizar essa conexão para as classes que a estende. A classe RegistroDAO estende de PDOConnectionFactory e é responsável pela persistência de objetos do tipo Registro. Essa classe possui apenas o método insert(registro) que armazena um objeto do tipo Registro no banco de dados. A classe OcorrenciaDAO estende de PDOConnectionFactory e é responsável pela persistência de objetos do tipo Ocorrencia. O método insert(ocorrencia) armazena o objeto do tipo Ocorrencia no banco de dados. O método select_ultimos() retorna uma lista com os cinquenta registros de ocorrências mais recentes. A classe Registro_MovelDAO estende de PDOConnectionFactory e é responsável pela persistência de objetos do tipo Registro_Movel. O método select_ultimos() retorna uma lista com os dez últimos

43 42 registros de cada estação do sistema de alerta. Figura 9 Diagrama de classes do servidor

44 Diagramas de sequências Os diagramas de sequência tem como finalidade demonstrar a troca de mensagem entre as classes criadas, facilitando a implementação dos casos de uso. Nesta seção são apresentados os diagramas de sequência para os casos de uso Atualizar base local de registros das estações (UC06) e Relatar ocorrência (UC04) Diagrama de sequência atualizar base local de registros das estações O caso de uso Atualizar base local de registros das estações (UC06) parte da chamada do aplicativo cliente ao método atualizar_dados() da classe App.Controllers.Controlador, que por sua vez efetua uma chamada ao método atualizar_registros() da classe App.API.Registro_Movel. Esse método cria um objeto do tipo Titanium.Network.HTTPClient, que acessa o webservice do servidor e retorna os registros em formato App.Models.Registro_Movel. Esses registros são inseridos na base de dados local pelo módulo Titanium.Database. A Figura 10 apresenta o diagrama de sequência do caso de uso Atualizar base local de registros das estações (UC06).

45 Figura 10 Diagrama de sequência Atualizar base local de registros das estações 44

46 Diagrama de sequência relatar ocorrência O caso de uso Relatar ocorrência (UC04) parte do clique do usuário no botão correspondente a relatar ocorrência na tela principal do aplicativo e em seguida uma janela é exibida solicitando a descrição da ocorrência. Após clicar no botão Ok, a galeria de imagens do dispositivo abre para o usuário selecionar uma foto para a ocorrência. Isso é realizado pelo método Ti.Media.openPhotoGallery(). Após a seleção da foto, o aplicativo exibe uma nova janela que indica que está processando o registro da ocorrência. Durante o registro da ocorrência, o aplicativo envia os dados para postagem no Facebook, através do método Ti.Facebook.requestWithGraphPath(String,Array,String,function). Em seguida, através de nova chamada ao mesmo método anterior, o aplicativo recupera as informações da postagem no Facebook, para então enviar os dados da ocorrência ao servidor, através do objeto do tipo Titanium.Network.HTTPClient. Ao fim, é exibido um aviso informando ao usuário o sucesso ou o não sucesso ao efetuar o registro da ocorrência. A Figura 11 apresenta o diagrama de sequência do caso de uso Relatar ocorrência (UC04).

47 Figura 11 Diagrama de sequência Relatar ocorrência 46

48 Banco de dados As informações básicas do sistema foram persistidas em bancos de dados no cliente e no servidor. O aplicativo cliente utiliza bibliotecas do framework Titanium para criar e manipular um banco de dados SQLite, que está disponível tanto na plataforma Android quanto na ios. Esse banco é armazenado no dispositivo móvel na área de memória dedicada ao armazenamento de arquivos da aplicação. Dessa forma, as informações não podem ser acessadas por outro aplicativo sendo executado no dispositivo. A Figura 12 apresenta o MER do banco de dados criado no aplicativo cliente. Figura 12 MER do aplicativo cliente A tabela Registro_Movel contém as informações dos registros das estações do sistema de alerta. Essa tabela é atualizada toda vez que o aplicativo cliente solicita os dados atualizados do servidor. As informações contidas nessa tabela são persistidas e recuperadas pela classe App.API.Registro_Movel, que é responsável em converter as informações de um objeto do tipo App.Models.Registro_Movel em informações a serem persistidas e efetuar o processo contrário, conforme necessidade. A tabela Ocorrencia contém os registros de ocorrências efetuados pelos usuários. Essa tabela é atualizada toda vez que o aplicativo cliente solicita os dados atualizados do servidor. As informações contidas nessa tabela são persistidas e recuperadas pela classe App.API.Ocorrencia que é responsável em converter as informações de um objeto do tipo App.Models.Ocorrencia em informações a serem persistidas e efetuar o processo contrário, conforme necessidade. O servidor utiliza um banco de dados MySQL para persistir e recuperar as informações relativas aos registros das estações do sistema de alerta e das ocorrências registradas pelos usuários. A Figura 13 contém o MER do banco de dados do aplicativo servidor.

49 48 Figura 13 MER do aplicativo servidor A tabela Registro contém todas as informações dos registros das estações recuperadas do sistema de alerta. Essa tabela é acessada por duas classes. A classe RegistroDAO é responsável por converter objetos do tipo Registro para informações a serem persistidas. Os atributos da classe Registro são correspondentes em número e nome aos campos da tabela Registro. A outra classe que acessa essa tabela é a classe Registro_MovelDAO, que é responsável por converter as informações persistidas na tabela Registro para objetos do tipo Registro_Movel. Esse tipo de objeto contém apenas as informações relevantes para o aplicativo cliente. A tabela Ocorrencia contém as informações de todas as ocorrências registradas pelos usuários. As informações contidas nessa tabela são persistidas e recuperadas pela classe OcorrenciaDAO que é responsável em converter as informações de um objeto do tipo Ocorrencia em informações a serem persistidas e efetuar o processo contrário, conforme necessidade. Os atributos da classe Ocorrencia são correspondentes em número e nome aos campos da tabela Ocorrencia. 3.4 IMPLEMENTAÇÃO A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da

50 49 implementação Técnicas e ferramentas utilizadas A implementação do sistema proposto foi efetuada em duas partes de forma paralela. As funcionalidades propostas foram desenvolvidas em um aplicativo cliente, a ser executado nas plataformas Android e ios. Para atender algumas das funcionalidades propostas no aplicativo cliente foi desenvolvido um segundo aplicativo que atende como servidor. Para a implementação da aplicação cliente foi utilizada a linguagem de programação JavaScript no ambiente de desenvolvimento Titanium Studio, versão 2.1.2, que consiste em uma camada de plugins e empacotadores que juntamente com o Aptana Studio trabalham sobre o core do Eclipse versão Combinado a esse ambiente o Titanium SDK, versão GA. As camadas desse ambiente podem ser visualizadas na Figura 14. Fonte: Appcelerator (2012b). Figura 14 Camadas do ambiente de desenvolvimento

51 50 A Figura 15 apresenta o fluxo de desenvolvimento utilizando o Titanium Studio. A implementação pode ser realizada em JavaScript ou HTML sobre o Titanium SDK, que gera código objeto para as plataformas ios, Android e aplicações web em HTML5 para diversos dispositivos. Fonte: Appcelerator (2012c). Figura 15 Fluxo de desenvolvimento no Titanium Studio Para deploy à plataforma Android, foi utilizado o Android SDK, versão para GNU/Linux. Esse ambiente foi executado sobre o Java Development Kit (JDK) versão 1.7.0_75 de 64 bits, para GNU/Linux Fedora, versão 17 (Beefy Miracle). Para deploy à plataforma ios, foi utilizado o Xcode SDK, versão 5.1. Esse ambiente foi executado no SO ios 5.1. Os testes do aplicativo cliente na plataforma Android foram realizados em dispositivos com as versões 2.3 e 4.0 além do emulador do Android SDK nas versões 2.1 e 2.2. Os testes na plataforma ios foram realizados em dispositivo ipad2 64GB com ios versão instalado, além dos emuladores do Xcode de iphone e ipad com o ios versão 5.1. Para integrar o Integrated Development Environment (IDE) Eclipse ao Android SDK foi utilizado o plugin Android Development Tools (ADT). O servidor foi desenvolvido na linguagem de programação PHP, através de ambiente de desenvolvimento Eclipse, versão (Juno). Como servidor de aplicação foi utilizado o

52 51 servidor Apache HTTP Server, versão 2.0 para GNU/Linux CentOS, versão 5.6, plataforma i686. A persistência das informações é efetuada através de um servidor MySQL, versão de 64 bits para GNU/Linux. O acesso ao servidor é efetuado através do driver PDO para MySQL, versão Os testes do aplicativo servidor foram realizados através do navegador de internet Mozilla Firefox, versão para GNU/Linux Fedora, versão 17 com 64 bits Arquivo tiapp.xml O arquivo tiapp.xml é um arquivo no formato extensible Markup Language (XML), que contém informações para configuração básicas das aplicações desenvolvidas. Algumas informações são obrigatórias e existem em todas as aplicações, como a versão do Titanium SDK que será utilizada, o código da versão e as plataformas que serão utilizadas no projeto. Além dessas, outras são opcionais e existem conforme as necessidades de cada aplicação. Para o correto funcionamento da aplicação cliente, foram necessárias definições de permissões e bibliotecas utilizadas. O Quadro 10 apresenta o primeiro trecho do arquivo tiapp.xml. <?xml version="1.0" encoding="utf-8"?> <ti:app xmlns:ti="http://ti.appcelerator.org"> <property name="ti.ui.defaultunit" type="string">dip</property> <property name="ti.facebook.appid"> </property> <deployment-targets> <target device="android">true</target> <target device="iphone">true</target> <target device="ipad">true</target> <target device="mobileweb">false</target> <target device="blackberry">false</target> </deployment-targets> <sdk-version>2.1.3.ga</sdk-version> <id>br.furb.carlossouza.tcc</id> <name>tcc</name> <icon>icone.png</icon> Quadro 10 Primeiro trecho do arquivo tiapp.xml A tag <property name="ti.ui.defaultunit" type="string">dip</property> define que Titanium.UI.UNIT_DIP é a unidade de medida padrão para os componentes gráficos, eliminando a necessidade de se especificar sempre que definir propriedades de tamanho e distância, por exemplo. A tag <property name="ti.facebook.appid"> </property> indica o id do aplicativo do Facebook intitulado TCC Carlos Souza, que é responsável por postar as informações enviadas

53 52 pelo usuário. As tags inseridas na seção identificada pela tag <deployment-targets> correspondem às plataformas suportadas pelo framework, e atribui valor true às que são utilizadas neste projeto. A tag <sdk-version>2.1.3.ga</sdk-version> define que a versão do framework utilizada neste projeto é a GA. A tag <id>br.furb.carlossouza.tcc</id> indica o id da aplicação, informação que será utilizada pelas plataformas para gerenciamento do aplicativo. A tag <name>tcc</name> define o nome do aplicativo que, entre outros locais, será exibido junto ao ícone da aplicação no menu do dispositivo. A tag <icon>icone.png</icon> indica o arquivo de ícone para representar o aplicativo no menu do dispositivo Organização dos arquivos do projeto O Titanium Studio possui um padrão para armazenamento dos arquivos do projeto organizando-os em diretórios, formando uma hierarquia, conforme visualizado na Figura 16. Figura 16 Organização dos arquivos do projeto

54 53 O diretório Resources armazena todos os arquivos JavaScript, e dentro dele são criados diretórios específicos para cada plataforma utilizada no projeto, android e iphone. Nesses diretórios, são armazenados arquivos correspondentes a componentes específicos utilizados em cada plataforma. Os outros diretórios contêm os componentes principais do programa. O diretório api contém arquivos de classes utilizadas para acesso a recursos do dispositivo. O diretório controllers é designado para guardar a classe App.Controllers.Controlador, que é a controladora da aplicação. O diretório images contém imagens utilizadas na interface gráfica do aplicativo. O diretório lib contém arquivos que definem os parâmetros iniciais e funções globais da aplicação. O diretório models contém os arquivos das classes que representam os modelos dos objetos do programa. O diretório ui contém os arquivos das classes que representam os objetos de interface gráfica. O arquivo app.js é o arquivo principal da aplicação, é o primeiro a executar e é responsável por iniciar os componentes necessários para a execução do programa Persistência no aplicativo cliente No aplicativo cliente a persistência de dados é implementada na forma de registros de um banco de dados. O banco de dados é acessado e gerenciado através de bibliotecas do framework Titanium. Essas bibliotecas acessam uma base de dados SQLite local. O Quadro 11 apresenta um trecho do código fonte da classe App.API.Registro_Movel em que o banco de dados local é inicializado. var nome_db = 'tcc'; // Inicializa banco de dados local. var db = Ti.Database.open(nome_db); // Cria tabela Registro_Movel caso não exista. db.execute('create TABLE IF NOT EXISTS Registro_Movel(cd_registro INTEGER, dt_registro TEXT, cd_estacao INTEGER, ds_estacao TEXT, dt_leitura TEXT, vlr_nivel REAL, vlr_precipitacao REAL, ds_status TEXT, nr_latitude REAL, nr_longitude REAL)'); // Fecha a conexão com o banco de dados. db.close(); Quadro 11 Inicialização do banco de dados do aplicativo cliente na classe App.API.Registro_Movel Através do método Ti.Database.open(String), o banco de dados local é lido ou criado. Uma referência para a base de dados tcc é armazenada na variável db, que passa a ser um objeto do tipo Titanium.Database.DB. Em seguida, é executado o método

55 54 execute(string) do objeto db, que executa um comando Structured Query Language (SQL) na base de dados. Este comando cria a tabela Registro_Movel, caso não existir. Ao final, a conexão com a base de dados é encerrada através do método close(). A persistência e recuperação de informações também são efetuadas via bibliotecas do framework Titanium. O Quadro 12 demonstra a recuperação de informações através de um trecho de código do método select_ultimos() da classe App.API.Ocorrencia. // Conecta com a base local. db = Ti.Database.open(nome_db); // Executa SELECT na base local. var retornobd = db.execute('select * FROM Ocorrencia ORDER BY cd_ocorrencia DESC'); // Percorre retorno extraindo os registros de Ocorrência. while (retornobd.isvalidrow()) { // Cria Ocorrencia e seta os atributos. var ocorrencia = new App.Models.Ocorrencia(); ocorrencia.cd_ocorrencia = retornobd.fieldbyname('cd_ocorrencia'); ocorrencia.cd_usuario_fb = retornobd.fieldbyname('cd_usuario_fb'); ocorrencia.nm_usuario_fb = retornobd.fieldbyname('nm_usuario_fb'); ocorrencia.ds_ocorrencia = retornobd.fieldbyname('ds_ocorrencia'); ocorrencia.nr_latitude = retornobd.fieldbyname('nr_latitude'); ocorrencia.nr_longitude = retornobd.fieldbyname('nr_longitude'); ocorrencia.cd_post_fb = retornobd.fieldbyname('cd_post_fb'); ocorrencia.ds_url_img = retornobd.fieldbyname('ds_url_img'); ocorrencia.dt_ocorrencia = retornobd.fieldbyname('dt_ocorrencia'); //... } // Retorna o próximo registro. retornobd.next(); // Fecha conexão com base de dados. retornobd.close(); db.close(); Quadro 12 Trecho do método select_ultimos() da classe App.API.Ocorrencia em que as informações são recuperadas Inicialmente é estabelecida uma conexão com o banco de dados tcc através da chamada ao método open(string). A referência para a base de dados é armazenada na variável bd. Em seguida, é executado um comando SQL que retorna todos os registros da tabela Ocorrencia em um objeto do tipo Titanium.Database.ResultSet, e o armazena na variável retornobd. Esse objeto consiste em uma lista de registros. Através de um laço de repetição, a lista é percorrida e, em cada iteração, é criado um objeto do tipo App.Models.Ocorrencia. Os atributos deste objeto recebem os valores correspondentes do registro do banco de dados. Concluído o processamento do registro atual, o próximo é recuperado através da chamada ao método next() do objeto retornobd. Ao término do laço

56 55 de repetição sobre o objeto retornobd, este objeto é encerrado através da chamada ao método close(). Em seguida, a conexão com a base de dados também é encerrada através da chamada do método close() Comunicação do aplicativo cliente com o aplicativo servidor A comunicação com o servidor é efetuada através de requisições POST, no padrão multipart. As requisições recebem como resposta arquivos JSON contendo as informações solicitadas. O Quadro 13 apresenta um trecho do código fonte do método atualizar_registros() da classe App.API.Registro_Movel que representa como é estabelecida a comunicação com o servidor. Através do método Ti.Network.createHTTPClient(Dictionary<Titanium.Network.HTTPClient>), instanciado um novo objeto do tipo Titanium.Network.HTTPClient, responsável por criar um cliente HTTP. Este método recebe duas funções e um valor do tipo int como parâmetros. A função definida no parâmetro onload é executada quando há sucesso na conexão, ou seja, quando há retorno válido do servidor. A função definida no parâmetro onerror é executada quando há algum erro ao recuperar o retorno do servidor. O valor definido no parâmetro timeout define qual o tempo máximo de aguardo do retorno do servidor, se não houver retorno após este tempo a conexão é abortada. Após definido o objeto xhr, para iniciar a conexão é chamado o método open(string,string). O primeiro parâmetro corresponde ao método da requisição HTTP, que é definido como POST. O segundo parâmetro corresponde ao endereço do servidor, que foi definido como atributo da classe App.API.Registro_Movel. No caso de sucesso em receber retorno do servidor, a função informada em onload acessa a mensagem de retorno do servidor consultando o valor do atributo responsetext, do próprio objeto xhr que está referenciado pelo termo this. Com a função JSON.parse, esta mensagem de retorno é convertida do formato JSON para um array de objeto. Cada objeto deste array corresponde a um registro de uma estação, e seus valores são utilizados para atribuir os valores dos atributos do objeto registro_movel, que é criado em cada iteração sobre essa lista. A função informada em onload retorna o valor true no final da execução, informando o sucesso ao receber os dados do servidor. é

57 56 // Cria objeto HTTP cliente. var xhr = Ti.Network.createHTTPClient({ // Quando concluir o carregamento. onload : function() { // Converte retorno para JSON. var json = JSON.parse(this.responseText); // Verifica se há dados no retorno. if (json!= '') { //... // Percorre retorno extraindo os registros de Registro_Movel. for (var i = 0; i < json.objetos.length; i++) { JSON. // Cria objeto temporário para receber o registro do var registro = json.objetos[i]; // Cria registro_movel e seta os atributos. var registro_movel = new App.Models.Registro_Movel(); registro_movel.cd_registro = registro.cd_registro; registro_movel.dt_registro = registro.dt_registro; registro_movel.cd_estacao = registro.cd_estacao; registro_movel.ds_estacao = registro.ds_estacao; registro_movel.dt_leitura = registro.dt_leitura; registro_movel.vlr_nivel = registro.vlr_nivel; registro_movel.vlr_precipitacao = registro.vlr_precipitacao; registro_movel.ds_status = registro.ds_status; registro_movel.nr_latitude = registro.nr_latitude; registro_movel.nr_longitude = registro.nr_longitude; //... }, } } //... //... return true; // Quando houver erro na conexão com o servidor. onerror : function(e) { // Informa erro ao usuário var alerta = Ti.UI.createAlertDialog({ message : 'Erro ao atualizar os registros das estações!', ok : 'OK', title : 'Atualização' }); alerta.show();

58 57 }, return false; // Tempo limite para comunicação com o servidor e retorno dos dados. timeout : 5000 }); // Abre comunicação com servidor webservice. xhr.open("post", url_ws); // Envia dados. xhr.send(); Quadro 13 Trecho de código do método atualizar_registros() da classe App.API.Registro_Movel que representa comunicação com o servidor. No caso de não sucesso em receber retorno do servidor, a função informada no parâmetro onerror cria uma janela informando o erro na comunicação ao usuário. O componente Ti.UI.createAlertDialog cria uma janela com o padrão da plataforma onde está sendo executado o aplicativo, para informar ao usuário uma mensagem descrevendo o erro ocorrido. A mensagem é definida no parâmetro message. O parâmetro ok define qual o título do único botão da janela, que é pressionado para fechar a mensagem. No parâmetro title é definido o título da janela. Para exibir a janela, é chamado o método open() do objeto alerta Comunicação do aplicativo cliente com servidor do Facebook Quando o usuário faz o registro de uma ocorrência, ele deve ter efetuado login no Facebook. Isto é necessário porque durante o registro da ocorrência, o aplicativo cliente envia para o Facebook a foto, a descrição e a localização atual do usuário para criar uma postagem no grupo TCC Carlos Souza. Em seguida, o aplicativo cliente solicita ao Facebook os dados da postagem, como por exemplo a Uniform Resource Locator (URL) da foto e o nome completo do usuário. Estes dados são enviados num próximo momento ao aplicativo servidor, que salva na base de dados do sistema. A comunicação com o Facebook é gerenciada pelo módulo do Titanium Titanium.Facebook, utilizando a Application Programming Interface (API) Graph API disponibilizada pelo Facebook para acesso de aplicativos. Essa API utiliza o conceito de grafos, compostos por objetos e suas conexões (FACEBOOK, 2012b). Para utilizar a Graph API, foi necessário criar um aplicativo no Facebook. A referência Facebook (2012a) traz informações do processo de criação de um aplicativo no Facebook. A inicialização do módulo

59 58 do Facebook requer a definição do id do aplicativo e dos recursos necessários. Esses recursos serão disponibilizados após o usuário permitir a instalação do aplicativo TCC Carlos Souza em sua conta do Facebook. A permissão para realizar esse procedimento é solicitada ao usuário na primeira vez que for efetuado login no aplicativo. As ações de login e logout são executadas a partir de dois listeners declarados no arquivo facebook.js. O Quadro 14 apresenta o código do arquivo facebook.js presente no diretório lib, que implementa a configuração do módulo Titanium.Facebook para conexão com o Facebook e as rotinas de login e logout do usuário no Facebook. No início do arquivo facebook.js são informados os dados básicos para comunicação do aplicativo com a API Graph API do Facebook. A propriedade Ti.Facebook.appid define o id do aplicativo no Facebook. A propriedade Ti.Facebook.permissions consiste em uma lista com os recursos necessários para implementar as funcionalidades do aplicativo. Em seguida são descritos os listeners dos eventos de login e logout. Estes eventos são disparados através do click no botão do Facebook declarado na classe App.UI.Mapa. Os eventos são declarados através da chamada da função Ti.Facebook.addEventListener(String,function(Object)), onde o primeiro parâmetro consiste no nome do evento, que pode ser login ou logout, e o segundo parâmetro consiste na função que é executada quando o evento é ativado. No evento de login, a função executada testa se o atributo success do objeto e contém valor true. Isso significa que o login foi realizado com sucesso. Neste caso, o botão relatar ocorrência da tela principal é habilitado através da chamada do método App.controlador.habilitar_relatar_ocorrencia(). Em seguida é exibido uma mensagem ao usuário informando que o login foi bem sucedido, através do componente Ti.UI.alertDialog, já descrito anteriormente. Caso a propriedade success do objeto e conter valor false, significa que houve erro ao efetuar login no Facebook, e uma mensagem de erro é exibida ao usuário. No evento de logout, a função executada desabilita o botão relatar ocorrência da tela principal do aplicativo através da chamada ao método App.controlador.desabilitar_relatar_ocorrencia(). Dessa forma o usuário não tem mais permissão para relatar ocorrência. Em seguida, é exibida uma mensagem ao usuário informando que o logout no Facebook foi efetuado com sucesso.

60 59 /** Arquivo de definição do módulo de conexão com o Facebook. */ // Inicializa Módulo Facebook. Ti.Facebook.appid = ' '; Ti.Facebook.permissions = ['publish_stream', 'read_stream', 'user_location', 'photo_upload']; /** Event login do Facebook */ Ti.Facebook.addEventListener('login', function(e) { // Testa se efetuou login com sucesso. if (e.success) { // Habilita botão relatar_ocorrencia App.controlador.habilitar_relatar_ocorrencia(); // Exibe informação ao usuário. var alerta = Ti.UI.createAlertDialog({ message : 'Login efetuado com sucesso!', ok : 'OK', title : 'Facebook' }); alerta.show(); } else { // Caso houve erro ao efetuar login. }); } // Exibe informação ao usuário. var alerta = Ti.UI.createAlertDialog({ message : 'Erro ao efetuar login.', ok : 'OK', title : 'Facebook' }); alerta.show(); /** Event logout do Facebook */ Ti.Facebook.addEventListener('logout', function(e) { // Desabilita botão relatar ocorrência. App.controlador.desabilitar_relatar_ocorrencia(); }); // Exibe informação ao usuário. var alerta = Ti.UI.createAlertDialog({ message : 'Desconectado.', ok : 'OK', title : 'Facebook' }); alerta.show(); Quadro 14 Arquivo facebook.js

61 Comunicação do aplicativo servidor com servidor do sistema de alerta O aplicativo servidor coleta do servidor do sistema de alerta periodicamente os dados dos últimos registros de cada estação e salva as informações em uma base de dados própria. Os principais objetivos em manter uma base de dados própria são o de permitir a disponibilização dessas informações de forma ágil ao aplicativo cliente e de garantir a persistência dos dados. O aplicativo servidor acessa dois webservices do servidor do sistema de alerta a cada quinze minutos. Os dados são recebidos em arquivos no formato JSON. Os dados de ambos webservices são processados juntos para criar objetos do tipo Registro. Os atributos desse objeto podem ser consultados no diagrama de classes do servidor, já apresentado anteriormente. O Quadro 15 apresenta um trecho de código do arquivo coletar.php, que consiste em um script no aplicativo servidor que recupera a informação dos webservices disponibilizados pelo sistema de alerta. // Retorna dados do web service Tabela. $json_url_tabela = "http://www.comiteitajai.org.br/alerta/alerta/json/tabela.json"; $tabela = get_json($json_url_tabela); // Retorna dados do web service Últimas. $json_url_ultimas = "http://www.comiteitajai.org.br/alerta/alerta/json/ultimas.json"; $ultimas = get_json($json_url_ultimas); Quadro 15 Trecho de código do arquivo coletar.php No início do trecho de código, é definida a URL de cada webservice disponibilizado pelo sistema de alerta. A variável $tabela recebe o retorno da função get_json(string), que é responsável por estabelecer a conexão com o servidor através da URL definida na variável $json_url_tabela e retornar os dados fornecidos por esse webservice. Da mesma forma, a variável $ultimas recebe o retorno da função get_json(string), que retorna os dados fornecidos pelo segundo webservice. O Quadro 16 apresenta o código da função get_json() que está definida no arquivo include/funcoes.php. A comunicação do aplicativo servidor com os webservices é definida utilizando a biblioteca libcurl, versão No início da função get_json(string), é criado o objeto que representa a conexão com o servidor do sistema de alerta, passando como parâmetro a URL do webservice. Através da chamada do método curl_setopt_array(object,array), é configurado o objeto ch com propriedades armazenadas em uma lista do tipo array. Em seguida, é estabelecida a conexão através da chamada do método curl_exec(object), passando o objeto ch como parâmetro. O retorno deste método é o arquivo em formato JSON

62 61 recebido do webservice. O método get_json() finaliza retornando os dados recuperados do webservice transformados de JSON para um array de duas dimensões, onde a primeira dimensão corresponde ao registro e a segunda a seus atributos. /** * Conecta a um webservice e retorna JSON. string $json_url URL do web service. string Retorno JSON do web service. */ function get_json($json_url){ // Cria objeto de conexão. $ch = curl_init($json_url); // Configura opções curl. $options = array( CURLOPT_RETURNTRANSFER => true, CURLOPT_HTTPHEADER => array('content-type: application/json'), ); curl_setopt_array($ch, $options); } // Resultado/retorno JSON. $result = curl_exec($ch); // Retorna JSON formatado para array. return json_decode($result,true); Quadro 16 Função get_json(string) do arquivo include/funcoes.php Ao receber o retorno da função get_json(string), o script coletar.php processa os dados recuperados de ambos webservices para criar os objetos do tipo Registro que serão armazenados em banco de dados próprio. O Quadro 17 apresenta o trecho de código do arquivo coletar.php responsável por criar os objetos do tipo Registro. No início do trecho de código do arquivo coletar.php, é criado a lista $dados para receber os dados dos webservices. Em seguida, é verificado o tamanho das listas armazenadas nas variáveis $tabela e $ultimas. Essas representam as listas retornadas das conexões com os dois webservices do servidor do sistema de alerta. O tamanho maior que zero representa que houve retorno dos webservices, permitindo a continuidade da execução da função. Caso contrário o processamento termina. Na continuidade do processamento da função, a lista $tabela é percorrida e tem seus registros inseridos na lista $dados, indexados pelo valor do campo cd_estacao. Ao término dessa iteração, a lista $dados contém todos os registros recuperados do primeiro webservice, que consiste numa lista com doze registros, onde cada um representa a última leitura realizada em cada estação. Em seguida, é percorrida a lista $ultimas, que também contém doze registros, onde cada um representa a última leitura realizada em cada estação, porém essa contém informações complementares às recuperadas

63 62 pelo primeiro webservice. // Cria array para receber objetos Registro. $dados = array(); // Se houve retorno do servidor, cria Registro insere em base de dados própria. if (count($tabela) > 0 && count($ultimas) > 0){ // Adiciona registros de nível e precipitação no array dados, retirados do web service Tabela. foreach ($tabela as $key => $item){ $dados[$item['cd_estacao']] = $item; } // Adiciona informações de latitude e longitude, retirados do web service Últimas. foreach ($ultimas as $key => $item){ $dados[$item['cd_estacao']]['nr_latitude'] = $item['nr_latitude']; $dados[$item['cd_estacao']]['nr_longitude'] = $item['nr_longitude']; } // Percorre array dados, cria objeto Registro e grava no banco de dados. foreach ($dados as $key => $dado){ // Formata o campo dt_leitura para formato do banco de dados MySQL (aaaa-mm-dd hh:mm:ss). $dado['dt_leitura'] = texto_data($dado['dt_leitura']); // Cria objeto Registro. $registro = new Registro(); // Atribui valores aos atributos do Registro. $registro->set_atributos($dado); } //... } Quadro 17 Trecho de código do arquivo coletar.php Do segundo webservice, recupera-se as informações de geolocalização da estação onde foi registrado esses dados, e são armazenadas no registro correspondente a mesma estação na lista $dados. Ao término dessa iteração, a lista $dados contém todas as informações necessárias sobre as últimas leituras das estações monitoradas pelo sistema de alerta, indexados pelo campo cd_estacao. Em seguida, a lista $dados é percorrida. Neste processo, o campo dt_leitura de cada registro é transformado para o formato TIMESTAMP utilizado pelo banco de dados MySQL. O formato TIMESTAMP consiste em uma informação textual composta por quatro dígitos referentes ao ano, acrescentado de um hífen, dois dígitos referentes ao mês, hífen, dois dígitos referente ao dia, espaço, dois dígitos referente às horas, sinal de dois pontos, dois dígitos referente aos minutos, sinal de dois pontos e mais dois

64 63 dígitos referente aos segundos. Em seguida, é criado um objeto do tipo Registro para armazenar os dados de cada registro da lista $dados. O método set_atributos(array) do objeto do tipo Registro atribui os valores a seus atributos a partir de uma lista do tipo Array. O Quadro 18 apresenta o método set_atributos(array) da classe Registro. /** * Função que recebe array com os valores dos parametros da classe. array $atributos Array contendo os valores dos atributos. boolean Retorna confirmando se a operação foi bem sucedida. */ public function set_atributos($atributos){ // Itera sobre o array recebido. foreach ($atributos as $nome_atributo => $valor_atributo) { try { // Monta o nome da função a ser chamada. $funcao = "set_".$nome_atributo; chamado. // Cria objeto de reflexão correspondente ao método a ser $rm = new ReflectionMethod(get_class($this), $funcao); // Chama o método enviando um array dos parâmetros necessários. $rm->invokeargs($this,array($valor_atributo)); } } catch (ReflectionException $e) { // Caso houver erro na execução, exibe erro. echo $e->getmessage(); // Retorna não sucesso. return false; } } // Retorna sucesso. return true; Quadro 18 Método set_atributos(array) da classe Registro O método set_atributos(array) consiste numa rotina que itera sobre a lista recebida como parâmetro. Essa lista representa os valores dos atributos do objeto do tipo Registro, indexados por valores que representam os nomes de seus atributos. Ou seja, cada registro da lista define um nome de um atributo do objeto do tipo Registro e seu respectivo valor. A associação do valor ao atributo se faz através da técnica de reflexão, construção que é implementada por diversas linguagens de programação orientadas a objetos, como exemplo da linguagem de programação PHP5 que é utilizada neste trabalho. Inicialmente define-se qual o método que será chamado, concatenando o valor set_

65 64 com o nome do atributo. Em seguida, é criado o objeto $rm que representa a reflexão do método, através do comando new ReflectionMethod(String, String). O primeiro parâmetro refere-se ao nome da classe, neste caso referenciado pela chamada da função get_class($this), que retorna o nome da classe atual, que é Registro. O segundo parâmetro é o nome do método, que foi definido na variável $funcao. Em seguida, a chamada ao método invokeargs(object, Array) do objeto $rm executa o método resultante da reflexão. O parâmetro do tipo Object é o objeto do qual será chamado o método da reflexão, que neste caso é o próprio objeto onde esta função está sendo chamada, portanto é referenciado pelo termo $this. O parâmetro do tipo Array é uma lista com os parâmetros necessários para a execução do método resultante da reflexão. Neste caso, contém apenas o valor do atributo. Caso ocorrer erro neste processo, é gerada uma exceção do tipo ReflectionException e armazenada na variável $e. Ao término da execução, a função set_atributos(array) retorna o valor false se houver erro. Caso houver sucesso na atribuição de valores aos atributos do tipo Registro, a função retorna o valor true. Esse método para atribuição de valores aos atributos da classe também é utilizado nas classes Ocorrencia e Registro_Movel do aplicativo servidor Persistência no aplicativo servidor No aplicativo servidor a persistência de dados é implementada na forma de registros de um banco de dados. O banco de dados é acessado através do driver PDO_MYSQL que implementa a interface PDO, utilizada para acesso a banco de dados. Essa interface é configurada para acessar uma base de dados MySQL. O Quadro 19 apresenta o código fonte da classe PDOConnectionFactory em que o banco de dados é acessado.

66 65 <?php /** * Carlos Eduardo de Souza * Object $con PDO da conexão com o banco de dados. boolean $persistent Indica se a conexão é persistente. int $timeout Indica o tempo limite da conexão. * */ class PDOConnectionFactory { // Armazena a conexão com o banco de dados. private $con = null; // Define a persistência da conexão. private $persistent = true; // Define o tempo limite da conexão. private $timeout = 60; /** * Construtor. Não recebe parâmetros. */ public function PDOConnectionFactory() { // Nada. } /** * Função que retorna objeto do tipo PDO da conexão com o banco de dados. Object Retorna PDO da conexão com o banco de dados. Se houver erro retorna false. */ public function get_connection() { // Dados para acesso ao banco de dados. $host = "cpmy0030.servidorwebfacil.com"; $user = "stsistem_tcc"; $senha = "tcc12345"; $db = "stsistem_tcc"; // Estabelece conexão com banco de dados. try { $this->con = new PDO("mysql:dbname=$db;host=$host", $user, $senha, array( PDO::ATTR_PERSISTENT => $this->persistent, PDO::ATTR_TIMEOUT => $this->timeout ) ); // Realizado com sucesso, retorna conexão. return $this->con; } catch ( PDOException $ex ) { }?> } } // Caso ocorra erro na conexão, retorna false. return false; Quadro 19 Classe PDOConnectionFactory

67 66 No início da implementação da classe são definidos seus atributos. O atributo $con armazena o objeto do tipo PDO, que representa a conexão com o banco de dados. Este atributo é inicializado com o valor null. O atributo $persistent contém um valor do tipo boolean e define se a conexão é persistente. Uma conexão persistente não é encerrada no final da execução do script, mas fica em cache e é reutilizada quando outro script solicita uma nova conexão utilizando as mesmas credenciais. O cache da conexão persistente permite evitar a sobrecarga causada pela consequência de inúmeros processos para estabelecer uma nova conexão toda vez que um script precisa conectar-se ao banco de dados, resultando em uma aplicação web mais rápida (THE PHP GROUP, 2012). Este atributo é inicializado com o valor true, indicando que a conexão é persistente. Em seguida, o atributo timeout é definido com um valor do tipo int, que define o tempo máximo em segundos que a conexão com o banco de dados ficará estabelecida antes de ser encerrada. Este atributo é iniciado com o valor 60, representando que a conexão com o banco de dados ficará ativa em no máximo sessenta segundos. Após este período de tempo, a conexão é armazenada em cache pelo driver PDO_MYSQL, devido à configuração da persistência. Caso contrário, a conexão seria encerrada. O método construtor é definido através da assinatura public function PDOConnectionFactory(). Este método não possui instruções para serem executadas. Em seguida é definido o método get_connection(), que estabelece a conexão com o banco de dados. No início desse método, são definidas algumas variáveis de conexão. A variável $host define a URL do servidor do banco de dados. A variável $user define o usuário, e a variável $senha define a senha, que são utilizados como credenciais para acesso ao banco de dados. A variável $db representa o nome do database no banco de dados que contém as tabelas utilizadas pela aplicação servidora. Em seguida é criado o objeto do tipo PDO e armazenado no atributo $con da própria classe PDOConnectionFactory, portanto é declarado como $this- >con. Ao criar o objeto, são passadas por parâmetros as configurações para a conexão com o banco de dados. O primeiro parâmetro representa as informações básicas necessárias para conectar ao banco de dados. Ele é definido através de um valor textual no formato Data Source Name (DSN). O parâmetro no formato DSN utilizado neste trabalho consiste na concatenação do texto mysql:dbname=, acrescentando o valor da variável $db, pontovírgula, host=, o valor da variável $host e encerrando com. O segundo parâmetro define o usuário, e o terceiro parâmetro a senha, utilizados para a autenticação com o banco de dados. O quarto parâmetro é uma lista que atribui valores a algumas constantes do objeto PDO.

68 67 A constante PDO::ATTR_PERSISTENT define se a conexão é persistente. É atribuído a ela o valor do atributo $persistent da própria classe PDOConnectionFactory. A constante PDO::ATTR_TIMEOUT define o tempo limite da conexão. É atribuído a ela o valor do atributo $timeout, também definido na própria classe PDOConnectionFactory. Em seguida, a função get_connection() retorna o objeto do tipo PDO que representa a conexão com o banco de dados. Caso ocorrer algum erro na conexão com o banco de dados, o programa gera uma exceção e executa o código definido no bloco catch, que recebe como parâmetro uma exceção representada pelo objeto $ex do tipo PDOException. O comando executado no bloco catch retorna o valor false, indicando que não houve sucesso ao conectar-se com o banco de dados. Utilizando-se do recurso de herança disponível na programação orientada a objetos, a classe PDOConnectionFactory é herdada por três outras classes. Essas classes têm em suas assinaturas o sufixo extends PDOConnectionFactory, que indica essa herança. Essa relação proporciona o acesso direto ao método get_connection(). O Quadro 20 contém um trecho de código da classe OcorrenciaDAO com o método select_ultimos(), onde é realizada uma chamada ao método get_connection() e em seguida é executado um comando SQL que recupera os dados de objetos do tipo Ocorrencia. A classe é declarada com a assinatura class OcorrenciaDAO extends PDOConnectionFactory, definindo o relacionamento de herança da classe PDOConnectionFactory. O atributo $conex armazena a conexão com o banco de dados, e é inicializado com o valor null. A função select_ultimos() é responsável por recuperar as informações das cinquenta ocorrências mais recentes armazenadas no banco de dados. Essas informações são representadas por objetos do tipo Ocorrencia. No início dessa função, é efetuada uma chamada a função get_connection() da classe PDOConnectionFactory, que é referenciada pelo termo parent, devido ao relacionamento de herança. Em seguida, é definido o comando SQL e armazenado na variável $sql. Esse comando SQL retorna uma lista com os cinquenta registros mais recentes da tabela Ocorrencia. A variável $stmt recebe um objeto do tipo PDOStatement, resultado da chamada da função prepare(string) do atributo $conex, da própria classe Ocorrencia. A função prepare(string) recebe como parâmetro o comando SQL definido anteriormente. Caso ocorrer erro na chamada a função prepare(string), ocorre uma exceção do tipo PDOException e o fluxo do programa é direcionado ao bloco catch, que finaliza a execução da função select_ultimos() e retorna o valor false.

69 68 class OcorrenciaDAO extends PDOConnectionFactory { private $conex = null; //... /** * Retorna as 50 últimas ocorrências registradas. Array Lista de Ocorrencia. */ public function select_ultimos() { // Abre conexão com banco de dados. $this->conex = parent::get_connection(); dados. // Tenta selecionar registros de ocorrencias no banco de try { // Monta comando SQL. $sql = "SELECT * FROM Ocorrencia ORDER BY cd_ocorrencia DESC LIMIT 0, 50"; // Monta Statement. $stmt = $this->conex->prepare($sql); dados. objetos. // Executa query e testa se houve retorno do banco de if ($stmt->execute()){ // Converte retorno do banco de dados para array de $ocorrenciasbd = $stmt->fetchall(); ser retornadas. // Array para armazenar as ocorrencias que deverão $ocorrencias = array(); // Percorre retorno do banco de dados. foreach ($ocorrenciasbd as $key => $value) { // Cria objeto Ocorrencia. $ocorrencia = new Ocorrencia(); // Define atributos com os valores do objeto proveniente do banco de dados. $ocorrencia- >set_atributos(array_retiraindicesnumericos($value)); } // Adiciona a ocorrência ao array de retorno. array_push($ocorrencias, $ocorrencia); // Fecha a conexão. $this->conex = null; // Retorna array de ocorrencias. return $ocorrencias;

70 69 } else { // Erro ao executar query no banco de dados. } return false; } catch ( PDOException $ex ) { // Erro ao conectar no banco de dados. return false; } } } Quadro 20 Trecho de código da classe OcorrenciaDAO com método select_ultimos() O objeto do tipo PDOStatement representa a declaração de uma instrução preparada para ser executada no banco de dados. Em seguida, é chamada a função execute() do objeto $stmt, que executa a instrução e retorna um valor do banco de dados. Caso ocorrer erro em executar essa instrução, o fluxo é desviado para o bloco else e a função select_ultimos() finaliza retornando o valor false, que indica erro ao recuperar os registros das ocorrências. No caso de sucesso na execução da instrução no banco de dados, o valor de retorno dessa instrução é uma lista de registros da tabela Ocorrencia. Em seguida o retorno do banco de dados é transformado para uma lista de objetos, através de uma chamada ao método fetchall() do objeto $stmt, e armazenada na variável $ocorrenciasbd. Uma lista é criada para receber os objetos do tipo Ocorrencia, e armazenada na variável $ocorrencias. Em seguida é percorrida a lista de objetos provenientes do banco de dados através de um bloco for. Em cada iteração, é criado um novo objeto do tipo Ocorrencia e armazenado na variável $ocorrencia. Este objeto tem seus atributos valorados a partir da chamada do método set_atributos(array), já descrito anteriormente. Como parâmetro, é informado uma lista resultante da chamada a função array_retira_indices_numericos($array), que consiste em excluir de um objeto do tipo Array todos os registros que são indexados por um valor numérico. Isso se faz necessário porque a lista de retorno do banco de dados é composta por dois registros para cada campo da tabela, onde um registro é indexado pelo nome do campo correspondente e outro por um número inteiro sequencial. Este último não se faz necessário, e deve ser excluído para a execução da atribuição dos valores do objeto $ocorrencia através da técnica de reflexão, já descrita anteriormente. Em seguida, o objeto $ocorrencia está com seus atributos devidamente valorados, e então é adicionado a lista $ocorrencias através da chamada a função array_push(array,object). Em seguida é informado à interface PDO que a conexão não será mais utilizada por esse bloco de código através da atribuição do valor null ao

71 70 atributo $conex da classe OcorrenciaDAO. A conexão é armazenada em cache pelo servidor de aplicação devido à propriedade da persistência estar ativada. Em seguida, a função select_ultimos() finaliza sua execução retornando a lista $ocorrencias, que contém os objetos do tipo Ocorrencia recuperados do banco de dados. Um exemplo de como é registrado as ocorrências no banco de dados do servidor pode ser visto na próxima seção Recebimento de dados no aplicativo servidor O aplicativo servidor recebe dados do aplicativo cliente via comunicação HTTP através de requisições POST, no padrão multipart, a scripts que servem como webservices. As requisições recebidas são processadas e no final retornam como resposta ao aplicativo cliente informações em formato JSON. O Quadro 21 apresenta um trecho de código do webservice definido no arquivo cadastrar_ocorrencia.php, onde são processados os dados recebidos de uma requisição de cadastro de ocorrência realizada pelo aplicativo cliente. As informações recebidas via POST são recuperadas no PHP através da variável de ambiente $_POST, que representa uma lista onde cada registro é indexado com o nome da propriedade recebida. No início do arquivo, é realizado teste se foi informado uma variável com nome acao pelo aplicativo cliente através do comando isset(). Este comando é nativo do PHP, e retorna o valor true se a variável informada existe, false caso não existir. Este teste verifica se a chamada ao webservice é válida, e os próximos campos podem ser conferidos. Caso não for informada a propriedade acao, o fluxo de execução é alterado para o bloco else correspondente. A execução do programa é finalizada retornando o valor 0 em formato JSON, que indica o não sucesso no cadastro da ocorrência. Se a variável $_POST[ acao ] existir, é realizado teste se todas as informações obrigatórias para o cadastro da ocorrência foram informadas. Caso algum campo esteja vazio, o fluxo do programa é desviado para o bloco else correspondente e finalizada a execução retornando o valor 0, que informa o não sucesso no cadastro da ocorrência.

72 71 // Se foi informado $_POST['acao']. if (isset($_post['acao'])){ // Testa conteúdo das variáveis necessárias para proceder cadastro da ocorrência. if ($_POST['acao'] == 'cadastrar_ocorrencia' && $_POST['cd_usuario_fb']!= '' && $_POST['nm_usuario_fb']!= '' && $_POST['ds_url_img']!= '' && $_POST['nr_latitude']!= '' && $_POST['nr_longitude']!= '' && $_POST['cd_post_fb']!= ''){ // Cria objeto Ocorrencia. $ocorrencia = new Ocorrencia(); POST. // Define os valores dos atributos conforme recebido via $ocorrencia->set_cd_usuario_fb($_post['cd_usuario_fb']); $ocorrencia->set_nm_usuario_fb($_post['nm_usuario_fb']); $ocorrencia->set_ds_ocorrencia($_post['ds_ocorrencia']); $ocorrencia->set_nr_latitude($_post['nr_latitude']); $ocorrencia->set_nr_longitude($_post['nr_longitude']); $ocorrencia->set_cd_post_fb($_post['cd_post_fb']); $ocorrencia->set_ds_url_img($_post['ds_url_img']); // Cria instância de acesso ao banco de dados para objeto Ocorrencia. $ocorrenciadao = new OcorrenciaDAO(); // Insere Ocorrencia no banco de dados. Testa se houve sucesso. if ($ocorrenciadao->insert($ocorrencia)){ // Sucesso no cadastro da Ocorrencia. Retorna 1 em formato JSON. echo json_encode('1'); } else { JSON. // Erro no cadastro da Ocorrencia. Retorna 0 em formato echo json_encode('0'); } } else { // Erro nas variáveis recebidas. Retorna 0 em formato JSON. echo json_encode('0'); } } else { // Erro na variávei $_POST['acao']. Retorna 0 em formato JSON. echo json_encode('0'); } Quadro 21 Trecho de código do webservice definido no arquivo cadastrar_ocorrencia.php

73 72 Com todos os dados obrigatórios informados, o programa cria um objeto do tipo Ocorrencia para armazenar os valores recebidos via POST. Em seguida, são definidos os valores dos atributos do objeto $ocorrencia através de chamada aos métodos setters, informando como parâmetro os valores correspondentes em $_POST. Em seguida, é criado um objeto do tipo OcorrenciaDAO, que gerencia a persistência de objetos do tipo Ocorrencia no banco de dados. A persistência do objeto $ocorrencia é realizada através da chamada a função insert(object) do objeto OcorrenciaDAO. Esta função retorna um valor do tipo boolean, informando se houve sucesso ao inserir o objeto $ocorrencia na tabela Ocorrencia do banco de dados. Caso houver sucesso, o programa finaliza a execução retornando o valor 1 no formato JSON ao aplicativo cliente, informando o sucesso no cadastro da ocorrência. Caso contrário, o programa finaliza retornando o valor 0 no formato JSON ao aplicativo cliente, informando o não sucesso no cadastro da ocorrência. O Quadro 22 representa o método insert(object) da classe OcorrenciaDAO, responsável pela persistência de objetos do tipo Ocorrencia. No início da execução do método insert(object), é requisitado a conexão com o banco de dados através do método get_connection(), já descrito anteriormente. Em seguida, são recuperados os valores do objeto $ocorrencia formatando-os através da função mysql_escape_string(string), que tem por objetivo adicionar o sinal de escape em símbolos especiais da linguagem SQL nos valores dos atributos, para evitar que ocorra problemas ao montar a instrução de inserção desses dados no banco de dados. Em seguida é montado o comando SQL para inserção do registro na tabela Ocorrencia. Os valores dos campos não fazem parte do comando, são referenciados através de apelidos. Um objeto do tipo PDOStatement é criado através da chamada da função prepare(string) do atributo $conex da própria classe OcorrenciaDAO. Este objeto representa uma instrução para ser executada no banco de dados. Caso ocorrer erro na chamada da função prepare(string) do objeto $stmt, ocorre uma exceção do tipo PDOException e o fluxo do programa é direcionado ao bloco catch, que finaliza a execução da função insert($object) e retorna o valor false. Em seguida, os apelidos constantes no comando SQL são relacionados a seus respectivos valores através do comando bindvalue(string,string,int) do objeto $stmt. O primeiro parâmetro define qual o nome do apelido. O segundo parâmetro é o valor que deve ser atribuído a esse apelido. O terceiro parâmetro define qual o tipo do dado definido na sintaxe do SQL para o valor atribuído ao apelido. Este último é definido utilizando constantes do objeto PDO. Os valores

74 73 possíveis são: PDO::PARAM_BOOL, para valores do tipo boolean; PDO::PARAM_NULL, para valor do tipo null; PDO::PARAM_INT, para valores do tipo integer; PDO::PARAM_STR, para representar valores do tipo char, varchar, ou outros dados em formato string, como double e timestamp; ou PDO::PARAM_LOB, para valores do tipo blob. Para configurar os valores dos apelidos foi utilizado apenas o tipo de dado PDO::PARAM_STR. /** * Insere Ocorrencia no banco de dados. Object $ocorrencia Objeto Ocorrencia para ser inserido no banco de dados. boolean Retorna confirmando se a operação foi bem sucedida. */ public function insert($ocorrencia) { // Abre conexão com banco de dados. $this->conex = parent::get_connection(); // Tenta inserir registro no banco de dados. try { // Recupera informações do objeto $ocorrencia. $cd_usuario_fb = mysql_escape_string($ocorrencia- >get_cd_usuario_fb()); $nm_usuario_fb = mysql_escape_string($ocorrencia- >get_nm_usuario_fb()); $ds_ocorrencia = mysql_escape_string($ocorrencia- >get_ds_ocorrencia()); $nr_latitude = mysql_escape_string($ocorrencia- >get_nr_latitude()); $nr_longitude = mysql_escape_string($ocorrencia- >get_nr_longitude()); $cd_post_fb = mysql_escape_string($ocorrencia- >get_cd_post_fb()); $ds_url_img = mysql_escape_string($ocorrencia- >get_ds_url_img()); // Monta comando SQL. $sql = "INSERT INTO Ocorrencia (cd_usuario_fb, nm_usuario_fb, ds_ocorrencia, nr_latitude, nr_longitude, cd_post_fb, ds_url_img) VALUES (:cd_usuario_fb, :nm_usuario_fb, :ds_ocorrencia, :nr_latitude, :nr_longitude, :cd_post_fb, :ds_url_img)"; // Monta Statement. $stmt = $this->conex->prepare($sql); // Atribui valores aos apelidos informados no $sql. $stmt->bindvalue(':cd_usuario_fb', $cd_usuario_fb, PDO::PARAM_STR); $stmt->bindvalue(':nm_usuario_fb', $nm_usuario_fb, PDO::PARAM_STR); $stmt->bindvalue(':ds_ocorrencia', $ds_ocorrencia, PDO::PARAM_STR); $stmt->bindvalue(':nr_latitude', $nr_latitude, PDO::PARAM_STR); $stmt->bindvalue(':nr_longitude', $nr_longitude, PDO::PARAM_STR);

75 74 $stmt->bindvalue(':cd_post_fb', $cd_post_fb, PDO::PARAM_STR); $stmt->bindvalue(':ds_url_img', $ds_url_img, PDO::PARAM_STR); // Executa a query. $retorno = $stmt->execute(); // Fecha a conexão. $this->conex = null; return true; } catch ( PDOException $ex ) { } // Erro ao inserir o registro no banco de dados. return false; } Quadro 22 Método insert(object) da classe OcorrenciaDAO A instrução preparada através da chamada a função execute() do objeto $stmt é executada. Caso ocorrer erro em executar essa instrução, o fluxo é desviado para o bloco else e a função insert($object) finaliza retornando o valor false, que indica erro ao cadastrar o objeto do tipo Ocorrencia. Em seguida é informado à interface PDO que a conexão não será mais utilizada por esse bloco de código através da atribuição do valor null ao atributo $conex da classe OcorrenciaDAO. A conexão é armazenada em cache pelo servidor de aplicação devido à propriedade da persistência estar ativada. Em seguida, a função select_ultimos() finaliza sua execução retornando a lista $ocorrencias, que contém os objetos do tipo Ocorrencia recuperados do banco de dados Operacionalidade da implementação As principais funcionalidades do aplicativo cliente estão relacionadas à visualização das informações dos registros coletados nas estações do sistema de alerta, a visualização e registro de ocorrências e integração com a rede social Facebook. Esta seção apresenta a tela principal do aplicativo e seus componentes, a visualização das informações e histórico de registros das estações, a visualização das ocorrências registradas, o login na rede social Facebook através do aplicativo, e o registro de nova ocorrência. Para as demonstrações a seguir, foi utilizado o dispositivo Sony Ericsson X10a com o Android instalado.

76 Tela de abertura e tela principal do aplicativo. A tela de abertura é exibida enquanto o aplicativo está sendo carregado, e em seguida é exibida a tela principal. A tela principal disponibiliza quatro botões de ação. No canto superior esquerdo o botão para login e logout no Facebook. No canto superior direito o botão para relatar nova ocorrência. No canto inferior esquerdo o botão para atualização dos dados do aplicativo, banco de dados de registros das estações, banco de dados de registros de ocorrências, marcadores no mapa e geolocalização atual. No canto inferior direito o botão para aproximar o mapa na localização atual do usuário e aplicar zoom. Após ser pressionado esse último botão, seu ícone e função mudam. Ao ser pressionado novamente, o botão atualiza a visualização do mapa para uma abrangência um pouco maior, porém mantendo o mapa centralizado na localização do usuário. A Figura 17 apresenta lado a lado a tela de abertura e a tela principal do aplicativo. Figura 17 Tela de abertura (esquerda) e tela principal do aplicativo (direita)

77 Visualizar informações e histórico de registros da estação. A tela inicial da aplicação apresenta um mapa com marcadores em formato de bandeiras. Cada bandeira representa uma estação do sistema de alerta do CEOPS, e está localizada no mapa na posição correspondente a sua geolocalização identificada pelas coordenadas de latitude e longitude informadas pelo sistema de alerta. Esses marcadores são coloridos de acordo com a situação identificada no último registro do nível do rio Itajaí-Açu naquela estação. As cores utilizadas são: azul para situação não definida; verde para situação normal; amarela para situação de atenção; laranja para situação de alerta; e vermelha para situação de emergência. As condições para identificar qual a classificação do estado da estação são estabelecidas pelo sistema de alerta, que disponibiliza os registros já categorizados. A Figura 18 apresenta lado a lado as telas do processo para visualização das informações e histórico de registros das estações. Figura 18 Telas do processo para visualização das informações e histórico de registros das estações Para obter as informações do último registro da estação, o usuário deve clicar sobre a bandeira. Esta ação irá abrir um pequeno quadro próximo à bandeira com as informações do último registro. O quadro próximo ao marcador da estação exibe a descrição da estação e o

78 77 último nível registrado do rio Itajaí-Açu na estação de Blumenau. A data e hora do registro aparecem logo abaixo. Para visualizar o histórico com os últimos dez registros, o usuário deve clicar na imagem correspondente a informações, dentro do quadro de informações da estação. Em seguida é exibida ao usuário uma nova janela que contém uma tabela onde cada linha representa um registro, que estão ordenados do mais recente ao mais antigo. A imagem da bandeira representa por cor a classificação do estado da estação na data e hora registradas Visualizar as ocorrências registradas. No mapa que é exibido na tela inicial da aplicação, são apresentadas as ocorrências registradas pelos usuários através de ícones azuis, representando o local onde foram registradas. A localização geográfica é recuperada no momento do registro da ocorrência. A Figura 19 apresenta lado a lado as telas do processo para visualização das informações das ocorrências registradas pelos usuários. Figura 19 Telas do processo para visualização das informações e histórico de registros das estações O quadro próximo ao marcador da ocorrência exibe a data e hora em que foi registrada a ocorrência e logo abaixo o nome completo do usuário. Para visualizar as informações da

79 78 ocorrência, o usuário deve clicar na imagem correspondente a informações, dentro do quadro de informações da ocorrência. Em seguida é exibida ao usuário uma nova janela com as informações da ocorrência. A foto da ocorrência é exibida no meio da tela. No canto inferior esquerdo são exibidas as informações de data e hora de registro, descrição da ocorrência e nome completo do usuário que realizou o registro da ocorrência. No canto inferior direito é exibido o botão para fechar a tela e voltar a pagina inicial do aplicativo. No Facebook a postagem realizada no momento do registro dessa ocorrência fica armazenada no mural do grupo TCC Carlos Souza. A Figura 20 apresenta a postagem desta ocorrência no Facebook, acessado através do navegador de internet Mozilla Firefox para computador. Fonte: Facebook (2012c). Figura 20 Postagem da ocorrência no grupo TCC Carlos Souza acessado via navegador de internet Mozilla Firefox para computador A foto da ocorrência é exibida no mural do grupo. A descrição da ocorrência informada pelo usuário é concatenada a um link que referencia o local da ocorrência no mapa do serviço Google Maps (GOOGLE, 2012b).

80 Login no Facebook Para o usuário ter permissão para registrar uma nova ocorrência, ele deve ter efetuado login no Facebook. Na tela inicial, no canto superior esquerdo, é visualizado o botão Connect na plataforma Android e Login na plataforma ios, que inicia o procedimento de login no Facebook. A Figura 21 apresenta lado a lado as telas do processo de login no Facebook. Figura 21 Telas do processo para login no Facebook A tela de login no Facebook aparece em uma janela separada da tela inicial do programa. Existem dois campos para autenticação do usuário. O usuário deve digitar os dados de sua credencial no serviço Facebook e clicar no botão Entrar. Se essa for a primeira vez que esse usuário faz login no Facebook pelo aplicativo TCC Carlos Souza, será exibida uma tela solicitando que ele instale o aplicativo em sua conta do Facebook. Isso permite ao aplicativo cliente efetuar postagem em nome do usuário. Em seguida é exibida ao usuário uma tela que solicita a instalação do aplicativo TCC Carlos Souza para a conta do usuário no Facebook. Esse aplicativo necessita permissão para acesso às informações básicas do usuário e localização. Para confirmar a instalação, o usuário deve pressionar o botão Instalar presente no canto superior direito da tela. Caso o usuário desista de realizar a instalação, basta clicar no botão Cancelar no canto superior esquerdo da tela. Ao fim do processo de login, é exibida uma mensagem ao usuário confirmando o login ou informando do erro ao efetuar o login.

81 Relatar ocorrência. Após ter efetuado login no Facebook, o usuário pode relatar ocorrência. Para relatar uma nova ocorrência deve ser clicado o botão no canto superior direito da tela principal do aplicativo. Será exibida uma nova janela, onde o usuário deverá digitar a descrição da ocorrência e clicar em Ok. A Figura 22 apresenta a sequência das telas do processo para relatar ocorrência. Além do botão Ok, o usuário pode optar também por clicar no botão Cancelar para interromper o processo. Neste caso o programa retorna para a tela principal. Após o usuário clicar em Ok, a programa abre uma tela com acesso à galeria de imagens do dispositivo, para o usuário selecionar a foto para ser registrada na ocorrência. Depois de selecionado a foto, o aplicativo exibe uma mensagem de espera enquanto envia os dados ao Facebook e ao aplicativo servidor, e em seguida exibe uma mensagem informando ao usuário o sucesso no registro da ocorrência.

82 Figura 22 Telas do processo para relatar ocorrência 81

83 RESULTADOS E DISCUSSÃO O presente trabalho teve como objetivo inicial o desenvolvimento de um aplicativo multiplataforma integrado ao sistema de alerta de cheias da bacia do Itajaí, que permitisse aos usuários consultar os registros disponibilizados pelo CEOPS, além de permitir que os usuários informem ocorrências em situações adversas. Para um melhor entendimento dos testes realizados é apresentado o cenário do sistema na Figura 23. Figura 23 Cenário do sistema O cenário do sistema é composto por três servidores. O servidor do sistema de alerta tem o papel de disponibilizar os dados das estações através de webservices. O servidor de aplicação contém o aplicativo servidor que acessa o banco de dados MySQL do servidor de banco de dados. Os dispositivos móveis possuem o aplicativo cliente instalado, e servem às solicitações dos usuários via interface gráfica. Havia sido proposto que a foto da ocorrência seria obtida através da câmera do dispositivo, mas após testes com a função showcamera() do módulo Titanium.Media notouse instabilidade no funcionamento desse componente. Em pesquisas realizadas, chegou-se a conclusão que esta falha deve-se a um bug do Titanium SDK, e já foi informada aos desenvolvedores e mantenedores do framework. Em medida paliativa para o andamento e conclusão do presente trabalho, a foto da ocorrência passou a ser capturada da galeria de

84 83 imagens do dispositivo. Dessa forma, o usuário precisa ter capturado a foto previamente com outro aplicativo nativo da plataforma utilizado para essa função, e em seguida utilizar o aplicativo desenvolvido neste trabalho. Havia sido proposto que as informações recuperadas do sistema de alerta seriam atualizadas constantemente, mas durante o desenvolvimento deste trabalho, o servidor do CEOPS, responsável por fornecer essas informações, parou de responder às requisições. Dessa forma, o aplicativo servidor não consegue atualizar sua base de dados desde a data de cinco de outubro de dois mil e doze. Apesar disso, os procedimentos de transferência e disponibilização dessas informações implementadas nos aplicativos cliente e servidor não sofreram interferência. A rotina de atualização da base de dados do servidor continua sendo executada a cada quinze minutos, porém não consegue obter informações atualizadas do sistema de alerta. Após uma pesquisa foi identificado que devido a mudanças na infraestrutura de servidores, o portal onde estava hospedado o webservice do sistema de alerta foi desativado, e até a presente data persiste dessa maneira. A Figura 24 apresenta a configuração de Domain Name System (DNS) do domínio utilizado pelo servidor do sistema de alerta junto ao Núcleo de Informação e Coordenação do ponto BR (NICBR), consultado no dia quatorze de outubro de dois mil e doze. Fonte: Núcleo de Informação e Coordenação do Ponto BR (2012). Figura 24 Configuração DNS do servidor do sistema de alerta Pode ser verificado que o DNS primário do domínio não estava respondendo requisições, e a data de alteração dessas configurações coincide com a data em que o portal deixou de responder às requisições HTTP, cinco de outubro de dois mil e doze. Foram realizados testes do aplicativo cliente em dispositivos e simuladores das

85 84 plataformas Android e ios e conclui-se que não houve alteração na interface gráfica entre dispositivos e simuladores, desde que estivessem utilizando a mesma versão do sistema operacional de suas respectivas plataformas. Os testes das interfaces gráficas têm por objetivo analisar a compatibilidade dos componentes gráficos implementados neste trabalho, entre as duas plataformas estudadas. Foram realizados testes de disponibilidade no aplicativo servidor, visando analisar a infraestrutura onde se encontra o servidor e concluir quais os recursos necessários para atender à grande número de requisições de aplicativos clientes simultaneamente Interface gráfica O desenvolvimento do aplicativo multiplataforma tinha por objetivo o desenvolvimento de interfaces gráficas semelhantes para as diversas marcas e modelos de dispositivos atendidos por essa aplicação. Em suma, as telas e interação com o usuário seguiram o padrão de cada plataforma, utilizando-se de seus itens básicos, como componentes gráficos de alertas e mapas. São destacados nesta seção as comparações dos componentes gráficos utilizados neste trabalho entre as plataformas Android e ios e suas versões. A Figura 25 apresenta a comparação da janela principal entre dispositivo da plataforma Android (esquerda) e o simulador do iphone da plataforma ios versão 5.1 (direita). Figura 25 Tela principal em dispositivo Android (esquerda) e no simulador do iphone com ios 5.1 (direita)

86 85 Os componentes de janelas de alerta, botão de login no Facebook, mapas e galeria de imagens exibidas aos usuários são nativos do sistema operacional utilizado pelo dispositivo. Os componentes de alerta foram implementados utilizando o módulo Titanium.UI.Alert do framework Titanium. A Figura 26 apresenta a comparação da janela de alerta e botão do Facebook entre o emulador da plataforma Android 2.2 (esquerda), um dispositivo da plataforma Android (centro) e o simulador do iphone da plataforma ios versão 5.1 (direita). Figura 26 Janela de alerta e botão do Facebook em simulador Android 2.2 (esquerda), em um dispositivo Android (centro) e no simulador do iphone com ios 5.1 (direita) Os mapas foram implementados utilizando o módulo Titanium.Map do framework Titanium. Na plataforma Android e ios (até as versões 5.X) os mapas são provenientes do serviço Google Maps. Na última versão do ios (6.0.1) os mapas utilizados são da empresa Apple Inc. e suas parceiras. A Figura 27 apresenta a comparação do mapa entre o simulador do ipad da plataforma ios versão 5.1 (esquerda) e um dispositivo ipad da plataforma ios versão (direita). A galeria de imagem é gerenciada pelo módulo Titanium.Media do framework Titanium e é mais um componente nativo que foi utilizado neste aplicativo. A Figura 28 apresenta a comparação da galeria de imagem entre um dispositivo da plataforma Android (esquerda) e o simulador do iphone da plataforma ios versão 5.1 (direita).

87 86 Figura 27 Mapa em simulador do ipad com ios 5.1 (esquerda) e em um dispositivo ipad com ios (direita) Figura 28 Galeria de imagem em dispositivo Android (esquerda) e no simulador do iphone com ios 5.1 (direita)

Desenvolvimento de aplicativo móvel multiplataforma integrado ao sistema de alerta de cheias da bacia do Itajaí

Desenvolvimento de aplicativo móvel multiplataforma integrado ao sistema de alerta de cheias da bacia do Itajaí Desenvolvimento de aplicativo móvel multiplataforma integrado ao sistema de alerta de cheias da bacia do Itajaí Acadêmico: Carlos Eduardo de Souza Orientador: M.Sc. Dalton Solano dos Reis FURB Universidade

Leia mais

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID Alessandro Teixeira de Andrade¹; Geazy Menezes² UFGD/FACET Caixa Postal 533,

Leia mais

Frameworks para criação de Web Apps para o Ensino Mobile

Frameworks para criação de Web Apps para o Ensino Mobile 393 Frameworks para criação de Web Apps para o Ensino Mobile Lucas Zamim 1 Roberto Franciscatto 1 Evandro Preuss 1 1 Colégio Agrícola de Frederico Westphalen (CAFW) Universidade Federal de Santa Maria

Leia mais

Fundamentos da Computação Móvel

Fundamentos da Computação Móvel Fundamentos da Computação Móvel (Plataformas Sistemas Operacionais e Desenvolvimento) Programação de Dispositivos Móveis Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus

Leia mais

Informações importantes

Informações importantes Informações importantes Genexus Web: Marketing e TI alinhados em Aplicativos para Dispositivos móveis DUAS ÁREAS IMPORTANTES... DOIS AMBIENTES... Mais do nunca, marketing e TI precisam estar alinhados

Leia mais

DESENVOLVIMENTO DE APLICATIVO MÓVEL PARA AUXÍLIO NA PREVENÇÃO DE TRAGÉDIAS EM DECORRÊNCIA DE ENCHENTES

DESENVOLVIMENTO DE APLICATIVO MÓVEL PARA AUXÍLIO NA PREVENÇÃO DE TRAGÉDIAS EM DECORRÊNCIA DE ENCHENTES DESENVOLVIMENTO DE APLICATIVO MÓVEL PARA AUXÍLIO NA PREVENÇÃO DE TRAGÉDIAS EM DECORRÊNCIA DE ENCHENTES Autores: Luciano GONÇALVES JUNIOR, Natália Maria Karmierczak DA SILVA, Paulo César Rodacki GOMES,

Leia mais

DESENVOLVIMENTO EM DISPOSITIVOS MÓVEIS UTILIZANDO BANCO DE DADOS

DESENVOLVIMENTO EM DISPOSITIVOS MÓVEIS UTILIZANDO BANCO DE DADOS DESENVOLVIMENTO EM DISPOSITIVOS MÓVEIS UTILIZANDO BANCO DE DADOS Leandro Guilherme Gouvea 1, João Paulo Rodrigues 1, Wyllian Fressatti 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil leandrog.gouvea@gmail.com,

Leia mais

SIGMAON SISTEMA DE INFORMAÇÃO GEOGRAFICA PARA MONITORAMENTO DE ALAGAMENTOS ON-LINE

SIGMAON SISTEMA DE INFORMAÇÃO GEOGRAFICA PARA MONITORAMENTO DE ALAGAMENTOS ON-LINE SIGMAON SISTEMA DE INFORMAÇÃO GEOGRAFICA PARA MONITORAMENTO DE ALAGAMENTOS ON-LINE Marcio Jose Mantau,1 Giovane Farias Aita2, Jaison Ademir Savegnani3, Carlos Alberto Barth4 Palavras-chave: Sistemas de

Leia mais

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE por Miguel Aguiar Barbosa Trabalho de curso II submetido como

Leia mais

Manual de referência do HP Web Jetadmin Database Connector Plug-in

Manual de referência do HP Web Jetadmin Database Connector Plug-in Manual de referência do HP Web Jetadmin Database Connector Plug-in Aviso sobre direitos autorais 2004 Copyright Hewlett-Packard Development Company, L.P. A reprodução, adaptação ou tradução sem permissão

Leia mais

Estratégias para o Desenvolvimento de Aplicações Móveis HP Enterprise Services CMT - Cloud, Mobility and Transformation Março, 2013

Estratégias para o Desenvolvimento de Aplicações Móveis HP Enterprise Services CMT - Cloud, Mobility and Transformation Março, 2013 Estratégias para o Desenvolvimento de Aplicações Móveis HP Enterprise Services CMT - Cloud, Mobility and Transformation Março, 2013 Copyright 2012 Hewlett-Packard Development Company, L.P. The information

Leia mais

Módulo I - Introdução. Faculdade Christus Sistemas de Informação 17/09/2010. Carlos Eugênio Torres Engenheiro de Informática http://cetorres.

Módulo I - Introdução. Faculdade Christus Sistemas de Informação 17/09/2010. Carlos Eugênio Torres Engenheiro de Informática http://cetorres. Módulo I - Introdução Aula 2 Carlos Eugênio Torres Engenheiro de Informática http://cetorres.com Faculdade Christus Sistemas de Informação 17/09/2010 Graduado em Ciência da Computação pela UFC, Brasil

Leia mais

DMS Documento de Modelagem de Sistema. Versão: 1.4

DMS Documento de Modelagem de Sistema. Versão: 1.4 DMS Documento de Modelagem de Sistema Versão: 1.4 VERANEIO Gibson Macedo Denis Carvalho Matheus Pedro Ingrid Cavalcanti Rafael Ribeiro Tabela de Revisões Versão Principais Autores da Versão Data de Término

Leia mais

Inicialização Rápida do Novell Vibe Mobile

Inicialização Rápida do Novell Vibe Mobile Inicialização Rápida do Novell Vibe Mobile Março de 2015 Introdução O acesso móvel ao site do Novell Vibe pode ser desativado por seu administrador do Vibe. Se não conseguir acessar a interface móvel do

Leia mais

USANDO RESPONSIVE WEB DESIGN PARA DESENVOLVIMENTO DE SISTEMAS WEB. Rodrigo Eduardo Boni orientado por Prof. Jhony Alceu Pereira Orientador - FURB

USANDO RESPONSIVE WEB DESIGN PARA DESENVOLVIMENTO DE SISTEMAS WEB. Rodrigo Eduardo Boni orientado por Prof. Jhony Alceu Pereira Orientador - FURB USANDO RESPONSIVE WEB DESIGN PARA DESENVOLVIMENTO DE SISTEMAS WEB Rodrigo Eduardo Boni orientado por Prof. Jhony Alceu Pereira Orientador - FURB ROTEIRO Introdução Objetivos Fundamentação teórica Especificação

Leia mais

GuiBi: Um aplicativo para plataforma Android com um guia comercial da cidade de Bambuí MG

GuiBi: Um aplicativo para plataforma Android com um guia comercial da cidade de Bambuí MG GuiBi: Um aplicativo para plataforma Android com um guia comercial da cidade de Bambuí MG Bruno Alberto Soares Oliveira 1,3 ; Lucas Vieira Murilo 1,3 ; Maik Olher Chaves 2,3 1 Estudante de Engenharia de

Leia mais

Estudo de Frameworks Multiplataforma Para Desenvolvimento de Aplicações Mobile Híbridas

Estudo de Frameworks Multiplataforma Para Desenvolvimento de Aplicações Mobile Híbridas 72 Estudo de Frameworks Multiplataforma Para Desenvolvimento de Aplicações Mobile Híbridas Ezequiel Douglas Prezotto 1, Bruno Batista Boniati 1 1 Tecnologia em Sistemas para Internet - Universidade Federal

Leia mais

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ DEPARTAMENTO ACADÊMICO DE INFORMÁTICA CURSO DE ESPECIALIZAÇÃO EM TECNOLOGIA JAVA

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ DEPARTAMENTO ACADÊMICO DE INFORMÁTICA CURSO DE ESPECIALIZAÇÃO EM TECNOLOGIA JAVA UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ DEPARTAMENTO ACADÊMICO DE INFORMÁTICA CURSO DE ESPECIALIZAÇÃO EM TECNOLOGIA JAVA CARLOS HUMBERTO LOPES COSTA DESENVOLVIMENTO DE APLICATIVO MÓVEL DO SERVIÇO WEB

Leia mais

ANÁLISE COMPARATIVA DE FERRAMENTAS DE DESENVOLVIMENTO DE APLICATIVOS MÓVEIS MULTIPLATAFORMA

ANÁLISE COMPARATIVA DE FERRAMENTAS DE DESENVOLVIMENTO DE APLICATIVOS MÓVEIS MULTIPLATAFORMA UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIA DA COMPUTAÇÃO BACHARELADO ANÁLISE COMPARATIVA DE FERRAMENTAS DE DESENVOLVIMENTO DE APLICATIVOS MÓVEIS MULTIPLATAFORMA

Leia mais

4 Desenvolvimento da ferramenta

4 Desenvolvimento da ferramenta direcionados por comportamento 38 4 Desenvolvimento da ferramenta Visando facilitar a tarefa de documentar requisitos funcionais e de gerar testes automáticos em uma única ferramenta para proporcionar

Leia mais

Proteste Postos: um aplicativo móvel utilizando o cross-framework Phonegap. Bernardo Salgueiro

Proteste Postos: um aplicativo móvel utilizando o cross-framework Phonegap. Bernardo Salgueiro UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA ESCOLA DE INFORMÁTICA APLICADA Proteste Postos: um aplicativo móvel utilizando o cross-framework Phonegap Bernardo

Leia mais

Aquisição móvel de dados com Smartphones & Tablets

Aquisição móvel de dados com Smartphones & Tablets Aquisição móvel de dados com Smartphones & Tablets André Pereira Gerente de Marketing Técnico Mike Munhato Engenheiro de Marketing Técnico Por que as pessoas usam tablets? É fácil de carregar Interface

Leia mais

Programação para Dispositivos Móveis

Programação para Dispositivos Móveis Programação para Dispositivos Móveis Fatec Ipiranga Análise e Desenvolvimento de Sistemas Aula 02 História do desenvolvimento de software para dispositivos móveis Dalton Martins dmartins@gmail.com São

Leia mais

Introdução a Computação Móvel

Introdução a Computação Móvel Introdução a Computação Móvel Computação Móvel Prof. Me. Adauto Mendes adauto.inatel@gmail.com Histórico Em 1947 alguns engenheiros resolveram mudar o rumo da história da telefonia. Pensando em uma maneira

Leia mais

Como configurar e-mails nos celulares. Ebook. Como configurar e-mails no seu celular. W3alpha - Desenvolvimento e hospedagem na internet

Como configurar e-mails nos celulares. Ebook. Como configurar e-mails no seu celular. W3alpha - Desenvolvimento e hospedagem na internet Ebook Como configurar e-mails no seu celular Este e-book irá mostrar como configurar e-mails, no seu celular. Sistemas operacionais: Android, Apple, BlackBerry, Nokia e Windows Phone Há muitos modelos

Leia mais

SISTEMA PARA AUTOMATIZAR O MONITORAMENTO DE ROTEADORES DE UM PROVEDOR DE ACESSO

SISTEMA PARA AUTOMATIZAR O MONITORAMENTO DE ROTEADORES DE UM PROVEDOR DE ACESSO FURB Universidade Regional de Blumenau Bacharelado em Ciência da Computação SISTEMA PARA AUTOMATIZAR O MONITORAMENTO DE ROTEADORES DE UM PROVEDOR DE ACESSO Jean Victor Zunino Miguel Alexandre Wisintainer

Leia mais

Manual do Usuário Nextel Cloud. Manual do Usuário. Versão 1.0.0. Copyright Nextel 2014. http://nextelcloud.nextel.com.br

Manual do Usuário Nextel Cloud. Manual do Usuário. Versão 1.0.0. Copyright Nextel 2014. http://nextelcloud.nextel.com.br Manual do Usuário Versão 1.0.0 Copyright Nextel 2014 http://nextelcloud.nextel.com.br 1 Nextel Cloud... 4 2 Nextel Cloud Web... 5 2.1 Página Inicial... 6 2.1.1 Meu Perfil... 7 2.1.2 Meu Dispositivo...

Leia mais

INTEGRAÇÃO DO SISTEMA VALE PIZZA PARA AS REDES SOCIAIS

INTEGRAÇÃO DO SISTEMA VALE PIZZA PARA AS REDES SOCIAIS UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE SISTEMAS DE INFORMAÇÃO BACHARELADO INTEGRAÇÃO DO SISTEMA VALE PIZZA PARA AS REDES SOCIAIS DANIEL ÉRICO PONTES SANDOR BLUMENAU

Leia mais

PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS - APLICATIVOS HÍBRIDOS. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza

PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS - APLICATIVOS HÍBRIDOS. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS - APLICATIVOS HÍBRIDOS Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza ROTEIRO Introdução PhoneGap PhoneGap Build GitHub INTRODUÇÃO Aplicativos nativos

Leia mais

História e Evolução da Web. Aécio Costa

História e Evolução da Web. Aécio Costa Aécio Costa A História da Web O que estamos estudando? Período em anos que a tecnologia demorou para atingir 50 milhões de usuários 3 As dez tecnologias mais promissoras 4 A evolução da Web Web 1.0- Passado

Leia mais

PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS APLICATIVOS HÍBRIDOS. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza

PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS APLICATIVOS HÍBRIDOS. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS APLICATIVOS HÍBRIDOS Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza ROTEIRO Introdução PhoneGap PhoneGap Build GitHub INTRODUÇÃO Aplicativos nativos É

Leia mais

7 Utilização do Mobile Social Gateway

7 Utilização do Mobile Social Gateway 7 Utilização do Mobile Social Gateway Existem três atores envolvidos na arquitetura do Mobile Social Gateway: desenvolvedor do framework MoSoGw: é o responsável pelo desenvolvimento de novas features,

Leia mais

Guia do usuário do PrintMe Mobile 3.0

Guia do usuário do PrintMe Mobile 3.0 Guia do usuário do PrintMe Mobile 3.0 Visão geral do conteúdo Sobre o PrintMe Mobile Requisitos do sistema Impressão Solução de problemas Sobre o PrintMe Mobile O PrintMe Mobile é uma solução empresarial

Leia mais

Busca Certa Combustíveis

Busca Certa Combustíveis UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS Busca Certa Combustíveis por Luma Melo Borges Documento de conclusão da disciplina de Trabalho

Leia mais

Frameworks para Desenvolvimento em PHP Elton Luís Minetto

Frameworks para Desenvolvimento em PHP Elton Luís Minetto Frameworks para Desenvolvimento em PHP Elton Luís Minetto Novatec capítulo 1 Introdução Uma das grandes vantagens do PHP é sua facilidade de aprendizado. Ao ler poucas páginas de tutoriais ou de algum

Leia mais

SENCHA TOUCH: DESENVOLVENDO APLICAÇÕES UNIVERSAIS

SENCHA TOUCH: DESENVOLVENDO APLICAÇÕES UNIVERSAIS SENCHA TOUCH: DESENVOLVENDO APLICAÇÕES UNIVERSAIS Rafael Nunes BATISTA 1 Ana Paula Ambrósio ZANELATO 2 RESUMO: O presente artigo visa apresentar um novo framework de desenvolvimento, que, embora seja compatível

Leia mais

GERADOR DE INTERFACES GRÁFICAS PARA IOS

GERADOR DE INTERFACES GRÁFICAS PARA IOS UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIA DA COMPUTAÇÃO BACHARELADO GERADOR DE INTERFACES GRÁFICAS PARA IOS GABRIEL SEBASTIAN RAMIREZ BLUMENAU 2013 2013/2-05

Leia mais

Introdução a programação de dispositivos móveis. Prof. Me. Hélio Esperidião

Introdução a programação de dispositivos móveis. Prof. Me. Hélio Esperidião Introdução a programação de dispositivos móveis. Prof. Me. Hélio Esperidião Windows Mobile O Windows Mobile é um sistema operacional compacto, desenvolvido para rodar em dispositivos móveis como Pocket

Leia mais

BlackBerry Mobile Voice System

BlackBerry Mobile Voice System BlackBerry Mobile Voice System Versão: 5.0 Service pack: 2 Testes de verificação SWD-980801-0125102730-012 Conteúdo 1 Visão geral... 4 2 Tipos de telefones e contas de usuário... 5 3 Verificando a instalação

Leia mais

Guia para o Google Cloud Print

Guia para o Google Cloud Print Guia para o Google Cloud Print Versão 0 BRA Definições das observações Utilizamos o estilo de observação a seguir ao longo deste manual do usuário: ensina como agir em determinada situação ou fornece dicas

Leia mais

Manual. Roteador - 3G Portátil

Manual. Roteador - 3G Portátil Manual Roteador - 3G Portátil Conteúdo da Embalagem 1. 1 x Produto 2. 1 x Guia de Instalação Rápida 3. 1 x Carregador USB Visão Geral (3) Recarregando o Power Bank: Conecte a ponta Micro USB à porta de

Leia mais

SISTEMA DE FIXAÇÃO ALFABÉTICA

SISTEMA DE FIXAÇÃO ALFABÉTICA CENTRO UNIVERSITÁRIO ESTADUAL DA ZONA OESTE Colegiado de Computação e Matemática Aplicada Curso de Bacharelado em Ciência da Computação SISTEMA DE FIXAÇÃO ALFABÉTICA ROBERTO AFFONSO GOMES RIO DE JANEIRO,

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

Manual do Aplicativo - Rastreamento Veicular

Manual do Aplicativo - Rastreamento Veicular Manual do Aplicativo - Rastreamento Veicular Sumário Apresentação... 2 Instalação do Aplicativo... 2 Localizando o aplicativo no smartphone... 5 Inserindo o link da aplicação... 6 Acessando o sistema...

Leia mais

Estudo comparativo entre tecnologias Java: Applet e JWS.

Estudo comparativo entre tecnologias Java: Applet e JWS. Estudo comparativo entre tecnologias Java: Applet e JWS. Clara Aben-Athar B. Fernandes¹, Carlos Alberto P. Araújo¹ 1 Centro Universitário Luterano de Santarém Comunidade Evangélica Luterana (CEULS/ULBRA)

Leia mais

WWW - World Wide Web

WWW - World Wide Web WWW World Wide Web WWW Cap. 9.1 WWW - World Wide Web Idéia básica do WWW: Estratégia de acesso a uma teia (WEB) de documentos referenciados (linked) em computadores na Internet (ou Rede TCP/IP privada)

Leia mais

SyncEasy Aplicativo para sincronização de arquivos entre dispositivos móveis e computadores utilizando metadados

SyncEasy Aplicativo para sincronização de arquivos entre dispositivos móveis e computadores utilizando metadados SyncEasy Aplicativo para sincronização de arquivos entre dispositivos móveis e computadores utilizando metadados Acadêmico: Bernardo Marquardt Müller Orientador: Prof. Dr. Mauro Marcelo Mattos Roteiro

Leia mais

AP_ Conta Aplicativo para digitação e envio de contas médicas no padrão TISS

AP_ Conta Aplicativo para digitação e envio de contas médicas no padrão TISS AP_ Conta Aplicativo para digitação e envio de contas médicas no padrão TISS Manual de Instalação Tempro Software StavTISS Sumário 1. INTRODUÇÃO... 2 2. REQUISITOS DO SISTEMA... 3 3. INSTALAÇÃO... 4 4.

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

Leia mais

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Processo de garantia da qualidade baseado no modelo MPS.BR Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Roteiro introdução objetivos do trabalho fundamentação teórica desenvolvimento da ferramenta

Leia mais

Mobile Command. Diego Armando Gusava. Orientador: Mauro Marcelo Mattos

Mobile Command. Diego Armando Gusava. Orientador: Mauro Marcelo Mattos Mobile Command Diego Armando Gusava Orientador: Mauro Marcelo Mattos Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento Implementação Conclusão Extensões Introdução O que me motivou? Solução

Leia mais

GESTÃO DE PEDIDOS EM PLATAFORMA ANDROID:

GESTÃO DE PEDIDOS EM PLATAFORMA ANDROID: GESTÃO DE PEDIDOS EM PLATAFORMA ANDROID: UM SISTEMA PARA ESTABELECIMENTOS DO SETOR GASTRONÔMICO SAMUEL ELIAS BRAVO LOPEZ Prof. Rion Brattig Correia, M.Sc. - Orientador ROTEIRO DA APRESENTAÇÃO Introdução

Leia mais

Desenvolvendo para. Windows 8. Aprenda a desenvolver aplicativos para Windows Phone 8 e Windows 8. Ricardo R. Lecheta. Novatec

Desenvolvendo para. Windows 8. Aprenda a desenvolver aplicativos para Windows Phone 8 e Windows 8. Ricardo R. Lecheta. Novatec Desenvolvendo para Windows 8 Aprenda a desenvolver aplicativos para Windows Phone 8 e Windows 8 Ricardo R. Lecheta Novatec Copyright 2013 da Novatec Editora Ltda. Todos os direitos reservados e protegidos

Leia mais

PAV - PORTAL DO AGENTE DE VENDAS AGL Versão 2.0.6. Manual de Instalação e Demonstração AGL Sistemas Corporativos

PAV - PORTAL DO AGENTE DE VENDAS AGL Versão 2.0.6. Manual de Instalação e Demonstração AGL Sistemas Corporativos PAV - PORTAL DO AGENTE DE VENDAS AGL Versão 2.0.6 Manual de Instalação e Demonstração AGL Sistemas Corporativos Add-on responsável pela integração do SAP Business One com o setor comercial através da internet.

Leia mais

SenchaTouch + PhoneGap

SenchaTouch + PhoneGap SenchaTouch + PhoneGap Ramos de Souza Janones Phonegap.ramosdainformatica.com.br Desenvolvendo para 7 plataformas mobile www.sucessocomsoftware.com.br No mundo Android ios Windows Phone Outros 1% 4% 25%

Leia mais

UM FRAMEWORK PARA DESENVOLVIMENTO DE

UM FRAMEWORK PARA DESENVOLVIMENTO DE UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA UM FRAMEWORK PARA DESENVOLVIMENTO DE APLICATIVOS EM WINDOWS MOBILE. PROPOSTA DE TRABALHO DE GRADUAÇÃO Aluno:

Leia mais

Desenvolvendo para WEB

Desenvolvendo para WEB Nível - Básico Desenvolvendo para WEB Por: Evandro Silva Neste nosso primeiro artigo vamos revisar alguns conceitos que envolvem a programação de aplicativos WEB. A ideia aqui é explicarmos a arquitetura

Leia mais

SISTEMAS OPERACIONAIS MÓVEIS - ANDROID X IOS

SISTEMAS OPERACIONAIS MÓVEIS - ANDROID X IOS SISTEMAS OPERACIONAIS MÓVEIS - ANDROID X IOS Danielle Dias Simões¹, Júlio César Pereira². Universidade Paranaense - Unipar Paranavaí PR - Brasil dannesimoes@hotmail.com juliocesarp@unipar.br Resumo. O

Leia mais

Aula 1 - Introdução e configuração de ambiente de desenvolvimento

Aula 1 - Introdução e configuração de ambiente de desenvolvimento Aula 1 - Introdução e configuração de ambiente de desenvolvimento Olá, seja bem-vindo à primeira aula do curso para desenvolvedor de Android, neste curso você irá aprender a criar aplicativos para dispositivos

Leia mais

Programação para Android

Programação para Android Programação para Android Aula 01: Visão geral do android, instalação e configuração do ambiente de desenvolvimento, estrutura básica de uma aplicação para Android Objetivos Configurar o ambiente de trabalho

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Tipos de Sistemas Operacionais Com o avanço dos computadores foram surgindo alguns tipos de sistemas operacionais que contribuíram para o desenvolvimento do software. Os tipos de

Leia mais

Aplicações Móveis e sua aplicação na saúde: micd, exemplo prático

Aplicações Móveis e sua aplicação na saúde: micd, exemplo prático Aplicações Móveis e sua aplicação na saúde: micd, exemplo prático Leonel Machava Email: leonelmachava@gmail.com MOZAMBICAN OPEN ARCHITECTURES STANDARDS AND INFORMATION SYSTEMS Conteúdo Definição de aplicação

Leia mais

Home Page da Estação Automática do IF-SC

Home Page da Estação Automática do IF-SC Home Page da Estação Automática do IF-SC Ana Paula Jorge Fraga Email: anaa_fraga@hotmail.com Artur da Silva Querino E-mail: arturquerino@gmail.com Kathilça Lopes de Souza E-mail: kathii16@hotmail.com Rayana

Leia mais

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64 direcionados por comportamento 64 5 Estudo de caso Neste capítulo serão apresentadas as aplicações web utilizadas na aplicação da abordagem proposta, bem como a tecnologia em que foram desenvolvidas, o

Leia mais

CA Nimsoft Monitor Mobile

CA Nimsoft Monitor Mobile CA Nimsoft Monitor Mobile Guia do Usuário 7.0 Histórico da revisão do documento Versão do documento Data Alterações 1.0 Setembro 2013 Versão inicial do Nimsoft Mobile 7.0. Avisos legais Copyright 2013,

Leia mais

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Carlos Henrique Pereira WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Florianópolis - SC 2007 / 2 Resumo O objetivo deste trabalho é especificar

Leia mais

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Ferramenta de apoio a gerência de configuração de software Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Gerência de Configuração

Leia mais

// Questões para estudo

// Questões para estudo // Questões para estudo 2 // Ferramentas Básicas de Internet e Web 2.0 1. Sobre a internet, marque a opção correta: A) A internet poder ser definida como uma rede mundial, composta por mihões e milhões

Leia mais

Especificação dos Requisitos do Software. White Label

Especificação dos Requisitos do Software. White Label Ubee Especificação dos Requisitos do Software White Label Review 0.3 Autores: Airton Sampaio de Sobral (asds@cin.ufpe.br) Alan Gomes Alvino (aga@cin.ufpe.br) Glauco Roberto Pires dos Santos (grps@cin.ufpe.br)

Leia mais

ESCOLHA UM TESTE PARA EXECUTAR

ESCOLHA UM TESTE PARA EXECUTAR ESCOLHA UM TESTE PARA EXECUTAR Acompanhe o ritmo de aceleração dos ciclos de lançamento. Descubra a automatização com um toque humano EXECUTE UM TESTE 26032015 Com a Borland, tanto analistas de negócios

Leia mais

Versão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe:

Versão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe: Versão Documento de Requisitos Documento de Requisitos Equipe: Bruno Harada (bhhc) Edilson Augusto Junior (easj) José Ivson Soares da Silva (jiss) Pedro Rodolfo da Silva Gonçalves (prsg) Raphael

Leia mais

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1 DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1 SUMÁRIO DEFINIÇÃO DE REQUISITOS 4 1. INTRODUÇÃO 4 1.1 FINALIDADE 4 1.2 ESCOPO 4 1.3 DEFINIÇÕES, ACRÔNIMOS

Leia mais

Facilidade e flexibilidade na web

Facilidade e flexibilidade na web Facilidade e flexibilidade na web palavras-chave: acessibilidade, usabilidade, web 2.0 Tersis Zonato www.tersis.com.br Web 2.0 o termo de marketing x a nova forma de conhecimento Web 2.0 O conceito começou

Leia mais

Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões. Prof. MSc. Hugo Souza

Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões. Prof. MSc. Hugo Souza Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões Prof. MSc. Hugo Souza Se você precisar manter informações sobre seus usuários enquanto eles navegam pelo seu site, ou até quando eles saem

Leia mais

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

Leia mais

Universidade Católica de Pelotas. Centro Politécnico. Analise e Desenvolvimento de Sistema LET S RUNNING. Por. Guilherme Carvalho Gehling

Universidade Católica de Pelotas. Centro Politécnico. Analise e Desenvolvimento de Sistema LET S RUNNING. Por. Guilherme Carvalho Gehling Universidade Católica de Pelotas Centro Politécnico Analise e Desenvolvimento de Sistema LET S RUNNING Por Guilherme Carvalho Gehling Documento de conclusão da disciplina de Trabalho de Curso II Orientador.

Leia mais

SISTEMA DE CONTROLE INTERNO DE FLUXO DE CAIXA DO SETOR DE APOIO FINANCEIRO (ULBRA GUAÍBA)

SISTEMA DE CONTROLE INTERNO DE FLUXO DE CAIXA DO SETOR DE APOIO FINANCEIRO (ULBRA GUAÍBA) SISTEMA DE CONTROLE INTERNO DE FLUXO DE CAIXA DO SETOR DE APOIO FINANCEIRO (ULBRA GUAÍBA) Alessandra Lubbe 1 Alexandre Evangelista 2 Jeandro Perceval 3 José Ramiro Pereira 4 Luiz Gustavo Mahlmann 5 RESUMO

Leia mais

4.0 SP2 (4.0.2.0) maio 2015 708P90911. Xerox FreeFlow Core Guia de Instalação: Windows 8.1 Update

4.0 SP2 (4.0.2.0) maio 2015 708P90911. Xerox FreeFlow Core Guia de Instalação: Windows 8.1 Update 4.0 SP2 (4.0.2.0) maio 2015 708P90911 2015 Xerox Corporation. Todos os direitos reservados. Xerox, Xerox com a marca figurativa e FreeFlow são marcas da Xerox Corporation nos Estados Unidos e/ou em outros

Leia mais

PROGRAMANDO ANDROID NA IDE ECLIPSE GABRIEL NUNES, JEAN CARVALHO TURMA TI7

PROGRAMANDO ANDROID NA IDE ECLIPSE GABRIEL NUNES, JEAN CARVALHO TURMA TI7 Serviço Nacional de Aprendizagem Comercial do Rio Grande do Sul Informação e Comunicação: Habilitação Técnica de Nível Médio Técnico em Informática Programação Android na IDE Eclipse PROGRAMANDO ANDROID

Leia mais

Agregador de feeds RSS para dispositivos móveis

Agregador de feeds RSS para dispositivos móveis Agregador de feeds RSS para dispositivos móveis Disciplina: Computação Móvel Professor: Mauro Nacif Rocha Data: 27/02/2007 Hadriel Toledo Lima 50290 Juliana Pinheiro Campos 47683 Luis Felipe Hussin Bento

Leia mais

Desenvolvimento em Smartphones - Aplicativos Nativos e Web

Desenvolvimento em Smartphones - Aplicativos Nativos e Web Desenvolvimento em Smartphones - Aplicativos Nativos e Web Jan Miszura Toledo 1, Gilcimar Divino de Deus 2 1 Departamento de Computação - Pontifícia Universidade Católica de Goiás - GO - Brasil janmiszura@gmail.com

Leia mais

Manual Vivo Sync. Manual do Usuário. Versão 1.0.0. Copyright Vivo 2013. http://vivosync.com.br

Manual Vivo Sync. Manual do Usuário. Versão 1.0.0. Copyright Vivo 2013. http://vivosync.com.br Manual do Usuário Versão 1.0.0 Copyright Vivo 2013 http://vivosync.com.br 1 1 Índice 1 Índice... 2 2 Vivo Sync... 5 3 Vivo Sync Web... 6 3.1 Página Inicial... 6 3.1.1 Novo Contato... 7 3.1.2 Editar Contato...

Leia mais

NOVO COMPONENTE ASSINADOR ESEC

NOVO COMPONENTE ASSINADOR ESEC NOTAS FISCAIS DE SERVIÇO ELETRÔNICAS PREFEITURA DE JUIZ DE FORA COMPLEMENTO AO SUPORTE A ATENDIMENTO NÍVEL 1 1.0 Autor: Juiz de Fora, Fevereiro 2015. PÁGINA 1 DE 38 SUMÁRIO 1REQUISITOS MÍNIMOS CONFIGURAÇÕES

Leia mais

ATA - Exercícios Informática Carlos Viana. 2012 Copyright. Curso Agora eu Passo - Todos os direitos reservados ao autor.

ATA - Exercícios Informática Carlos Viana. 2012 Copyright. Curso Agora eu Passo - Todos os direitos reservados ao autor. ATA - Exercícios Informática Carlos Viana 2012 Copyright. Curso Agora eu Passo - Todos os direitos reservados ao autor. ATA EXERCÍCIOS CARLOS VIANA 01 -Existem vários tipos de vírus de computadores, dentre

Leia mais

Aplicativo de inicialização rápida Novell Filr 1.0.2 Mobile

Aplicativo de inicialização rápida Novell Filr 1.0.2 Mobile Aplicativo de inicialização rápida Novell Filr 1.0.2 Mobile Setembro de 2013 Novell Inicialização rápida O Novell Filr permite que você acesse facilmente todos os seus arquivos e pastas do desktop, browser

Leia mais

Computação II Orientação a Objetos

Computação II Orientação a Objetos Computação II Orientação a Objetos Fabio Mascarenhas - 2014.1 http://www.dcc.ufrj.br/~fabiom/java Android Android é um sistema operacional para dispositivos móveis Kernel Linux, drivers e bibliotecas do

Leia mais

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013 A DIRETORIA DE INFORMÁTICA DINFO DA UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO -UERJ, no uso de suas atribuições legais, estabelece: Art. 1º: Para fins de normatização do Desenvolvimento Tecnológico na UERJ

Leia mais

SISTEMA BASEADO EM LOCALIZAÇÃO DE SERVIÇOS DE TÁXI

SISTEMA BASEADO EM LOCALIZAÇÃO DE SERVIÇOS DE TÁXI SISTEMA BASEADO EM LOCALIZAÇÃO DE SERVIÇOS DE TÁXI Acadêmico: Arthur Henrique Kienolt Orientador: Prof. Dr. Mauro Marcelo Mattos ROTEIRO Introdução Objetivos do trabalho Fundamentação teórica Desenvolvimento

Leia mais

Navegador ou browser, é um programa de computador que permite a seus usuários a interagirem com documentos virtuais da Internet.

Navegador ou browser, é um programa de computador que permite a seus usuários a interagirem com documentos virtuais da Internet. TERMINOLOGIA Navegador ou Browser Navegador ou browser, é um programa de computador que permite a seus usuários a interagirem com documentos virtuais da Internet. Os Browsers se comunicam com servidores

Leia mais

Guia do Laboratório de Teste: Demonstre colaboração de Intranet com SharePoint Server 2013

Guia do Laboratório de Teste: Demonstre colaboração de Intranet com SharePoint Server 2013 Guia do Laboratório de Teste: Demonstre colaboração de Intranet com SharePoint Server 2013 Este documento é fornecido no estado em que se encontra. As informações e exibições expressas neste documento,

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE UMA API DE SERVIÇO RESTFUL INTEGRADO COM UMA APLICAÇÃO MÓVEL ANDROID PARA O SETOR IMOBILIÁRIO

METODOLOGIA DE DESENVOLVIMENTO DE UMA API DE SERVIÇO RESTFUL INTEGRADO COM UMA APLICAÇÃO MÓVEL ANDROID PARA O SETOR IMOBILIÁRIO CENTRO UNIVERSITÁRIO EURÍPIDES DE MARÍLIA FUNDAÇÃO DE ENSINO EURÍPIDES SOARES DA ROCHA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO METODOLOGIA DE DESENVOLVIMENTO DE UMA API DE SERVIÇO RESTFUL INTEGRADO

Leia mais

TEMA TECNOLOGIA DA INFORMAÇÃO -Tipos de SI e Recursos de Software parte2. AULA DE SISTEMAS DE INFORMAÇÃO PROFa. ROSA MOTTA

TEMA TECNOLOGIA DA INFORMAÇÃO -Tipos de SI e Recursos de Software parte2. AULA DE SISTEMAS DE INFORMAÇÃO PROFa. ROSA MOTTA TEMA TECNOLOGIA DA INFORMAÇÃO -Tipos de SI e Recursos de Software parte2 AULA DE SISTEMAS DE INFORMAÇÃO PROFa. ROSA MOTTA CONTEÚDO DA AULA Tipos de Software Serviços Web Tendências 2 OBJETIVOS ESPECÍFICOS

Leia mais

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

Leia mais

Manual de Instalação KIT DVR VENTURA Parte 1: Conexões Parte 2: Configurações de rede Parte 3: Acesso via telefone móvel

Manual de Instalação KIT DVR VENTURA Parte 1: Conexões Parte 2: Configurações de rede Parte 3: Acesso via telefone móvel 1 Manual de Instalação KIT DVR VENTURA Parte 1: Conexões Parte 2: Configurações de rede Parte 3: Acesso via telefone móvel Parte 1: Conexões 2 Instalação do Disco Rídigo (HD) Primeiro é necessário a instalação

Leia mais

UNIVERSIDADE SALGADO DE OLIVEIRA Pró-Reitoria de Pós-graduação e Pesquisa

UNIVERSIDADE SALGADO DE OLIVEIRA Pró-Reitoria de Pós-graduação e Pesquisa 1. Título do Curso Desenvolvimento de Aplicações Móveis 2. Justificativa O crescimento acentuado de dispositivos móveis como celulares, smartphones, tablets e outros, e as mudanças no comportamento dos

Leia mais

ANEXO 05 ARQUITETURAS TECNOLÓGICAS PROCERGS

ANEXO 05 ARQUITETURAS TECNOLÓGICAS PROCERGS ANEXO 05 ARQUITETURAS TECNOLÓGICAS PROCERGS Este anexo apresenta uma visão geral das seguintes plataformas: 1. Plataforma Microsoft.NET - VB.NET e C#; 2. Plataforma JAVA; 3. Plataforma Android, ios e Windows

Leia mais

Manual de instalação e configuração da Ferramenta Android SDK

Manual de instalação e configuração da Ferramenta Android SDK Trabalho de Programação para Dispositivos Móveis Turma: 1011 Camila Botelho camilacunhabotelho@gmail.com Manual de instalação e configuração da Ferramenta Android SDK Introdução O Android é uma ferramenta

Leia mais

Modelo: H.264 Câmera IP (1.0 Megapixels) guia de instalação rápida

Modelo: H.264 Câmera IP (1.0 Megapixels) guia de instalação rápida 1 Modelo: H.264 Câmera IP (1.0 Megapixels) guia de instalação rápida 1. Colocado diretamente no desktop Colocou a câmera IP na posição adequada 2 2. Montagem na parede O suporte com o parafuso de bloqueio

Leia mais

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Juarez Bachmann Orientador: Alexander Roberto Valdameri Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento

Leia mais