faculdades integradas do vale do ivaÍ · modelo de classes ... silverman, 2001). este conceito...
TRANSCRIPT
FACULDADES INTEGRADAS DO VALE DO IVAÍ
Mantida pela Instituição Cultural e Educacional de Ivaiporã – ICEI
Recredenciada pela Portaria nº. 545 de 11/05/2012 – D.O.U. – 14/05/2012
Tecnologia em Análise e Desenvolvimento de Sistemas
RODRIGO ROHLING CRUZ
SANDRO DUTRA DO NASCIMENTO JUNIOR
BIOMETRIA APLICADA A SEGURANÇA RESIDENCIAL
IVAIPORÃ/PR
2013
RODRIGO ROHLING CRUZ
SANDRO DUTRA DO NASCIMENTO JUNIOR
BIOMETRIA APLICADA A SEGURANÇA RESIDENCIAL
Trabalho de conclusão de curso apresentado
ao curso superior de Tecnologia em Análise
e Desenvolvimento de Sistemas, das
Faculdades Integradas do Vale do Ivaí como
requisito parcial para obtenção do título de
tecnólogo em Análise e Desenvolvimento de
Sistemas.
Orientador: Prof. RobsonL.Zambroti
IVAIPORÃ/PR
2013
RODRIGO ROHLING CRUZ
SANDRO DUTRA DO NASCIMENTO JUNIOR
BIOMETRIA APLICADA A SEGURANÇA RESIDENCIAL
Trabalho de Conclusão de Curso apresentado
a Faculdades Integradas do Vale do Ivaí, como
requisito parcial para obtenção do título de
Tecnólogo em Análise e Desenvolvimento de
Sistemas, sob apreciação da seguinte banca
examinadora:
Aprovado(a) em 30/11/2013
COMISSÃO EXAMINADORA
_______________________________
Guilherme de Lemos
_______________________________
Pedro Henrique de Sousa
_______________________________
Robson de Lacerda Zambroti
“A tarefa não é tanto ver o que ninguém viu ainda, mas pensar o que ninguém
pensou sobre algo que todos vêem” (Arthur Schopenhaurer)
AGRADECIMENTOS
Primeiramente agradecemos a Deus por nos ter dado força nos
momentos de dificuldades (que não foram poucos) e também nos ajudou a suportar
os pessimistas que disseram que não íamos dar conta do recado. Queremos
agradecer, também, todas as pessoas, que, de alguma forma, contribuíram para a
produção deste projeto. Seja com palavras de incentivo ou com dicas que
agregaram melhorias.
CRUZ, Rodrigo Rohling; NASCIMENTO JUNIOR, Sandro Dutra do, 70 páginas. Biometria Aplicada a Segurança Residencial. Trabalho de conclusão de curso (superior de tecnologia em Análise e Desenvolvimento de Sistemas) - Faculdades Integradas do Vale do Ivaí. Ivaiporã, 2013.
RESUMO
Atualmente, o índice de furtos a residência vem aumentando. Em 2012, a PM
(Policia Militar) registrou uma elevação de 44% na taxa de furtos a residência no
Brasil (SILVA, 2012), por isso surge a necessidade de ter um sistema que possibilite
um controle de acesso mais seguro que seja acessível a maior parte da população,
já que o uso de chaves e fechaduras simples não são tão eficazes contra os furtos.O
objetivo deste projeto é desenvolver um sistema similar aos já existentes, porém,
com preço mais reduzido, possibilitando o controle de acesso para uma camada da
população, que em sua maioria, não possui condições de adquirir um dos já
existentes. Para isso, será utilizado um leitor biométrico em conjunto com uma trava
elétrica que, ligada a um computador, através da porta paralela, por intermédio de
um software, realizará o controle de acesso. O resultado esperado com este projeto
é desenvolver um sistema com componentes de custo baixo, utilizando a biometria,
para realizar o controle de acesso a uma residência. Desta forma, este projeto inova
ao trazer uma alternativa eficiente, que com a utilização de alguns recursos de preço
reduzido, atinge o objetivo central de todo o projeto, a utilização da biometria
aplicada à segurança residencial.
Palavras-chave: Biometria; Porta Paralela; Segurança; Software; Hardware.
CRUZ, Rodrigo Rohling; NASCIMENTO JUNIOR, Sandro Dutra do, 70 páginas. Biometria Aplicada a Segurança Residencial. Trabalho de conclusão de curso (superior de tecnologia em Análise e Desenvolvimento de Sistemas) - Faculdades Integradas do Vale do Ivaí. Ivaiporã, 2013.
ABSTRACT
Currently, the rate of thefts has increased the residence. In 2012, the MP (Military
Police) showed an increase of 44% in the rate of thefts residence in Brazil (Silva,
2012), so there is a need to have a system that allows an access control safer that is
accessible to most of the population, since the use of simple keys and locks are not
as effective against thefts. The objective of this project is to develop a system similar
to the existing, but with lower price, enabling the access control for a segment of the
population that mostly does not have a position to acquire one of the existing ones.
To this end, a reader will be used in conjunction with a biometric electric lock that
connected to a computer through the parallel port, through software, to perform
access control. The expected outcome of this project is to develop a system with low
cost components, using biometrics to perform access control to a residence. Thus,
this project breaks new ground by bringing an efficient alternative, that the use of
some resources, reaches the central purpose of the entire project, the use of
biometrics applied to residential security.
Keywords: Biometrics, Parallel Port, Security, Software,Hardware.
SUMÁRIO
1. INTRODUÇÃO ...................................................................................................... 13
2. DESCRIÇÃO DO TEMA .............................. ......................................................... 14
3. JUSTIFICATIVA .................................. .................................................................. 15
4. OBJETIVOS ...................................... .................................................................... 16
4.1. Objetivos Gerais ................................................................................................. 16
4.2. Objetivos Específicos ......................................................................................... 16
5. FUNDAMENTAÇÃO TEORICA .......................... .................................................. 17
5.1. Biometria ............................................................................................................ 17
5.2. Porta Paralela ..................................................................................................... 18
5.3. Porta Pararela X Porta Serial ............................................................................. 20
6. ENGENHARIA DE SOFTWARE ......................... .................................................. 21
6.1. Técnica De Coleta De Dados ............................................................................. 21
6.2. Observação Natural ........................................................................................... 22
6.3. Entrevistas .......................................................................................................... 23
7. LEVANTAMENTO DO SISTEMA ........................ ................................................. 24
7.1. Levantamento De Requisitos ............................................................................. 24
8. REQUISITOS FUNCIONAIS ................................................................................. 25
9. ESPECIFICAÇÃO DE CASO DE USO ................... .............................................. 26
9.1. Manter Usuário – Cadastro ................................................................................ 26
9.2. Manter Usuário – Alterar .................................................................................... 26
9.3. Manter Usuário – Exclusão ................................................................................ 27
9.4. Efetuar Login ...................................................................................................... 27
10. REQUISITOS NÃO FUNCIONAIS ..................... ................................................. 29
10.1. Requisitos Não Funcionais – Descrição ........................................................... 29
10.1.1. Portabilidade ................................................................................................. 29
10.1.2. Segurança ..................................................................................................... 29
10.1.3. Usabilidade .................................................................................................... 30
11. REGRAS DE NEGÓCIO ..................................................................................... 31
11.1. Regras de negócio do administrador ................................................................ 31
11.2. Regras de negocio do usuário morador ........................................................... 31
12. CICLO DE VIDA DE SOFTWARE ...................................................................... 32
13. METODOLOGIA DE DESENVOLVIMENTO ................ ...................................... 33
14. ESTUDO DE VIABILIDADE (ECONÔMICA - TÉCNICA) ... ................................ 34
14.1. Viabilidade Econômica ..................................................................................... 34
14.2. Viabilidade Técnica .......................................................................................... 34
15. CRONOGRAMA DE CONFECÇÃO ....................... ............................................ 36
16. MAPA CONCEITUAL ............................... .......................................................... 37
17. FASE DE PLANEJAMENTO E ANÁLISE ................ .......................................... 38
17.1. Planejamento do projeto................................................................................... 38
17.2. EAP (ESTRUTURA ANALÍTICA DE PROJETO) .............................................. 38
17.3. Estrutura Analítica do Projeto (EAP) ................................................................ 39
17.4. Plano de gerenciamento de tempo ................................................................... 39
18. ESPECIFICAÇÃO DO SOFTWARE ..................... .............................................. 42
18.1. Diagrama De Caso De Uso .............................................................................. 42
18.2. Diagrama De Classe ........................................................................................ 42
18.3. Diagrama de Sequência ................................................................................... 43
19. MODELO DE CASO DE USO ......................... .................................................... 44
19.1. Diagrama de Caso de Uso ............................................................................... 44
20. MODELO DE CLASSES ............................. ........................................................ 45
21. MODELO DE INTERAÇÕES .......................... .................................................... 46
21.1. Diagrama de Sequência Login ......................................................................... 46
21.2. Diagrama de Sequência Cadastro ................................................................... 47
21.3. Diagrama de Sequencia Editar ......................................................................... 48
21.4. Diagrama de Sequência Excluir ....................................................................... 49
22. PROJETO DE INTERFACE GRÁFICA (PROTÓTIPOS) ..... ............................... 50
22.1. Protótipo tela de Login...................................................................................... 50
22.2. Protótipo Manter Morador ................................................................................. 51
22.3. Protótipo Tela de Validação ............................................................................. 52
23. PROJETO DE BANCO DE DADOS ..................... .............................................. 53
23.1. Der.................................................................................................................... 53
23.2. Der Inicial ......................................................................................................... 53
23.3. Der Final ........................................................................................................... 54
24. COMANDOS SQL .................................. ............................................................. 56
25. VALIDAÇÃO BIOMÉTRICA .......................... ..................................................... 58
26. TECNOLOGIAS UTILIZADAS ........................ .................................................... 59
26.1. Componente Finger .......................................................................................... 59
26.2. Firebird – Banco De Dados .............................................................................. 59
26.3. Delphi - Ambiente De Programação ................................................................. 59
26.4. IBExpert – Sistema Gerenciador De Banco De Dados (SGBD) ....................... 60
26.5. SDK Nitgen– Kit De Desenvolvimento ............................................................. 60
26.6. Fing Key Hamster Dx – Leitor Biométrico ......................................................... 61
26.7. InpOut32.dll ...................................................................................................... 61
26.8. Astah Community – Diagramação .................................................................... 61
26.9. Case Studio – Modelagem Do Banco De Dados .............................................. 62
27. LIMITAÇÕES DO SISTEMA ......................... ...................................................... 63
28. EXPERIMENTOS REALIZADOS ....................... ................................................. 64
29. TRABALHOS FUTUROS ............................. ....................................................... 65
30. CONCLUSÃO ..................................... ................................................................ 66
APÊNDICE................................................................................................................ 67
REFERENCIAS......................................................................................................... 68
LISTA ABREVIAÇÕES
SQL - Structured Query Language ou Linguagem de Consulta Estruturada
UML –UnifiedModelingLanguage ou Linguagem de Modelo Unificado
DCU – Diagrama de Caso de Uso
UC – Use Case ou Caso de Uso
RC – Requisitos de Confiabilidade
RD – Requisitos de Desempenho
RF – Requisito Funcional
RN – Regra de Negócio
RP – Requisitos de Portabilidade
RS – Requisitos de Segurança
RU – Requisitos de Usabilidade
SDK – Software Development Kit ou Kit de Desenvolvimento
LISTA DE QUADROS
Quadro 1 - Requisitos funcionais...............................................................................23
Quadro 2 - Requisito de portabilidade........................................................................26
Quadro 3 - Requisitos segurança...............................................................................26
Quadro 4 - Requisitos usabilidade......................................................................... ...27
Quadro 5 – Regras de negócio do administrador.......................................................28
Quadro 6 - Regras de negócio do usuário morador...................................................28
Quadro 7 – Cronograma Inicial..................................................................................30
LISTA DE ILUSTRAÇÕES
Figura 1 – Mapa Conceitual.......................................................................................31
Figura 2 – EAP...........................................................................................................33
Figura 3 – Diagrama de Caso de Uso........................................................................37
Figura 4 – Diagrama de Classe..................................................................................38
Figura 5 – Diagrama de Sequência – Login...............................................................39
Figura 6 – Diagrama de Sequência – Cadastro.........................................................40
Figura 7 – Diagrama de Sequência – Editar..............................................................41
Figura 8 – Diagrama de Sequência – Excluir.............................................................42
Figura 9 – Protótipo – Tela de Login..........................................................................43
Figura 10 – Protótipo – Manter Morador....................................................................44
Figura 11 – Protótipo – Validação..............................................................................45
Figura 12 – DER Inicial...............................................................................................46
Figura 13 – DER Final................................................................................................47
13
1. INTRODUÇÃO
A carência de uma tecnologia eficaz eacessível para o controle de
acesso, no mercado, é algo evidente. Existem, porém, sistemas similares que
oferecem maior segurança a residências, entretanto, possuem custo muito alto, e,
grande parte da população, não possui condições de adquirir.
O uso da biometria traz uma inovação ao mercado de segurança
residencial, pois a digital é algo pessoal e intransferível que não corremos o risco de
perder ou esquecer. Segundo MARTINS, 2009 “O termo biometria significa medição
biológica, ou seja, é o estudo das características físicas e comportamentais de cada
pessoa. O princípio básico desta técnica para identificação é: seu corpo, sua
senha.”.
A prosperidade que a tecnologia biométrica vem tendo, visando a
segurança residencial, é um fato. Esta ascensão esta ligada ao fato da facilidade da
autenticação via digital. Segundo Giuseppe "O grande atrativo é trocar as senhas
por uma chave mais segura e protegida, onde você é sua própria chave, que
ninguém pode roubar ou pegar emprestada", afirma.
Neste sentido, o objetivo deste projeto, é desenvolver um sistema que
possibilita o controle de acesso a uma residência, utilizando a digital, por intermédio
da leitura biométrica, porém, com um diferencial: o baixo custo.
14
2. DESCRIÇÃO DO TEMA
O tema proposto visa agregar mais segurança aos domicílios que
utilizarão o sistema. A biometria vai auxiliar de forma que, em um sistema que utiliza
esta tecnologia, só é possível o acesso à residência se determinado usuário for
cadastrado, ou seja, esta certificação biométrica traz mais confiabilidade.
Um sistema biométrico para esta área de mercado auxilia na diminuição
de roubos a casas que estão vulneráveis porque ainda não contam com um sistema
de autenticação automatizado.
A biometria é uma tecnologia usada para fazer uma validação, neste caso
específico, usando a digital dos dedos. A aplicação desta tecnologia resultará em
uma diminuição dos índices de roubos, pois a biometria oferece uma verificação de
alto nível, onde somente pessoas cadastradas no sistema podem ter acesso a
residência, através de uma chave única, neste caso, o dedo.
Conceitualmente, biometria é a medida de características únicas do
indivíduo que podem ser utilizadas para reconhecer sua identidade (LIU &
SILVERMAN, 2001). Este conceito aplica-se à identificação de pessoas, pois seus
padrões físicos tornam-se seus métodos de autenticação.
Para garantir um nível aceitável de segurança o sistema possuirá travas
que serão acionadas e desacionadas pelo usuário através do sistema. O usuário
efetuará o cadastro de pessoas autorizadas ao acesso da residência através de uma
interface simples e de fácil manuseio que ficará localizada dentro da residência,
podendo alterar, excluir, acrescentar cadastros quando quiser, de modo que para se
fazer alterações o indivíduo precisa autenticar-se perante o sistema.
15
3. JUSTIFICATIVA
Devido ao alto índice de violência a que estamos sujeitos é imprescindível
que haja um sistema que faça o controle de acesso residencial de qualidade. Para
realizar esse controle a biometria seria um meio muito útil, pois só seria permitida a
entrada de pessoas cadastradas no sistema.
Desenvolver um sistema que utiliza a biometria para fazer uma
autenticação resolverá os problemas supracitados. Para controlar a entrada e/ou
saída com maior facilidade e agilidade propõe-se a utilização da biométrica para
sanar os problemas. Este sistema visa dar maior garantia de que a pessoa que entra
ou sai de sua casa é realmente alguém que você conhece e que estava previamente
cadastrada em seu sistema, ou seja, o risco de um ladrão entrar em sua casa pelo
fato de ter roubado suas chaves fica reduzido, pois dificilmente as chaves serão
utilizadas, apenas em casos de extrema urgência, como por exemplo, uma eventual
queda de energia, onde os mecanismos de autenticação perdem a funcionalidade
por serem dependentes deste recurso. E a chave pode ser utilizada com ou sem
energia elétrica.
16
4. OBJETIVOS
4.1. Objetivos Gerais
Conforme Oliveira (2011, p. 36) “o objetivo geral precisa dar conta da
totalidade do problema da pesquisa, devendo ser elaborado com um verbo de
precisão, evitando ao máximo uma possível distorção na interpretação do que se
pretende pesquisar.”. Abaixo segue o objetivo geral deste presente projeto:
O intuito central deste presente projeto é desenvolver um sistema que
utiliza a tecnologia da biometria a fim de auxiliar na segurança residencial e agregar
qualidade na forma de acesso do usuário, tornando mais fácil e rápido uma
autenticação biométrica, pelo fato da ‘chave’ está sempre disponível.
4.2. Objetivos Específicos
De acordo com Oliveira (2011, p. 37) “os objetivos específicos fazem o
detalhamento do objetivo geral e devem ser iniciados com o verbo no infinitivo.”
Abaixo segue os objetivos específicos para este projeto:
• Analisar os requisitos;
• Verificar a existência de sistemas similares;
• Desenvolver uma interface de comunicação entre Hardware e Software;
• Desenvolver uma base de dados que suporte o cadastro dos usuários;
• Utilizar a trava elétrica como forma de abertura de uma porta;
• Utilizar a leitura biométrica, diminuindo o uso da chave;
• Identificar o usuário pela leitura biométrica;
• Identificar como forma alternativa, o acesso do usuário, por senha
cadastrada;
17
5. FUNDAMENTAÇÃO TEORICA
5.1. Biometria
Qual é a verdadeira vantagem de se utilizar a leitura biométrica como um
meio de autenticação, substituindo o uso da venha chave?
Atualmente, a biometria vem tendo notoriedade no mercado de segurança
residencial, visto que a digital é algo pessoal e intransferível que não corremos o
risco de perder ou esquecer. Segundo WILSON, 2004 “A biometria é a tecnologia
que identifica a pessoa baseando-se em suas características físicas ou
comportamentais”.
Uma impressão digital é composta por vários sulcos, que em sua
formação manifestam diferenças que são chamadas de pontos de minúcias (partes
em que os sulcos se dividem ou onde terminam abruptamente). Nestes pontos,
existem características únicas, que podem ser medidas. De acordo com GIUSEPPE,
que trabalha para o Serviço Federal de Processamento de Dados (Serpro), onde são
desenvolvidas soluções em segurança e autenticação de redes. "Na Europa,
judicialmente, são necessárias 12 minúcias para saber quem é uma pessoa. Os
leitores biométricos são capazes de identificar mais de 40 minúcias de uma
impressão digital", conclui.
Em tese, o processo de análise biométrica não é tão complexo quanto
parece. Quando o scanner é acionado, a principal função dele é obter uma imagem
nítida e de alta resolução do objeto em estudo: no caso a digital. Após este processo
concluído, o próximo passo é colocar a imagem captada para a análise em um
software que faça a leitura biométrica, o qual deve analisar e extrair as
características mais relevantes da figura.
Podemos citar o DETRAN como um exemplo de utilização da digital como
forma de confirmar a presença do usuário em suas aulas de trânsito. Outra
tecnologia que vem sendo utilizada, e, em paralelotestada pelo UNIBANCOé o
reconhecimento da íris (CUNHA, 2008).
A ascensão desta tecnologia com o intuito de controlar o acesso
residencial, é uma realidade. Esta ascensão esta ligada ao fato da facilidade da
autenticação via digital, segundo GIUSEPPE "O grande atrativo é trocar as senhas
18
por uma chave mais segura e protegida, onde você é sua própria chave, que
ninguém pode roubar ou pegar emprestada", afirma.
Quando falamos em biometria, devemos rememorar que a biometria é
classificada em duas categorias: físicas e comportamentais. Dentro da física
podemos elencar as formas de identificação: veias da mão, impressão digital,
reconhecimento facial, Íris, retina e geometria da mão. Já na
comportamental,existem estudos complexos sobre as atitudes tomadas pelas
pessoas, pois os cientistas acreditam que, futuramente será possível distinguir uma
pessoa no meio da multidão apenas pelo jeito de caminhar, a forma que ela mexe as
mãos ou identificando alguma “mania” dele.
5.2. Porta Paralela
Uma porta paralela é uma interface de comunicação entre o computador e
um periférico. Logo quando foi criada, pela IBM, a sua ideia era conectar essa porta
a uma impressora, mas atualmente, existem vários periféricos que utilizam a porta
paralela tanto para enviar, quanto para receber dados de um computador, como por
exemplo: unidades de disco removível e scanners.
A porta paralela é uma interface de comunicação entre o computador e um periférico. Quando a IBM criou seu primeiro PC (Personal Computer) ou Computador Pessoal, a idéia era conectar a essa porta uma impressora, mas atualmente, são vários os periféricos que utilizam-se desta porta para enviar e receber dados do computador(MESSIAS, 2006).
Segundo SILVA: “[...] a porta paralela transmite 8bits de dados, ou seja, 1
byte de uma só vez pelo fato dos 8 bits serem transmitidos em paralelo uns aos
outros, através de fios diferentes.”
Para desenvolver um software que controle um aparelho conectado a
porta paralela, basicamente, precisa-se de conhecimentos de eletrônica e de uma
linguagem de programação, podendo ser em C/C++/C++Builder, Pascal/Delphi ou
Visual. Através de um cabo paralelo, e de um pouco eletrônica aliada com a
programação, é possível realizar determinada funcionalidade. Segundo MESSIAS,
2006 “O DB25 é um conector que fica na parte de trás do gabinete do computador, e
é através deste, que o cabo paralelo se conecta ao computador para poder enviar e
receber dados”relata.
19
Esta porta tem ligação direta com a placa mãe do computador, sendo
necessário extremo cuidado ao conectar circuitos eletrônicos a essa porta, visto que
uma descarga elétrica ou um componente com sua polaridade invertida poderá
causar sérios danos ao computador.
A porta paralela possui dois modelos de transmissão, o unidirecional e o
bidirecional. O unidirecional, como o próprio nome sugere, a comunicação é
realizada utilizando um BUS de dados de 8bits, transmitindo 4bits por vez com o
periférico, este modelo é conhecido como SPP (Standard ParallelPort), podendo
chegar a 150kb/s. O modelo bidirecional utiliza um BUS de dados (ou barramento)
de 32 bits e a transmissão para periféricos se dá 8bits por vez, a velocidade de
transferência pode chegar 2mb/s, necessitando de cabeamento especial para atingir
o melhor desempenho.
No projeto será usado o modelo unidirecional, pois devido a necessidade
estabelecida, a intenção do projeto e a quantidade de dados existentes no sistema
não se faz necessário demanda maior do que o modelo unidirecional suprirá. A porta
paralela, neste sistema, não ficará responsável por grande volume de transmissão
de dados, e sim ficará responsável pelo envio do sinal capaz de destravar a tranca
elétrica. Sendo assim, este fato comprova o uso do modelo unidirecional.
Por padrão, os computadores que utilizamos nomeiam as portas paralelas
com a seguinte nomenclatura: LPT1. Podem existir mais portas, como por exemplo,
LPT2, LPT3, etc. Mudando apenas os endereços onde elas são encontradas por
seus controladores.
Quanto à extensão do cabo paralelo, este pode ser de no máximo de 8m
de comprimento, sendo que quanto maior o cabo, maior é o índice de interferência
na transmissão de dados. Deduz-se então, que quanto menor o cabo conector,
melhor será a integridade da informação transmitida por ele.
Tendo esta limitação do comprimento do cabo paralelo, a saída
encontrada para contornar este problema será utilizar controle remoto, que já veio
integrado com a fechadura, que trabalham com ondas de rádio para a comunicação
entre sistema e hardware, fazendo-se assim possível aumentar esta limitação de
8m.
A comunicação se dá através do conector DB25, é através dele que os
dados são transferidos. Tudo se resume em comandos elétricos, onde cada pino
recebe determinada voltagem para saber qual tarefa deverá ser seguida. A
20
linguagem de programação tem o papel de controlar a porta, através de códigos-
fonte de escrita de alto nível, que mais tarde, serão convertidos em sinais elétricos,
respeitando toda a hierarquia e camadas de um computador.
5.3. Porta Pararela X Porta Serial
Por que usar a porta paralela e não a serial?
Para entender a vantagem na utilização da porta paralela, primeiramente,
precisamos explicar o funcionamento de uma porta serial e de uma porta paralela,
posteriormente, devem-se confrontar as duas definições, e, diante disso, fica clara a
escolha da porta paralela para este projeto.
A porta serial é considerada umas das conexões externas básicas para o computador e esta inserida nos computadores a anos. Seu nome se deriva do fato dessa porta transmitir os bitsem séries. A vantagem dessa porta é que utiliza somente um fio para transmitir os 8bits, diferente da porta paralela que necessita de oito fios. Isso faz com que cabos seriais sejam menores, diminuindo seu custo. Inicialmente, a porta serial atingia a velocidade de 9600 bitspor segundo, sua ultima versão chegou a 115 kbytes. Quanto a desvantagem, está o fato de levar oito vezes mais tempo para transmitir os dados. (SILVA, 2009, pg.37)
Segundo a mesma autora, a vantagem da porta paralela é a transmissão
mais rápida.
A porta paralela transmite 8bits de dados, ou seja, 1 byte de uma só vez pelo fato dos 8 bitsserem transmitidos em paralela uns aos outros, através de fios diferentes. Sua velocidade inicial era de 150 kbytes por segundo, chegando a atingir num segundo momento 1,2 MB pelas ultimas impressoras paralela fabricadas. (SILVA, 2009, pg.37).
A partir das definições supracitadas, podemos entender a vantagem da
utilização da porta paralela e a não utilização de uma porta serial. O ponto forte da
porta paralela está na transmissão dos dados, de modo que, uma porta serial não
tem esta capacidade de transmissão maior.
Devemos considerar que a porta serial possui um tamanho menor
comparada a uma porta paralela, consequentemente, possui também menor custo,
entretanto, o que marca a utilização da porta paralela neste projeto, é, justamente, a
velocidade na transmissão dos dados. É importante ressaltar, que a porta serial leva
oito vezes mais tempo para transmitir os dados (SILVA, 2009, pg.37), fato este que
justifica a utilização da porta paralela neste projeto.
21
6. ENGENHARIA DE SOFTWARE
A Engenharia de software é voltada ao desenvolvimento, finalização e
manutenção de um software, que visa organização, qualidade e produtividade, que
atendam as necessidades solicitadas pelo cliente. Para atingir estas necessidades, o
softwaredeve ser considerado de alta qualidade, possuindo bom tempo de resposta
bem como, de processamento, tendo como sua principal característica a usabilidade
no seu alto nível, atendendo as expectativas.
A engenharia de software é uma disciplina de engenharia relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção, depois que este entrar em operação.(SOMMERVILLE, 2007, p.05).
A ideia da Engenharia de software é agregar organização ao projeto, pois,
com esta organização, consegue-se produzir um software de alta qualidade.
Sommerville(2007, p.5), diz que ”[...] os engenheiros de software adotam uma
abordagem sistemática e organizada em seu trabalho, que é, frequentemente, a
maneira mais eficaz de produzir softwarede alta qualidade”.
Na construção de sistemas de software, assim como na construção de sistemas habitacionais, também a uma graduação de complexidade. Para a construção de sistemas de software mais complexos, também é necessário planejamento inicial (BEZERRA, 2007, p.2)
Como visto acima, Bezerra faz uma analogia entre a engenharia civil e a
engenharia de software, abordando a necessidade de planejamento do projeto, a fim
de garantir que em projetos complexos, a sua conclusão seja atingida com sucesso.
6.1. Técnica De Coleta De Dados
A coleta de dados é utilizada para capturar informações relevantes e
corretas a cerca de um sistema. A etapa de coleta de dados auxilia na etapa de
levantamento dos requisitos de um projeto. É uma etapa que exige muita cautela e
empenho, pois dados coletados de forma incorreta ou incoerente resulta, no
produtos final, uma funcionalidade falha, ou em um sistema que foge da
necessidade do usuário.
O propósito da coleta de dados é reunir informações suficientes, relevantes e apropriadas, de forma que um conjunto de requisitos estável possa ser produzido. Mesmo no caso de existir um conjunto de requisitos iniciais, será
22
exigido que a coleta de dados expanda, esclareça e confirme esses requisitos iniciais. (PREECE, 2005, pg.230).
Na fase de coleta de dados necessita-se descobrir algumas questões
essenciais sobre o projeto.
“Precisamos descobrir dados sobre as tarefas que os usuários realizam atualmente e seus objetivos associados, o contexto em que as tarefas são realizadas e as razões por que as coisas são damaneira que são.” (PREECE, 2005, pg. 230).
6.2. Observação Natural
A definição desta técnica de coleta de dados para este projeto foi
motivada pela necessidade de análise do comportamento de usuários, bem como, o
cenário de violência que se encontra. Através da observação, levantou-se que o
método utilizado pela maioria dos usuários, era um método falho. A fechadura
antiga, que utiliza uma simples chave, não oferece a segurança e comodidade
necessária para os usuários. Diante desta observação, podem-se levantar alguns
requisitos que seriam necessários para sanar os problemas dos usuários.
Segundo PREECE, 2005, pg.233 a observação natural: “[...] implica
passar algum tempo com os stakeholdersenquanto realizam suas tarefas diárias,
observando o trabalho como ele realmente acontece, em seu ambiente natural.”.
Além de ajudar a atestarpormenoresque as outras técnicas de coleta de
dados não apresentam, a técnica de observação natural auxilia na identificação do
comportamento que uma máquina deve expressar.
A observação natural pode não apenas ajudar a preencher detalhes e nuanças, que simplesmente não aparecem em outras investigações, mas também oferecer um contexto para as tarefas. Contextualizar o trabalho ou o comportamento que uma máquina deve apresentar fornece dados que outras técnicas não fornecem – dados dos quais podemos extrair requisitos (PREECE, 2005, pg. 234).
É importante sobrelevar que esta técnica resulta em um grande volume
de dados, exigindo mais tempo e comprometimento por parte dos membros, a fim de
extrair o maior numero possível de requisitos valendo-se deste grande quantidade
de dados.
23
6.3. Entrevistas
Outra forma, dentre várias outras, de coleta de dados, que são realizadas
em conjunto são as entrevistas. As entrevistas podem ser pensadas como
“conversação com um propósito” (Kahn e Canneli, 1957). São perguntas realizadas
a um determinado público para entender as opiniões, necessidades e restrições à
um determinado produto. Com intuito de dar uma justificativa plausível para o
projeto, que defende uma forma de baixo custo de autenticação, foram feitas
entrevistas, onde foram abordadas perguntas como: “Porque você não possui uma
forma de autenticação biométrica?”. As respostas na maioria dos casos foram a
respeito do elevado custo de aquisição e manutenção. Tendo isto como base, o
projeto visa diminuir esta justificativa dos usuários de classes menos favorecida.
24
7. LEVANTAMENTO DO SISTEMA
7.1. Levantamento De Requisitos
De forma direta e resumida, os requisitos são as funcionalidades do
sistema, estes requisitos são extraídos após todo um processo de análise da
necessidade do cliente e através das coletas de dados.
Um requisito, basicamente, é uma condição que ou capacidade que um
sistema deve atender para satisfazer (ARAUJO, 2012).
Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais. Esses requisitos refletem as necessidades dos clientes de um sistema que ajuda a resolver algum problema, por exemplo, controlar um dispositivo, enviar um pedido ou encontrar informações. O processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado de engenharia de requisitos. (SOMMERVILLE, 2007, pg. 79).
A atividade de levantamento de requisitos (também conhecida como elicitação de requisitos) corresponde a etapa de compreensão do problema aplicada ao desenvolvimento de software. O principal objetivo do levantamento de requisitos é que usuários e desenvolvedores tenham a mesma visão do problema a ser resolvido. Nessa etapa, os desenvolvedores, juntamente com os clientes, tentam levantar e definir as necessidades dos futuros usuários do sistema a ser desenvolvido. Essas necessidades são geralmente denominadas requisitos (BEZERRA, 2007, pg.22)
25
8. REQUISITOS FUNCIONAIS
Os requisitos funcionais descrevem as funções que um softwaredeverá
desempenhar.
Os requisitos funcionais descrevem o que o sistema deve fazer. Esses requisitos dependem do tipo de software que está sendo desenvolvido, dos usuários a que o software se destina e da abordagem geral considerada pela organização ao redigir os requisitos. Eles descrevem as funções do sistema detalhadamente (SOMMERVILLE, 2007, p.81).
Segundo FILHO, 2011, p.7, requisitos funcionais: “[...] representam os
comportamentos que um programa ou sistema deve apresentar diante de certas
ações de seus usuários.”.
Conforme supracitado, um bom detalhamento dos requisitos, é um ponto
forte para obter as funcionalidades que se deseja do sistema.
Quadro 1 - Requisitos funcionais:
RF01 – Manter Morador
Funcionalidadeque compete única e exclusivamente pelo usuário
ADMINISTRADOR;
RF02 – Efetuar Login
Funcionalidadedesempenhada por usuários comuns e administrador;
RF03 – Visualizar Log
Funcionalidadeque compete única e exclusivamente pelo usuário
ADMINISTRADOR;
26
9. ESPECIFICAÇÃO DE CASO DE USO
9.1. Manter Usuário– Cadastro
Ator: Usuário Administrador
Objetivo: Realizar a inclusão de um cadastro
Pré-condições
O usuário administrador deve estar logado e na tela de cadastro..
Fluxo Principal
1 - O usuário seleciona a opção “Incluir”;
2–O usuário administrador insere o nome do morador;
3 - O usuário seleciona a opção de “Ler a Digital”;
4 - O sistema exibe a tela do SDK;
5 - O SDK valida a digital;
6- O usuário insere a senha alternativa;
7- O usuário seleciona “Gravar”;
8- O sistema salva o cadastro no banco de dados;
Fluxo Alternativo
4.1A - Se o usuário já for cadastrado, o sistema do SDK informa o erro.
9.2. Manter Usuário– Alterar
Ator: Usuário Master
Objetivo: Realizar a alteração de um cadastro.
Pré-condições
O usuário administrador deve estar logado e na tela de cadastro.
27
Fluxo Principal
1 - O usuário seleciona o registro;
2 –O usuário seleciona alterar;
3 –O usuário edita os campos que deseja;
4- O usuário seleciona “Gravar”
5- O sistema salva os dados no banco.
9.3. Manter Usuário– Exclusão
Ator: Usuário Administrador
Objetivo: Realizar a exclusão de um cadastro.
Pré-condições
O usuário administrador deve estar logado e na tela de cadastro.
Fluxo Principal
1 - O usuário seleciona o registro;
2 – O usuário seleciona a opção Excluir;
3 – O sistema exclui o registro do banco;
9.4. Efetuar Login
Ator: Usuário Administrador e Morador
Objetivo: Realizar ao login no sistema
Fluxo Principal
1 –Usuário clica em Verificar;
28
2 – Usuário coloca o dedo no leitor biométrico;
3 – Sistema valida se usuário já está cadastrado;
4- Sistema envia comando que destrava a porta.
29
10. REQUISITOS NÃO FUNCIONAIS
De forma simplificada, pode-se dizer que os requisitos não funcionais
descrevem as qualidades globais do sistema. Vale-se lembrar, ainda, que a
avaliação dos requisitos não funcionais começa na fase de desenvolvimento e vai
até a fase de testes finais do projeto.
Os requisitos não funcionais são aqueles não diretamente relacionados às funções específicas fornecidas pelo sistema. Eles podem estar relacionadosàspropriedades emergentes do sistema, como confiabilidade, tempo de resposta e espaço de armazenamento (SOMMERVILLE, 2007, p.82).
Segundo Wilson de Pádua Paula Filho, 2011, p.7, requisitos não
funcionais: “[...] quantificam determinados aspectos do comportamento.”.
10.1. Requisitos Não Funcionais – Descrição
10.1.1. Portabilidade
A portabilidade de um programa de computador, é a capacidadedele ser
executado ou compilado em diferentes arquiteturas de software ou hardware.
Segundo Bezerra(2007 p.24) Portabilidade é “restrições sobre as
plataformas de hardware e de software nas quais o sistema será implantado e sobre
o grau de facilidade para transportar o sistema para outras plataformas” .
Quadro 2 - Requisito de portabilidade:
RP01 O sistema deverá rodar na plataforma Windows
10.1.2. Segurança
De acordo com Sommerville (2007, p.32), “Segurança é o julgamento da
probabilidade de que um sistema possa resistir a intrusões acidentais ou
intencionais. Essas intrusões têm como alvo a base de dados, onde ficam
armazenadas as informações da empresa em questão”.
30
Segundo Bezerra(2007 p.24) segurança “é limitações do sistema em
relação a acessos não autorizados”.
Quadro 3 -Requisitos segurança:
RS01 -O banco de dadosé protegido com usuário e senha.
RS02 -Todo usuário, seja ele morador ou administrador, que tentar acessar o sistema
deverá passar pela identificação biométrica ou inserir a senha alternativa.
RS03 -Para cada ação que o usuário fizer no sistema, será gravado um log, ou seja,
será armazenado um registro da ação que ele realizou. Neste log, deve constar
o nome do usuário, a ação desempenhada por ele, data e hora.
10.1.3. Usabilidade
SegundoBezerra (2007 p.24) usabilidade: “são requisitos que se
relacionam ou afetam a usabilidade do sistema. Incluem requisitos sobre facilidade
de uso e a necessidade ou não de treinamentos dos usuários”.
Quadro 4 - Requisitos usabilidade:
RU01 O sistema deve ter uma interface simples e objetiva
RU02 As cores que compõem o sistema serão leves, evitando o cansaço do usuário.
O estudo de usabilidade é uma parte essencial de todo processo de projeto de software. Se um sistema de software deve atingir todo seu potencial, é essencial que sua interface com o usuário seja projetada para combinar as habilidades, experiências e expectativas dos usuários. Muitos doschamados ‘erros deusuário’são causados pelo fato de que as interfaces de usuário não consideram as capacidades dos usuários reais e seu ambiente de trabalho (SOMMERVILLE, 2007, p.241).
31
11. REGRAS DE NEGÓCIO
Também conhecida como domínio da aplicação, asregras de negocio
definem restrições e quesitos que devem ser seguidos no projeto.
De acordo com Alenquer, 2002.
Sob o ponto-de-vista de sistemas de informações, regra de negócio é “uma sentença que define ou restringe algum aspecto do negócio (...) sua intenção é manter a estrutura do negócio, ou controlar ou influenciar algum aspecto do negócio”. Nesse contexto, as regras de negócio dizem respeito aos “dados que podem ser cadastrados em um sistema de informação”.
11.1. Regras de negócio do administrador
Quadro 5 – Regras de negócio do administrador:
RN01 A área de cadastro, alteração, inclusão e exclusão do morador só pode
ser acessada mediante logine senha pré-cadastrados do usuário
administrador.
RN02 O usuário administrador deve cadastrar, necessariamente, senha
biométrica e senha alternativa.
11.2. Regras de negocio do usuário morador
Quadro 6 -Regras de negócio do usuário morador
RN01 O usuário morador não poderá cadastrar outros moradores.
32
12. CICLO DE VIDA DE SOFTWARE
“O desenvolvimento de um sistema envolve diversas fases, a um
encadeamento especifico dessas fases para a construção do sistema dá-se o nome
de Modelo de Ciclo de Vida. (BEZERRA, 2007, p.35)”.
O Ciclo de Vida de um software expõe as fases que um sistema passa de
sua concepção até seu fim, é a verificação do processo do desenvolvimento dos
métodos aplicados que permite detectar os erros do software com mais rapidez e
assim dominar a qualidade do software.
33
13. METODOLOGIA DE DESENVOLVIMENTO
A metodologia de desenvolvimento que será adotada para a execução do
presente projeto, será a Espiral. Com esta metodologia torna-se possível a
visualização interativa durante o projeto, o que facilita a reavaliação constante dos
requisitos e dados do processo.Segundo FILHO, 2011, p.94, no modelo espiral: “O
produto é desenvolvido em uma série de iterações. Cada nova iteração corresponde
a uma volta na espiral.”.
Ainda segundo o mesmo autor:
O ciclo de vida em espiral permite que os requisitos sejam definidos progressivamente, e apresenta alta flexibilidade e visibilidade. Esse modelo permite que, em pontos bem-definidos, os usuários possam avaliar partes do produto e fornecer realimentação quanto as decisões tomadas (Wilson de Pádua Paula Filho, 2011, pg.94).
34
14. ESTUDO DE VIABILIDADE (ECONÔMICA - TÉCNICA)
Para entender a necessidade de se desenvolver um estudo de
viabilidade, devemos primeiramente saber para que serve este estudo e como ele é
feito.
Em todos os sistemas novos, o processo de engenharia de requisitos deve começar com um estudo de viabilidade. A entrada para o estudo de viabilidade consiste de um conjunto preliminar de requisitos de negócios, um esboço da descrição do sistema e como o sistema pretende apoiar os processos de negócios. (SOMMERVILLE, 2007, pg.97).
Este estudo tem como objetivo analisar se a viabilidade de implantação
do sistema realmente existe, neste estudo são levantadas as necessidades técnicas
e econômicas.
14.1. Viabilidade Econômica
14.1.1.1. Aquisições de equipamentos e itens
Depois de uma análise feita sobre os requisitos mínimos de software e
hardwareque serão necessários para implantação do sistema, verificou-se a
necessidade de adquirir alguns equipamentos e itens:
• Uma fechadura elétrica com controle remoto, de 12Volts;
• Um leitor biométrico Nitgen;
• 3 (três) metros de fio;
• Um cabo paralelo;
• Controle remoto(incluso na fechadura);
14.2. Viabilidade Técnica
Será necessário a utilização dos equipamentos e ferramentas
(hardwareesoftware) que darão suporte à implantação do sistema, não havendo
35
nenhum requisitoourestrição que afete o desempenho ou a capacidade de se
obterumsistema aceitável.
• Porta (podendo ser de Madeira ou ferro);
• Micro-computador(Dual Core (ou superior), 1GB RAM, 360HD,WindowsXP
(ou superior);
• Leitor biométrico Nitgen;
• Fechadura elétrica
36
15. CRONOGRAMA DE CONFECÇÃO
Quadro 7 – Cronograma Inicial
Atividades
MÊS E ANO DO PROJETO
MAR
2013
ABR
2013
MAI
2013
JUN
2013
JUL
2013
AGO
2013
SET
2013
OUT
2013
NOV
2013
DEZ
2013
A1- Leitura de Livros X X X X X X X X X X
A2- Análise de Requisitos X X X
A3-Documentaçãodo Sis. X X X
A4-Desenvolvimento X X X X
A5- Testes X X X X
A6-Implantação X X
A7- Conclusão X
37
16. MAPA CONCEITUAL
Um mapa conceitual é uma ferramenta gráfica que visa organizar e
representar o conhecimento. Sua estrutura é feita a partir de conceitos fundamentais
e suas relações. Normalmente, os conceitos são destacados em caixas de texto. A
relação entre dois conceitos é representada por uma linha ou seta, contendo uma
"palavra de ligação" ou "frase de ligação". Desta forma, um mapa conceitual tem por
objetivo reduzir, de forma analítica, a estrutura cognitiva subjacente a um dado
conhecimento, aos seus elementos básicos. Neste mapa estão contidos os usuários
que terão acesso ao sistema e suas respectivas denominações perante o sistema,
ficando bem claros e visíveis a ponto de entender quais são as incumbências de
cada tipo de usuário no sistema.
A figura abaixo representa o mapa conceitual deste projeto.
Figura 1 – Mapa Conceitual
38
17. FASE DE PLANEJAMENTO E ANÁLISE
17.1. Planejamento do projeto
A fase de planejamento de um projeto apresenta, de forma organizada,
toda a concepção, fundamentação, planejamento e meios de acompanhamento e
avaliação do projeto, sendo referência básica para sua execução.
O plano de projeto estabelece os recursos disponíveis para o projeto, a estrutura analítica do projeto e um cronograma para realizar o trabalho. Em algumas organizações, o plano de projeto é um único documento que inclui diferentes tipos de plano. Em outros casos, o plano está relacionado apenas ao processo de desenvolvimento (SOMMERVILLE, Ian, 2007, p.64).
17.2. EAP (ESTRUTURA ANALÍTICA DE PROJETO)
A EAP é uma ferramenta visual que permite a estruturação de um projeto
de forma simples e contém todo o trabalho necessário para conclusão do projeto. “A
estrutura analítica de um projeto é a base para definir o trabalho relacionado aos
objetivos do projeto. Trata-se do processo de criar uma estrutura capaz de conter a
subdivisão do produto em componentes menores (subprodutos), mais
gerenciáveis”(Passos,2008, pag.110).
Joseph Phillips (2002, p.131) define a estrutura analítica de um projeto
como “o trabalho necessário à conclusão do projeto.” A seguir, abordaremos a
estrutura analítica do projeto proposto.
17.3. Estrutura Analítica do Projeto (EAP
A figura abaixo demonstra a EAP para este projeto:
17.4. Plano de gerenciamento de tempo
Para definir o gerenciamento de tempo é necessário definir as atividades,
a duração delas, a sucessão de eventos e depois disso, desenvolver o cronograma.
Segundo PASSOS (2008, pag.117): “os
temposão divididos em quatro subprocessos:
das atividades, duração das atividades e contr
supracitados, são descritos a seguir.
Estrutura Analítica do Projeto (EAP )
A figura abaixo demonstra a EAP para este projeto:
Figura 2 - EAP
Plano de gerenciamento de tempo
Para definir o gerenciamento de tempo é necessário definir as atividades,
a sucessão de eventos e depois disso, desenvolver o cronograma.
Segundo PASSOS (2008, pag.117): “os processos de gerenciamento de
em quatro subprocessos: Definiçãodas atividades,sequ
das atividades, duração das atividades e controle de cronogramas.”
supracitados, são descritos a seguir.
39
Para definir o gerenciamento de tempo é necessário definir as atividades,
a sucessão de eventos e depois disso, desenvolver o cronograma.
de gerenciamento de
efiniçãodas atividades,sequência
ole de cronogramas.” Os processos
40
• Definição de atividades
Trata-se de decompor os níveis mais baixos da estrutura analítica do projeto
em um conjunto de atividades que, quando executadas, produzem
ossubprodutospropostos na EAP.
• Sequência das Atividades
Trata-se da identificação e documentação da interdependência entre as
atividades de modo a suportar o desenvolvimento de cronogramas realistas
para o projeto.
• Duração das atividades
A elaboração de estimativas de duração de uma atividade depende muito da
experiência de quem estima o tempo de realização da tarefa. Necessita de
discernimento e experiência adquirida com trabalhos semelhantes.
• Controle de cronogramas
Trata-se do processo de controlar a duração e a sequência de cada atividade
doprojeto. Cumpre examinarmos neste passo que o controle rígido dos
cronogramas é fundamental para o sucesso do projeto.
Após as noções citadas anteriormente, a seguir, abordaremos a tabela que descreve
os processos do plano de gerenciamento de tempo deste projeto.
TabelaGerenciamento de tempo
Item EAP Atividades Descrição Prazo
Estudo de
Viabilidade
Desenvolver o
estudo de
viabilidade do
projeto
Neste estudo, aborda-se a
viabilidade técnica e econômica
do projeto.
1 Mês
Levantamento de
Requisitos
Definir Técnica de
Coleta de Dados.
Analisar e Definir
Nesta fase, é definida a técnica
utilizada para coletar os
requisitos e posteriormente é
2 Meses
41
os requisitos feita a analise e definição dos
mesmos.
Documentação e
Planejamento
Construir o DER.
Construir
Diagramas.
Nesta fase, é construído o DER
do sistema, bem como os
diagramas que servirão de base
para a próxima fase
1 Mês
Desenvolvimento Desenvolver o
sistema.
Testar
Nesta fase, o sistema é
desenvolvido e posteriormente
testado
3 Meses
Implantação Instalação do
Sistema.
Treinar Usuário
Nesta fase é feita a instalação
do sistema proposto, bem como
é feito o treinamento do usuário
1 Mês
42
18. ESPECIFICAÇÃO DO SOFTWARE
18.1. Diagrama De Caso De Uso
Dentro da engenharia de software, os casos de uso são utilizados para
captar o comportamento pretendido de um sistema, sem ter a necessidade de
especificar como o comportamento será implementado. Pode-se dizer, que o
documento de caso de uso descreve uma sequência de eventos de um ator que
interage com o sistema para completar um processo.
O DCU é um dos diagramas da UML e corresponde a uma visão externa de alto nível do sistema. Esse diagrama representa graficamente os atores, casos de uso e relacionamento entre esses elementos. O DCU tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidade do sistema. (BEZERRA, 2007, p.70).
Booch, Rumbaugh, Jacobson (2005, p.241) afirmam que:
Os diagramas de caso de uso são aplicados para modelar a visão de caso de uso do sistema. Eles são muitos importantes para visualizar,especificaredocumentaro comportamento de um elemento. Essesdiagramasfazemcomque sistemas, subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como esses elementos podem ser utilizados no contexto.
18.2. Diagrama De Classe
Os diagramas de classe são representações da estrutura das classes,
que serviram como modelo para objeto. Expõem características e comportamentos
comuns a um conjunto de objetos. Considera-se que esta modelagem é muito útil
para o sistema, uma vez que define todas as classes que o sistema necessita
conter. Alémdisso, é a base para a construção dos diagramas de comunicação,
sequência e estados.
O diagrama de classes se encontra no centro do processo de modelagem de objetos. Ele é o diagrama principal para capturar todas as regras que governam a definição eo uso de objetos. Como o repositório para todas as regras, ele também é a principalfonte para a engenharia direta (transformar um modelo em código) e o alvo para aengenharia reversa (transformar código em um modelo). [...] O diagrama de classesprovavelmente é o diagrama mais utilizado da UML. (PENDER, 2004, p.83). Os diagramas de classes são os diagramas encontrados com maior freqüêncianamodelagem de sistemas orientados a objetos. Um diagrama de
43
classes mostra umconjunto de classes, interfaces e colaborações e seus relacionamentos. [...] Sãousados para fazer a modelagem estática do projeto de um sistema. São importantes não só para a visualização, a especificação e a documentação de modelos estruturais,mas também para a construção de sistemas executáveis por intermédio deengenharia de produção e reversa (Booch, Rumbaugh, Jacobson, 2005, p.107).
Dentre os diagramas da UML(UnifiedModelingLanguage), ou seja,
Linguagem de Modelagem Unificada pode-se considerar o diagrama de classe, um
dos diagramas mais abastado em termos de notações.
Para BEZERRA, 2007, pg. 122: “O diagrama de classes é utilizado na
construção do modelo de classes desde o nível de análise até o nível de
especialização. De todos os diagramas da UML, esse é o mais rico em termos de
notação.”, afirma.
18.3. Diagrama de Sequência
Este diagrama tem o objetivo de mostrar como as mensagens entre
objetos são trocadas no decorrer do tempo para a realização de uma operação.
O diagrama de seqüência é um diagrama de interação que dá ênfase à ordenação temporal das mensagens. Um diagrama de seqüência mostra um conjunto de papéis e as mensagens enviadas e recebidas pelas instâncias que representam os papéis. Use o diagrama de seqüência para ilustrar a visão dinâmica de um sistema (Booch, Rumbaugh, Jacobson, 2005, p.98).
Pender, 2004, p.49, define que:
O foco do diagrama está na identificação de interações entre os objetos com otempo. O maior benefício do diagrama é que ele ajuda a identificar as mensagenstrocadas entre os objetos. A troca de mensagem exige um transmissor e um receptor.
Para BEZERRA, 2007, pg. 193: “O objetivo do diagrama de sequência é
apresentar as interações entre objetos na ordem temporal em que elas acontecem.
Assim como os outros diagramas da UML, o diagrama de sequência possui um
conjunto de elementos gráficos.”, relata.
44
19. MODELO DE CASO DE USO
19.1. Diagrama de Caso de Uso
Figura 3 – Diagrama de Caso de Uso
45
20. MODELO DE CLASSES
20.1. Diagrama de Classe
Figura 4 – Diagrama de Classe
46
21. MODELO DE INTERAÇÕES
21.1. Diagrama de Sequência Login
Figura 5 – Diagrama de Sequência –Login
47
21.2. Diagrama de Sequência Cadastro
Figura 6 – Diagrama de Sequência - Cadastro
48
21.3. Diagrama de Sequencia Editar
Figura 7 – Diagrama de Sequência – Editar
49
21.4. Diagrama de Sequência Excluir
Figura 8 – Diagrama de Sequência – Excluir
22. PROJETO DE INTERFACE
22.1. Protótipo tela de Login
PROJETO DE INTERFACE GRÁFICA (PROTÓTIPOS)
Protótipo tela de Login
Figura 9 – Protótipo – Tela de Login
50
22.2. Protótipo Manter Morador
Protótipo Manter Morador
Figura 10 – Protótipo – Manter Morador
51
52
22.3. Protótipo Tela de Validação
Figura 11 – Protótipo – Validação
53
23. PROJETO DE BANCO DE DADOS
23.1. Der
O Diagrama de Entidade e Relacionamento descreve, na forma de
diagramas, como a base de dados está estabelecida, ele informa em um grau de
abstração muito elevado as tabelas do banco de dados, suas colunas e os
relacionamentos entre elas.
23.2. Der Inicial
No início do projeto, foi abstraída uma determinada necessidade, que
segue representada abaixo:
54
Figura 12 – DER Inicial
23.3. Der Final
Durante o desenvolvimento, foram identificadas tabelas que,
desnecessariamente estavam contidas no DER, pois não agregavam valos algum ao
projeto e sim somente demandava mais trabalho.
A equipe de desenvolvimento reformulou o DER, deixando-o mais simples
e de modo que atendesse os requisitos do projeto.
A nova proposta defende a tese de que um DER não precisa ser
complexo e difícil entender. O projeto realizado propõe um controle de acesso, que
55
por intermédio de interface gráfica, o usuário possa destrancar sua porta através de
autenticação. Subentende-se que, para este cenário, não se faz necessário um
banco com inúmeras tabelas, até mesmo porque elas não seriam utilizadas de forma
útil.
Figura 13 – DER Final
56
24. COMANDOS SQL
Abaixo segue a representação dos comandos efetuados para a criação do
banco de dados, tabelas e suas devidas manipulações:
Create Table "USUARIIO" (
"ID_USUARIO" Integer NOT NULL UNIQUE,
"NOME" Varchar(90) NOT NULL,
"SENHA_ALTERNATIVA" Char(12) NOT NULL,
"ADM" Smallint Default 0,
Primary Key ("ID_USUARIO")
);
Create Table "EVENTOS" (
"ID_EVENTO" Integer NOT NULL UNIQUE,
"DATA_HORA" Timestamp NOT NULL,
"TIPO" Char(1) NOT NULL,
"ID_USUARIO" Integer NOT NULL,
Primary Key ("ID_EVENTO")
);
Alter Table "EVENTOS" add Foreign Key ("ID_USUARIO") references "USUARIIO"
("ID_USUARIO") on update no action on delete no action;
A tabela USUÁRIO foi definida para suportar os cadastros de usuários
que vão interagir com o sistema. Nestas tabelas foram definidas colunas onde as
57
informações relevantes serão armazenadas. A tabela USUARIO é composta pelas
colunas:
• ID_USUARIO: Coluna responsável pela chave primária do registro,
cada registro é diferenciado por esta chave.
• NOME: Coluna responsável pelo armazenamento do nome do
indivíduo. É de extrema importância, pois quem irá interagir com o
sistema, irá diferenciar os registros pelo nome, ao contrário do
bando de dados.
• SENHA_ALTERNATIVA: Coluna responsável pelo armazenamento
da senha alternativa, que é utilizada caso a autenticação
biométrica falhe.
• ADM: Coluna que indica o tipo de USUARIO, diferindo se ele é
administrador ou usuário comum. Por padrão, todos os registros
terão valor 0, ou seja, usuário comum. O usuário administrador é
definido na base de dados e recebe valor 1. Lógica esta que
permite agregar permissões.
Visto que um sistema de autenticação necessita de um registro de
eventos realizados, foi implementada a tabela EVENTOS, onde quem passa pela
autenticação perante o sistema, fica registrado esta assim. As colunas da tabela
EVENTOS foram definidas da seguinte forma:
• ID_EVENTO: Coluna responsável pelo armazenamento da chave
primária do evento registrado.
• DATA_HORA: Coluna onde serão armazenadas data e hora do
evento registrado.
• TIPO: Define o tipo de evento, ou seja, se foi um login ou um logout
do usuário administrador ou apenas uma passagem de qualquer
usuário.
• ID_USUARIO: Chave estrangeira onde fica definido o usuário que
realizou determinada ação. Esta chave ficou definida no código
pela alteração da tabela EVENTOS, como demonstrada no código
acima que referencia a chave estrangeira ao campo definido.
58
25. VALIDAÇÃO BIOMÉTRICA
Como já foi dito anteriormente no projeto, a validação biométrica é
realizada pelo leitor biométrico(hardware) que captura a digital inserida pelo usuário,
em conjunto com o SDK(software), e em seguida esta captura é analisada por seus
pontos de minúcias, diferindo um indivíduo do outro. Mas esta leitura está passível
de erros por diversos motivos, e eventualmente um usuário pode não obter êxito na
leitura biométrica. São vários os motivos que podem ocasionar um mau
funcionamento na leitura biométrica, um dedo cortado, desgastado ou algo
semelhante. Para amenizar este funcionamento indesejado, o sistema possui
alternativas de autenticação, como por exemplos, a senha alternativa. Ao realizar o
cadastro, o morador é obrigado a inserir uma senha numérica como forma
alternativa de autenticação e também pode cadastrar mais de um dedo na leitura
biométrica. Estes dois passos contribuem para uma melhor qualidade e reduz as
chances de erros quando uma validação está sendo efetuada.
59
26. TECNOLOGIAS UTILIZADAS
26.1. Componente Finger
Como já foi abordada anteriormente, neste projeto, a validação via
biometria é feita pela captação do leitor biométrico e o tratamento dos dados
armazenados é realizado através do SDK fornecido pelo fabricante, de forma
gratuita. Porém, este SDK não está totalmente ‘tratado’, está utilizando sintaxes e
conhecimentos de alto nível, onde demandaria muito atenção e estudo perante a
documentação deste SDK. Tendo isto como fato, o Srº. Robson de Lacerda
Zambroti, orientador deste trabalho, forneceu um componente, criado por ele, em
Delphi, que permite realizar as validações e leituras através de procedimentos
confeccionados por ele. Neste componente há vários métodos onde utiliza recursos
do SDK para realizar a leitura armazenamento dos dados extraídos.
26.2. Firebird – Banco De Dados
O banco de dados é um recipiente para uma coleção de arquivos de
dados computadorizados. Segundo DATE “Um sistema de banco de dados é
basicamente apenas um sistema computadorizado de manutenção de registros. O
banco de dados, por si só, pode ser considerado como o equivalente eletrônico de
um armário de arquivamento.”.
Para este projeto, o banco de dados escolhido foi o Firebird 2.5, pois
atende a necessidade do projeto e é gratuito.
O Firebird é derivado do código do Borland InterBase 6.0. Ele tem o código aberto e não possui licença dupla, portanto você pode utilizá-lo em qualquer tipo de aplicação, seja ela comercial ou não, sem pagar nada por isso.(Carlos H. Cantu, 2010).
26.3. Delphi - Ambiente De Programação
O Delphi é um compilador, uma IDE e uma linguagem de programação,
produzido antigamente pela Borland e atualmente produzido pela
Embarcadero.Largamente utilizado no desenvolvimento de aplicações desktop,
60
aplicações multicamadas e cliente/servidor, compatível com os bancos de dados
mais conhecidos do mercado. (SOMERA, 2007).
Foi eleito para o desenvolvimento da interface do projeto por ser capaz de
comunicar-se facilmente com o hardware e possui uma forma útil de trabalhar com
projetos, ficando de forma organizada e ágil o desenvolvimento.
26.4. IBExpert – Sistema Gerenciador De Banco De Da dos (SGBD)
Para o gerenciamentodos registros inseridos pelos usuários e também as
eventuais consultas efetuadas, será utilizado um SGBD (Sistema Gerenciador de
Banco de Dados) chamado IBExpert. Este SGBD será utilizado para manipular
tabelas, relacionamentos e eventuais procedures e triggers que estão contidas na
base de dados. Será utilizado em conjunto com o banco de dados Firebird, que
possui licença gratuita e supre a demanda de volume. Esta ferramenta é
inteiramente livre, ou seja, sua licença para uso não é cobrada pela empresa
fornecedora. É uma eficiente ferramenta para manutençãoda base de dados.
26.5. SDK Nitgen– Kit De Desenvolvimento
SDK significa Software Development Kit, ou seja, é um kit de
desenvolvimento fornecido pela fabricante, a Nitgen, para auxiliar no
desenvolvimento de softwares. O código é totalmente aberto, de modo com que
possa ser feitas alterações a qualquer momento no escopo do código-fonte, bem
como o reaproveitamento de procedimentos e funções contidas no código. Para o
projeto foi utilizado o SDK da Nitgen, a mesma fabricante do leitor biométrico
utilizado no projeto. Com este recurso, a verificação e validação da digital são feitas
de forma ágil e eficaz. No projeto possui um botão de realizar a validação da digital,
tanto para cadastramento, quanto para verificação para autenticar, neste botão é
acionado este SDK, que por meio de alterações no código, faz busca em um banco
de dados específico e analise se é permitido o acesso ou não.
61
26.6. Fing Key Hamster Dx – LeitorBiométrico
O FingKeyHamster DX é um eficiente e moderno leitor biométrico, sua
leitura é concisa e raramente falha. Este equipamento foi eleito por sua extrema
qualidade e preço acessível, que agrega ao intuito do projeto.
26.7. InpOut32.dll
É uma DLL utilizada para obter acessoa porta paralela via programação.
Com a adição deste recurso, fica mais fácil a manipulação e comunicação entre
código e hardware. O InpOut32 recebe parâmetros para encontrar o destino
desejado, no caso a porta paralela. Atua com a seguinte sintaxe:
“outportb($378,255);”. Onde é passado um caminho hexadecimal ($378) que
corresponde ao endereço designado à porta paralela, e que recebe valores binários
para comandar os pinos da porta. No exemplo acima, está recebendo o valor 255.
No código-fonte foi utilizado da seguinte maneira:
outportb($378,255);
sleep(1000);
outportb($378,0);
Onde é acionado e desacionado em um intervalo de um segundo.
26.8. AstahCommunity – Diagramação
Dentre várias ferramentas de UML existentes, a eleita para realizar a
parte de diagramas do projeto foi o Astah, que anteriormente era chamado de Jude.
É uma poderosa ferramenta de modelagem UML criada em Java. Esta ferramenta
permite o manuseio dos diversos diagramas previstos na engenharia de software e
que são de vital importância para um projeto bem definido e para agregar qualidade
no produto final.
62
26.9. Case Studio – Modelagem Do Banco De Dados
Case Studio se enquadra nas ferramentas de desenvolvimento, que
auxiliam desenvolvedores a modelar suas aplicações de forma prática e de fácil
manipulação. Esta ferramenta foi utilizada para modelar a base de dados onde serão
inseridas as informações e registros dos usuários. Ela permite fazer o DER
(Diagrama de Entidade e Relacionamento), ou seja, todas as tabelas do banco de
dados e seus respectivos relacionamentos. Através de uma interface gráfica é
possível criar as tabelas com seus campos, definindo os tipos de dados e limitações.
Após toda a ilustração gráfica é possível realizar a extração do código SQL para
exportar para o banco de dados, fazendo com que não haja retrabalho e facilite o
andamento do projeto.
63
27. LIMITAÇÕES DO SISTEMA
Para o pleno funcionamento do sistema, necessita-se utilizar eletricidade,
a fim de, alimentar a fechadura e o sistema como um todo. Todavia, existe a
possibilidade da falta da mesma, podendo-se dizer que o sistema de controle de
acesso é prejudicado caso ocorra uma queda na eletricidade.
Para contornar esta problemática, a chave física não foi eliminada no
projeto.
64
28. EXPERIMENTOS REALIZADOS
Para inicialização do projeto e para conseguir controlar a porta paralela
via sistema foi feitas algumas formas de teste. Primeiramente foram utilizados LEDs
(Light EmittingDiode), no português, Diodo Emissor de Luz, soldados juntamente aos
pinos da porta paralela com intuito de testar os comandos elétricos enviados via
programação.
Estes testes foram feitos com êxito, de modo que toda vez que era
emitido o comando para o pino via software, o led que se localizava no respectivo,
ascendia. Porém a equipe de desenvolvimento conseguiu enviar estes comandos
somente via um sistema fabricado por terceiros. Entretanto, com os estudos e as
buscas realizadas foi encontrada uma forma gratuita e prática de realizar esta
comunicação, utilizando o componente IoPort, instalado no Delphi. Componente este
capaz de enviar comandos em específicos pinos, definidos na linguagem de
programação.
No decorrer das tentativas, foi tentado implantar um relê que ficara
incumbido de fazer o intermédio entre porta paralela e fechadura e controlaria
sobrecargas, a fim de evitar eventuais transtornos, como queimar a porta. Porém,
este equipamento perdeu espaço no projeto, pois a trava elétrica utilizada no projeto,
estava acompanhada de um controle remoto. Com este recurso, apenas soldamos o
controle à porta paralela, eliminando cabos entre porta paralela e fechadura.
Fazendo assim, com que o comando fosse enviado de forma mais eficaz, através de
sinais de rádio ao receptor.
De forma resumida, o comando enviado à porta paralela simula um
‘apertar de botão’ no controle remoto.
65
29. TRABALHOS FUTUROS
A ideia do projeto foi necessariamente atendido, utilizando os recursos
propostos e fazendo com que, em conjuntos, todas as partes funcionassem. Porém,
há muito mais que pode ser feito com estes mesmos recursos, no que se refere à
automação residencial. Por exemplo, pode ser implementado um modelo de
consulta via web (não suportado no projeto atual), onde o usuário pode obter acesso
à sua residência do seu trabalho, escola, entre vários outros lugares. Esta ideia pode
virar realidade, se o sistema for integrado com webcams, ele pode ter acesso visual
em áreas estratégicas de sua casa, aumentando e valorizando a segurança.
Pode ser implementado, também, recursos de SMS (Short Message
Service), ou seja, serviço de mensagens curtas, para simplificar mais, a famosa
‘Mensagem de Celular’. Ela pode ser utilizada para mandar comandos ao sistema
via telefonia celular.
Com os recursos utilizados no projeto atual, pode-se também comandar
mais setores e objetos da residência. A porta paralela possui vários pinos, e via
linguagem de programação é possível designar em qual pino mandar comandos
elétricos. Com esta possibilidade, faz-se possível controlar janelas, elaborar um
recolhimento inteligente de varal de roupas, bem como acionar e desacionar
equipamentos eletrônicos.
O campo onde estes recursos podem ser aplicados, à fim de reduzir os
custos, é bem abrangente. Com disponibilidade e tempo hábil, a automação
residencial pode ser realizada de forma simplificada e de menor custo final para o
consumidor.
Nesta seção foram citadas algumas formas de aproveitar os mesmo
recursos usados neste trabalho, porém as ideias não ficam restritas apenas a estas.
66
30. CONCLUSÃO
Com o projeto, concluiu-se que um sistema de controle de acesso pode
ser desenvolvido com recursos de baixo custo, que, em conjunto, oferecem maior
segurança residencial, como qualquer tranca elétrica biométrica existente. Os
hardwares utilizados neste projeto possibilitam uma expansão de uso, que não se
restringe apenas a um simples controle de acesso, com trabalhos futuros surge a
possibilidades de agregar outras funções, e, não apenas a abertura de uma porta.
Conclui-se também, que as dificuldades encontradas no decorrer do
desenvolvimento, ofereceram novos caminhos, novos métodos para atingir o
objetivo do presente projeto. Para ultimar, a tecnologia biométrica que foi utilizada
facilita e agiliza uma atividade tão comum desempenhada diariamente, o abrir de
uma porta, com o préstimo da segurança, com a digital que é algo pessoal e
intransferível e muito mais difícil de ser falsificado, se comparada com uma simples
chave.
67
APÊNDICE
Foto do circuito montado para envio de comando ao controle remoto
68
REFERÊNCIAS
SILVA, Ceccatto Camila da.Manutenção completa em computadores .
MARTINS, Elaine. O que é biometria? Publicado em Novembro de 2009.
Disponivelem:http://www.tecmundo.com.br/o-que-e/3121-o-que-e-biometria-.html.
Acessado em 18/05/2013 às 14:15
CUNHA, Rodrigo.Com a biometria, a senha somos nós. Publicado em 2008.
Disponivelem:http://cienciaecultura.bvs.br/scielo.php?pid=S0009-
67252008000100003&script=sci_arttext. Acessado em 18/05/2013 às 15:56
BOOCH,Grady,RUMBAUGH, James, JACOBSON, Ivar, UML Guia do Usuário,
2ª edição , tradução de Fabio Freitas da Silva e Cristina de Amorim Machado – Rio
de Janeiro, editora: Campus, 2005
PAULA FILHO, Wilson de Pádua. Engenharia de software: fundamentos,
métodos e padrões . 3. ed. Rio de Janeiro: Reimpr, 2011.
PREECE, Jennifer; ROGERS, Yvonne; SHARP, Helen.Design de interação: Além
da interação homem-computador. Porto Alegre: Bookman, 2005. 548 p.
MESSIA, Antônio Rogério. Introdução a porta paralela. Disponível em:
<http://www.rogercom.com/pparalela/introducao.htm>. Acesso em: 01 jul. 2013.
GONÇALVES, José Artur Teixeira. Objetivos gerais e específicos. Disponível em:
<http://metodologiadapesquisa.blogspot.com.br/2008/11/objetivos-gerais-e-
especficos.html>. Acesso em: 08 jun. 2013.
WILSON, Tracy. Como funciona a biometria. Disponível em:
<http://informatica.hsw.uol.com.br/biometria.htm>. Acesso em: 01 ago. 2013.
SILVA, Marcos Aurélio. Furtos à residência têm alta de 44%, revela Polícia
Militar. Disponível em:
69
<http://www.jornalestadodegoias.com.br/noticias_detalhe.php?id_noticia=3012&&id_
editoria=4>. Acesso em: 28 mar. 2012.
SOMERA, Guilherme. Treinamento Profissional em Delphi . Digerati Books, São
Paulo, 2007.
ALENQUER, Pablo Lopes. Regras de Negócio para Análise em Ambientes
OLAP. Disponível em:
<http://www.cin.ufpe.br/~sfa/Regras%20de%20Neg%F3cio%20para%20An%E1lise
%20em%20Ambientes%20OLAP.pdf>. Acesso em: 22 set. 2013.
SOMMERVILLE, Ian, Engenharia de Software , 8ª edição, tradução de Selma
Melnikoff, Reginaldo Arakaki e Edilson de Andrade Barbosa– São Paulo, Editora:
Pearson Addison Wesley, 2007.
ROMAGNOLI, Giuseppe Dos Santos. Biometria: você é a senha. Disponível em:
<http://www1.serpro.gov.br/publicacoes/tematec/pubtem61.htm>. Acesso em: 11 jun.
2013
ARAUJO, Everson Santos. Desenvolvimento de Software. 2012. Disponível em:
<http://everson.com.br/files/Desenvolvimento_de_Software_-_impressao.pdf>.
Acesso em: 19 jul. 201
LIU, S.; SILVERMAN, M.A practical guide to biometric security technology . IT
Pro, 2001.
OLIVEIRA, Maria Marly de. Como fazer projetos, relatórios, monografias,
dissertações e teses. 5. ed. São Paulo: Elsevier, 2010.
70
BEZERRA, Eduardo, 2º edição, Princípios de Analise e Projetos de Sistemas
com UML – Rio de Janeiro, Editora: Campus, 2007.