pt

Documentação da versão inicial do protótipo

Este referido protótipo faz parte da monografia do AmadeuJunior como conclusão do curso de Bacharelado em Ciência da Computação pela UFBA.

Estrutura deste documento:


Estrutura do repositório de códigos

Todos os códigos do protótipo estão no repositório SVN: https://intranet.dcc.ufba.br/svn/gaudi/biometrica/ruby/

Dentro deste diretório de código na pasta src/afisdcc/ existe a seguinte arrumação:

  1. tags = ramificação que contém/conterá as versão liberadas oficialmente do programa
  2. branches = ramificação contém/conterá versões que se diferem muito entre si, ou seja, caso a mudança seja muito estrutural a ponto de diferenciar fortemente um tag de outro então cria-se um novo branch normalmente com um nome de identificação do release
  3. trunk = ramificação que contém os códigos que estão sendo trabalhados no momento atual, quando se considera que o código está pronto para ser liberado então faz-se um svn cp (para detalhes svn help cp) para uma nova tag ou novo branch, conforme necessidade

Em suma, o conteúdo das subpastas em tags, trunk e branches pode parecer igual, mas só parece porque os códigos em si estão congelados em momentos diferentes, por organização do trabalho. Esta metodologia facilita o desenvolvimento de vários programadores ao mesmo tempo no controle de versões e é usada por grandes equipes de desenvolvimento de código livre.

Estrutura básica:

  1. src/afisdcc/<tags,trunk ou branches>/ = diretório com os códigos principais
  2. src/afisdcc/<tags,trunk ou branches>/ext = extensões em Ruby
  3. src/afisdcc/<tags,trunk ou branches>/ext/biometrics = extensão escrita em C para a biblioteca DPFP
  4. src/afisdcc/<tags,trunk ou branches>/ext/nfis = extensão escrita em C para o NFIS (apenas reaproveitando os binários)
  5. src/afisdcc/<tags,trunk ou branches>/fingers = imagens com as impressões digitais e os arquivos .xyt todos nomeados com o respectivo hash MD5 do arquivo de imagem original para garantir a integridade
  6. src/afisdcc/<tags,trunk ou branches>/temp = diretório usado durante a execução mas que nunca deve ter seu conteúdo levado ao SVN já que é meramente temporário para a obtenção das imagens de teste, uma vez que tudo que é útil é guardado no diretório fingers
  7. src/afisdcc/<tags,trunk ou branches>/cluster_server.rb = servidor para processamento da parte da comparação do AFIS no cluster na porta 9091
  8. src/afisdcc/<tags,trunk ou branches>/cluster_client.rb = módulo que conecta nos clientes do webservice do cluster para enviar e recolher os dados do comparador na porta 9091, deposita no arquivo nomeado client-nodeX onde X é o número do PC, os resultados parciais da execução do bozorth3
  9. src/afisdcc/<tags,trunk ou branches>/setup.rb = script ruby para compilar e instalar as extensões, uso: ruby setup.rb
  10. src/afisdcc/<tags,trunk ou branches>/server.rb = servidor principal que contém a exportação do webservice e conexão ao banco bem como o uso do código em cluster_client.rb
  11. src/afisdcc/<tags,trunk ou branches>/client.rb = módulo que conecta no servidor principal na porta 9090 e envia e coleta os dados via webservice
  12. src/afisdcc/<tags,trunk ou branches>/test.rb = porção de código (por enquanto desestruturada) que usa o código do client.rb, usa a extensão do biometrics e define uma interface gráfica para o usuário final em gtk2

Disposição das máquinas e serviços

  1. Servidor externo do webservice e banco de dados:
    • host: topgrid.dcc.ufba.br
    • ip externo: 200.17.147.12
    • ip interno: 172.16.132.201
    • porta utilizada no webservice atualmente implementado em ruby: 9090
    • tipo do banco de dados: postgresql
    • porta do banco de dados: 5432
    • usuario do banco: dccuser
    • senha do banco: ????
    • nome do banco: afis
  2. Servidores internos para processamento da comparação via webservice:
    • 4 máquinas com ips apenas internos 172.16.132.202-205
    • para tal função é preciso montar o diretório fingers em algum lugar com caminho base igual para compartilhar

Explicações gerais sobre o código

A partir das explicações dadas sobre o aparato tecnológico utilizado neste protótipo, pode-se perceber que implementou-se duas extensões de Ruby na linguagem C. Para entender o que é uma extensão de Ruby veja: http://www.rubycentral.com/book (ótima referência para iniciantes):

  • A extensão biometrics é para reusar o código da biblioteca (DPFP) do sensor (http://dpfp.berlios.de) em sua versão 0.2.1, que suporta a captura ao-vivo
  • A extensão nfis é para reusar o código do NFIS. Em detalhe o NFIS não poderia ser redistribuído na íntegra, logo esta extensão limitou-se a reusar os binários do NFIS previamente compilado e instalado para então reaproveitar sua funcionalidades mais gerais, contornando os problemas de restrição de licença. A passagem de parâmetros como a localização do PATH para o NFIS compilado, fica nos arquivos .rb referentes às classes ruby que usam esta extensão, ou seja, tal PATH não está nesta extensão, para facilitar a vida do programador que vai usar esta extensão. Um exemplo é o código server.rb e o código cluster_server.rb que usam a extensão nfis.

Para compilar todas as extensões entre no ramo principal do trunk ou tag, por exemplo, e execute: ruby setup.rb. Será necessário acesso de root para instalar os arquivos objetos das extensões, que são colocados em uma subpasta específica dentro da pasta /usr/local/lib do GNU/Linux para posterior entendimento do interpretador Ruby.

Para rodar o protótipo é necessário:

  1. Instalar a biblioteca DPFP para o sensor U.are.U 4000B, onde a biblioteca encontra-se em: http://http://prdownload.berlios.de/dpfp/libdpfp-0.2.1.tar.gz. Ajuda com a instalação:
    • ./configure && make && make install : eventualmente será necessário instalar alguns pacotes referentes à dependências de outras bibliotecas como: libusb-dev libc6-dev (devem estar faltando alguns que não lembro agora)
    • copiar o arquivo do repositório SVN: src/afisdcc/<tags,trunk ou branches>/utils/z99_digitalpersona.rules para a pasta /etc/udev/rules.d : importante para a detecção automática do dispositivo USB e posterior definição de permissão no dispositivo para leituras a qualquer usuário do grupo plugdev
    • reiniciar o serviço udev, desconectar e reconectar o sensor USB para só então usar
  2. Instalar o NFIS conforme tutorial em https://intranet.dcc.ufba.br/pastas/gaudi/biometrica/NFIS/como-compilar.txt (talvez desatualizado)
  3. Instalar Ruby e bibliotecas dependentes: ruby ruby-dev ruby-gnome2 libdbi-ruby libdbd-pg-ruby rubygems rake librmagick-ruby
  4. Iniciar o serviço de webservice principal no servidor topgrid.dcc.ufba.br com o comando: ruby server.rb
  5. Montar o NFS para todas as máquinas do cluster no mesmo local (em cada máquina), por exemplo, com o comando: mount -t nfs topgrid.dcc.ufba.br:/home/amadeu/AFISDCC/trunk /home/amadeu/AFISDCC/trunk, pois cada máquina do cluster vai gerar um arquivo nomeado client-nodeX que deve estar disponível para o servidor principal na máquina topgrid.dcc.ufba.br
  6. Iniciar o serviço de webservice em cada máquina do cluster com o comando: ruby cluster_server.rb
  7. Conectar o sensor na porta USB de sua máquina de testes
  8. Iniciar o código cliente com o comando: ruby test.rb, caso o sensor não esteja conectado ou com permissão errada de leitura o protótipo irá apresentar um trace de erro com esta informação. Em caso de ao término do protótipo o sensor permanecer com a luz ligada para sempre, execute: ruby stop.rb para resetar o equipamento.

O que falta ou pode melhorar ?

Em geral o protótipo é funcional, mas:

  1. Precisa de reengenharia total da porção de código test.rb para que cada tela represente uma classe em Ruby e use com mais qualidade os serviços prestados pelas outras porções de código.
  2. Deve permitir um filtro de busca por uma chave primária do cidadão (implementado assim a fase de verificação da tecnologia AFIS) servindo à requisitos de aplicações como controle de ponto
  3. Deve permitir utilização de todas as cidades de todos os estados, pois limitamos a usar o estado Bahia, uma vez que verificamos grande demora na listagem na interface gráfica de todas as milhares de cidades (deve haver uma forma adequada para carregar esta listagem aos poucos ou filtrar antes por estado)
  4. Pode possuir uma interface web usando a bilbioteca libgtk-mozembed-ruby e o framework rails ou algo como uma extensão em XUL para o gecko (engine do Mozilla)

Links

-- AmadeuJunior - 24 Jul 2007