Introdução - Entrega.docx
Propaganda
0 UNIVERSIDADE SÃO FRANCISCO Engenharia de Computação ALLAN NICOLAU DE CAMPOS ROMANATO JESSICA BORGES ROSENDO LUIZ CAIO FERREIRA SISTEMA CRIPTOGRAFADO DE VOTAÇÃO INTERATIVA PARA ANDROID Itatiba 2014 1 UNIVERSIDADE SÃO FRANCISCO Engenharia de Computação ALLAN NICOLAU DE CAMPOS ROMANATO – R.A. 002201201564 JESSICA BORGES ROSENDO – R.A. 002201000449 LUIZ CAIO FERREIRA – R.A. 002200900033 SISTEMA CRIPTOGRAFADO DE VOTAÇÃO INTERATIVA PARA ANDROID Monografia apresentada ao Curso de Engenharia de Computação da Universidade São Francisco, como exigência para conclusão do curso de graduação. Orientador: Prof. Esp. Felipe Cavalaro Itatiba 2014 2 AGRADECIMENTOS Agradeço aos meus pais, Mônica e Sergio, pelo apoio que sempre me deram desde a infância, me incentivando a estudar e ser alguém na vida. Cintia, minha companheira em todos os momentos, que teve toda a paciência comigo durante todos esses anos e por acreditar que eu conseguiria. A todo o corpo docente que contribuiu para minha formação profissional, especialmente, ao meu orientador Prof. Esp. Felipe Cavalaro pela paciência com a qual orientou este trabalho. Agradeço aos meus mestres que sempre me orientaram para que triunfasse sobre as dificuldades. Allan Nicolau de Campos Romanato Agradeço a Deus, primeiramente, que permitiu o meu acesso ao ensino superior, me concedendo saúde, força e sabedoria para superar todas as dificuldades. A Universidade São Francisco e a ONG Educafro, que em parceria, me ofereceram a oportunidade de realizar o curso. A todo o corpo docente que contribuiu para minha formação profissional, especialmente, ao meu orientador Prof. Esp. Felipe Cavalaro, pelo confiança, apoio e paciência com a qual orientou este trabalho. Aos meus pais Claudio e Marlene, que sempre me incentivaram em meus estudos e, sem medir esforços, me deram todo o suporte necessário para que eu pudesse chegar até esta etapa da minha vida. Às minhas irmãs Caroline e Camila, por alegrarem os meus dias e por acreditarem na minha capacidade de realizar qualquer coisa. 3 Aos meus parceiros neste trabalho Allan e Luiz Caio, pela amizade, companheirismo e, principalmente pela paciência diante dos contratempos. Aos colegas de classe, que direta ou indiretamente fizeram parte da minha formação, o meu muito obrigado. Jessica Borges Agradeço primeiramente à minha mãe, Marivelse Gorte, meu espelho, minha inspiração, que me deu não somente o incentivo inicial para essa jornada, mas também a enorme força de superação e convicção que utilizo diariamente pra superar esse e outros desafios impostos pela vida. Bianca Eweny, hoje minha esposa, minha eterna companheira, com quem compartilhei cada momento nesse período e que teve grande paciência e compreensão com a minha ausência em certos momentos. Agradeço também aos poucos, porém fieis amigos que cultivei nesse curto espaço de tempo e que espero poder manter para o resto da minha vida. Eles com certeza tornaram essa jornada mais estimulante e menos árdua. Luiz Felipe, Thiago Duarte, Paulo Cesar, Bruna Luz, João Vitor, Phelipe Conrado, Renan Rosa, Guilherme Araújo, Juliano Darlin e Mateus Cruz. E finalmente, expresso a minha gratidão aos ótimos professores com quem tive o prazer e a honra de me graduar nesta faculdade. Renato Camargo, Silvio Petroli, Fábio Andrijauskas, Milena Moretto, Andre Bakalereskis, entre outros, e em especial ao nosso prezado orientador Felipe Cavalaro. Luiz Caio Ferreira 4 “A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original.” Albert Einstein 5 RESUMO Com o avanço tecnológico das últimas décadas, seu barateamento e alcance na sociedade atual, fica evidente que cada vez mais tarefas do nosso cotidiano que anteriormente eram executadas de forma manual ou verbal, passaram a ser realizadas de forma mais ágil e eficiente. O objetivo do presente trabalho é criar de um sistema criptografado de votação interativa para Android. Demonstrando a possibilidade de empregar esse conceito como ferramenta aos professores em sala de aula, melhorando o nível de comunicação e interatividade entre eles e seus alunos. Para o desenvolvimento do sistema proposto foi utilizada a linguagem de programação Java e Java EE para as aplicações, servidor e cliente, HTML5 e Android Studio para as interfaces com usuários e a DBMS escolhida foi a MySQL. Em conjunto, também será analisada a viabilidade da utilização da criptografia AES, recurso que promove a segurança das informações trocadas durante a comunicação entre os clientes e o servidor na rede. Ao final, evidenciamos através de testes elevando ao limite a quantidade de conexões simultâneas, simulando ataques de interceptação de dados e comparando o desempenho em função do tempo, demonstrando que o sistema de votação desenvolvido pode ser implantado com sucesso em uma rede local, desempenhando sua função com eficiência e segurança. Palavras-chaves: android. criptografia. interatividade. votação interativa. 6 ABSTRACT With technological advances in recent decades, its cheapness and scope in today's society, it is clear that more and more, our daily tasks that were previously performed manually or verbal, started to be realized in a faster way through the aid of these technologies. The aim of this study is to create an encrypted system of interactive voting for Android. With this, we can demonstrate how this concept can be used to aid teachers in the classroom, improving the level of communication and interaction between them and their students. To develop the system, we used the Java programming language and Java EE for applications, HTML5 and Android Studio for user interfaces and the chosen DBMS was MySQL. Together, will also be analyzed the viability of using the AES encryption, resource that promotes information security. Finally, evidenced by testing the amount increasing to a limit of simultaneous connections, simulating the information security attacks and the speed performance, the system can be deployed successfully and safely in a local network. Keywords: android: encryption. interactivity. interactive voting. 7 LISTA DE ILUSTRAÇÕES FIGURA 01 – Arquitetura do Android................................................................................. 20 FIGURA 02 – Comparando modelo OSI com modelo TCP/IP........................................... 21 FIGURA 03 – Cabeçalho do TCP...................................................................................... 23 FIGURA 04 – Estabelecimento de conexão TCP.............................................................. 24 FIGURA 05 – Comunicação de processos através de sockets......................................... 26 FIGURA 06 – Máquina virtual Java.................................................................................... 28 FIGURA 07 – Conexão com banco de dados através do JDBC........................................ 29 FIGURA 08 – Arquitetura de servlet.................................................................................. 31 FIGURA 09 – Estrutura do sistema.................................................................................... 33 FIGURA 10 – IDE Eclipse utilizada no desenvolvimento da aplicação “servidor web”.... 35 FIGURA 11 – IDE Android Studio utilizada no desenvolvimento da aplicação “cliente”.... 35 FIGURA 12 – Tabela de dados do sistema no MySQL..................................................... 36 FIGURA 13 – Fluxograma sistema.................................................................................... 37 FIGURA 14 – Estrutura das tabelas no banco de dados................................................... 40 FIGURA 15 – Pipeline de comunicação............................................................................. 42 FIGURA 16 – Tela de login da interface do servidor......................................................... 44 FIGURA 17 – Tela de perguntas e respostas.................................................................... 45 FIGURA 18 – Tela de resultados das respostas................................................................ 46 FIGURA 19 – Tela principal da interface do cliente........................................................... 47 FIGURA 20 – Tela de acesso ao servidor......................................................................... 48 FIGURA 21 – Tela de cadastro de clientes........................................................................ 49 FIGURA 22 – Tela de votação........................................................................................... 50 FIGURA 23 – Tela de aviso de tentativa de reincidência de votação................................ 51 8 FIGURA 24 – Tela de despedida e encerramento da votação....................................... 52 FIGURA 25 – Teste de tempo de conexão cliente-servidor sem criptografia.................... 53 FIGURA 26 – Teste de tempo de conexão cliente-servidor com criptografia.................... 54 FIGURA 27 – Demonstração do teste de conexão ao servidor......................................... 55 FIGURA 28 – Demonstração do limite de conexão atingido.............................................. 56 FIGURA 29 – Demonstração do tráfego antes e depois da criptografia............................ 57 FIGURA 30 – Demonstração do tráfego antes e depois da criptografia............................ 57 9 LISTA DE TABELAS TABELA 1 – Propriedade servidor do sistema de votação....................................... 34 TABELA 2 – Propriedade servidor de banco de dados............................................ 34 10 LISTA DE ABREVIATURAS E SIGLAS API – Application Programming Interface CSS3 – Cascading Style Sheets DBMS – Database Management System DVM – Dalvik Virtual Machine GPL – General Public License GSM – Global System for Mobile Communications HTML – HyperText Markup Language HTTP – HyperText Transfer Protocol IBM – International Business Machines Corporation IDC – International Data Corporation IP – Internet Protocol ISO – International Organization for Standardization JDBC – Java Database Connectivity JSON – JavaScript Object Notation JVM – Java Virtual Machine Kbps – Kilobits por segundo LAN – Local Area Network LED – Light Emitting Diode 11 LTS – Long Term Support OHA – Open Handset Alliance OSI – Open Systems Interconnection RMI – Remote Method Invocation RPC – Remote Procedure Call SMS – Short Message Service SSL – Secure Socket Layer TCP – Transmission Control Protocol TSE – Tribunal Superior Eleitoral UDP – User Datagram Protocol URL – Uniform Ressource Locator W3C – World Wide Web Consortium XHTML– Extensible Hypertext Markup Language XML – Extension Markup Language 12 SUMÁRIO 1. INTRODUÇÃO ................................................................................................................ 14 2. DESENVOLVIMENTO ..................................................................................................... 16 2.1. Fundamentação teórica .............................................................................................. 16 2.1.1. História do voto........................................................................................................ 16 2.1.2. Interatividade ........................................................................................................... 17 2.1.3. Sistema Operacional ............................................................................................... 18 2.1.3.1. Android .................................................................................................................. 18 2.1.3.1.1. Arquitetura.......................................................................................................... 19 2.1.4. Protocolos de comunicação de rede...................................................................... 20 2.1.4.1. Protocolo TCP (Transmition Control Protocol) ................................................... 22 2.1.5. Comunicação entre processos ............................................................................... 24 2.1.5.1. Comunicação cliente-servidor através de sockets............................................. 25 2.1.6. Java .......................................................................................................................... 27 2.1.6.1. Acesso a bancos de dados com JDBC ............................................................... 28 2.1.6.2. Servlets .................................................................................................................. 30 2.1.6.2.1. Arquitetura de servlets ...................................................................................... 31 2.1.6.7. Servidor Web Apache ........................................................................................... 32 3. METODOLOGIA .............................................................................................................. 33 3.1. Ferramentas ............................................................................................................. 33 3.1.1. Desenvolvendo as interfaces do usuário ............................................................... 36 3.1.2. Fluxo de funcionamento do sistema ...................................................................... 31 3.1.2.1. Ambiente ............................................................................................................... 31 3.1.2.2. Comunicações multiplas ...................................................................................... 31 3.1.2.3. Comunicação Cliente x Servidor ......................................................................... 31 13 3.1.2.4. Armazenamento de Respostas ............................................................................ 31 3.1.2.5. Servidor Java ........................................................................................................ 40 3.1.2.6. Cliente Android ..................................................................................................... 41 3.1.2.7. Pipeline .................................................................................................................. 42 3.1.2.8. Criptografia............................................................................................................ 42 4. RESULTADOS ................................................................................................................ 44 4.1. Interface Web “Servidor” .......................................................................................... 44 4.2. Inteface Android “Cliente” ......................................................................................... 46 4.3. Criptografia ................................................................................................................. 53 5. CONCLUSÃO .................................................................................................................. 58 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................... 59 14 1. INTRODUÇÃO Com o início da civilização as pessoas foram se juntando em pequenos grupos sociais, dando origem às aldeias, vilas e cidades, surgindo a necessidade da tomada de decisões em grupo para a resolução de um problema em comum. Tal fato culminou no formato de tomada de opinião conhecido hoje, podendo ser chamado de votação, quiz, enquete, entre outros. Geralmente o formato empregado é o seguinte: um tema é proposto e colocado em questão, disponibilizando para os participantes algumas alternativas a serem escolhidas. Entretanto, esse tipo de sistema nem sempre foi confiável, pois geralmente sofria algum tipo de fraude devido à fácil alteração e manipulação das respostas, já que esse método era realizado de forma manual através de cédulas de papel e urnas de madeira ou lona. Hoje, com o avanço da tecnologia pode-se facilmente criar um sistema de perguntas e respostas semelhante, porém de forma virtual onde seja possível evitar computacionalmente que as respostas sejam alteradas, obtendo um sistema onde o sigilo e sua totalização seja confiável e comprovado. Para que o sistema possa existir de forma funcional, onde seja possível coletar os votos de diversos indivíduos, é necessário que ele seja aplicado sobre uma rede virtual. Para isso pode-se utilizar um dos aparelhos mais utilizados para comunicação entre as pessoas de todo o planeta: o celular. Criado pela tecnologia recente, o celular contribuiu para reduzir a distância entre as pessoas, melhorando a forma e a velocidade da comunicação entre elas ao redor do planeta, gerando uma “rede”. Em se tratando de um aparelho mundialmente disseminado, entende-se que a criação de um sistema de perguntas e respostas que rode nessa plataforma tornaria o ato de tomada opinião muito mais prático e rápido, possibilitando sua aplicação em diversos ambientes. 15 Sendo assim, o presente trabalho objetiva implementar um sistema criptografado de votação interativa desenvolvido para plataforma Android, que possa ser aplicado em ambiente educativo para dinamizar a interação entre o professor e aluno. 16 2. DESENVOLVIMENTO 2.1. Fundamentação teórica 2.1.1. História do voto Com o advento da democracia que data do início do século 5 a.C. na cidade-Estado de Atenas, na Grécia, as decisões sobre os mais diversos temas sociais passaram a ser tomadas obtendo a opinião de todos os envolvidos através de uma votação não secreta, na qual o voto era declarado publicamente e em voz alta, algo muito constrangedor e perigoso para época (SOUSA, 2014). Segundo Sousa (2014), por volta do século 2 a.C., com o intuito de preservar o sigilo do voto e evitar constrangimento pra o eleitor, os romanos tiveram a ideia de utilizar cédulas onde o voto era gravado de forma manual através da escrita e depositado em uma urna que posteriormente seria aberta para apuração dos votos, também de forma manual. Essa técnica ainda é utilizada em diversas partes do mundo. No Brasil, a primeira votação data de 1532 e ocorreu na vila de São Vicente, convocada por seu donatário, Martim Afonso de Souza, que tinha a finalidade de escolher o Conselho administrativo da vila (SENA, 2014). Segundo informações do Tribunal Superior Eleitoral (TSE), os votos nessa época eram depositados em bolas de cera chamadas pelouros, depois surgiram urnas de madeira, as de ferro e as de lona. Entretanto, desde o início, a democracia sofre com a existência de fraudes quase que inevitáveis em toda extensão do processo de votação, desde o cadastramento do eleitor, votação e apuração dos votos. 17 Visando evitar possíveis manipulações, o sistema de votação brasileiro vem sofrendo diversas alterações principalmente durante a República. O último e mais importante passo para o aperfeiçoamento das votações foi a implantação, em 2000, de um sistema de votação informatizado através de urnas eletrônicas que tem como objetivo principal garantir o total sigilo para o eleitor, confiabilidade e agilidade na totalização dos votos, utilizando uma interface o mais interativa possível, de fácil aprendizagem e máxima acessibilidade. 2.1.2. Interatividade Lemos (2000), descreve a interatividade como uma nova maneira de relação dos seres humanos com as máquinas, já para Alex Primo (2007), a interatividade não tem significado, mas sim a interação entre os seres humanos, que podem ser mediadas por computadores. Segundo Marcos Silva (2014), a interatividade é um conceito de comunicação. Pode ser empregado para significar a comunicação entre interlocutores humanos, entre humanos e máquinas e entre usuário e serviço. O desenvolvimento de uma nova abordagem propõe a interatividade como ponto central e de grande importância em um novo sistema de votação. Esse mesmo conceito pode ser facilmente empregado e adaptado para outras áreas menos formais da sociedade, podendo ser aplicado em situações mais cotidianas, como por exemplo, em palestras e seminários, nas áreas empresarial e comercial, bem como na área educacional. O modelo de ensino tradicional vem sendo questionado há muito tempo. A uniformidade e unidirecionalidade do ensino enraizado com a figura do professor como emissor-ditador da mensagem e do aluno receptor não acompanha a velocidade das novas gerações que nasceram na era da tecnologia. Conhecidos como geração x e y, esses alunos são imersos em recursos tecnológicos que possibilitam fazer, justamente, o que não podem em sala de aula, ou seja, interagir com a informação que contribuirá em sua formação escolar, tornando-se cocriadores (Carlos Silva) e tomando para si, em certos momentos, o lugar do emissor. 18 Se analisarmos as gradações de interatividade propostas por Francis Kretz (1985 apud Santaella, 2004), um sistema de votação para Android se encaixa no nível mais alto de interatividade e criação, no qual o usuário tem a possibilidade de compor uma mensagem, no caso o seu voto, contribuindo para o produto ou resultado final. 2.1.3. Sistema Operacional Segundo Tanenbaum (2003a), Sistema Operacional é um programa responsável pelo controle dos recursos da máquina, processadores, memória principal, discos, interface de rede e outros dispositivos de entrada e saída, e por fornecer a base sobre as quais outros programas e aplicativos possam ser criados. O primeiro sistema operacional móvel criado foi o WebOS, lançado em 1996 desenvolvido pela Palm, adquirida posteriormente pela Hewlett-Parckard. Desde então surgiram diversos sistemas concorrentes brigando pelo domínio desse novo mercado, podendo ser citado entre eles o Symbian, IOS, Windows Mobile, MeeGo Brew mp, Blackberry. Entretanto o sistema que ocupa o topo no mercado mundial atualmente é o Android (COSTA; DUARTE FILHO, 2013) 2.1.3.1. Android É um sistema operacional mobile open source baseado em Linux, desenvolvido pela Open Handset Alliance (OHA), uma fundação sem fins lucrativos que inclui fabricantes de aparelhos eletrônicos, empresas de telefonia e desenvolvimento de software. Uma das vantagens do sistema é ter a plataforma livre e não ser preso a um hardware específico, possibilitando a qualquer fabricante ou desenvolvedor alterar o sistema e criar 19 aplicativos para o aparelho tendo acesso irrestrito ao hardware. A linguagem utilizada para o desenvolvimento é o Java (MORIMOTO, 2009). O Android proporciona ao usuário uma navegação intuitiva disponibilizando atalhos para os aplicativos e várias telas que podem ser alternadas, auxiliando na organização destes. É possível visualizar notificações e checar o estado de recursos apenas acessando uma aba superior que é expandida com o passar de dedos. Grande parte da estratégia em torno do Android é centrada no desenvolvimento de aplicativos por parte de outras empresas e programadores independentes. A Google entendeu que, assim como nos desktops, as plataformas de smartphones estão se consolidando e os aplicativos passaram a ser funções básicas do sistema e não o hardware (MORIMOTO, 2009). 2.1.3.1.1. Arquitetura O sistema operacional Android funciona como uma pilha de softwares. Como pode ser observado na figura 01, cada camada da pilha contêm vários programas que suportam algumas funções específicas do sistema operacional. A soma dessas pilhas forma o sistema como um todo (STRICKLAND, 2014). Na base da pilha está o Kernel, baseado em Linux na versão 2.6. Nessa parte ocorre o gerenciamento de memória, configurações de segurança, gerenciamento de energia e drivers de hardware. No próximo nível encontram-se as bibliotecas C/C++ do Android, que são conjuntos de instruções que auxiliam o dispositivo no tratamento de diferentes tipos de dados. Em conjunto, existem as bibliotecas do núcleo Java e a Máquina Virtual Dalvik (DVM). A máquina virtual é uma aplicação de software que simula um dispositivo independente, rodando seus próprios processos e, consequentemente, fornecendo robustez ao Android. Assim, nenhuma aplicação fica dependente da outra, não afetando o sistema como um todo caso alguma delas parem. A DVM, também auxilia no gerenciamento de memória. 20 Fonte: http://www.devmedia.com.br FIGURA 01 – Arquitetura do Android. A próxima camada chama-se framework de aplicação, onde estão os programas de gerenciamento de funções básicas como alocação de recursos, mudança entre processos e programas Os desenvolvedores tem acesso total ao framework, podendo desenvolver aplicações mais complexas. No topo da pilha existe a aplicação, camada onde é feita a interação com o usuário, como efetuar ligação, acesso ao navegador, aplicativos, lista de contatos, entre outros. 2.1.4. Protocolos de comunicação de rede Segundo Kurose e Ross (2006), para que dispositivos na rede possam estabelecer uma comunicação entre si, é necessário utilizar regras e convenções, conhecidas como protocolos, que controlam o formato e a ordem das informações trocadas por essas entidades durante o diálogo. 21 Entre os principais protocolos da Internet estão o IP (Internet Protocol), o TCP (Transmission Control Protocol) e o UDP (User Datagram Protocol), sendo os dois últimos importantes protocolos da camada de transporte do modelo de referência TCP/IP. Esse modelo é baseado no modelo OSI, uma arquitetura de rede de sete camadas criada pela ISO (International Organization for Standardization) para padronizar os protocolos existentes nessas camadas, possibilitando a comunicação de sistemas abertos (TANENBAUM, 2003b). O modelo TCP/IP, de acordo com Tanenbaum (2003b), apresenta apenas quatro camadas em sua arquitetura de rede, se comparado ao modelo OSI, como pode ser observado na figura 02. Fonte: TANENBAUM (2003b) FIGURA 02 – Comparando modelo OSI com modelo TCP/IP. A camada de aplicação define como os processos de uma aplicação, em sistemas finais diferentes, trocam mensagens entre si. Nessa camada encontram-se todos os protocolos de nível mais alto, como o TELNET, o FTP, o SMTP, o DNS, o HTTP, entre muitos outros. A camada de transporte tem como finalidade permitir que as entidades de origem e de destino, em uma interconexão, mantenham uma conversação. Como foi relatado, anteriormente, dois protocolos fim a fim são importantes aqui: TCP e UDP. A camada inter-redes permite que os hosts injetem pacotes em qualquer rede e garante que eles trafegarão até o destino. Esses pacotes podem chegar de forma desordenada daquela em que foram enviados, obrigando as camadas superiores a reorganizá-los, se necessário. 22 A camada de host/rede não é padronizada no TCP/IP, por isso, somente sabe-se que o host tem de se conectar a rede utilizando algum protocolo para que seja possível enviar pacotes IP. Redes TCP/IP, como observam Kurose e Ross (2006), oferecem dois tipos de serviços às aplicações de sistemas finais: serviço não orientado para conexão (UDP) e serviços orientados para conexão (TCP). Como a maioria das aplicações da Internet necessita de um serviço orientado a conexão, com entrega de dados confiável e em sequência, o presente trabalho focará em comunicação de sistemas com a utilização do protocolo TCP. 2.1.4.1. Protocolo TCP (Transmition Control Protocol) De acordo com Tanenbaum (2003b), o TCP é um protocolo orientado a conexões que tem como principal objetivo transportar bytes fim a fim em segurança, mesmo em uma interrede (Internet), se adaptando dinamicamente e buscando evitar problemas que possam ocorrer durante a transmissão das informações. Para solucionar alguns desses problemas esse protocolo provê serviços essenciais à comunicação entre dois computadores de uma rede, como transferência confiável, controle de fluxo e controle de congestionamentos de pacotes de dados. As entidades transmissoras e receptoras do TCP, de acordo com Tanenbaum (2003b), trocam dados na forma de segmentos, como pode ser observado na figura 03. Cada segmento tem um cabeçalho de formato fixo de 20 bytes e pode conter até 65.535 bytes de dados, quando for o caso. 23 Fonte: TANENBAUM (2003b) FIGURA 03 – Cabeçalho do TCP. O estabelecimento da conexão TCP normal entre dois computadores (cliente e servidor), conhecido como 3-Way Handshake, figura 04, é realizado em três etapas, afirma Kurose e Ross (2006): Primeiro, o TCP cliente envia um segmento SYN para o TCP servidor, encapsulando-o em um datagrama IP. O servidor extrai o segmento SYN do datagrama, aloca buffers e variáveis TCP à conexão e envia um segmento de aceitação SYNACK para o TCP cliente. Após receber o segmento SYNACK, o cliente também aloca buffers e variáveis à conexão. Então, o cliente envia outro segmento, reconhecendo o segmento de confirmação de conexão do servidor. 24 Fonte: TANENBAUM (2003b) FIGURA 04 – Estabelecimento de conexão TCP 2.1.5. Comunicação entre processos Os computadores modernos são capazes de executar vários programas ao mesmo tempo. Em sistemas multiprogramados, os softwares utilizam a comunicação entre seus processos para realizar diversas tarefas (TANENBAUM, 2003a). Essa comunicação deve ocorrer, preferencialmente, de maneira bem estruturada e sem interrupções, seja quando os processos estiverem rodando no mesmo sistema final, no qual a comunicação acontece através de recursos como o compartilhamento de uma memória comum, ou quando os processos estiverem em execução em diferentes sistemas finais, comunicandose através da troca de mensagens pela rede, utilizando mecanismos como sockets, RMI (Remote Method Invocation) ou RPC (Remote Procedure Call) (SILBERSCHATZ; GALVIN; GAGNE, 2000). Pela natureza da proposta, o presente trabalho dará ênfase à comunicação em rede através de sockets, descrevendo seus principais conceitos e características de implementação. 25 2.1.5.1. Comunicação cliente-servidor através de sockets A maioria das aplicações de rede consiste, essencialmente, em pares de processos comunicantes que enviam mensagens um para o outro. Todas as mensagens trocadas entre uma aplicação cliente-servidor são organizadas segundo um protocolo, isto é, um conjunto de regras que definem o formato do conteúdo da mensagem para que ela seja inteligível a ambas as partes envolvidas na troca de mensagens (SILBERSCHATZ; GALVIN; GAGNE, 2000). Segundo Kurose e Ross (2006), na Internet, por exemplo, o processo cliente de um browser troca mensagens com o processo de um servidor Web. Qualquer mensagem enviada deve passar por uma rede subjacente, na qual cada um dos processos envia e recebe mensagens através de uma interface de software (API) conhecida como socket. O socket é definido como uma extremidade de um canal de comunicação entre a camada de aplicação e a camada de transporte dentro de uma máquina. Essa interface é formada por um endereço IP concatenado com um número de porta do host. Quando um cliente com endereço IP 146.86.5.20 inicia um pedido de conexão a um servidor Web (que ouve na porta 80) de endereço 161.25.19.8, ele recebe um número de porta arbitrário maior que 1024. Todas as conexões devem ser exclusivas, por isso, se outro processo no mesmo host X, desejasse estabelecer outra conexão com o mesmo servidor Web, a ele seria atribuído um número de porta maior que 1024 e diferente de 1625. Isso garante que todas as conexões consistem em um único par de sockets. Na figura 05 podemos observar uma ilustração da aplicação de socket numa estrutura de comunicação. 26 Fonte: Adaptado de Kurose e Ross (2006). FIGURA 05 – Comunicação de processos através de sockets. Utilizando essa interface, o desenvolvedor pode controlar tudo o que existe em relação aos elementos inerentes à camada de aplicação, entretanto, tem-se um controle mínimo no que diz respeito à camada de transporte: o desenvolvedor, somente, pode decidir o protocolo de transporte a ser utilizado e, talvez, determinar alguns de alguns dos parâmetros dessa camada (KUROSE; ROSS, 2006). Cada protocolo de transporte escolhido determina o tipo de socket a ser utilizado. Neste contexto, vamos abordar apenas sockets TCP/IP, compreendendo essencialmente dois tipos: sockets de fluxo, que usam o protocolo TCP, e sockets de datagrama, que usam o protocolo UDP (User Datagram Protocol). Como a aplicação cliente-servidor desenvolvida será multiplataforma, isto é, o cliente será executado em um sistema operacional (no caso, Android), enquanto o servidor será executado em outro (no caso, Mac OSX), uma linguagem de programação será abordada no âmbito de implementação de sockets: Java. 27 2.1.6. Java O Java é uma linguagem de programação amplamente utilizada para escrever software de rede de computadores e aplicativos distribuídos cliente/servidor. Essa linguagem foi anunciada formalmente pela Sun Microsystems em Maio de 1995 e chamou a atenção da comunidade de negócios por causa do enorme interesse na Internet (DEITEL, 2005). Segundo Deitel (2005), o Java é utilizado para desenvolver aplicativos corporativos de grande porte, aprimorar a funcionalidade de servidores Web, fornecer aplicativos para dispositivos voltados para o consumo popular (como celulares) e para muitos outros propósitos. Para Jandl (2002), dentre as características do Java, algumas podem ser destacadas, tais como: É uma linguagem puramente orientada a objetos: tudo em Java são classes ou instâncias de uma classe, que oferecem mecanismos de abstração, encapsulamento e hereditariedade; Independente de plataforma: em um ambiente de desenvolvimento Java, os programas são compilados para uma forma intermediária de código destinada à JVM, que interpreta esse código para a plataforma no qual ele é executado; Sem ponteiros: o Java não permite manipulação direta de endereços de memória. A JVM possui um mecanismo automático de gerenciamento de memória, que recupera a memória alocada para objetos não mais referenciados pelo programa; Boa performance: existem várias JVM que dispõem de compiladores Just in Time (JIT), capazes de compilar o código intermediário (bytecodes) em código nativo durante a carga do programa, melhorando o desempenho dos programas Java; Segurança: o Java especifica diferentes níveis de acesso ao sistema de arquivos da máquina alvo para evitar qualquer operação indevida nesse sistema; Permite multithread: oferece recursos para o desenvolvimento de aplicações capazes de executar múltiplas rotinas concorrentemente, possibilitando sua sincronização. 28 Na figura 06 pode-se observar a estrutura de uma aplicação Java. Fonte: Adaptado de Silberschatz, Galvin e Gagne (2000). FIGURA 06 – Máquina virtual Java. Programas Java, de acordo com Silberschatz, Galvin e Gagne (2000), consistem em partes chamadas de classes, as quais incluem partes chamadas de métodos que realizam tarefas e retornam informações ao concluir. Muitas dessas classes são reunidas em pacotes que constituem a interface de programação de aplicativos (API), um conjunto de bibliotecas de classe Java. Essas bibliotecas fornecem um grande conjunto de classes predefinidas com métodos para realizar cálculos matemáticos, manipulação de String, operações de entrada/saída, operações de banco de dados, operações de rede, verificação de erros e muitas outras tarefas úteis (DEITEL, 2005). 2.1.6.1. Acesso a bancos de dados com JDBC Muitos sistemas precisam manter as informações com as quais trabalham, seja para permitir consultas futuras, geração de relatórios ou possíveis alterações. Para que esses dados 29 durem por muito tempo, esses sistemas geralmente os armazenam em um banco de dados, mantendo-os de forma organizada e prontos para consultas (CAELUM, 2014b). Para Deitel (2005), há muitas estratégias diferentes na organização de dados para facilitar o seu acesso e manipulação. Um sistema de gerenciamento de banco de dados (DBMS) fornece o mecanismo necessário para armazenar, organizar, recuperar e modificar dados para muitos usuários. Na comunicação com bancos de dados, os programas Java utilizam o JDBC, uma API baseada na linguagem SQL. O JDBC permite aos aplicativos Java conectar-se a um banco de dados em um DBMS particular e permite aos programadores manipular qualquer origem de dados baseados em tabelas (DEITEL, 2005). Para evitar que uma API diferente seja implementada para cada banco, o Java oferece um conjunto único de interfaces muito bem definidas que ficam dentro do pacote java.sql. Entre essas interfaces, existe a interface Connection que gerencia a conexão entre o programa Java e o banco de dados, além de definir métodos para executar instruções SQL (como select, insert, update e delete), entre outros (CAELUM, 2014b). De acordo com Deitel (2005), o programa inicializa a conexão com o resultado de uma chamada para o método getConnection da classe DriverManager (pacote java.sql), que tenta conectar-se ao banco especificado por sua URL, a qual especifica o protocolo de comunicação (jdbc), o subprotocolo de comunicação (mysql) e a localização do banco de dados (//localhost/teste), como mostra a figura abaixo. Fonte: Caelum (2014b). FIGURA 07 – Conexão com banco de dados através do JDBC. 30 Esses e outros conjuntos de classes concretas serão responsáveis por fazer a ponte entre o código cliente que usa a API JDBC e o banco de dados. São essas classes que sabem se comunicar através do protocolo proprietário do banco de dados. Esse conjunto de classes recebe o nome de driver, figura 07. Todos os principais bancos de dados do mercado possuem drivers JDBC para serem utilizados com Java (CAELUM, 2014b). 2.1.6.2. Servlets Quando a Web surgiu, seu objetivo era a troca de conteúdos através, principalmente, de páginas estáticas HTML. Mas logo se percebeu que a Web tinha um enorme potencial de comunicação e interação além da exibição de simples conteúdos. Para atingir esse novo objetivo, porém, páginas estáticas não seriam suficientes, por isso, seria necessário servir páginas HTML geradas dinamicamente baseadas nas requisições dos usuários (TEMPLE et al., 2014). Na plataforma Java, a primeira e principal tecnologia capaz de gerar páginas dinâmicas são as servlets, definidas por classes e interfaces dos pacotes javax.servlet e javax.servlet.http. O nome “servlet” surgiu da ideia de um pequeno servidor (“servidorzinho”, em inglês) cujo objetivo é receber chamadas HTTP, processá-las e devolver uma resposta ao cliente (CAELUM, 2014b). Segundo Deitel (2005), os servlets são ferramentas eficientes para desenvolver soluções baseadas na Web que ajudam a fornecer acesso seguro a um site, interagir com bancos de dados em favor de um cliente, gerar dinamicamente documentos personalizados de XHTML a ser exibidos por navegadores e manter informações de sessão exclusivas de cada cliente. Essa ferramenta é comumente utilizada quando uma pequena parte do conteúdo enviado ao cliente é texto ou marcação, porém existem servlets que não produzem conteúdo, por isso, em uma solicitação de um cliente, invocam outros servlets para fornecer uma resposta (CAELUM, 2014b). 31 2.1.6.2.1. Arquitetura de servlets A World Wibe Web é baseada no protocolo HTTP, que utiliza URLs para localizar recursos na Internet. Um servlet estende a funcionalidade de um servidor, como um servidor Web que serve páginas da Internet para um navegador do usuário com o protocolo HTTP (TEMPLE et al., 2014). Na comunicação cliente-servidor, um cliente envia uma solicitação de HTTP ao servidor. O servidor que executa a servlet, conhecido como contêiner de servlets, recebe a solicitação e a direciona para ser processada pelo servlet apropriado. O servlet faz seu processamento, que pode incluir interagir com um banco de dados ou com outros servlets. O servlet retorna seus resultados ao cliente (HTML, XHTML, XML, imagens ou dados binários) como pode ser observado na figura 08, para exibir em um navegador (DEITEL, 2005). Fonte: Deitel (2005). FIGURA 08 – Arquitetura de servlet. 32 2.1.7. Servidor Web Apache O servidor mais popular é de longe o Apache, o qual estima-se que seja utilizado para hospedar 70% de todos os sites Web. O Apache é uma peça complexa de software e, com inúmeros aprimoramentos para os tipos de documentos que são oferecidos agora na Web, é importante que o servidor tenha alta capacidade de configuração e extensibilidade e que, ao mesmo tempo, em grande parte, seja independente de plataformas específicas. Em essência, tornar o servidor independente de plataforma significa ele oferecer seu próprio ambiente de execução básico que, na sequência, é implementado para diferentes sistemas operacionais. Esse ambiente de execução conhecido como Apache Portable Runtime (APR) é uma biblioteca que fornece interface independente de plataforma para manipulação de arquivos, trabalhos em rede, threads e assim por diante. Na ocasião de extensão do APACHE, a portabilidade é, em grande parte, garantida, contanto que sejam feitas apenas chamadas ao APR e evitados chamadas de bibliotecas especificas de plataforma (TANENBAUM, 2007). O Apache não somente é configurado para proporcionar flexibilidade, mas também é relativamente fácil estender sua funcionalidade. 33 3. METODOLOGIA Nesta seção, será apresentada a metodologia de desenvolvimento do trabalho, com a descrição da implementação do sistema desenvolvido, bem como as ferramentas e ambiente computacional utilizado. 3.1. Ferramentas O sistema de votação foi desenvolvido com base nos conceitos de sistemas distribuídos como pode ser notado na figura 09, logo abaixo. Foi utilizado um computador, no qual se encontra o sistema de gerenciamento de banco de dados (MySQL) e um outro computador contendo a IDE Eclipse, utilizada para desenvolver o servidor da aplicação, e a IDE Android Studio, utilizada para desenvolver a aplicação Android cliente da comunicação cliente-servidor. FIGURA 09 - Estrutura do sistema. Cada um dos computadores mencionados acima possuem características de hardware e software distintas, as quais são apresentados nas tabelas a seguir. 34 TABELA 1 – Servidor do sistema de votação. Item Descrição Processador Intel Core i5 Memória 16 GB RAM Hard Disk 500 GB Sata II Sistema Operacional Mac OSX Yosemite Placa de rede 10/100 Mbps TABELA 2 – Servidor de banco de dados. Item Descrição Processador Intel Core i7 Memória 08 GB RAM Hard Disk 1 TB Sata II Sistema Operacional Microsoft Windows 7 64 Placa de rede bits 10/100 Mbps O servidor de aplicação é responsável por disponibilizar na rede local (LAN) o acesso ao software de votação interativa para os clientes Android, fazer a comunicação com o banco de dados para armazenar os dados coletados após a votação, realizar apuração dos votos e disponibilizar os resultados e estatísticas. Os aplicativos servidor e cliente foram desenvolvidos utilizando a plataforma de programação Java através da IDE Eclipse, figura 10, porém, para o desenvolvimento da versão cliente será utilizado o Java EE com auxílio da IDE Android Studio, figura 11, pois serão utilizados como cliente um ou mais dispositivos móveis. 35 FIGURA 10 – IDE Eclipse utilizada no desenvolvimento da aplicação “servidor web”. FIGURA 11 – IDE Android Studio utilizada no desenvolvimento da aplicação “cliente”. 36 FIGURA 12 – Tabelas de dados do sistema no MySQL. 3.1.1. Desenvolvendo as interfaces do usuário Um item de suma importância para o devido funcionamento do projeto como um todo e que tem grande impacto diretamente na experiência do usuário durante sua utilização é a interface, parte visual na qual os usuários podem interagir tendo contato de fato com o sistema. Foram desenvolvidos dois tipos de interface com objetivos diferentes. O primeiro tipo foi a interface Web, utilizada no servidor para que o professor possa realizar o cadastro da pergunta e das alternativa que serão disponibilizadas na sessão de votação. O segundo tipo foi a interface Android, desenvoldida para ser utilizada no aplicativo Android, de onde os alunos terão acesso a sessão de votação criada pelo professor, visualizando a pergunta e suas alternativas. 37 Para ambos os casos o objetivo foi desenvolver uma interface de utilização simples, porém objetiva e intuitiva, aliada a uma lógica de programação que guie o usuário do início até o término da votação. 3.1.2. Fluxo de funcionamento do Sistema FIGURA 13 – Fluxograma do sistema. 38 3.1.2.1. Ambiente Por se tratar de um sistema amplo e distribuído, foram utilizados diversos ambientes para o seu desenvolvimento e aplicação. No ambiente de desenvolvimento foram escolhidos a IDE Eclipse para o desenvolvimento do aplicativo servidor. Para o aplicativo Android Cliente foi utilizado a IDE Android Studio e para o armazenamendo de dados foi implementado a DBMS MySQL com auxilio do JDBC de acesso Java. No ambiente de aplicação utilizamos para o Servidor o sistema operacional MAC OS, para o manter o banco de dados foi escolhido o Windows 7 e consequentemente para acesso dos clientes o Android OS. 3.1.2.2 . Conexões Múltiplas Devido a natureza da utilização do sistema desenvolvido, existe o problema de gerenciamento de conexões, pois os clientes tem acesso simultâneo ao servidor, enviando e recebendo dados. Como solução foi utilizada a estratégia de processamento por threads, possibilitando que cada cliente tenha uma conexão independente com o Servidor, que por sua vez pode processa-las paralelamente. Para o funcionamento ideal desse tipo de processamento foi também necessário aplicar semáforos para gerenciar produtores e consumidores, garantindo a exclusão mútua, já que enquanto um processo produz outro não poderá consumir. Para o trafégo dos pacotes foram utilizados sockets de rede, uma das melhores formas e mais comumente empregada para esse fim. Através de uma combinação de um endereço de IP e um número da porta, os sockets transportam e entregam pacotes de dados entre servidor/cliente para determinado processo ou thread de aplicação. 39 3.1.2.3. Comunicação Cliente x Servidor Quando se trata de comunicação de um sistema que exija confiabilidade de dados, uma das maiores preocupações geralmente é a garantia do envio e entrega das informações por uma rede. Justamente por esse motivo escolhemos o protocolo TCP, pois ele garante através de confirmação de recebimento que todos os pacotes enviados foram entregues, inclusive na mesma ordem de envio. Outra vantagem do protocolo é notada quando ocorre perda de pacote na rede, diagnosticada pelo alto tempo de espera por uma confirmação de recebimento do último pacote, nesse caso, após excedido o tempo limite de espera, imediatamente o pacote em questão é reenviado. Sobre o protocolo TCP utilizamos mensagens baseadas em chaves, utilizadas para criar um sincronismo entre as ações do Servidor e Cliente para disparar ações como efetuar cadastro do cliente, reconhecer cliente e enviar pergunta, entre outros. Com base nessas mensagens de sincronismo utilizada tornou-se praticamente indispensável a opção por programação orientada à comunicação (TCP) em vez de orientada à datagrama (UDP), apesar desta ser mais rápida. Ao contrário do protoloco TCP, no UDP não existem garantias de entrega de pacotes ou mesmo respeito à ordem de recebimento ou em relação à ordem de envio dos pacotes, fatos que acarretariam mau funcionamento ao sistema. 3.1.2.4. Armazenamento de Respostas Como mencionado anteriormente na sessão Acesso ao Banco de dados, para que fosse possível o acesso ao banco de dados MySQL pelo aplicativo Java no Servidor foi necessário a utilização do JDBC Driver for MySQL (Connector/J), um driver que recebe os comandos de acesso e faz a intermediação entre uma linguagem e outra. Após o servidor receber as informações de votação de um cliente e encerrar a sessão de votação para aquele cliente, os dados colhidos são armazenados conforme a estrutura demostrada na figura 14. 40 FIGURA 14 – Estrutura tabelas banco de dados. De posse dessas informações e após encerrar a sessão de votação, o servidor, por padrão, pode gerar o seguinte relatório: Alternativas x Respostas – Quantidade respectiva de votos que cada alternativa recebeu. 3.1.2.5. Servidor Java No servidor, através da interface com o usuário, no caso o professor, é possível cadastrar uma nova pergunta, escolher ou excluir uma pré-cadastrada. Depois de selecionada a pergunta e inicada a sessão o servidor de aplicação Java se responsabiliza pela abertura das conexões para os clientes. Assim que um cliente se conecta, uma nova conexão é criada para aguardar o possível próximo cliente. Após a conexão com o cliente ser fechada, o servidor gerencia a troca de requisições com esse cliente, tratando os dados recebidos e analisando quando deve efetuar um cadastro, montar a pergunta e enviar, receber dados de votação e armazenar ou finalizar a conexão. 41 3.1.2.6. Cliente Android O aplicativo Cliente Android é responsável pelas seguintes funções: Conectar ao servidor – A partir do apertar do botão “Iniciar” o cliente busca e encontra na rede uma sessão de votação aberta, caso encontre, a conexão é fechada com a porta aberta previamente pelo servidor. Identificação aparelho e aluno – Após ter a conexão estabelecida, o servidor requisita o MAC do aparelho que é enviado pelo cliente da seguinte forma: HELLO!;MAC, então, o servidor requisita os dados para o cadastro do cliente, é exibida para o cliente a tela de cadastro do aluno, onde o mesmo deverá inserir seu R.A e nome pressionando o botão “Cadastrar”, que são enviados pelo cliente no seguinte formato: MACcliente;nome;RA_aluno. Esse procedimento de cadastro e idendificação se dá para o caso de ser a primeira participação daquele aluno no sistema. Se o aluno tiver participado de alguma sessão anterior e possuir cadastro no sistema, no momento em que o servidor recebe o endereço MAC, ele é comparado com a base, identificado e caso ele ainda não tenha votado nessa sessão, é então ignoranda a tela de cadastro e redirecionando o cliente diretamente para pergunta ativa. Evitar Usuário Reincidente – Para evitar que exista mais de uma votação por aluno foi adicionada mensagens de checagem. No momento em que é identificado o cadastro pré existente do endereço MAC na base de dados, o servidor solicita ao cliente a identificação do usuário, GREAT;nome. De posse do nome o servidor faz uma comparação com os usuários que já votaram e caso não seja encontrado na lista o servidor retorna a seguinte mensagem para o cliente: Allan;Nvotou, enviando uma tela de boas vindas com a mensagem “Você ainda não votou, toque na tela para iniciar a sessão”. Após o toque o fluxo tem continuidade com o aplicativo cliente enviando uma mensagem solicitando a pergunta da sessão, ENVIA;PERG. 42 Caso o usuário seja encontrado na lista de já votantes, a seguinte mensagem é enviada: Allan;Votou, e uma tela de aviso é enviado para o cliente com a mensagem “ Você já participou, obrigado!” encerrando todos os processos, threads e fechando a conexão com o cliente. 3.1.2.7. Pipeline Trajeto de todo o fluxo de dados de um sistema, exemplificado pela figura 15. O tráfego de dados entre cliente e servidor se ocorre sobre uma rede Ethernet. Parte do caminho percorrido pelos dados nessa rede é efetuada através de um roteador Wireless, meio por onde os equipamentos clientes poderão se conectar à rede e por fim ao servidor. O protocolo utilizado para essa comunciação foi o TCP em conjunto com o protocolo IP, formando uma pilha de protocolos chamada de TCP/IP permitindo que diversos equipamentos possam se “enxergar” em uma rede e trocar dados de forma eficiente e organizada com recurso de confirmação de entrega de dados. FIGURA 15 – Pipeline de comunicação. 3.1.2.8 Criptografia Por se tratar de um sistema que envolve sigilo da informação trafegada, em nada adianta utilizarmos um formato de comunicação eficiente e organizada sem pensar na segurança durante essa troca de dados. 43 Existem diversas formas de ataque a uma rede, como a interceptação de pacotes trafegados com o intuito de conhecer a informações ou modificar e reinserir informações falsas nesse tráfego. Como prevenção a esses ou outros tipos de ataques, foi implementado um algoritmo de criptografia sobre os dados trocados. O algoritmo escolhido foi o AES, pois é amplamente utilizado atualmente devido a facilidade na sua utilização e robustez. Foi programado utilizando a cripitografia de base64, que utiliza para seus cálculos, letras, números e caracteres especiais tornando sua transferência pela rede mais fácil, trazendo boa relação custo x benefício para o conjunto total do sistema. Com sua aplicação torna-se praticamente inviável ataques para decifrar os pacotes transmitidos, porém eleva-se um pouco o tempo de comunicação devido aos completos cálculos matemáticos envolvidos. Comparação de tempo – Dados criptografados x Dados não criptografados Para efeito de teste resolvemos realizar a comparação entre as médias dos tempos utilizados pelo sistema sem criptografia em relação ao sistema com a criptografia ativa sobre a comunicação. O período do tempo considerado foi tomado a partir do início da conexão do cliente ao servidor até o seu encerramento com a votação finalizada. 44 4. RESULTADOS 4.1. Interface Web “Servidor” Para o desenvolvimento da interface Web foi escolhida a linguagem HTML5 por se tratar de uma linguagem recentemente homologada pela W3C e capaz de suportar as mídias atuais. Ela dispõe de mais poder de criação, pois traz uma nova abordagem incorporando as linguagems CSS3 responsável somente pelo estilo visual ou formatação da página e o JavaScript, reservado para implementação de funções envolvendo interatividade. O HTML5 agrupando essas tecnologias pode se dedicar apenas a semântica, onde os navegadores e mecanismos de busca conseguem enxergar um significado para cada tag declarada ou trecho do código. Tela de Login É a tela inicial vista pelo professor onde o mesmo irá inserir um nome e senha, que por hora não serão gerenciados pelo servidor, figura 16. FIGURA 16 – Tela de login da interface do servidor. 45 Tela de Inserção de Pergunta Após o logon o professor é direcionado para tela de inserção de pergunta, figura 17, onde poderá ser cadastrado apenas uma pergunta por sessão. Insere-se a pergunta no campo respectivo e as alternativas logo abaixo. Ao clicar no botão Cadastrar, a pergunta é inserida no banco de dados. FIGURA 17 – Tela de perguntas e respostas. 46 Tela de Exibição de Resultados Para a tela de resultados, logo abaixo, foi pensado um gráfico onde é mostrada a quantidade de votos direcionados a cada alternativa. FIGURA 18 – Tela de resultados das respostas. 4.2. Inteface Android “Cliente” Uma boa aplicação é aquela que possui uma interface amigável para o usuário. Para a interface gráfica do cliente foi utilizado o Android Studio 0.8.6 Beta e a linguagem XML. 47 Tela Principal A primeira tela do aplicativo Android apresenta o botão “Iniciar” onde o cliente, caso exista uma sessão de votação aberta, será direcionado para tela de votação. Está disponível logo abaixo o botão “Sobre”, onde estarão dispostas informações sobre o trabalho e grupo responsável. E por último o botão “Sair”, que somente finaliza o aplicativo. FIGURA 19 – Tela principal da interface do cliente. 48 Tela de acesso ao servidor Nessa tela abaixo deve ser inserido o endereço de IP atual do servidor, garantindo assim a sua localização. FIGURA 20 – Tela de acesso ao servidor. 49 Tela de Cadastro Caso seja detectado que o cliente não possui cadastro na base de dados, será exibida a tela da figura 21, onde estarão disponíveis os campos Nome e R.A, que serão registrado após pressionar o botão “Cadastrar”. FIGURA 21 – Tela de cadastro de clientes. 50 Tela Votação Na tela de votação estará disponível abaixo da mensagem de boas vindas a pergunta cadastrada anteriormente pelo professor e suas cinco alternativas, podendo ser escolhida apenas uma entre elas. O cliente pode registrar sua escolha atraves do botão “Confirmar”, figura 22. FIGURA 22 – Tela de votação. 51 Tela de aviso Caso o usuario tente votar novamente na mesma pergunta, essa tela o impede de participar, lançando-lhe uma mensagem de que sua participação já foi computada. FIGURA 23 – Tela de aviso de participação na votação. 52 Tela final Com a alternativa escolhida e registrada, é então exibida a tela de despedida e encerramento da sessão para esse cliente específico, figura 24. FIGURA 24 – Tela de despedida e encerramento da votação. 53 4.3. Criptografia Sobre a estrutura do servidor de aplicação e de banco de dados montada, com o auxilido de um software (autômato) programado para simular as requisições de clientes, foram realizadas duzentas vezes o ciclo completo de uma votação. O primeiro teste realizado foi a comparação entre as médias dos tempos utilizados pelo sistema sem criptografia e com a criptografia ativa durante a comunicação. O tempo da reação humana não foi considerado nesse teste. No teste sem a criptografia, foi obtido o valor do tempo médio de 251 ms. Figura 25. FIGURA 25 – Teste de tempo de conexão cliente-servidor sem criptografia. 54 No teste com a criptografia ativa, figura 26, pode-se notar que o tempo médio obtido teve um acréscimo de 206% em relação ao anterior, subindo para 769 ms. Esse aumento devese aos cálculos complexos exigidos pela criptografia. FIGURA 26 – Teste de tempo de conexão cliente-servidor com criptografia. Durante os testes foi possível notar uma barreira quanto à quantidade de conexões simultâneas ao banco de dados existente a partir da versão 5.1.15 desse DBMS. Esse limite é gerenciado pela variável max connections e tem o intuido de preservas um bom desempenho geral do sistema, mas pode ser alterada. Entretanto, o limite máximo que o MySQL poderá suportar dependerá da qualidade da biblioteca, sistema operacional, quantidade de RAM disponível, carga de trabalho para cada conexão e o tempo de resposta desejado. Nos testes realizados, a comunicação foi bem sucedida até a quantidade de cento e ciquenta conexões, figura 27. Acima desse número o servidor retorna uma mensagem de falha de timed out, pois não consegue criar novas conexões já que toda as disponíveis estao em uso por outros cliente, figura 28. 55 FIGURA 27 – Demonstração teste conexão servidor. 56 FIGURA 28 – Demonstração limite de conexões atingido. Outro teste realizado foi relacionado à segurança, onde foi simulado o ataque à rede do tipo man in the middle, quando um terceiro faz a interceptação dos dados trafegados. No primeiro momento sem criptografia, utilizamos com sucesso o software chamado Wireshark para capturar e exibir as informações contidas nos pacotes trafegados pela rede durante a sessão de votação. Após ativação da criptografia, como pode ser observado na figura 29 e 30, os dados ainda puderam ser interceptados, porém, tornaram-se ilegíveis, pois estavam cifrados. 57 FIGURA 29 – Demonstração antes e depois funcionamento criptografia. FIGURA 30 – Demonstração antes e depois funcionamento criptografia. 58 5. CONCLUSÃO A tecnologia é um item que passou a estar presente em nossas vidas, colaborando diretamente e indiretamente em nossas ações cotidianas. Trabalhando com o projeto em questão notamos que essa mudança é praticamente irreversível e tende a ser aplicada em inúmeras outras áreas e ocasiões, tanto profissinais quanto pessoais. Partindo da proposta inicial do trabalho, a criação de um sistema criptografado de votação interativa para Android, munido de um servidor local e aplicativo Android para votação que facilita a interação professor x aluno em sala de aula, concluimos que foi possível implementar com sucesso o sistema sob uma rede local. Com o sistema finalizado e sua estrutura montada, foi possível realizar simulações de votações abrangendo um ciclo de uma votação completa, desde sua primeira ação, que seria o cadastro da pergunta no servidor, até a exibição dos resultados e encerramento das conexões. É válido lembrar que os dados mantiveram-se criptografados durante todo o percurso. Paralelamente às simulações citadas acima, foi possível realizar testes onde foi atingido o limite aceitável de cento e cinquenta conexões simultâneas ao DBMS MySQL, e simular ataques de segurança da informação sobre os dados trafegados, do tipo man in the middle, através do software Wireshark, evidenciando a eficácia da criptografia empregada. Por último foi registrada a mediana dos tempos de execução de todas as sessões de votação, duzentas votações, obtendo o tempo de 769 ms. Resultado satisfatório, levando-se em conta que a criptografia mantinha-se ativa. Fica como aprendizado e melhoria para as próximas versões deste projeto a questão da escolha do protocolo de comunicação, pois notou-se que ao optar por HTTPS, haveria economia de tempo de programação em relação à criptografia, gerenciamento das threads e produtores e consumidores, já que tais fatores seriam mantidos nativamente pelo servidor através de objetos JSON e criptografia SSL. 59 REFERÊNCIAS BIBLIOGRÁFICAS CAELUM. FJ-11: Java e Orientação a Objetos. Disponível em: <https://www.caelum.com.br/apostila-java-orientacao-objetos/>. Acesso em: 13 out. 2014a. ________. FJ-21: Java para Desenvolvimento Web. Disponível em: <https://www.caelum.com.br/apostila-java-web/>. Acesso em: 13 out. 2014b. COSTA, N.P.O.; DUARTE FILHO, N.F. Análise e avaliação funcional de sistemas operacionais móveis: vantagens e desvantagens. Revista de Sistemas e Computação, Salvador, v. 3, n. 1, p. 66-77, jan/jun. 2013. DEITEL, Harvey M. Java: como programar, 6. ed. São Paulo: Pearson Prentice Hall, 1110 p., 2005. DEVMEDIA. Android, a nova plataforma móvel – Parte II. Disponível em: <http://www.devmedia.com.br/android-a-nova-plataforma-movel-parte-ii/8432>. Acessado em: 18 maio 2014. JANDL JUNIOR, Peter. Introdução ao Java. São Paulo: Berkeley Brasil, 518 p., 2002. LEMOS, André. Olhares sobre a cibercultura. Porto Alegre: Sulina, 231 p., 2003. MORIMOTO, Carlos E. Distribuições Linux – Definição de Distribuição Linux. Disponível em <http://www.guiadohardware.net/termos/distribuicao-linux>. Acessado em: 18 maio 2014. ______. Smartphone guia prático. Disponível em: <http://www.hardware.com.br/livros/smartphones/android.html>. Acessado em: 18 maio 2014. MYSQL Manual. Too many connections. Disponível em: < http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html>. Acessado em: 07 de dezembro de 2014. NORTON, Peter; GRIFFITH, Arthur. Guia Completo do Linux. São Paulo: Berkeley, 2000. 60 PASSARELLI, B.; JUNQUEIRA, A.H. Gerações Interativas Brasil: Crianças e adolescentes diante das telas. São Paulo: Escola do Futuro/USP, 2012. SENA, N.S. História do voto no Brasil. Disponível em: <http://www.webartigos.com/artigos/historia-do-voto-no-brasil/29371/>. Acessado em: 18 maio 2014. SALA DE AULA INTERATIVA. Interatividade requer a morte do sujeito narcisicamente investido do poder. Disponível em: <http://www.saladeaulainterativa.pro.br/entrevista_0 002.htm>. Acessado em: 16 maio 2014. SIERRA, Kathy; BATES, Bert. Use a cabeça Java. Rio de Janeiro: Alta Books, 496 p., 2005. SILBERSCHATZ, A.; GALVIN, P.; GAGNE, G. Sistemas Operacionais: conceitos e aplicações. Rio de Janeiro: Campus, 585 p., 2000. SILVA, M. Sala de aula interativa. Rio de Janeiro: Quartet, 2000. ________. Interatividade: uma mudança fundamental do esquema clássico da comunicação. Boletim Técnico do SENAC, Rio de Janeiro, v. 23, n. 3, p. 19-27, set/dez. 2000b. SOUSA, Raider. História das eleições. Disponível em: <http://www.historiadomundo.com.br/idade-moderna/historia-das-eleicoes.htm>. Acessado em: 4 jun. 2014. STRICKLAND, Jonathan. Arquitetura do Android. Disponível em: <http://tecnologia.hsw.uol.com.br/google-phone2.htm>. Acessado em: 18 maio 2014. TANENBAUM, Andrew S. Sistemas Operacionais Modernos, 2.ed. São Paulo: Prentice Hall, 695 p., 2003a. __________. Redes de computadores, 4.ed. Rio de Janeiro: Campus, 945 p., 2003. __________. Sistemas Distribuídos: princípios e paradigmas, 2.ed. São Paulo: Pearson Prentice Hall, 402 p., 2007. 61 TELECO. Estatísticas de celulares no Brasil. Disponível em: <http://www.teleco.com.br/ncel.asp>. Acessado em: 18 maio 2014. __________. MPLS I: Conceitos de Redes. Disponível em: <http://www.teleco.com.br/ncel.asp>. Acessado em: 18 maio 2014. TEMPLE, A.; MELLO, R. Fernandes de; CALEGARI, T.D.; SCHIEZARO, M. Programação Web com Jsp, Servlets e J2EE. Disponível em: <http://www.icmc.usp.br/pessoas/mello/livroj2ee.pdf>. Acessado em: 10 novembro 2014. WORLD WIDE WEB CONSORTIUM (W3C). W3C Recommendation 28 October 2014 Disponível em: <http://www.w3.org/TR/html5/>. Acessado em: 25 de novembro de 2014.
