3.5 Ferramentas de Desenvolvimento
3.5.2 MySQL Workbench
O MySQL Workbench é uma aplicação visual para a criação e manutenção de base de dados. Permite a criação de tabelas e ligações de uma base de da- dos. Facilita o processo de criação, ao gerar o código correspondente ao projeto desenvolvido através do interface gráfico. É também possível a conexão ás base de dados para a alteração de dados, bem como a criação de queries SQL.
3.5.3
NetBeans
O NetBeans é um IDE, grátis e open-source, para programação na linguagem Java, mas com a possibilidade de programação noutras linguagens. Foi inicialmente
3.5. FERRAMENTAS DE DESENVOLVIMENTO
desenvolvido por um estudante da Universidade Charles de Praga. Mais tarde foi adquirido pela SunMicrosystems que tornou o software open-source e a comunidade começou a crescer cada vez mais. Suporta vários tipos de desenvolvimento Java, como por exemplo, Java SE, Java EE. Facilita a criação de aplicações Web em Java e tem suporte ao servidor Glassfish.
CAPÍTULO 3. ANÁLISE DO SISTEMA
3.6
Componentes de Hardware
3.6.1
Mifare
Mifare é uma tecnologia sem fios proprietária da NXP Semiconductors. Uti-
liza o protocolo de comunicação ISO14443A, funciona a 13,56MHz e é alimentada através da própria comunicação sem fios. Podem ser utilizados para guardar infor- mação de identidade, valores monetários ou como bilhetes. Existem vários tipos de cartões Mifare, como por exemplo Classic, Ultralight, DESFire, entre outros. A estrutura da memoria é representada na figura 3.12. Os cartões Mifare Classic são os mais utilizados, onde existem 3 versões: 320 bytes, 1024 bytes e 4096 bytes. Em 1994 surgiram os cartões Mifare Classic 1k que guardam a informação dividida em 4 blocos de 16 bytes por 16 sectores, onde cada sector é protegido com duas chaves diferentes, A e B, que são guardadas no bloco 3 de cada sector. A autenti- cação com estas chaves permite operações como leitura e escrita[22]. Apesar das comunicações entre o cartão e o leitor serem encriptadas, e a informação não estar acessível sem o acesso às chaves, esta tecnologia é vulnerável [23].
Figura 3.12: Estrutura de Memoria Mifare
3.6. COMPONENTES DE HARDWARE
3.6.2
Smartphone
O smartphone escolhido foi o Sony Xperia S, lançado em Fevereiro de 2012, pois contem hardware que permite a utilização da tecnologia NFC. Além disso, este smartphone é capaz de desempenhar as funções normais como acesso a redes
Wireless, GPS, acelerómetro, entre outros [24].
Capítulo 4
Modelação do Sistema
Neste capítulo é feita a descrição dos componentes do sistema Better Patrol:
- Base de dados; - Aplicação Android; - WebSite;
- Servidor.
4.1
Base de Dados
Este sistema utiliza uma base de dados relacional, onde é possível guardar a informação. Para isso foi utilizado o MySQL por ser uma base de dados open-source e sem licença. A base de dados foi criada utilizando o utilitário MySQLWorkbench, que permite criar as tabelas e as suas relações de uma forma mais intuitiva. Na figura 4.1, é apresentado o DER (Diagrama Entidade e Relações) que demonstra o modelo de dados da base de dados do sistema.
O sistema foi desenvolvido para suportar diversas entidades separadas. As- sim, a base de dados pode ser analisada começando pela tabela ‘Empresa’. Esta tabela guarda a informação das empresas existentes no sistema, como o nome, o estado de funcionamento e o endereço de servidor. Este endereço de servidor foi inserido para permitir separar as ligações de empresas para servidores dedicados.
CAPÍTULO 4. MODELAÇÃO DO SISTEMA
Figura 4.1: Diagrama ER
dente.
Na tabela ‘users’ são guardados todos os seguranças do sistema correspon- dente a uma determinada empresa. Nesta tabela é necessário guardar informação importante relativa ao segurança, no entanto os dados mais importantes para o sistema estão relacionados com os seguintes campos:
- username – Nome de utilizador que permite efetuar o Login. - password – Palavra passe para efetuar o Login.
- live_monitoring – Este campo é utilizado para definir se o dispositivo deste segurança deverá enviar informações em tempo real sobre a sua posição.
- device_token – Esta chave serve para identificar qual o dispositivo que está associado a determinado segurança no momento.
A tabela ‘users’ está relacionada com mais 4 tabelas além da tabela ‘Em- presa’. São as tabelas ‘user_types’, ‘user_health’, ‘warnings’ e ‘user_rondas’.
A tabela ‘user_types’ é utilizada para identificar o tipo de segurança, neste caso ele poderá ser segurança ou supervisor.
Na tabela ‘user_health’ é guardada a informação relativa dos dados prove- nientes da monitorização em tempo real.
4.1. BASE DE DADOS
‘Warnings’, esta tabela está relacionada com os seguranças e com a empresa à qual eles pertencem. Aqui são salvaguardados os dados relativos aos avisos ori- ginados pela aplicação Android, como por exemplo, uma situação de pânico.
A tabela ‘user_rondas’ que está relacionada com os seguranças, em conjunto com as tabelas ‘rondas’, ‘rondas_points’ e ‘point_time’, fazem parte de uma fun- cionalidade não implementada, mas que ficou decidido deixar o suporte à mesma. Esta funcionalidade consiste na possibilidade da existência de rondas com uma ordem de checkpoints específica, com tempos e datas definidas, tanto nos check-
points como nas próprias rondas. Estas rondas poderiam estar relacionadas com
seguranças e ser agendadas em calendário.
Na tabela ‘points’ é guardada a informação correspondente aos checkpoints do sistema de cada empresa. Aqui é possível guardar informações como o ‘nome’, ‘latitude’, ‘longitude’, ‘notas’,‘tag_nfc’, entre outros. É a partir da chave ‘tag_nfc’ que é possível associar os checkpoints a determinadas localizações.
Nas tabelas ‘log_types’ e ‘logs’, são guardadas todas as informações relativas às ações executadas no sistema.
Depois de modelar o sistema, utilizando o MySQLWorkbench, o código MySQL correspondente foi gerado de forma automática, para ser executado. Juntamente com este código foi também inserido o código de inserção de informação, com dados de teste.
CAPÍTULO 4. MODELAÇÃO DO SISTEMA
4.2
Aplicação Android
A aplicação Android é o componente do sistema que tem mais interação com os seguranças. O fluxo de execução da aplicação para o smartphone Android é demonstrado na figura 4.2.
Figura 4.2: Fluxo aplicação Android
O login pode ser feito em modo offline ou em modo online. Para o modo
online o dispositivo deve ter uma ligação à internet ativa e pode ser feito com a
inserção de texto ou com a passagem do cartão Mifare pessoal. No modo offline o segurança deve fazer o login com o seu cartão pessoal. O fluxograma do login pode ser verificado na figura 4.3.
4.2. APLICAÇÃO ANDROID
Figura 4.3: Fluxograma Login
No Login online é enviado um pedido HTTP POST para o servidor, onde vão inseridos o username e a password encriptada com o algoritmo SHA-256. Caso o login seja válido a resposta por parte do servidor consiste no id de segurança, o id da empresa ao qual pertence o segurança, o tipo de utilizador, segurança ou supervisor, o estado da monitorização em tempo real e o endereço ao qual o dispositivo deverá fazer os pedidos. Este endereço foi adicionado caso mais tarde seja pretendido ter empresas separadas em máquinas diferentes/dedicadas.
No Login offline o segurança passa o seu cartão Mifare pessoal no smartphone e insere os dados de username e password. É então feita uma verificação dos dados guardados no cartão e os dados inseridos pelo segurança. Caso estes sejam
CAPÍTULO 4. MODELAÇÃO DO SISTEMA
Após feito o login, é criado um serviço para correr em ‘background’, figura 4.4. O serviço é responsável por executar várias tarefas. Caso o login seja feito em modo offline, este procura efetuar o login automático, quando o smartphone obtiver ligação de dados ativa.
Se o Login for verificado, o serviço procede ao pedido de uma nova chave GCM (Google Cloud Messaging). Após recebida esta chave, é enviada uma notificação ao servidor com a chave para permitir futuras mensagens push.
O serviço inicia a atualização dos dados contidos no smartphone, isto é, a informação de checkpoints. Para isso é utilizado como comparação a última data de alteração do checkpoint e assim é possível verificar se é necessário descarregar uma atualização. É também verificado se a imagem foi alterada pela data de ultima alteração da imagem, evitando o download de dados repetidos.
O serviço ativa igualmente a monitorização do acelerómetro para enviar um aviso para o servidor, caso seja detetada uma situação de panico.
Figura 4.4: Fluxograma Serviço
Caso este utilizador tenha ativa a sua monitorização em tempo real, este serviço está encarregue de enviar a informação da sua posição atual através do sinal de GPS. Esta monitorização é definida pelo supervisor no WebSite. Quando o supervisor efetuar a alteração desta definição é enviado uma mensagem push do
4.2. APLICAÇÃO ANDROID
servidor para o smartphone do segurança através do GCM, o seu funcionamento pode ser demonstrado na figura 4.5. As mensagens deste serviço têm um tama- nho máximo de 4Kb, que são suficientes para enviar uma simples mensagem ao
smartphone do segurança para sinalizar que houve uma atualização. Em seguida
é feito um pedido HTTP para receber os novos dados.
Quando o segurança está a efetuar uma ronda é possível que este perca a sua ligação de dados, no entanto, todos os checkpoints registados serão guardados para mais tarde serem enviados, quando for retomada a ligação de dados. Este serviço ao detetar ligação de dados, verifica se tem conteúdo a enviar para o servidor. Deste modo a informação da ronda não é perdida caso haja uma falha na ligação. Este serviço permanece ativo durante todos os ecrãs, evitando assim a repetição de código em todos eles.
Figura 4.5: GCM Push Notifications
Depois do login o segurança pode iniciar uma nova ronda e efetuar a pas- sagem por checkpoints através da leitura de cartões Mifare. Pode visualizar os pontos por onde passou, bem como, detalhes e imagem do checkpoint. É feito o download destes dados logo após a passagem por um checkpoint caso exista uma ligação de dados ativa. Estes dados, são então guardados no smartphone de modo a que na próxima passagem não seja necessário efetuar o download novamente. No
CAPÍTULO 4. MODELAÇÃO DO SISTEMA
ligação de dados for reestabelecida, se possa proceder ao pedido dos dados corres- pondentes.
O segurança tem a possibilidade de definir um botão de atalho para uma aplicação para câmaras de CCTV.
Como já foi referido anteriormente o valor do acelerómetro é monitorizado para detetar algum evento de perigo, como uma situação de queda ou panico. Com base na equação estudada no artigo [18],
|At| =
q
|Ax|2+ |Ay|2+ |Az|2 (4.1)
e após algumas amostras foi definido o valor de 25 que ao ser ultrapassado envia o aviso para o servidor.
Ainda na aplicação Android, o supervisor poderá efetuar o login, onde terá todas as funcionalidades da versão para segurança, bem como a possibilidade de programar cartões pessoais Mifare para seguranças e tags para checkpoints.
4.3. WEBSITE
4.3
WebSite
As ações relativas ao WebSite são demonstradas na figura 4.6.
Figura 4.6: Fluxo WebSite
No Website pode ser criada uma nova entidade, uma empresa. Ao criar uma nova empresa deve ser criado um perfil de supervisor para permitir o login.
Como referido anteriormente o login no Website só pode ser efetuado pelo supervisor onde este pode executar as ações de listar, criar, editar seguranças e
checkpoints.
Na criação de segurança ou checkpoint, o supervisor deve respeitar todos os campos obrigatórios a serem preenchidos, pode também efetuar o upload de uma imagem para o servidor associado a um segurança ou a um checkpoint.
O supervisor tem a possibilidade de monitorizar os eventos em tempo real e a visualização de Logs.
Quando o supervisor edita um segurança e caso altere o estado da monitori- zação em tempo real é enviada uma mensagem push do servidor para o dispositivo do segurança, de forma a que o dispositivo comece a enviar a informação do GPS atual do segurança.
CAPÍTULO 4. MODELAÇÃO DO SISTEMA
4.4
Servidor
O servidor Glassfish é responsável por responder aos pedidos efetuados pela aplicação Android e pelo WebSite. Estes são pedidos HTTP POST, onde a infor- mação é transferida utilizando o formato de texto JSON. O servidor ao receber os pedidos, na camada Services, direciona-os para a camada Business.
A camada Business tem todas as funções necessárias para responder às soli- citações e é responsável pela ‘inteligência’ do servidor.
Na camada DAO, existem todos os métodos que permitem a ligação da ca- mada Business à base de dados.
Por sua vez, a camada Model disponibiliza as classes correspondentes à estru- tura da base de dados MySQL, tornando mais fácil a manipulação da informação. O fluxograma do servidor pode ser verificado na figura 4.7.
Figura 4.7: Fluxo Servidor
A camada Services é utilizada para definir os objetos URI para a sua utili- zação como WebServices. Quando um pedido é feito a determinado URI, o JSON recebido é descodificado em variáveis. Se este JSON não corresponder com o es-
4.4. SERVIDOR
perado é enviado um erro. Após a descodificação do JSON estas variáveis são reencaminhadas para o método especifico na camada Business, relacionado tanto com a aplicação Android ou com o WebSite.
Na figura 4.1 estão demonstrados os serviços para a aplicação Android.
Método HTTP URI Content-type
Login na aplicação Android POST /MobileApp_LoginUser JSON Verificar se checkpoint atualizado POST /MobileApp_CheckChkp JSON Obter checkpoint POST /MobileApp_getChkp JSON Listagem de checkpoints POST /MobileApp_get_all_CHKP JSON Listagem de seguranças POST /MobileApp_get_all_users JSON Passagem por checkpoint POST /MobileApp_authCHKP JSON Associar checkpoint a tag Mifare POST /MobileApp_associateCHKP JSON Monitorização em tempo real POST /MobileApp_UserStatus JSON Sinal de Alarme POST /MobileApp_UserAlarmOn JSON
Tabela 4.1: Web services para aplicação Android
Na figura 4.2, estão demonstrados os serviços que dão suporte as funcionali- dade presentes no Website.
Método HTTP URI Content-type
Criação de nova empresa POST /WebApp_addacc MultipartFormData
Login no Website POST /WebApp_weblogin JSON
Listagem de seguranças POST /WebApp_getusers JSON
Adicionar novo segurança POST /WebApp_addUser MultipartFormData Editar segurança POST /WebApp_editUser MultipartFormData Eliminar segurança POST /WebApp_deleteUser JSON
Listagem de checkpoint POST /WebApp_getchkps JSON
Adicionar checkpoint POST /WebApp_addChkp MultipartFormData Editar checkpoint POST /WebApp_editChkp MultipartFormData Eliminar checkpoint POST /WebApp_deleteChkp JSON
Listagem de logs POST /WebApp_getlogs JSON Listagem de logs com filtros POST /WebApp_getlogsfilter JSON Lista de últimos eventos POST /WebApp_getlive JSON Verificar se há novos eventos POST /WebApp_checklive JSON
Capítulo 5
Implementação do Sistema
No capítulo da implementação é demonstrado o desenvolvimento dos com- ponentes constituintes do sistema, que foram especificados no capítulo anterior. No capítulo anterior foram definidas as funcionalidades e requisitos que o sistema deve ter, sendo a solução proposta demonstrada neste capítulo.
Este capítulo aborda a implementação da aplicação Android, do Website e do servidor.
5.1
Aplicação Android
A aplicação Better Patrol no Android, pode ser iniciada através do ícone de aplicação, através da passagem de um cartão de segurança ou quando o smartphone é inicializado.
A aplicação Android pode ser dividida em várias secções:
- Ecrã de Login; - Ecrã de Entrada; - Serviço;
- Ecrã Ronda;
- Ecrã Entrada de Administração; - Ecrã Associar Segurança;
CAPÍTULO 5. IMPLEMENTAÇÃO DO SISTEMA
5.1.1
Ecrã de Login
No ecrã de Login (figura 5.1), o segurança poderá efetuar o login de duas maneiras, o login online e o login offline. O login online pode ser efetuado com recurso a cartão Mifare pessoal ou à inserção dos seus dados de autenticação, o nome de utilizador (username) e a palavra passe (password). Poderá escolher também a opção de lembrar estes dados. O login offline só é possível com o cartão
Mifare pessoal.
Figura 5.1: Ecrã Login
Na figura 5.2, pode-se visualizar a autenticação feita no cartão Mifare, onde será feita também a leitura dos dados do cartão.
5.1. APLICAÇÃO ANDROID
Figura 5.2: Função leitura de cartão
A figura 5.3, mostra a função utilizada para efetuar o Login através de um HTTP POST ao serviço definido na modelação.
Figura 5.3: Função Login
Após efetuado o Login a aplicação passa para o ecrã de entrada.
5.1.2
Ecrã de Entrada
No Ecrã de Entrada, figura 5.4, o segurança pode pressionar no botão para o ecrã de ronda ou pressionar no botão para iniciar a aplicação de CCTV (Closed
Circuit Television) que pode ser alterada nas definições.
Caso o utilizador seja um supervisor, é então visível a opção para aceder ao ecrã entrada de administração. Neste ecrã é iniciado também o serviço que é
CAPÍTULO 5. IMPLEMENTAÇÃO DO SISTEMA
Figura 5.4: Ecrã Entrada
Na figura seguinte é possível visualizar o protótipo das funções utilizadas pelo serviço que é executado em background. Esta funções servem para várias funções, como enviar a chave GCM do dispositivo, atualizar os checkpoints do smartphone, enviar passagem por checkpoint, enviar alarme de pânico, enviar monitorização em tempo real bem como obter configurações do servidor.
Figura 5.5: Funções do serviço
5.1. APLICAÇÃO ANDROID
5.1.3
Ecrã Ronda
O ecrã Ronda é o ecrã principal da aplicação, onde o segurança pode iniciar uma ronda e efetuar a passagem pelos checkpoints. Ao iniciar a ronda, a aplicação fica à espera de uma passagem por checkpoint, figura 5.6.
Figura 5.6: Ecrã Ronda
Quando é feita uma passagem por um checkpoint, o smartphone lê o conteúdo do cartão e verifica se este é um checkpoint. Com a chave única do cartão é possível verificar se a informação relativa ao checkpoint está disponível no smartphone.
Caso não esteja, é feito o download deste checkpoint para permitir a visuali- zação dos dados correspondentes. É enviado ao servidor a informação de passagem do checkpoint mas se a ligação de dados falhar, esta passagem é guardada num vector auxiliar que irá ser enviada para o servidor pelo serviço que corre em back-
ground, logo que a ligação de dados retorne.
CAPÍTULO 5. IMPLEMENTAÇÃO DO SISTEMA
checkpoint irá deslizar até abrir totalmente, figura 5.7. Também é possível abrir
um novo ecrã de checkpoint pressionando na seta correspondente. Este ecrã con- tem a fotografia e os detalhes do checkpoint e decidiu-se não demonstrar este ecrã por ser uma repetição de informação. No entanto este ecrã foi criado na aplica- ção de modo a permitir uma fácil inclusão de futuras funcionalidades, visto que a separação do focus da linha da lista com o botão nessa linha foi uma tarefa mais difícil devido a necessidade de ser criada uma lista customizada através do Base
Adapter.
Ao pressionar no símbolo da câmara é iniciado uma janela tipo pop-up que mostra a imagem correspondente ao checkpoint, figura 5.8.
Figura 5.7: Ecrã Ronda, Detalhes Checkpoint
Figura 5.8: Ecrã Ronda, Imagem Checkpoint
5.1. APLICAÇÃO ANDROID