Embed Size (px)
Citation preview
FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS
ALESSANDRA ARANTES DE SOUZA CAMARGO
DOUGLAS DE ALMEIDA BRITO
PROPOSTA DE MODELAGEM DE UM SISTEMA
PARA BIBLIOTECA UTILIZANDO JAVA E RFID
SÃO JOSÉ DOS CAMPOS
2009
i
ALESSANDRA ARANTES DE SOUZA CAMARGO
DOUGLAS DE ALMEIDA BRITO
PROPOSTA DE MODELAGEM DE UM SISTEMA
PARA BIBLIOTECA UTILIZANDO RFID E JAVA
Trabalho de graduação apresentado a
Faculdade de Tecnologia de São José dos
Campos, como parte dos requisitos necessários
para a obtenção do título de Tecnólogo em
Banco de Dados.
Orientador: Prof. Rogério Marinke
SÃO JOSÉ DOS CAMPOS
2009
ii
ALESSANDRA ARANTES DE SOUZA CAMARGO
DOUGLAS DE ALMEIDA BRITO
PROPOSTA DE MODELAGEM DE UM SISTEMA
PARA BIBLIOTECA UTILIZANDO RFID E JAVA
Trabalho de graduação apresentado a
Faculdade de Tecnologia de São José dos
Campos, como parte dos requisitos necessários
para a obtenção do título de Tecnólogo em
Banco de Dados.
__________________________________________________________
ANTÔNIO WELLINGTON SALES RIOS - MESTRE
__________________________________________________________
CARLOS AUGUSTO LOMBARDI GARCIA - MESTRE
___________________________________________________________
ROGÉRIO MARINKE - ESPECIALISTA
___/___/____
DATA DE APROVAÇÃO
iii
AGRADECIMENTOS
Aos nossos familiares pela compreensão e incentivo. Ao prof. Rogério Marinke que nos
orientou durante a execução deste trabalho. Ao prof. Giuliano Bertoti pelos constantes
ensinamentos. A todo o corpo docente que sempre nos acompanhou. À banca
examinadora pelas contribuições a este trabalho.
iv
RESUMO
A tecnologia de identificação por rádio-frequência (RFID) tem se apresentado como um
grande avanço no controle de informações e está sendo introduzida em bibliotecas com o
objetivo de proporcionar gestão eletrônica e novos serviços como o auto-atendimento e a
autodevolução de itens. A presente pesquisa tem o objetivo de propor a modelagem de uma
aplicação Web para bibliotecas utilizando a tecnologia Java e RFID. Foi adotado como estudo
de caso a biblioteca da Faculdade de Tecnologia (FATEC) de São José dos Campos. No
processo de desenvolvimento foi empregada a abordagem da orientação a objetos, gerando
documentos segundo a notação Unified Modeling Language (UML). Para implementação foi
empregada a linguagem de programação Java e frameworks que auxiliam o desenvolvimento
de aplicações Web. Como resultado da análise do problema foi definido uma proposta para a
arquitetura do sistema que está dividida em três camadas: apresentação, aplicação e dados. A
camada de apresentação é responsável pela interface com o usuário, requisita serviços ao
servidor da aplicação e apresenta os resultados. Na camada de negócios são definidas as
regras de negócio. Na camada de dados se encontra a base de dados da aplicação. Conclui-se
que a linguagem Java aliada aos frameworks adotados permite um desenvolvimento ágil com
software de boa qualidade.
Palavras-chave: RFID. Java. Sistema para Bibliotecas.
v
ABSTRACT
Radio Frequency Identification (RFID) technology has been presented as a substantial
progress for information control and applied on libraries with the intention of providing
electronic management such as customer attendance and return of products. This present
research's objective is propound a web application modeling for libraries using Java
technology and RFID. São José dos Campos FATEC's library was adopted as a case study. In
the development process was adopted the object orientation paradigm to generate whole
development process documentation in accordance with Unified Modeling Language (UML).
Java Language and frameworks were used to improve web applications development. A
proposal was defined as result of analysis of the problem to the system architecture distributed
in three layers: presentation, application and data. The presentation layer is responsible for
user interface, requiring services to server application and showing the results. The business
layer contains business rules defined during modeling process. The data layer where database
is found. In summary, Java language and the frameworks adopted allow a quick development
and a high quality of software.
Keywords: RFID. Java. Library Systems.
vi
LISTA DE FIGURAS
Figura 1 - Etiqueta padrão.........................................................................................................22
Figura 2 - Componentes físicos de um leitor ...........................................................................25
Figura 3 - Componentes lógicos de um leitor ..........................................................................26
Figura 4 - Processo de compilação de um programa Java .......................................................31
Figura 5 - Portabilidade do código Java ..................................................................................31
Figura 6 - Plataformas Java .....................................................................................................32
Figura 7 - Camadas de uma aplicação Java para Web..............................................................33
Figura 8 - Divisão do Container ..............................................................................................34
Figura 9 - Funcionamento do Sun Java System RFID ............................................................35
Figura 10 - Camadas de uma aplicação MVC .........................................................................39
Figura 11 - Aplicação do Struts no MVC ................................................................................43
Figura 12 - Funcionamento do Hibernate ................................................................................45
Figura 13 - Diagrama de casos de uso .....................................................................................52
Figura 14 - Arquitetura do sistema ..........................................................................................65
Figura 15 - Visão Geral do Diagrama de Classes da Aplicação Web .....................................66
Figura 16 - Diagrama de classes (Empréstimo) ......................................................................67
Figura 17 - Diagrama de classes (Usuário) .............................................................................68
Figura 18 - Diagrama de classes (Atendente) .........................................................................69
Figura 19 - Diagrama de classes (Administrador) ..................................................................70
Figura 20 - Diagrama de classes (Item) ..................................................................................71
Figura 21 - Diagrama de classes (Tipo) ..................................................................................72
Figura 22 - Diagrama de classes (Segmento) .........................................................................73
Figura 23 - Diagrama de classes (Reserva) .............................................................................74
Figura 24 - Diagrama de classes (Consulta) ............................................................................75
Figura 25 - Diagrama de classes (Multa) ................................................................................76
Figura 26 - Diagrama de Sequência (Reserva) ........................................................................77
Figura 27 - Diagrama de Sequência (Empréstimo) .................................................................78
Figura 28 - Diagrama de Sequência (Empréstimo - RFID) ....................................................78
Figura 29 - Diagrama de Sequência (Devolução) ...................................................................79
Figura 30 - Diagrama de Sequência (Devolução - RFID) .......................................................79
Figura 31 - Diagrama de Sequência (Consulta) ......................................................................80
Figura 32 - Diagrama de Sequência (Consulta - RFID) ..........................................................80
vii
Figura 33 - Diagrama de Sequência (Pesquisar Itens) .............................................................81
Figura 34 - Diagrama de Sequência (Consultar situação do usuário) .....................................82
Figura 35 - Diagrama de Sequência (Registrar Multa) ...........................................................83
Figura 36 - Diagrama de Sequência (Cadastros) .....................................................................84
Figura 37 - Visão geral do Modelo relacional banco de dados ...............................................85
Figura 38 - Dicionário de Dados (Acervo) ..............................................................................87
Figura 39 - Dicionário de Dados (Consultas) ..........................................................................88
Figura 40 - Dicionário de Dados (Empréstimos) ....................................................................89
Figura 41 - Dicionário de Dados (Login) ................................................................................90
Figura 42 - Dicionário de Dados (Reserva) .............................................................................91
Figura 43 - Tela inicial ............................................................................................................92
Figura 44 - Uso do Ajax...........................................................................................................93
Figura 45 - Exemplo do uso do plugin Tablesorter..................................................................93
Figura 46 - Código-fonte de implementação do plugin Tablesorter.........................................94
Figura 47 - Área restrita do usuário..........................................................................................95
Figura 48 - Área restrita do administrador do sistema.............................................................96
Figura 49 - Código-Fonte da classe de mapeamento ConsultasAction.java............................97
Figura 50 - Código-Fonte da classe de mapeamento ConsultasForm.java..............................98
Figura 51 - Código-Fonte de implementação do arquivo struts-config.xml............................99
Figura 52 - Código-Fonte da implementação da classe hibernate.cfg.xml referente à conexão
com banco de dados ..............................................................................................................101
Figura 53 - Código-Fonte da classe hibernate.cfg.xml referente à Configuração do pool de
conexões.................................................................................................................................101
Figura 54 - Código-Fonte da classe de mapeamento Emprestimos.hbm.xml.........................102
Figura 55 - Código-Fonte da classe de mapeamento Emprestimos.hbm.xml.........................102
Figura 56 - Código-Fonte da classe de mapeamento Emprestimos.hbm.xml.........................102
Figura 57 - Código-Fonte da classe HibernateUtil.java..........................................................103
Figura 58 - Código-Fonte da implementação da classe EmprestimoDao.java, método
listar()......................................................................................................................................104
Figura 59 - Parte do Código-Fonte de implementação da classe HibernateUtil.java ............105
Figura 60 - Parte do Código-Fonte de implementação da classe ItensDao............................105
viii
LISTA DE TABELAS
Tabela 1 - Principais diferenças entre RFID e códigos de barras.............................................29
Tabela 2 - Descrição de caso de uso (Consultar itens).............................................................53
Tabela 3 - Descrição de caso de uso (Reservar itens)...............................................................54
Tabela 4 - Descrição de caso de uso (Pesquisar itens)..............................................................55
Tabela 5 - Descrição de caso de uso (Efetuar devolução)........................................................56
Tabela 6 - Descrição de caso de uso (Efetuar empréstimo)......................................................57
Tabela 7 - Descrição de caso de uso (Consultar situação do usuário)......................................58
Tabela 8 - Descrição de caso de uso (Registrar multa).............................................................59
Tabela 9 - Descrição de caso de uso (Cadastrar usuários)........................................................60
Tabela 10 - Descrição de caso de uso (Cadastrar atendentes)..................................................61
Tabela 11 - Descrição de caso de uso (Cadastrar itens)............................................................62
Tabela 12 - Descrição de caso de uso (Cadastrar segmentos)..................................................63
ix
LISTA DE ABREVIATURAS E SIGLAS
API: Application Programming Interface
CPU: Unidade Central de Processamento
CSS: Cascading Style Sheet
DAO: Data Access Object
DOM: Document Object Model
EAS: Eletronic Article Surveillance
EEPROM: Electrically Erasable Programmable Read-Only Memory
EJB: Enterprise JavaBeans
GPS: Global Positioning System
HTML: HyperText Markup Language
ISBN: International Standard Book Number
JSE: Java Standart Edition
JEE: Java Enterprise Edition
JME: Java Micro Edition
JVM: Java Virtual Machine
JSP: Java Server Pages
MIT: Massachusetts Institute of Technology
MVC: Model-View-Controller
RAM: Random Access Memory
RFID: Radio Frequency Identification
SQL: Structure Query Language
UHF: Ultra High Frequency
UML: Unified Modeling Language
XML: Extense Markup Language
XSTL: Extensible Style Sheet Language
x
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................12
1.1 Motivação .................................................................................................................. 12
1.2 Objetivos .................................................................................................................... 13
1.2.1 Objetivo geral............................................................................................................. 13
1.2.2 Objetivos específicos ................................................................................................. 13
1.3 Metodologia ............................................................................................................... 14
1.4 Organização do trabalho ............................................................................................ 15
2 RFID .................................................................................................................................. 16
2.1 Breve histórico ........................................................................................................... 16
2.2 Aplicações da tecnologia RFID ................................................................................. 18
2.2.1 Aplicação da tecnologia RFID em bibliotecas........................................................... 19
2.3 Identificação por rádio-frequência (RFID) ................................................................ 20
2.4 Componentes de um sistema RFID............................................................................ 21
2.4.1 Etiquetas RFID........................................................................................................... 21
2.4.2 Leitores ...................................................................................................................... 24
2.4.3 Middleware ................................................................................................................ 27
2.5 Visão geral de uma implementação RFID ................................................................. 28
2.6 RFID e códigos de barras ........................................................................................... 28
3 FERRAMENTAS PARA DESENVOLVIMENTO DO SISTEMA ................................ 30
3.1 Java ............................................................................................................................ 30
3.1.1 Java EE....................................................................................................................... 33
3.1.3 Sun Java System RFID .............................................................................................. 35
3.2 Servidor de Aplicação ................................................................................................ 36
3.3 AJAX ......................................................................................................................... 36
3.4 JQuery ........................................................................................................................ 37
3.5 Padrões de Projeto...................................................................................................... 38
3.5.1 MVC .......................................................................................................................... 38
3.5.2 Singleton .................................................................................................................... 41
3.6 Frameworks................................................................................................................ 42
3.6.1 Struts Framework ....................................................................................................... 43
3.6.2 Hibernate .................................................................................................................... 44
3.7 Oracle 10g Express Edition ....................................................................................... 46
xi
4 MODELAGEM E DESENVOLVIMENTO DO SISTEMA ............................................ 47
4.1 Processo de software .................................................................................................. 47
4.2 Especificação de Requisitos de Software ................................................................... 48
4.2.1 Requisitos funcionais do sistema ............................................................................... 50
4.2.2 Requisitos não funcionais .......................................................................................... 51
4.2.3 Diagrama de casos de uso .......................................................................................... 52
4.2.4 Descrição dos casos de uso ........................................................................................ 53
4.2.5 Arquitetura de sistema ............................................................................................... 64
4.2.6 Diagrama de classes ................................................................................................... 66
4.2.7 Diagramas de sequência ............................................................................................. 77
4.2.8 Modelo de dados ........................................................................................................ 85
4.3 Projeto e implementação do protótipo ....................................................................... 92
4.3.1 Camada de visualização ............................................................................................. 92
4.3.2 Camada de aplicação.................................................................................................. 96
4.3.3 Camada de dados ..................................................................................................... 100
5 CONSIDERAÇÕES FINAIS .......................................................................................... 106
5.1 Contribuições ........................................................................................................... 106
5.1.1 Publicações .............................................................................................................. 107
5.2 Trabalhos futuros ..................................................................................................... 107
REFERÊNCIAS.....................................................................................................................109
APÊNDICES..........................................................................................................................111
12
1 INTRODUÇÃO
1.1 Motivação
A Faculdade de Tecnologia (FATEC) de São José dos Campos não possui atualmente um
software que permita o controle automatizado de sua biblioteca. Todo o trabalho de
empréstimo e devolução é feito utilizando fichas que são preenchidas manualmente pelo
atendente e a assinatura do usuário é requerida para comprovar a retirada e a devolução de um
item. Não há um cadastro de usuários e quando estes solicitam um material, o atendente
precisa verificar nas estantes se o mesmo encontra-se disponível para empréstimo. Isto torna o
trabalho repetitivo, propenso a erros e causa demora no atendimento ao usuário.
Com o crescente número de publicações e de usuários é necessário formas eficazes para o
gerenciamento do acervo, visando proporcionar agilidade no atendimento e confiabilidade no
armazenamento de dados.
A tecnologia de identificação por rádio-frequência (RFID) tem se apresentado como um
grande avanço no controle de informações e está sendo introduzida em várias bibliotecas do
mundo com o objetivo de proporcionar a gestão eletrônica dos acervos e a implementação de
novos serviços.
Essa tecnologia pode auxiliar no armazenamento seguro de informações, na identificação
automática de itens, no controle de inventários e possibilitar a oferta de serviços como o auto-
atendimento e a autodevolução de itens (SANTINI, 2008).
Por exemplo, as bibliotecas públicas de Munique, Alemanha, substituíram seus sistemas de
códigos de barra e os sistemas de segurança eletromagnéticos pela tecnologia RFID. Todos os
itens do acervo, incluindo livros, revistas, áudio e vídeo, receberam etiquetas RFID. As
bibliotecas contam com balcões de auto-atendimento para permitir que os usuários realizem
empréstimo e devolução dos materiais do acervo. Os funcionários utilizam equipamentos com
tal tecnologia que permite prestar assistência aos usuários no empréstimo e na devolução de
materiais, assim como a configuração de etiquetas dos novos materiais adquiridos pela
13
biblioteca. Contam, também, com postos de devolução automática com leitores que detectam
e registram a devolução dos itens do acervo (VIEIRA, 2007).
Ainda segundo Vieira (2007), as bibliotecas públicas de Amsterdã, Holanda, também estão
adotando a tecnologia RFID no seu gerenciamento, para permitir o auto-atendimento e para
garantir maior segurança contra furtos. Desta forma, o empréstimo de materiais é feito de
forma rápida e eficiente e os funcionários são liberados de realizar as tarefas de empréstimo
para outros serviços de atendimento aos usuários. A implantação dos leitores RFID tornou a
realização de inventários mais ágeis e precisos sem necessidade de remoção dos materiais.
Além disso, este equipamento é utilizado para procura de itens do acervo e tornou mais ágil a
localização.
A tecnologia Java possibilita o desenvolvimento de um software que possa ser integrado com
a RFID. Esta tecnologia oferece portabilidade, robustez, apresenta extensa documentação
disponível e permite a utilização das metodologias mais modernas para o desenvolvimento de
software, tais como um intenso número de frameworks para apoio no desenvolvimento. A
tudo isso se adiciona o fato de ser uma das linguagens de programação mais utilizadas na
atualidade, possuindo maior estreitamento com a demanda do mercado de trabalho.
1.2 Objetivos
1.2.1 Objetivo geral
Propor a modelagem de uma aplicação Web para biblioteca utilizando as
tecnologias Java e RFID.
1.2.2 Objetivos específicos
a) Determinar cenários de uso na biblioteca da Fatec de São José dos Campos;
14
b) empregar o paradigma de modelagem de dados orientado a objetos;
c) implementar um protótipo da aplicação Web utilizando a linguagem de
programação Java que possibilita a utilização da tecnologia RFID;
d) empregar framewoks para apoio ao desenvolvimento da aplicação Web;
e) adotar Padrões de Projeto que possibilitam a criação de um projeto
orientado a objeto reutilizável e flexível.
1.3 Metodologia
A presente pesquisa será desenvolvida adotando como estudo de caso a biblioteca da
Faculdade de Tecnologia (FATEC) de São José dos Campos.
Pretende-se, para realizar esta pesquisa, fazer um levantamento bibliográfico sobre a
tecnologia RFID e tecnologias que serão utilizadas para a implementação do protótipo da
aplicação Web para biblioteca.
Posteriormente, fazer um levantamento de requisitos por meio de entrevistas com envolvidos
no projeto e visitas às bibliotecas do Instituto Nacional de Pesquisas Espaciais (INPE) e
Instituto Tecnológico de Aeronáutica (ITA). Realizar a modelagem do software utilizando os
seguintes diagramas da UML: casos de uso, diagramas de sequência e diagramas de classe.
Propor para documentação do banco de dados um modelo relacional e apresentar o dicionário
de dados.
Na implementação pretende-se utilizar a linguagem de programação Java. No entanto, devido
ao grande número de casos de uso, serão selecionados para compor o protótipo da aplicação
aqueles que possibilitam a utilização do RFID. Adicionalmente, utilizar Padrões de Projeto
como: Model-View-Controller (MVC), Data Access Object (DAO), Factory, Singleton a fim
de demonstrar a utilização destes padrões em projetos orientados a objetos, e, organizar e
possibilitar uma rápida manutenção quando necessário. Empregar o framework Struts que
facilita o desenvolvimento de aplicações e auxilia a implementação do Padrão de Projeto
MVC. Para persistência dos dados será utilizado o framework Hibernate, que facilita o
15
mapeamento dos atributos entre uma base de dados relacional e o modelo orientado a objetos
de uma aplicação.
1.4 Organização do trabalho
No capítulo 2 é apresentada a tecnologia RFID, um breve histórico de seu desenvolvimento,
algumas áreas de aplicação desta tecnologia, principalmente em bibliotecas. Também são
descritos os principais conceitos, os componentes envolvidos em seu funcionamento, uma
visão geral de seu funcionamento e uma comparação desta tecnologia com o sistema de
código de barras.
O capítulo 3 trata das ferramentas empregadas no protótipo da aplicação e na base de dados.
São apresentadas as tecnologias Java, Java Enterprise Edition (Java EE) e o software Sun Java
System RFID. Também são apresentados o servidor de aplicação Glassfish, que oferece
suporte às novas especificações Java EE, o JQuery, biblioteca JavaScript que permite o uso do
AJAX melhorando a usabilidade e a interatividade na Web, assim como Padrões de Projetos e
frameworks adotados. Por fim, é descrito o software Oracle 10g Express Edition, utilizado no
desenvolvimento da base de dados.
O capítulo 4 trata da modelagem e desenvolvimento do protótipo da aplicação. É abordado o
processo de desenvolvimento de software e as atividades fundamentais. São descritas as
especificações de requisitos, os diagramas de caso de uso, a arquitetura do sistema, diagramas
de sequência e diagramas de classes. Também são apresentados os modelos relacionais do
banco de dados e um dicionário de dados. Por fim, é apresentado como estudo de caso a
implementação do protótipo dos cenários de casos de uso escolhidos.
No capítulo 5 são apresentadas as considerações finais, experiências obtidas, publicações e
sugestões de trabalhos futuros.
16
2 RFID
O objetivo deste capítulo é apresentar os principais conceitos da
tecnologia RFID. Está subdividido em sessões que traçam um
breve histórico do seu desenvolvimento e áreas de aplicação,
enfatizando a aplicação em bibliotecas. As sessões posteriores
tratam o conceito da identificação por rádio-frequência e seus
principais componentes. Por fim, é abordada a relação entre
RFID e código de barras.
2.1 Breve histórico
A tecnologia RFID que significa identificação por rádio-freqüência é utilizada para
transmissão de informações de um determinado objeto através de ondas de rádio com o
objetivo de identificação.
O seu desenvolvimento teve origem na Segunda Guerra Mundial. Watson-Watt chefiou um
projeto secreto no qual os britânicos criaram o primeiro identificador ativo de amigo ou
inimigo (Identify Friend or Foe). Um transmissor foi inserido em cada avião britânico,
quando o transmissor recebia sinais da estação de radar começava a transmitir um sinal de
resposta que identificava se o avião era amigo ou inimigo (PINHEIRO, 2006).
Devido à inexistência de dispositivos de pequena dimensão, tais como transistores, circuitos
integrados e de microprocessadores, seu desenvolvimento foi postergado.
Pinheiro (2006) aponta que a miniaturização e integração ocorreram mais tarde na década de
60. Mas enquanto isso, cientistas e acadêmicos dos Estados Unidos, Europa e Japão
realizavam pesquisas sobre como a rádio-frequência poderia ser utilizada para identificar
objetos remotamente. No final desta década, algumas empresas começaram a comercializar
sistemas antifurto que utilizavam ondas de rádio para determinar se um item havia sido pago
ou não. Essas etiquetas de vigilância eletrônica, Eletronic Article Surveillance (EAS),
17
utilizam um bit, se a pessoa pagasse pela mercadoria, o bit era colocado em off ou 0 e os
sensores não disparavam o alarme. Caso contrário, o bit continuava em on ou 1, e se a
mercadoria saísse através dos sensores, um alarme era disparado.
A década de 70 foi caracterizada, de acordo com o autor, pelo desenvolvimento da tecnologia
eletrônica do RFID. Grandes empresas começaram a usar a tecnologia para controlar objetos e
veículos em movimento.
A consolidação do RFID como uma tecnologia, ocorreu somente na década de 80, com o
desenvolvimento de aplicações nos Estados Unidos em áreas de controle de mercadorias,
meios de transporte, acesso de pessoas e identificação animal. Na Europa, os esforços eram
concentrados, principalmente, no uso da tecnologia para identificação animal, atividades
industriais e controle de acesso em rodovias.
No final da década de 80, engenheiros da IBM desenvolveram um sistema RFID baseado na
tecnologia Ultra High Frequency (UHF). O UHF oferecia um alcance de leitura muito maior e
transferência de dados mais velozes. Porém, o custo era muito alto devido ao volume reduzido
de vendas e a falta de padrões internacionais, sendo utilizada somente em aplicações
complexas ou que pudessem justificar os altos custos.
Na década de 90, com a miniaturização dos componentes, os transponders puderam ser
alimentados pelo campo eletromagnético do equipamento que o requisitava. Com a utilização
de memória Electrically Erasable Programmable Read-Only Memory (EEPROM) ao invés da
memória Random Access Memory (RAM), não era mais necessário ter uma bateria
alimentando constantemente o transponder a fim de garantir a permanência dos dados na
memória (PINHEIRO, 2006).
Com o objetivo de tornar a tecnologia RFID viável para aplicação em cadeias de suprimento,
o Massachusetts Institute of Technology (MIT) fundou em 1999 o Centro AutoID. Em 2000 o
Centro AutoID desenvolveu o Código Eletrônico de Produto (EPC) que tinha como objetivo
principal a substituição do Código de Barra (UPC).
Em 2003 empresas dos Estados Unidos e da Europa junto com o Centro de AutoID,
apontaram a necessidade da criação um órgão responsável pela padronização da tecnologia
18
RFID e criaram, então, a EPCGlobal, que tem como objetivo ser o principal órgão
responsável pela padronização da tecnologia RFID. Deste modo o Centro de AutoID
transmitiu toda sua base de pesquisa ao EPCGlobal e passou a se chamar AutoID Labs com o
intuito de aproximar as instituições universitárias de pesquisas ao EPCGlobal criando novas
tecnologias.
2.2 Aplicações da tecnologia RFID
Atualmente a tecnologia RFID tem sido amplamente estudada e encontra uma área crescente
de aplicação, basta a necessidade da captura automática de dados (PINHEIRO, 2006).
Dentre as áreas, o autor cita as aplicações médicas com os implantes humanos para fins de
identificação. Os microchips podem armazenar informações como tipo sanguíneo, alergias,
doenças crônicas, histórico de medicamentos utilizados pelo paciente, agilizando a leitura da
ficha de um paciente por um médico assim que este dá entrada no hospital. Uniformes,
crachás e equipamentos também podem ser etiquetados, permitindo um melhor
gerenciamento, reduzindo erros e aumentando a segurança.
Implantes em humanos podem ser usados para controle de acesso a lugares restritos ou para
facilitar o acesso a certos lugares. Pulseiras metálicas com transponders são usadas em
prisões nos Estados Unidos para identificar e localizar prisioneiros (PINHEIRO, 2006).
Os microchips podem ainda, ser acoplados a sistemas baseados em satélites como o GPS, para
permitir a localização com precisão de uma pessoa ou produto. Provendo segurança e útil em
caso de sequestros ou atentados.
O autor relata que a tecnologia RFID pode ser útil em indústrias para identificar ferramentas,
recipientes e embalagens de produtos periculosos, controle de acesso de segurança. Uma
aplicação promissora é em linhas de montagem de veículos ou máquinas industriais, neste
caso o RFID pode monitorar desde o início do processo até a entrega ao consumidor,
inclusive em caso de manutenção.
19
Na área de gerenciamento de transportes, a tecnologia de RFID é utilizada com o objetivo de
facilitar a manutenção de frotas, gerenciar os bilhetes dos passageiros e na aceleração da
passagem em rodovias com pedágios. Também é utilizado por empresas aéreas e portuárias na
identificação de malas, containers e demais cargas (SANTINI, 2008).
2.2.1 Aplicação da tecnologia RFID em bibliotecas
A tecnologia RFID pode estar associada a materiais de acervo, como livros, filmes, jornais,
processos jurídicos. Neste contexto, a implantação desta tecnologia pode auxiliar diversas
atividades, seja no armazenamento seguro das informações, na realização de inventários ou na
identificação e rastreamento de materiais do acervo. A adoção da tecnologia permite a
implementação de novos serviços tais como: serviços de auto-atendimento para empréstimo e
devolução de matérias para os usuários, classificação automática de materiais na devolução,
serviço 24 horas de devolução de materiais (VIEIRA, 2007).
O autor salienta que diversas bibliotecas no mundo todo têm implantado a tecnologia RFID
para agilizar as suas diversas atividades e fornecer novos serviços. As etiquetas RFID são
colocadas nos livros e nos demais itens do acervo facilitando o empréstimo dos materiais. Os
leitores RFID identificam os itens e registram no sistema de informatização da biblioteca
aqueles que estão sendo emprestados ou devolvidos.
Os bibliotecários podem utilizar um computador manual com leitor RFID para realizar
inventário, localizar materiais colocados em prateleiras ou outros locais de forma errada,
simplesmente passando o leitor RFID portátil nos livros que se encontram nas prateleiras. Um
número reduzido de funcionários pode tomar conta da circulação de materiais, sem a
necessidade de manusear os itens do acervo.
Utilizando esta tecnologia as bibliotecas podem implementar serviços de auto-atendimento
para empréstimo e devolução de materiais sem necessidade de intervenção dos funcionários.
Em seu artigo, Vieira (2007), propõe diversas vantagens na implantação da RFID nas
bibliotecas:
20
a) diminuição do tempo gasto em tarefas como, circulação de materiais,
manuseio dos itens do acervo nos processos de empréstimo e devolução de
materiais;
b) agilidade na incorporação de novos itens ao acervo;
c) agilidade na realização de inventários;
d) possibilidade de implementar sistemas de auto-atendimento e sistemas
automatizados de classificação na devolução de materiais do acervo da
biblioteca;
e) melhorias no gerenciamento dos itens, mediante a utilização de
equipamentos para realizar inventários do acervo em tempo reduzido e
localizar materiais que se encontram em locais errados;
f) a identificação individual dos itens do acervo permitem implementar
funções de segurança contra furtos.
2.3 Identificação por rádio-frequência (RFID)
A tecnologia RFID é um “sistema que transmite dados de um objeto qualquer, através de um
meio não guiado, usando ondas de rádio” (SANTINI, 2008, p. 2).
Pinheiro (2006) salienta que a RFID é uma tecnologia de identificação automática que utiliza
as ondas de rádio para capturar os dados contidos em um dispositivo eletrônico ou etiqueta
RFID, ou seja, utiliza a comunicação por rádio-frequência para transmitir dados de um
dispositivo móvel a um leitor.
As etiquetas RFID armazenam os dados dos objetos aos quais estão anexados. Quando estes
objetos entram numa área de cobertura de um leitor RFID, as etiquetas transmitem os dados
para o leitor, por meio de uma antena. O leitor RFID lê os dados e os envia para um software.
Este aplicativo pode então utilizar esses dados, por exemplo, para atualizar as informações
destes objetos numa base de dados.
Segundo o RFID Journal, esta tecnologia utiliza ondas de rádio para identificação automática
de pessoas, lugares ou objetos.
21
Existem vários métodos para identificação, o mais comum é armazenar informações em
etiquetas RFID que são compostas de um microchip associado a uma antena. A antena
permite que o microchip envie informações para o leitor. Este leitor converte a onda de rádio
refletida em informação digital que pode ser passada a um computador
(http://www.rfidjournal.com/faq/16/49).
2.4 Componentes de um sistema RFID
De acordo com Pinheiro (2006), esta tecnologia é geralmente composta por dois elementos:
tags também conhecidas como “etiqueta RFID”, microchip ou transponders, que são usadas
para realizar a transmissão de dados, e um leitor que pode estar conectado a um computador.
Além das etiquetas e dos leitores, Glover e Bhatt (2008), apontam que um sistema RFID
também necessita de um middleware para transformar dados em informação. O middleware
gerencia dados vindos das etiquetas, capturados pelos leitores, e os repassa para uma
aplicação ou para uma base de dados. Ou seja, ele controla o fluxo de informações entre estes
componentes tornando-se responsável pela qualidade e usabilidade da informação.
2.4.1 Etiquetas RFID
As etiquetas RFID são constituídas de chips de silício e uma pequena antena embutidos em
um invólucro, sendo capazes de responder aos sinais de rádio frequência de um leitor e de
transmitir dados sem a necessidade de fios. São responsáveis pelo armazenamento da
informação do objeto ao qual estão acopladas e que posteriormente será lida por um leitor
(WANT, 2004).
22
Figura 1 - Etiqueta padrão.
Fonte: SANTINI, 2008.
Ao contrário do código de barras que precisa ser lido individualmente, as etiquetas RFID
emitem sinais que podem ser identificados e tratados à distância e em lotes. Dentro do alcance
do leitor é possível ler centenas de tags por segundo com maior rapidez, mesmo contendo um
número muito maior de informações do que os identificadores atuais.
As tags podem ser divididas em três partes: um substrato contendo o chip e outros
componentes eletrônicos, a antena conectada ao chip e um encapsulamento (WANT, 2004).
Pinheiro (2006) ressalta que o principal componente é o chip, que além de realizar a
comunicação com um leitor, possui uma memória onde os dados são armazenados.
A antena é um dispositivo que pode emitir ou receber ondas eletromagnéticas. O leitor e as
etiquetas precisam de uma antena para se comunicar. A principal característica de uma antena
em um sistema RFID é realizar de maneira confiável a troca de informações entre o leitor e a
etiqueta RFID.
Para Glover e Bhatt (2008), existem várias formas de encapsulamento. As tags podem ficar
em botões plásticos, cápsulas de vidro, rótulos de papel, cartões de plástico e até em caixas de
metal. Estas formas influenciam em questões como: a durabilidade, resistência a mudanças
de temperatura e acessibilidade.
23
As tags em botões, discos e moedas normalmente são de plástico ou PVC e suportam
temperaturas mais altas, sendo utilizadas quando a resistência do material é importante. Tags
em rótulos de papel são parecidas com códigos de barra, podendo ser aplicadas diretamente
em caixas, são de tamanhos reduzidos e ativadas apenas com a ativação do leitor. Tags em
cápsulas de vidro são ideais para implantes em humanos e animais. Devido a sua durabilidade
e ao seu tamanho também podem ser utilizadas em ambientes líquidos ou corrosivos
(GLOVER & BHATT, 2008).
Quanto ao tipo de operação as tags podem ser classificadas em somente leitura ou
leitura/escrita (PINHEIRO, 2006).
No tipo somente leitura, o sinal de resposta pode ser um simples número de identificação
armazenado em uma etiqueta somente-leitura que vem da fábrica com os dados já gravados
no chip e não podem ser alterados. Permite somente a transmissão dos dados pré-gravados
pelo fabricante da etiqueta.
No tipo leitura/escrita, o chip possui setores da memória somente para leitura contendo
geralmente um número de identificação e outros setores de memória disponíveis para serem
gravados e regravados durante o uso. A execução de leitura ou escrita pode ser feita com as
tags mesmo em movimento.
A capacidade de armazenamento do microchip é limitado, em sistemas passivos a capacidade
varia entre 64 bits e 8 kilobits. As etiquetas modernas podem armazenar em média, de 114
bytes a 1 kbyte de informação na memória.
Vieira (2007) ressalta que o tamanho das etiquetas RFID variam entre 90x130 mm e 9x25mm
e podem ser lidas através de diversos materiais: papéis, plásticos, tecidos, couro e muitos
outros. Porém, a leitura não pode ser feita através de materiais metálicos, como ferro e
alumínio.
Segundo sua forma de ativação, as etiquetas RFID podem ser classificadas em passivas e
ativas (VIEIRA, 2007).
24
As etiquetas RFID passivas não possuem fonte de energia própria, precisam entrar num
campo eletromagnético gerado por uma antena leitora para serem ativadas e transmitirem ou
gravarem informações. Existem diversos tipos de sistemas RFID passivos que podem ser
diferenciados pela freqüência em que trabalham e pelo alcance para leitura e gravação:
a) sistemas RFID de baixa freqüência (LF): operam a 125kHz com um alcance
máximo de 50,8 cm;
b) sistemas RFID de alta freqüência (HF): operam a 13,56 MHz com um
alcance de 100 cm;
c) sistemas RFID de ultra-alta freqüência (UHF): operam em diversas
freqüências incluindo 868 MHz, 915 MHz e 2,45 GHz. O alcance de leitura
varia entre 1 a 6 metros.
As etiquetas RFID ativas possuem pilhas como fonte de energia própria, isso permite a
transmissão das informações que estão armazenadas no seu microchip sem necessidade de
entrar num campo de ativação. A pilha é utilizada para aumentar o alcance de operação das
etiquetas e permite a transmissão de sinais periódicos, para que sejam capturados por diversos
leitores RFID distribuídos em diversas partes do prédio.
2.4.2 Leitores
A função do leitor é captar, dentro de sua área de cobertura, todas as etiquetas RFID. A
leitura das informações transmitidas pela etiqueta pode ser realizada diretamente pelo próprio
leitor ou através de um software (PINHEIRO, 2006).
O leitor opera pela emissão de um sinal de rádio-freqüência, fonte de energia que alimenta o
chip da etiqueta RFID, que por sua vez, responde ao conteúdo de sua memória.
Diferentemente do leitor de código de barras, o leitor RFID não necessita de contato visual
com a etiqueta para realizar a leitura dos dados. Podendo ainda realizar a leitura simultânea de
milhares de microchips e armazenar os dados em memória.
25
Pinheiro (2006) aponta que a distância entre o leitor e a etiqueta RFID depende de vários
fatores, tais como: tipo do transponder (passivo ou ativo), tamanho da antena, potência do
leitor, frequência empregada, podendo varias de centímetros a metros.
Glover e Bhatt (2008) salientam que o leitor tem como papel saber conversar com as tags,
criar eventos a partir das leituras e enviar estes eventos com um filtro de eventos.
Os leitores possuem duas estruturas gerais, os componentes físicos e os componentes lógicos.
2.4.2.1 Componentes físicos
Todo leitor deve possuir uma antena, não necessariamente acoplada a ele, uma interface de
rede de algum tipo para que o leitor possa se comunicar com algum outro dispositivo ou
servidor e um controlador ou microcomputador para implementar os protocolos de
comunicação e controlar o transmissor (GLOVER & BHATT, 2008).
Figura 2 - Componentes físicos de um leitor.
Fonte: GLOVER & BHATT, 2008.
Alguns leitores possuem uma ou duas antenas, embutidas nos próprios leitores, outros são
capazes de gerenciar muitas antenas em locais remotos. A principal limitação no número de
antenas que um leitor pode controlar é a perda de sinal no cabo, a maioria das instalações
mantém o leitor dentro de dois metros da antena mais distante, no entanto, distâncias maiores
são possíveis.
26
Os leitores se comunicam com a rede e com outros dispositivos através de
uma variedade de interfaces. Historicamente, a maioria dos leitores RFID
tem interfaces seriais usando RS 232 ou RS 422 (ponto a ponto, par
trançado) ou RS 485 (endereçável, par trançado). Nos últimos anos, cada vez
mais leitores tem suportado Ethernet e Bluetooth[...] (GLOVER & BHATT,
2008, p.98).
Um controlador tem como função gerenciar os protocolos de transmissão. E dentro dele se
encontram os componentes lógicos.
2.4.2.2 Componentes lógicos
Dentro de um controlador de leitor RFID, podemos encontrar quatro subsistemas separados
que lidam com diferentes responsabilidades (GLOVER & BHATT, 2008).
Figura 3 - Componentes lógicos de um leitor.
Fonte: GLOVER & BHATT, 2008.
Cada leitor representa uma interface de programação de aplicações. A Application
Programming Interface (API) é responsável por controlar os níveis de bateria das tags e
realizar a transmissão de informações entre um middleware e o leitor e vice-versa.
O subsistema de comunicações controla o protocolo de comunicação entre o middleware e o
leitor, gerencia a transmissão das informações que caracterizam a API. “Este é o componente
27
que implementa Bluetooth, Ethernet ou um protocolo proprietário para enviar e receber as
mensagens que constituem a API[...]” (GLOVER & BHATT, 2008, p.99).
O gerenciador de eventos identifica as observações que passarão a ser consideradas eventos e
quais eventos serão enviados a uma aplicação externa da rede. É este componente que avalia a
importância de um determinado evento, se é relevante para ser transmitido pela interface de
rede.
“Quando um leitor „vê‟ um identificador, chamamos isto de uma observação. Uma
observação que difira das observações anteriores é chamada de um evento. A separação destes
eventos é chamada de filtragem de eventos [...]” (GLOVER & BHATT, 2008, p.99).
O subsistema de antena é quem controla a comunicação da antena física para com as tag e
implementa os protocolos.
2.4.3 Middleware
Para Glover e Bhatt (2008), o middleware tem como objetivo tratar os dados obtidos pelos
leitores, seu papel é fundamental no processamento das informações.
É utilizado principalmente para filtrar os dados coletados pelos leitores. Os autores apontam
três motivos para se utilizar middleware RFID: encapsular as aplicações das interfaces de
dispositivos, processar as informações capturadas pelos leitores de modo que as aplicações só
vejam eventos significativos e como uma interface em nível de aplicação.
Os leitores simplesmente captam os dados, cabe ao middleware organizar esses dados e
transformá-los em informações.
Os sistemas integrados com os quais o middleware se comunica podem ser uma base de dados
como SQLServer, MySQL ou Oracle em um único computador ou ser distribuída.
28
2.5 Visão geral de uma implementação RFID
De acordo com Vieira (2007), podemos classificar em 3 camadas uma aplicação utilizando
um sistema RFID:
a) camada de transferência de dados: nesta camada estão contidos os diversos
modelos de etiquetas e leitoras;
b) camada operacional: nesta camada intermediária se encontra o middleware
que faz a integração entre as diversas leitoras com os diversos sistemas
existentes;
c) camada de negócio: nesta camada encontra-se toda a infraestrutura de uma
empresa que se utiliza da tecnologia RFID. Esta camada se caracteriza por sua
heterogeneidade devido a diversos tipos de plataformas e sistemas existentes.
2.6 RFID e códigos de barras
A tecnologia RFID e o código de barras são utilizados para coleta de dados e identificação
automática de objetos. Porém existem características que diferenciam uma tecnologia da outra
(VIEIRA, 2007).
Conforme o RFID Journal, o código de barras é eficiente em várias tarefas e irá coexistir com
a RFID por muitos anos (http://www.rfidjournal.com/faq/16/49).
A maior diferença entre essas duas tecnologias se refere à leitura de dados. Para que os dados
de um código de barras sejam lidos, um scanner precisa entrar em contato direto com o
código de barras. A RFID, ao contrário, não requer um contato direto, as tags podem ser lidas
se estiverem dentro da área de cobertura do leitor RFID.
A tabela a seguir apresenta as principais diferenças entre a tecnologia RFID e o código de
barras.
29
Tabela 1 - Principais diferenças entre RFID e códigos de barras.
RFID CÓDIGO DE BARRAS
Transmissão de dados por rádio freqüência. Não se aplica.
Diversas etiquetas RFID podem ser lidas
simultaneamente.
A leitura das etiquetas é sequencial.
A leitura das etiquetas RFID pode ser feita
mesmo se estiverem dentro de diversos
materiais como papel, madeira, plásticos,
entre outros.
Durante a leitura as etiquetas com código de
barras devem estar expostas sem nenhum
obstáculo entre elas e o leitor.
As etiquetas precisam simplesmente estar
no campo de ação da antena de detecção.
A etiqueta precisa estar alinhada ao campo de
visão do leitor de código de barras.
Permite inserir ou alterar os dados que
foram armazenados na etiqueta.
Não se aplica.
Maior alcance de leitura das etiquetas.
Menor alcance de leitura das etiquetas.
Fonte: VIEIRA, 2007.
Este capítulo abordou os principais conceitos da tecnologia
RFID. No próximo capítulo serão apresentadas ferramentas para
o desenvolvimento do protótipo do sistema para biblioteca.
30
3 FERRAMENTAS PARA DESENVOLVIMENTO DO SISTEMA
O objetivo deste capítulo é apresentar as ferramentas,
frameworks e Padrões de Projetos utilizados na implementação
do protótipo do sistema para biblioteca. Está subdividido em
sessões que traçam um breve resumo das tecnologias, suas
principais características e as vantagens de utilização.
3.1 Java
No desenvolvimento do protótipo do software para bibliotecas foi utilizada a tecnologia Java
criada pela Sun Microsystems na década de 90. Esta tecnologia foi projetada para permitir o
desenvolvimento de aplicações seguras, com alta performance e multiplataformas (GOSLING
& MCGILTON, 1996).
Para poder operar em várias plataformas o modo tradicional de distribuição das aplicações se
torna inviável. Por esse motivo a linguagem Java provê uma arquitetura neutra, portátil e
dinamicamente adaptável.
Dentre as principais características do Java podem ser citadas:
a) orientação a objetos: atende a todos os requisitos para que uma linguagem
seja considerada orientada a objetos, oferece mecanismos de abstração,
encapsulamento e herança. Permite ao desenvolvedor tirar proveito das
metodologias mais modernas para o desenvolvimento de software, além de
propiciar maior facilidade para reutilização de código;
b) portabilidade: é uma linguagem independente de plataforma, os programas
Java não são compilados para uma plataforma de hardware específica, mas
para uma forma intermediária de código destinada à Java Virtual Machine
(JVM). Todo código fonte escrito é transformado em um arquivo.class pelo
31
compilador. O arquivo.class não contém um código nativo do processador, ele
contém os bytecodes - a linguagem executada pela JVM;
c) performance: Java foi projetada para ser compacta, independente de
plataforma e para utilização em rede. Com a incorporação de um compilador
Just in Time na JVM que é capaz de converter os bytecodes em código nativo
durante a carga do programa, houve uma significativa melhora na performance
dos programas Java.
Figura 4 - Processo de compilação de um programa Java.
Fonte: SUN, 2008.
A JVM possibilita que um mesmo arquivo.class seja executado em diversas plataformas
diferentes.
Figura 5 - Portabilidade do código Java ("write once, run anywhere").
Fonte: SUN, 2008.
32
A tecnologia Java é formada por três plataformas principais apresentadas a seguir:
a) Java Standart Edition (JSE): é a tecnologia Java utilizada para computadores
pessoais, notebooks e arquiteturas com poder de processamento e memória
consideráveis;
b) Java Micro Edition (JME): é a tecnologia usada em aplicações para
dispositivos móveis com memória ou processamento limitados. São utilizadas
para sistemas em celulares, palm tops, pocket pcs, smartphones, entre outros;
c) Java Enterprise Edition (JEE): é uma plataforma para desenvolvimento de
sistemas distribuídos. Esta tecnologia está direcionada para aplicações
multicamadas executadas em um servidor de aplicações, é ideal para a
construção de servidores de aplicação, integração de sistemas ou distribuição
de serviços para terceiros. Apresenta facilidades para a utilização de dos
recursos computacionais e distribuídos tais como banco de dados, componentes
Web, etc.
Figura 6 - Plataformas Java.
Fonte: SUN, 2008.
33
3.1.1 Java EE
Java EE é uma plataforma para desenvolvimento de aplicações distribuídas baseada em
padrões de desenvolvimento. É destinado ao desenvolvimento de aplicações multicamadas,
baseadas em componentes executados em um servidor de aplicação (TEMPLE et. al., 2004).
A arquitetura de uma aplicação JEE pode ser dividida em quatro camadas:
a) camada de cliente: parte da aplicação que roda no computador do usuário. É
a parte responsável por interagir com o usuário e pela comunicação com as
outras camadas da aplicação;
b) camada de Web: é a camada responsável por receber as requisições do
cliente. Ela é responsável por processar a lógica do negócio. Os componentes
dessa camada residem no Web container;
c) camada de negócios: é a camada que trata a lógica da aplicação. Nessa
camada são definidas as regras de negócio. A camada de negócios também é
responsável pela persistência dos dados;
d) camada de dados: é a camada onde se encontra a base de dados da
aplicação.
Figura 7 - Camadas de uma aplicação Java para Web.
Fonte: SUN, 2008.
34
3.1.2 Containers
Um container é um ambiente de execução que provê serviços específicos a um componente.
Eles são responsáveis por tratar questões de concorrência, consistência, segurança,
disponibilidade, dentre outros.
Os containers podem ser divididos em dois tipos:
a) Container EJB: tem por objetivo prover a infraestrutura necessária para a
execução de componentes de negócio. Permite encapsular a lógica de negócio e
dados específicos de uma aplicação, pois os componentes não são acessados
diretamente pelo cliente. O cliente faz uma requisição ao Application Client
Container que faz a requisição ao Container EJB;
b) Container WEB: um Web Container destina-se a processar componentes
Web como Servlets, arquivos JSP, HTML e JavaBeans. Deve ser capaz de
aceitar requisições HTTP, acionar os componentes e gerar uma resposta para o
cliente.
Figura 8 - Divisão do Container.
Fonte: SUN, 2008.
35
3.1.3 Sun Java System RFID
O Sun Java System RFID é um software criado pela Sun Microsystems de acordo com as
especificações definidas pela EPCGlobal (SUN, 2006) para implementação do middleware
que faz a ligação entre o hardware RFID e a aplicação.
O objetivo do Sun Java System RFID é processar os dados capturados pelos leitores
possibilitando passar dados para a aplicação de forma fácil e padronizada.
O software é composto por dois módulos principais:
a) RFID Event Manager;
b) RFID Information Server.
O módulo RFID Event Manager tem a função de capturar e filtrar as informações vindas de
um dispositivo de leitura. Estas informações podem ser armazenadas para uma análise futura.
As informações também podem se enviadas para o módulo RFID Information Server.
O RFID Information Server é responsável por ler um conjunto de dados de baixo nível e
fornecer informações de alto nível para uma aplicação externa.
Figura 9 - Funcionamento do Sun Java System RFID.
Fonte: SUN, 2006.
36
3.2 Servidor de Aplicação
Servidores de aplicação são softwares que fornecem a infraestrutura de serviços para a
execução de aplicações (TEMPLE et. al., 2004).
A vantagem do uso de um servidor de aplicação é a possibilidade de abstrair algumas partes
complexas de um sistema computacional, permitindo que o desenvolvedor se concentre no
desenvolvimento da aplicação e não em questões de infraestrutura.
O servidor de aplicação fica responsável pelas funções de segurança, garantia de
disponibilidade, balanceamento de carga e tratamento de exceções. Como exemplos de
servidores de aplicação podem ser citados WebSphere Application Server, WebLogic Server,
JBoss, Glassfish, entre outros.
O servidor escolhido para a realização deste trabalho foi o GlassFish.
O GlassFish é um servidor de aplicações de código aberto desenvolvido pela Sun
Microsystems para a plataforma Java EE (Java Enterprise Edition), de nível corporativo que
oferece desempenho, confiabilidade, produtividade e facilidade de uso. Além disso, também
apresenta suporte total às novas especificações Java para Web.
3.3 AJAX
AJAX, abreviação para Asynchronus JavaScript and XML, não é uma tecnologia nova, mas
uma maneira de usar tecnologias já existentes para melhorar a usabilidade e a interatividade
na Web (CRANE et. al., 2006).
O principal componente é o XMLHttpRequest. Este objeto permite a um código JavaScript
fazer o envio de dados e receber uma resposta de um servidor sem a necessidade de recarregar
toda a página Web. Daí vem o termo Asynchronous, pois os dados não precisam
necessariamente ser carregados ao mesmo tempo em que se carrega a página, em outras
37
palavras, não precisa haver sincronia do carregamento de dados com o carregamento da
página Web.
Segundo Garrett, 2005, AJAX incorpora as seguintes tecnologias:
a) apresentação baseada em tecnologias padronizadas, usando HTML e CSS;
b) exibição e interação dinâmica utilizando DOM;
c) manipulação de utilizando dados XML e XSTL;
d) recuperação de dados assíncrona usando o XMLHttpRequest;
e) uso de JavaScript para interligar esse elementos.
Algumas aplicações possíveis para AJAX:
a) validação em tempo real: um campo pode ser validado antes do envio do
formulário ;
b) criação de interfaces sofisticadas (Rich Internet Application);
c) atualização de dados em uma página: as informações de uma página podem
ser atualizadas sem a necessidade de recarrega-lá.
3.4 JQuery
JQuery é uma biblioteca JavaScript de código aberto criada em 2006 por John Resig com o
objetivo de simplificar o código JavaScript e o uso do AJAX (BIBEAULT & KATZ, 2008).
A biblioteca JQuery permite ao programador:
a) acessar apenas partes da página através um mecanismo que permite
recuperar apenas a parte do documento que deve ser manipulada;
b) modificar a aparência da página através de CSS;
c) alterar o conteúdo da página;
d) responder interações do usuário com a página;
e) adicionar animações a uma página;
f) recuperar informações do servidor sem precisar recarregar a página usando
AJAX;
38
g) simplificar tarefas comuns do JavaScript, como iterações e manipulação de
arrays.
Além disso, a biblioteca JQuery dá suporte a vários plugins que podem simplificar o
desenvolvimento de páginas Web.
3.5 Padrões de Projeto
Padrões de Projeto, segundo Gamma et. al. (2005, p.20), “são descrições de objetos e classes
comunicantes que precisam ser personalizadas para resolver um problema geral de projeto
num contexto particular.”
Um Padrão de Projeto identifica e nomeia em uma estrutura de projeto os aspectos-chaves que
são comuns para a criação de projeto orientado a objetos reutilizáveis e flexíveis (GAMMA
et. al., 2005).
Há vários Padrões de Projeto, dentre eles apresentamos os padrões Model-View-Controller
(MVC), Factory Method, Observer, Composite, Strategy e Singleton, utilizados no software
para bibliotecas.
3.5.1 MVC
A arquitetura MVC é um Padrão de Projeto usado em engenharia de software. O seu uso faz
com que a lógica do negócio fique separada da interface gráfica, facilitando modificações na
aparência e nas regras de negócio isoladamente.
A tríade de classes Model-View-Controller, é composta por três tipos de objetos. A classe
Model é o objeto da aplicação, contém todos os estados, dados e lógica do aplicativo. A classe
View é a apresentação na tela, ou seja, a interface com o usuário. O Controller corresponde ao
39
gerenciamento das ações geradas pelo usuário. Este objeto recebe os dados do usuário e
determina o que isso significa para a Model (GAMMA et. al., 2005).
O fluxo de uma aplicação utilizando MVC normalmente acontece da seguinte forma:
a) o usuário interage com a interface (Ex: ao clicar em um botão);
b) o Controller captura o evento gerado pela interface gráfica e notifica o
Model da ação, possivelmente alterando o estado do Model (Ex: inserção de
registros no banco de dados);
c) uma View usa o Model para gerar a interface (Ex: resultados de uma
consulta no banco de dados);
d) a interface espera por outras interações do usuário, e o ciclo recomeça.
Esta arquitetura ajuda a reduzir a complexidade do Model e aumenta a flexibilidade e a
reutilização de código.
Figura 10 - Camadas de uma aplicação MVC.
Fonte: Gamma et. al. (2005).
Gamma et. al. (2005), aponta que a MVC também utiliza outros padrões de projeto, tais como
Factory Method, Observer, Composite e Strategy.
MODEL
- Encapsula o estado da
aplicação;
- notifica as Views de mudanças;
- expõe as funcionalidades da
aplicação;
- responde as interrogações de
estado.
CONTROLLER - Define o comportamento da
aplicação; - mapeia ações do usuário que
inpactem no Model;
- seleciona a View para resposta;
- uma para cada funcionalidade.
VIEW
- Serve o Model;
- solicita alterações no Model;
- envia as ações do usuário
a Controller;
- permite que a Controller selecione a View.
Seleciona a view
Ações do usuário Altera estados
Notificação de
mudanças
40
O padrão Factory Method define uma interface para criar um objeto e permite que as
subclasses definam qual classe será instanciada, adiando a instanciação para as subclasses.
Deve ser usado “quando uma classe não pode antecipar a classe de objetos que deve criar,
quando uma classe quer que suas subclasses especifiquem os objetos que criam e quando
classes delegam responsabilidades para uma dentre várias subclasses auxiliares (...)”
(GAMMA et. al., 2005, p.113).
A MVC utiliza o padrão de projeto Factory Method para especificar, por exemplo, a classe
Controller para uma View.
O padrão Observer define uma dependência de um-para-muitos entre os objetos, assim,
quando um objeto mudar de estado, todos os dependentes também serão notificados e
atualizados.
De acordo com Gamma et. al. (2005), o padrão Observer deve ser utilizado em algumas
situações: quando uma abstração tem dois aspectos e um dependente do outro, esses aspectos
são encapsulados em objetos separados, permitindo o reuso; quando a mudança em um objeto
implica em mudança em outros objetos e não se sabe quantos são ou quando um objeto deve
ser capaz de notificar outros objetos sem usar informações sobre quem são estes objetos.
O uso do padrão Observer mantém o Model totalmente independente das Views e Controllers,
e permite que sejam fornecidas Views alternativas, mantendo os objetos interessados
constantemente informados sobre suas mudanças de estado.
O padrão Composite compõe os objetos em forma de árvore para a representação de
hierarquias do tipo partes-todo, permite também que o tratamento de objetos individuais e
composições de objetos sejam iguais.
Seu uso é indicado quando se deseja representar hierarquias partes-todo de objetos, quando os
objetos forem tratados na estrutura composta de maneira uniforme (GAMMA et. al., 2005).
A View juntamente com o padrão Composite está à disposição do usuário esperando por
qualquer evento, quando este evento é ativado o Controller é avisado sobre o evento. O
41
Controller avisa para a View se atualizar, e ao mesmo tempo notifica o Model para que ele
atue para contemplar o evento provocado pelo usuário, depois da atuação o Model fica pronto
para ser acessado pela View, esta por sua vez atualiza-se para o usuário.
O padrão Strategy define uma família de algoritmos, encapsula cada um deles e permite que o
algoritmo varie independente de quem o utiliza.
É indicado quando as classes relacionadas apresentam diferenças apenas no seu
comportamento, para impedir a exposição das estruturas de dados do algoritmo e quando uma
classe apresenta muitos comportamentos e estes possuem operações com muitos comandos
condicionais (GAMMA et. al., 2005).
A View e o Controller utilizam o padrão Strategy que é fornecida pelo Controller. A View só
precisa se preocupar com os aspectos visuais do aplicativo, porque todas as decisões sobre o
comportamento da interface são delegadas ao Controller, o uso deste padrão mantém a
visualização desconectada do modelo, porque a responsabilidade pela iteração com o modelo
por executar as solicitações do usuário cabe apenas ao controlador, a visualização não tem a
mínima idéia de como isto é feito.
É o Controller que organiza a MVC por meio de métodos. Todas as decisões, estratégias e
eventos que podem ser usados pelo usuário são definidos nele, a View só se preocupa em
mostrar os dados ao usuário e reagir segundo as suas programações.
3.5.2 Singleton
Singleton é um padrão de projeto que garante “que uma classe tenha somente uma instância e
fornece um ponto global de acesso para a mesma” (GAMMA et. al., 2005, p.130).
Sua utilização é indicada quando for necessária a existência de apenas uma instância de uma
classe através de um ponto conhecido e quando essa instância for extensível através de
subclasses sem alteração do código (GAMMA et. al., 2005).
42
É um padrão simples, muito utilizado em conexões com banco de dados e oferece outros
benefícios:
a) acesso controlado à instância única: a classe Singleton encapsula a única
instância, possui também controle total sobre como e quando os usuários a
acessam;
b) espaço de nomes reduzido: apresenta uma melhoria com relação ao uso de
variáveis globais que armazenam instâncias únicas;
c) permite um refinamento de operações e da representação: é possível
configurar a aplicação com uma única instância da classe de que necessita em
tempo de execução;
d) permite um número variável de instâncias: permite mais de uma instância da
classe Singleton. Uma mesma abordagem para controlar o número de
instâncias pode ser utilizada e somente a operação que permite acesso à
instância de Singleton precisa ser mudada;
e) mais flexibilidade do que operações de classe: uma maneira de empacotar a
funcionalidade de um Singleton é usar operações de classe.
3.6 Frameworks
Segundo Brown et. al. (2004) um framework é uma estrutura que provê automação de tarefas
de um domínio comum. Tem como objetivo prover uma plataforma para que o
desenvolvimento de uma aplicação seja feito de maneira mais rápida.
Existem diversos frameworks, neste trabalho foram utilizados os frameworks Struts e
Hibernate.
43
3.6.1 Struts Framework
O Struts Framework é um projeto open source mantido pela Apache Software Foundation.
Foi criado por Craig McClanahan em maio de 2000, e desde então vem sendo melhorado pela
comunidade open source. Foi desenvolvida com o objetivo de fornecer um framework para
facilitar o desenvolvimento de aplicações para Web (BROWN et. al., 2004).
O framework Struts implementa o padrão de projeto Model-View-Controller (MVC). O
principal objetivo do Struts é separar a lógica da aplicação da camada de visualização e da
camada de controle.
O Controller já vem implementado no Struts e o fluxo da aplicação é programado em um
arquivo XML.
A geração da interface é feita através de Tag Libraries, também já implementada pela Struts,
evitando assim o uso de Scriptlets, deixando o código JSP mais limpo e fácil de manter.
Figura 11 - Aplicação do Struts no MVC.
Fonte: BROWN et. al., 2004.
44
Abaixo são listadas algumas vantagens do uso do framework Struts:
a) é um padrão de mercado;
b) foco nas regras de negócios;
c) uso de padrões de projeto;
d) aumento de produtividade;
e) simplifica o uso de Servlets;
f) Struts é um projeto de fonte aberta e bem documentado;
g) evita o uso de Scriptlets (trechos de código Java na camada de
visualização).
Neste trabalho foi usada a versão Struts 1.3.
3.6.2 Hibernate
Hibernate é um framework open source criado em meados de 2001 por Gavin King e outros
desenvolvedores. Desde então, vem se tornando um popular framework de persistência na
comunidade Java (BAUER & KING, 2005).
O Hibernate é uma solução para Mapeamento Objeto Relacional (ORM) para aplicações Java.
Segundo Bauer e King (2008), o Mapeamento Objeto Relacional consiste em persistir um
objeto Java numa tabela em uma base de dados relacional.
45
Figura 12 - Funcionamento do Hibernate.
Fonte: BAUER & KING, 2005.
Bauer e King (2008) apresentam as seguintes vantagens do uso do Hibernate:
a) produtividade: o Hibernate elimina a parte do código relacionada a
persistência, deixando o desenvolvedor se preocupar apenas com a lógica do
negócio;
b) esses fatores podem resultar numa significativa redução de tempo;
c) manutenção: quanto menos código, mais fácil se torna a compreensão do
programa. Outra importante vantagem é que o processo de refatoração pode ser
feito com mais facilidade;
d) independência do banco de banco: o mapeamento não depende do sistema
gerenciador do banco de dados (SGBD), pois a comunicação com o banco é
feita usando um SQL Dialect. Caso o SGBD seja trocado durante o
desenvolvimento o mapeamento não precisa ser refeito, apenas o Dialect
trocado.
46
3.7 Oracle 10g Express Edition
O Sistema Gerenciador de Banco de Dados (SGDB) utilizado neste trabalho foi o Oracle 10g
Express Edition (Oracle XE) produzido pela Oracle.
O banco de dados Oracle XE, possui tamanho compacto, para desenvolvimento,
implementação e distribuição livre. Pode ser instalado em uma máquina host de qualquer
tamanho com qualquer quantidade de Unidade Central de Processamento (CPU), um banco de
dados por máquina, mas o XE armazena até 4 GB de dados do usuário, consome até 1 GB de
memória e usa uma CPU na máquina host.
Apresenta, de acordo com o site de seu fabricante (www.oracle.com), as seguintes vantagens:
a) liberdade para desenvolver e implementar aplicativos de muitas plataformas,
trazendo suporte para uma grande variedade de ambientes de desenvolvimento;
b) facilidade para o usuário fazer atualização do Oracle Database XE e sua
aplicações para outras versões, sem mudanças estruturais;
c) possui o recurso Oracle HTML DB, que é usado para rápido
desenvolvimento e implementação de aplicativos baseados na Web;
d) apresenta suporte para diferentes comunidades de desenvolvimento como os
que trabalham com Java, PHP, .NET;
e) encontra-se disponível para sistema operacional Linux e Windows de 32
bits, e pode ser instalado em qualquer plataforma de hardware, com qualquer
configuração e qualquer número de CPUs;
f) oferece suporte ao Procedural Linguage/ Structure Query Language
(PL/SQL), extensão da linguagem SQL e desenvolvido pela Oracle.
Este capítulo abordou as principais tecnologias escolhidas para
implementação do protótipo do sistema para biblioteca. No
próximo capítulo será apresentada a modelagem e o
desenvolvimento do sistema.
47
4 MODELAGEM E DESENVOLVIMENTO DO SISTEMA
Este capítulo tem o objeto de descrever o processo de
desenvolvimento do sistema para bibliotecas. Está subdividido
em sessões que abordam as atividades do processo de software,
especificação de requisitos, os principais modelos gerados para a
sua documentação, tais como os modelos de sistema orientado a
objeto e modelos de dados, e por fim a implementação do
protótipo proposto.
4.1 Processo de software
A produção de um software engloba várias atividades que juntas formam o processo de
software. Segundo Sommerville (2007), as atividades fundamentais são:
a) especificação: são definidas as funcionalidades e as restrições na operação
de um software. Este processo leva à produção de um documento de requisitos
denominado especificação de requisitos;
b) projeto e implementação: produção do software se este atender às
especificações. É o processo de conversão de uma especificação em um
sistema executável;
c) validação: deve ser realizada para garantir que o software atenda às
necessidades do cliente. Destina-se a mostrar que o sistema está em
conformidade com as especificações;
d) evolução: a evolução de software deve existir para garantir que as
necessidades mutáveis do cliente sejam atendidas.
48
4.2 Especificação de Requisitos de Software
Uma técnica muito utilizada é documentar a especificação de software por meio de modelos
(SOMMERVILLE, 2007). Os modelos “são representações gráficas que descrevem os
processos de negócios, o problema a ser resolvido e o sistema a ser desenvolvido”
(SOMMERVILLE, 2007, p.112).
Podem ser desenvolvidos diferentes modelos para representar o sistema em diferentes
perspectivas. Como por exemplo, modelos de contexto, modelos de comportamento, modelos
de dados, modelos de objetos.
Para documentação da especificação de requisitos do software para bibliotecas foi utilizado o
modelo de objetos. Este modelo envolve um projeto de classes e de relacionamentos entre
essas classes que são responsáveis por definir os objetos do sistema e suas interações
(SOMMERVILLE, 2007).
O surgimento do paradigma orientado a objetos trouxe benefícios, tais como reuso das
classes, modularização do sistema e redução do custo de manutenção.
Sommerville (2007) aponta que ao longo do processo de desenvolvimento de um projeto
orientado a objetos estão presentes as seguintes etapas:
a) análise orientada a objetos: desenvolvimento de modelos orientado a objetos
do domínio da aplicação. Os objetos referem-se às entidades e operações;
b) projeto orientado a objetos: desenvolvimento de um modelo de um sistema
de software para implementação dos requisitos que foram identificados;
c) programação orientada a objetos: realização de um projeto utilizando uma
linguagem de programação orientada a objetos, como o Java.
Na análise de requisitos orientada a objetos deve-se modelar as entidades do mundo real por
meio de classes de objetos. Os modelos devem mostrar como as classes estão relacionadas
uma com as outras e como os objetos estão relacionados com outros objetos
(SOMMERVILLE, 2007).
49
Vários métodos de projeto orientado a objetos foram propostos, dentre eles a Unified
Modeling Language (UML), linguagem padrão para a modelagem orientada a objetos que
pode ser empregada para visualização, especificação, construção e documentação de artefatos
(BOOCH et. al., 2005).
Os diagramas na UML são representações gráficas dos elementos do sistema. A UML inclui
vários diagramas, tais como: diagrama de classes, diagramas de caso de uso, diagrama de
sequência, diagramas de gráficos de estado, entre outros.
O diagrama de classes é composto por um conjunto de classes, interfaces e colaborações,
incluindo seus relacionamentos e são encontrados em sistemas de modelagem orientados a
objetos (BOOCH et. al., 2005).
Apresenta uma visão de como as classes estão organizadas e como irão compor o sistema.
Possibilita definir a sua estrutura determinando os métodos e atributos, assim como
demonstrar como as classes se relacionam e trocam informações.
Diagrama de casos de uso se refere aos serviços, funções ou tarefas que podem ser utilizados
pelos usuários do sistema. Exibem um conjunto de casos de uso, atores e seus
relacionamentos (BOOCH et. al., 2005).
São usados para identificar as interações individuais com o sistema de forma mais detalhada.
Definem o comportamento do sistema, as exigências e o resultado esperado de uma
funcionalidade (SOMMERVILLE, 2007).
Diagramas de sequência são diagramas de interação que enfatiza as mensagens numa ordem
temporal. Muitas vezes são utilizados para propiciar mais informações aos casos de uso.
Mostram os agentes envolvidos nas interações, as operações associadas aos objetos e os com
quais objetos interagem (SOMMERVILLE, 2007).
Os diagramas de grafo de estado exibem máquinas de estados constituídos de estados,
transições e eventos (BOOCH et. al., 2005). São uma representação do estado ou situação em
que um objeto pode se encontrar no decorrer da execução de processos de um sistema ou
enquanto espera por eventos. Transição se refere ao relacionamento entre dois estados,
50
indicando que o objeto que está no primeiro estado irá passar para o segundo estado mediante
a ocorrência de um determinado evento.
4.2.1 Requisitos funcionais do sistema
RF01- O sistema deve permitir que o administrador cadastre usuários. Os usuários possuem
um número que é usado para sua identificação, nome, login e senha.
RF02- O sistema deve permitir que o administrador cadastre itens do acervo. Os itens devem
conter o ISBN, título, autor, edição, editora, cidade, ano, segmento ao qual pertence e ser
classificado por tipo, como: livros, revistas e material multimídia.
RF03- O sistema deve permitir que o administrador cadastre atendentes e estabeleça os perfis
de acesso do atendente no sistema. O atendente possui um número de identificação, nome,
login e senha.
RF04- O sistema deve permitir que o administrador cadastre segmentos dos itens do acervo,
contendo número de identificação, nome do segmento e descrição.
RF05- O sistema deve permitir que o administrador cadastre tipos de itens do acervo,
contendo um número de identificação e nome.
RF06- O sistema deve permitir que o atendente efetue empréstimo de no máximo dois itens
do acervo por vez ao usuário, contendo número de identificação do empréstimo, número de
identificação do usuário, item retirado, data de retirada, data prevista de devolução, data da
efetiva entrega e número de identificação do atendente que efetivou o empréstimo, passando a
etiqueta RFID do item pela leitora ou manualmente.
RF07- O sistema deve permitir que o atendente efetue a devolução de itens ao acervo,
contendo o número de identificação do usuário, o número de identificação do item, a data da
devolução e o número de identificação do atendente, passando a etiqueta RFID do item pela
leitora ou manualmente.
RF08- O sistema deve permitir que o atendente registre multas referentes a um usuário que
não entregar o item emprestado na data determinada para devolução, contendo número de
identificação do usuário, número de identificação da multa, número de identificação do
atendente, valor da multa, um status referente se o usuário efetivou o pagamento da multa ou
não, data do pagamento.
51
RF09- O sistema deve permitir que o atendente e o usuário realizem pesquisas referentes aos
itens do acervo, verifiquem se um item está disponível para empréstimo ou consulta,
informando a quantidade de exemplares dos itens disponíveis.
RF10- O sistema deve permitir que o atendente verifique se um item do acervo que está sendo
requisitado para empréstimo está reservado.
RF11- O sistema dever permitir que o atendente verifique a quantidade de um determinado
item do acervo. Se este item possuir mais de dois exemplares, o usuário terá um prazo de
devolução de sete dias. Caso contrário, o empréstimo terá um prazo de três dias.
RF12- O sistema deverá permitir que o atendente controle a situação do usuário, se ele está
apto ou não a efetuar empréstimo de itens do acervo.
RF13- O sistema deve permitir que o usuário consulte livros por um determinado período de
tempo, esse item não pode ser retirado da biblioteca, contendo o número de identificação do
usuário, número de identificação do item, número de identificação do atendente, data e data.
O atendente deve passar a etiqueta RFID do item pela leitora e o sistema captura a sua
identificação ou cadastrar manualmente a consulta.
RF14- O sistema deve permitir que o usuário reserve itens do acervo para empréstimo,
contendo o número de identificação do item, número de identificação do usuário e data da
reserva e prazo.
RF15- O sistema deve permitir que o usuário faça empréstimo do item desejado, ou seja, o
sistema deve permitir o auto-atendimento. O usuário deve passar a etiqueta RFID do item pela
leitora e o sistema captura a sua identificação.
RF16- O sistema deve permitir que o usuário faça a devolução de um item emprestado. O
usuário deve passar a etiqueta RFID do item pela leitora e o sistema captura a sua
identificação.
4.2.2 Requisitos não funcionais
RNF01- O sistema deve operar 24x7, com garantia de 90% de disponibilidade.
RNF02- O sistema deve conter áreas de acesso comum e acesso restrito por meio de login e
senha. O usuário poderá acessar apenas as informações que seu perfil necessita para realizar
suas atividades, sendo impedido de acessar às demais.
52
RNF03- O sistema de gestão de bibliotecas não é um sistema crítico, mas é fundamental a
realização de back-ups periódicos.
RNF04- O sistema deve ser uma aplicação Web e oferecer suporte aos browsers Firefox 1.5 e
Windows Internet Explorer.
4.2.3 Diagrama de casos de uso
A Figura 13 contém os casos de usos determinados na fase de levantamento de requisitos.
System
Usuário da biblioteca
RFID
Administrador
Cadastrar Atendentes
Cadastrar Itens
Cadastrar Usuários
Consultar Itens
Atendente
Efetuar Empréstimo
Efetuar Devolução
Cadastrar Segmentos
Reservar Itens
Registrar Multas
Pesquisar Itens
Consultar Situação de Usuários
Figura 13 - Diagrama de casos de uso.
53
4.2.4 Descrição dos casos de uso
4.2.4.1 Consultar itens
A Tabela 2 descreve o caso de uso consultar itens.
Tabela 2 - Descrição de Caso de Uso (Consultar itens).
ID do caso de
uso
COM-001
Função Consultar itens
Ator Usuário
Descrição Descreve as etapas necessárias para que o usuário retire um item do
acervo para consulta.
Entradas Número de identificação do item, número de identificação do usuário.
Origem A leitora do RFID faz a leitura da tag acoplada no item e envia o
número de identificação para o sistema.
Saídas Nome do item retirado para consulta.
Destino O item fica indisponível para ser retirado por outro usuário.
Exceções 1. O usuário não está cadastrado,
2. O item não está cadastrado,
3. O usuário está bloqueado,
4. Falha na leitura da tag.
Curso Normal O usuário informa seu número de identificação ao atendente que
verifica no sistema se o usuário está cadastrado e se possui alguma
restrição. Ao confirmar o usuário solicita ao atendente o item
desejado, o atendente pesquisa se o item está disponível, se sim o
atendente retira o item do local em que está armazenado, passa a tag
do item pela leitora RFID que envia ao sistema o número de
identificação do item e o usuário pode retirá-lo para consulta.
Curso
Alternativo
O atendente informa ao sistema o número de identificação do item.
Requer Validação do usuário e do item.
Precondição O usuário precisa estar cadastrado, o item precisa estar disponível.
Pós-condição Permite a retirada do item para consulta.
54
4.2.4.2 Reservar itens
A Tabela 3 apresenta a descrição do caso de uso reservar itens.
Tabela 3 - Descrição de Caso de Uso (Reservar itens).
ID do caso de uso RES-001
Função Reservar itens
Ator Usuário
Descrição Descreve as etapas necessárias para que o usuário faça a reserva
do item desejado.
Entradas Número de identificação do item, número de identificação do
usuário.
Origem Cadastro de itens.
Saídas Nome do item reservado.
Destino A solicitação de reserva fica armazenada.
Exceções 1. O usuário não está cadastrado.
Curso Normal O usuário informa o item que deseja reservar ao atendente, que
registra no sistema a reserva e o número de identificação do
usuário.
Curso Alternativo O usuário faz o login web, o sistema verifica se o usuário está
cadastrado. Se sim, o usuário poderá informa o item que deseja
reservar.
Requer Validação do usuário.
Precondição O usuário deve estar cadastrado, o item precisa estar cadastrado.
Pós-condição O item fica reservado.
55
4.2.4.3 Pesquisar itens
A Tabela 4 apresenta a descrição do caso de uso pesquisar itens.
Tabela 4 - Descrição de Caso de Uso (Pesquisar itens).
ID do caso de uso PES-001
Função Pesquisar itens
Ator Atendente, Usuário
Descrição Descreve as etapas necessárias para pesquisa sobre um determinado
item.
Entradas Número de identificação do item, nome do item, autor.
Origem Verificação dos itens cadastrados.
Saídas Informações acerca do item selecionado.
Destino Auxilia na efetivação de uma solicitação de consulta ou empréstimo
de um item ao usuário.
Exceções 1. O item não está cadastrado.
Curso Normal O atendente ou usuário informa ao sistema o número de identificação
do item, nome do item ou autor e realiza a pesquisa.
Curso Alternativo Não há.
Requer Validação do item.
Precondição O item deve estar cadastrado no sistema.
Pós-condição O usuário informa se deseja realizar uma consulta ou um
empréstimo.
56
4.2.4.4 Efetuar devolução
Na Tabela 5 é apresentada a descrição de caso de uso efetuar devolução.
Tabela 5 - Descrição de Caso de Uso (Efetuar devolução).
ID do caso de uso DEV-001
Função Efetuar devolução
Ator Atendente, Usuário
Descrição Descreve as etapas necessárias para que o sistema registre a
devolução de um item entregue por um usuário.
Entradas Número de identificação do item.
Origem A leitora do RFID faz a leitura da tag acoplada no item e envia o
número de identificação para o sistema.
O atendente efetua a devolução no sistema.
Saídas Confirmação da devolução.
Destino O item fica liberado para novo empréstimo.
Exceções 1. Falha na leitura da tag.
Curso Normal O usuário entrega o item ao atendente que passa a leitora RFID
pela tag. É enviado ao sistema o número de identificação do
item e o livro liberado para novo empréstimo.
Curso Alternativo O atendente registra manualmente no sistema a devolução do
item que é liberado para novo empréstimo.
Requer Validação do item.
Precondição O empréstimo precisa estar cadastrado.
Pós-condição Libera o item para novo empréstimo.
57
4.2.4.5 Efetuar empréstimo
A Tabela 6 descreve o caso de uso efetuar empréstimo.
Tabela 6 - Descrição de Caso de Uso (Efetuar empréstimo).
ID do caso de uso EMP-001
Função Efetuar empréstimo
Ator Atendente, Usuário
Descrição Descreve as etapas necessárias para que o sistema registre o
empréstimo de um item a um usuário.
Entradas Número de identificação do item, número de identificação do
usuário.
Origem A leitora do RFID faz a leitura da tag acoplada no item e envia o
número de identificação para o sistema.
O atendente efetua no sistema o empréstimo.
Saídas Confirmação do empréstimo.
Destino O item fica indisponível para ser retirado por outro usuário.
Exceções 1. O usuário não está cadastrado,
2. O item não está cadastrado,
3. Falha na leitura da tag,
4.Usuário encontra-se bloqueado para realizar empréstimos.
Curso Normal O usuário informa seu número de identificação ao atendente que
verifica no sistema se o usuário está cadastrado e se o mesmo
possui restrição que o impeça de solicitar o empréstimo. Ao
confirmar o usuário solicita ao atendente o item desejado, o
atendente pesquisa se o item está disponível para empréstimo, se
sim o atendente retira o item do local em que está armazenado,
passa a tag do item pela leitora RFID que envia ao sistema o
número de identificação do item e o usuário pode retirá-lo.
Curso Alternativo O atendente deve realizar o processo manualmente no sistema
informando o número de identificação do item, os dados do usuário
e confirma o empréstimo.
Requer Validação do item e do usuário.
Precondição O usuário precisa estar cadastrado, o item precisa estar disponível.
Pós-condição Permite empréstimo do item.
58
4.2.4.6 Consultar situação do usuário
Na Tabela 7 é apresentada uma descrição do caso de uso consultar situação do usuário.
Tabela 7 - Descrição de Caso de Uso (Consultar situação do usuário).
ID do caso de uso CSU-001
Função Consultar situação dos usuários
Ator Atendente
Descrição Descreve as etapas necessárias para que um atendente verifique a
situação de um usuário, se este está apto a realizar um empréstimo,
uma consulta e se há débitos pendentes.
Entradas Número de identificação do usuário.
Origem Cadastro de usuários.
Saídas Situação do usuário.
Destino Possibilita a realização de consulta ou empréstimo de item.
Exceções 1. O usuário não está cadastrado.
Curso Normal O atendente informa o número de identificação do usuário ao
sistema.
Curso Alternativo Não há.
Requer O usuário deve estar cadastrado.
Precondição Cadastro do usuário.
Pós-condição Informar o número de identificação do item e qual operação o
usuário deseja realizar, consulta ou empréstimo.
59
4.2.4.7 Registrar multas
Na Tabela 8 é apresentada uma descrição do caso de uso registrar multas.
Tabela 8 - Descrição de Caso de Uso (Registrar multa).
ID do caso de uso MUL-001
Função Registrar multas
Ator Atendente
Descrição Descreve as etapas necessárias para o atendente registrar multas
referentes a um usuário.
Entradas Número de identificação do usuário.
Origem Cadastro de usuários.
Saídas Registro de multa.
Destino Situação do usuário.
Exceções 1. Usuário não cadastrado.
Curso Normal O atendente informa o número de identificação do usuário, o
sistema armazena a informação nos dados do usuário.
Curso Alternativo Não há.
Requer O usuário efetua a devolução após a data registrada para entrega
do item.
Precondição Ultrapassar a data registrada para entrega.
Pós-condição O usuário fica bloqueado para solicitar consulta e empréstimo.
60
4.2.4.8 Cadastrar usuários
A Tabela 9 descreve o caso de uso cadastrar usuário.
Tabela 9 - Descrição de Caso de Uso (Cadastrar usuários).
ID do caso de uso USU-001
Função Cadastrar usuários
Ator Administrador
Descrição Descreve as etapas necessárias para cadastrar e alterar dados
sobre um usuário.
Entradas Dados do usuário.
Origem Informações fornecidas pelo usuário.
Saídas Confirmação de cadastro do usuário.
Destino Cadastro do usuário.
Exceções 1. Usuário já cadastrado.
Curso Normal O administrador efetua login no sistema, realiza o cadastro do
usuário.
Curso Alternativo Não há.
Requer Ter perfil de administrador.
Precondição Os dados devem ser inseridos pelo administrador.
Pós-condição Habilita o usuário a realizar empréstimo e consulta de itens do
acervo.
61
4.2.4.9 Cadastrar atendentes
A Tabela 10 apresenta uma descrição do caso de uso cadastrar atendentes.
Tabela 10 - Descrição de Caso de Uso (Cadastrar atendentes).
ID do caso de uso ATE-001
Função Cadastrar atendentes
Ator Administrador
Descrição Descreve as etapas necessárias para cadastro, alteração e
exclusão de dados de um atendente.
Entradas Dados do atendente.
Origem Informações fornecidas pelo atendente.
Saídas Confirmação de cadastro do atendente.
Destino Cadastro do atendente.
Exceções 1. Atendente já cadastrado.
Curso Normal O administrador efetua login no sistema, realiza o cadastro do
atendente.
Curso Alternativo Não há.
Requer Ter perfil de administrador.
Precondição Os dados devem ser inseridos pelo administrador.
Pós-condição Habilita o atendente a efetuar empréstimos, consultas de itens
do acervo, realizar pesquisa de itens, consultar situação dos
usuários.
62
4.2.4.10 Cadastrar itens
Na Tabela 11 é apresentada uma descrição do caso de uso cadastrar itens.
Tabela 11 - Descrição de Caso de Uso (Cadastrar itens).
ID do caso de uso ITE-001
Função Cadastrar itens
Ator Administrador
Descrição Descreve as etapas necessárias para o cadastro de itens do
acervo.
Entradas Dados do item.
Origem Informações fornecidas pelo administrador.
Saídas Confirmação de cadastro do item.
Destino Cadastro de itens.
Exceções 1. Item já cadastrado.
Curso Normal O administrador efetua login no sistema, realiza o cadastro do
item.
Curso Alternativo Não há.
Requer Ter perfil de administrador.
Precondição Os dados devem ser inseridos pelo administrador.
Pós-condição Habilita o item para empréstimos e consultas.
63
4.2.4.11 Cadastrar segmentos
Na Tabela 12 é apresentada uma descrição do caso de uso cadastrar segmentos.
Tabela 12 - Descrição de Caso de Uso (Cadastrar segmentos).
ID do caso de uso SEG-001
Função Cadastrar segmentos
Ator Administrador
Descrição Descreve as etapas necessárias para o cadastro de segmentos dos
itens do acervo.
Entradas Descrição do segmento.
Origem Informações fornecidas pelo administrador.
Saídas Confirmação de cadastro do segmento.
Destino Cadastro de segmentos.
Exceções 1. Segmento já cadastrado.
Curso Normal O administrador efetua login no sistema, realiza o cadastro do
segmento.
Curso Alternativo Não há.
Requer Ter perfil de administrador.
Precondição Os dados devem ser inseridos pelo administrador.
Pós-condição Habilita uso do segmento.
64
4.2.5 Arquitetura de sistema
O software para bibliotecas é uma aplicação Web com arquitetura cliente-servidor dividida em
três camadas: camada de apresentação, camada de aplicação e camada de dados. É necessária
a integração desta aplicação com um middleware que tem como objetivo tratar os dados
obtidos pelos leitores RFID.
O middleware é composto pelos módulos RFID Event Manager que captura e filtra as
informações vindas de um dispositivo de leitura, e RFID Information Server que é
responsável por ler um conjunto de dados de baixo nível e fornecer informações de alto nível
para uma aplicação externa.
A arquitetura em 3 camadas envolve a separação das funcionalidades com o objetivo de
separar a lógica de apresentação, a lógica de negócio e a conexão com o banco de dados. Isto
torna o sistema mais flexível, de modo que partes podem ser alteradas independentemente.
A camada de apresentação ou camada de interface com o usuário é responsável pela
comunicação com as outras camadas da aplicação. Requisita serviços ao servidor da
aplicação, recebe a entrada de dados e apresenta os resultados.
A camada de aplicação trata a lógica da aplicação, nela são definidas as regras de negócio.
Nesta camada foi utilizado o Padrão de Projeto MVC.
Por fim, a camada de dados é a camada na qual se encontra a base de dados da aplicação.
65
Figura 14 - Arquitetura do sistema.
Controller
LÓGICA
DE
NEGÓCIO
JSP/HTML
1: requisição
3: seleciona a view
2: chama a
instância
4: retorna os dados
para visualização
Action
ActionServlets
ActionForm
BANCO
DE
DADOS
DAO
Model
Camada de Dados
BROWSER
5: Resposta
Camada de Apresentação Camada de Aplicação
JSP/HTML
View
Event
Manager
RFID
Information
Server
Middleware RFID
66
4.2.6 Diagrama de classes
Uma visão geral do diagrama de classes da aplicação Web é apresentada na Figura 15. Nas
subsessões posteriores, cada classe, juntamente com as variáveis e métodos que a compõe, é
apresentada seguindo o Padrão de Projeto MVC.
Reservas
Itens_Reservas
Itens
*
1
1
*
Tipos Segmentos
*
1
*
1
Usuários
Atendentes
Consultas
Empréstimos
Multas
Administrador
Itens_Emprestimos
Itens_Consultas
* 1
*
1
*
1
*
1
*
1
*
1
*
1
*1
*
1
*
1
1
1
Figura 15 - Visão Geral do Diagrama de Classes da Aplicação Web.
67
4.2.6.1 Empréstimo
Na Figura 16 são apresentadas as tabelas que compõe Empréstimos segundo o Padrão de
Projeto MVC. A classe Model foi nomeada como Emprestimo, a classe Controller como
CtrlEmprestimo, View como ViewEmprestimo e DAO como DaoEmprestimo.
Figura 16 - Diagrama de classes (Empréstimo).
68
4.2.6.2 Usuário
Na Figura 17 são apresentadas as tabelas que compõe Usuários segundo o Padrão de Projeto
MVC. A classe Model foi nomeada como Usuario, a classe Controller como CtrlUsuario,
View como ViewUsuario e DAO como DaoUsuario.
Figura 17 - Diagrama de classes (Usuário).
69
4.2.6.3 Atendente
Na Figura 18 são apresentadas as tabelas que compõe Atendentes segundo o Padrão de
Projeto MVC. A classe Model foi nomeada como Atendente, a classe Controller como
CtrlAtendente, View como ViewAtendente e DAO como DaoAtendente.
Figura 18 - Diagrama de classes (Atendente).
70
4.2.6.4 Administrador
Na Figura 19 são apresentadas as tabelas que compõe Administrador segundo o Padrão de
Projeto MVC. A classe Model foi nomeada como Administrador, a classe Controller como
CtrlAdministrador, View como ViewAdministrador e DAO como DaoAdministrador.
Figura 19 - Diagrama de classes (Administrador).
71
4.2.6.5 Item
Na Figura 20 são apresentadas as tabelas que compõe Itens segundo o Padrão de Projeto
MVC. A classe Model foi nomeada como Item, a classe Controller como CtrlItem, View
como ViewItem e DAO como DaoItem.
Figura 20 - Diagrama de classes (Item).
72
4.2.6.6 Tipo
Na Figura 21 são apresentadas as tabelas que compõe Tipos segundo o Padrão de Projeto
MVC. A classe Model foi nomeada como Tipo, a classe Controller como CtrlTipo, View
como ViewTipo e DAO como DaoTipo.
Figura 21 - Diagrama de classes (Tipo).
73
4.2.6.7 Segmento
Na Figura 22 são apresentadas as tabelas que compõe Segmentos segundo o Padrão de Projeto
MVC. A classe Model foi nomeada como Segmento, a classe Controller como CtrlSegmento,
View como ViewSegmento e DAO como DaoSegmento.
Figura 22 - Diagrama de classes (Segmento).
74
4.2.6.8 Reserva
Na Figura 23 são apresentadas as tabelas que compõe Reservas segundo o Padrão de Projeto
MVC. A classe Model foi nomeada como Reserva, a classe Controller como CtrlReserva,
View como ViewReserva e DAO como DaoReserva.
Figura 23 - Diagrama de classes (Reserva).
75
4.2.6.9 Consulta
Na Figura 24 são apresentadas as tabelas que compõe Consultas segundo o Padrão de Projeto
MVC. A classe Model foi nomeada como Consulta, a classe Controller como CtrlConsulta,
View como ViewConsulta e DAO como DaoConsulta.
Figura 24 - Diagrama de classes (Consulta).
76
4.2.6.10 Multa
Na Figura 25 são apresentadas as tabelas que compõe Multas segundo o Padrão de Projeto
MVC. A classe Model foi nomeada como Multa, a classe Controller como CtrlMulta, View
como ViewMulta e DAO como DaoMulta.
Figura 25 - Diagrama de classes (Multa).
77
4.2.7 Diagramas de sequência
4.2.7.1 Reserva
Usuário Interface Action Banco de Dados
1 : Entrar com os dados()2 : Validação e Envio de dados()
3 : Requisição()
4 : Buscar()
5 : Retornar dados()
6 : Carregar resultados()7 : Exibir resultados()
8 : Resultados não encontrados()
9 : Selecionar item desejado()10 : Envio de dados()
11 : Persistir dados()
12 : Grava()
13 : Retorna dados()14 : Retornar confirmação()
15 : Reserva efetuada com sucesso()
16 : Reserva não pode ser efetuada()
Figura 26 - Diagrama de Sequência (Reserva).
78
4.2.7.2 Empréstimo
Usuário Interface Action Banco de Dados
1 : Entrar com os dados()
2 : Validação e Envio de dados()3 : Requisição()
4 : Busca()
5 : Retornar resultados()6 : Carregar resultados()
7 : Exibir resultados()
8 : Resultados não encontrados()
9 : Selecionar item desejado()10 : Envio de dados()
11 : Persistir dados()
12 : Gravar()
13 : Retorna dados()14 : Retorna confirmação()
15 : Empréstimo efetuado com sucesso()
16 : Empréstimo não pode ser efetuado()
Figura 27 - Diagrama de Sequência (Empréstimo).
Figura 28 - Diagrama de Sequência (Empréstimo-RFID).
79
4.2.7.3 Devolução
Figura 29 - Diagrama de Sequência (Devolução).
Figura 30 - Diagrama de Sequência (Devolução - RFID).
80
4.2.7.4 Consulta
Usuário Interface Action Banco de Dados
1 : Entrar com os dados()2 : Validação e Envio de dados()
3 : Requisição()
4 : Buscar()
5 : Retornar dados()
6 : Carregar resultados()7 : Exibir resultados()
8 : Resultados não encontrados()
9 : Selecionar item desejado()10 : Envio de dados()
11 : Persistir dados()
12 : Grava()
13 : Retorna dados()14 : Retornar confirmação()
15 : Consulta efetuada com sucesso()
16 : Consulta não pode ser efetuada()
Figura 31 - Diagrama de Sequência (Consulta).
Figura 32 - Diagrama de Sequência (Consulta - RFID).
81
4.2.7.5 Pesquisar itens
Figura 33 - Diagrama de Sequência (Pesquisar Itens).
82
4.2.7.6 Consultar situação do usuário
Figura 34 - Diagrama de Sequência (Consultar situação do usuário).
83
4.2.7.7 Registrar Multa
Usuário Interface Action Banco de Dados
1 : Entrar com os dados()2 : Validação e Envio de dados()
3 : Requisição()
4 : Buscar()
5 : Retornar dados()
6 : Carregar resultados()7 : Exibir resultados()
8 : Resultados não encontrados()
9 : Selecionar usuário()10 : Envio de dados()
11 : Persistir dados()
12 : Grava()
13 : Retorna dados()14 : Retornar confirmação()
15 : Multa registrada com sucesso()
16 : Multa não pode ser registrada()
Figura 35 - Diagrama de Sequência (Registrar Multa).
84
4.2.7.8 Cadastros
Usuário Interface Action Banco de Dados
1 : Entrar com os dados()2 : Validação e Envio de dados()
3 : Requisição()
4 : Gravar()
5 : Retornar dados()
6 : Carregar resultados()7 : Exibir confirmação()
8 : Cadastro não pode ser efetuado()
Figura 36 - Diagrama de Sequência (Cadastros).
85
4.2.8 Modelo de dados
4.2.8.1 Visão Geral do Modelo Relacional
Modelo Relacional é um modelo de dados, criado por Edgar Frank Codd, em 1970, que se
baseia no princípio de que os dados são armazenados em tabelas ou relações.
Uma visão geral do Modelo Relacional é apresentada na Figura 37, os atributos são descritos
na sessão 4.2.8.2.
Figura 37 - Visão Geral do Modelo Relacional do Banco de Dados.
86
A representação do modelo relacional da base de dados foi desenvolvida usando a ferramenta
DBDesigner 4. Esta ferramenta foi adotada por apresentar uma interface simples e ser
distribuída sob a licença GNU GPL.
As tabelas do banco de dados foram dividas em regiões ou módulos que equivalem a áreas de
casos de uso. As regiões principais são: Reserva, Consulta, Empréstimo, Login e Acervo.
Na região Reserva foram criadas as tabelas RESERVAS e ITENS_RESERVAS que
possibilitam que o usuário faça reservas de itens do acervo.
Na região Login foram criadas as tabelas ADMINISTRADOR, USUÁRIOS E
ATENDENTES que oferecem recursos para gerenciamento dos usuários do sistema.
Na região Empréstimos foram criadas as tabelas EMPRÉSTIMOS, MULTAS E
ITENS_EMPRESTIMOS que permitem o gerenciamento de empréstimos realizados pelos
usuários. Oferece as funcionalidades de cadastro de empréstimo, de itens que compõem o
empréstimo e eventuais multas por atraso no prazo de entrega dos itens.
Na região Consultas foram criadas as tabelas CONSULTAS E ITENS_CONSULTAS que
permitem o gerenciamento de itens consultados pelos usuários. Uma das funcionalidades
disponíveis é o cadastro de itens que o usuário retira para consulta no próprio acervo.
Na região Acervo foram criadas as tabelas ITENS, TIPOS E SEGMENTOS que permitem o
gerenciamento dos itens existentes do acervo. Possibilita o cadastro, exclusão e pesquisa de
itens do acervo, especificados por tipo e segmento.
87
4.2.8.2 Dicionário de Dados
Dicionário de Dados é um conjunto de tabelas especiais, que tem como função registrar
informações de todos os objetos criados em um Banco de Dados. Na Figura 38 é apresentado
o Dicionário de Dados referente a Acervo, as tabelas que o compõe e seus respectivos
atributos.
Acervo
ITENS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
ITE_ID INTEGER PK NN UNSIGNED Número de identificação do item
AI
ITE_TIP_ID INTEGER NN UNSIGNED Tipo do item
ITE_SEG_ID INTEGER NN UNSIGNED Identificação do segmento do item
ITE_ISBN VARCHAR
ITE_TITULO VARCHAR Título do Item
ITE_AUTOR VARCHAR Autor do Item
ITE_EDITORA VARCHAR Editora do Item
ITE_EDICAO VARCHAR Edição do Item
ITE_ANO DATE NN Ano de publicação do item
ITE_CIDADE VARCHAR Local de publicação do item
ITE_QUANTIDADE INTEGER UNSIGNED Quantidade itens existentes
ITE_DISPONIVEL CHAR
IndexName IndexType Columns
PRIMARY PRIMARY ITE_ID
ITENS_FKIndex1 Index ITE_SEG_ID
ITENS_FKIndex2 Index ITE_TIP_ID
SEGMENTOS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
SEG_ID INTEGER PK NN UNSIGNED Número de identificação do Segmento
AI
SEG_NOME VARCHAR Nome do Segmento
SEG_DESCRICAO VARCHAR Descrição do Segmento
IndexName IndexType Columns
PRIMARY PRIMARY SEG_ID
TIPOS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
TIP_ID INTEGER PK NN UNSIGNED Número de identificação do tipo
AI
TIP_NOME VARCHAR Nome do tipo
IndexName IndexType Columns
PRIMARY PRIMARY TIP_ID
Figura 38 - Dicionário de Dados (Acervo).
88
Na Figura 39 é apresentado o Dicionário de Dados referente à Consulta, as tabelas que a
compõe e os respectivos atributos.
Consulta
CONSULTAS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
CON_ID INTEGER PK NN UNSIGNED Número de identificação da
consulta AI
CON_USU_ID INTEGER NN UNSIGNED
CON_ATE_ID INTEGER NN UNSIGNED Atendente responsável
CON_DATA DATE
CON_HORA VARCHAR
IndexName IndexType Columns
PRIMARY PRIMARY CON_ID
CONSULTAS_FKIndex1 Index CON_ATE_ID
CONSULTAS_FKIndex2 Index CON_USU_ID
ITENS_CONSULTAS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
ITC_ID INTEGER PK NN UNSIGNED Número de identificação do
registro AI
ITC_ITE_ID INTEGER NN UNSIGNED Número de identificação do
item da consulta
ITC_CON_ID INTEGER NN UNSIGNED Número de identificação da
consulta
IndexName IndexType Columns
PRIMARY PRIMARY ITC_ID
ITENS_CONSULTAS_FKIndex1 Index ITC_CON_ID
ITENS_CONSULTAS_FKIndex2 Index ITC_ITE_ID
Figura 39 - Dicionário de Dados (Consulta).
89
A Figura 40 apresenta o Dicionário de Dados referente a Empréstimo, as tabelas que o
compõe e os respectivos atributos.
Empréstimo
EMPRESTIMOS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
EMP_ID INTEGER PK NN UNSIGNED Número de identificação do empréstimo
AI
EMP_USU_ID INTEGER NN UNSIGNED
EMP_ATE_ID INTEGER UNSIGNED Número de identificação do Atendente
EMP_DATA_RETIRADA DATE Data de retirada dos itens
EMP_SITUACAO VARCHAR Situação do empréstimo
EMP_DATA_PREVISTA DATE Data de previsão de entrega
EMP_DATA_DEVOLUCAO DATE
IndexName IndexType Columns
PRIMARY PRIMARY EMP_ID
EMPRESTIMOS_FKIndex1 Index EMP_ATE_ID
EMPRESTIMOS_FKIndex2 Index EMP_USU_ID
MULTAS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
MUL_ID INTEGER PK NN UNSIGNED Número de identificação da multa
AI
MUL_EMP_ID INTEGER NN UNSIGNED
MUL_ATE_ID INTEGER NN UNSIGNED
MUL_VALOR FLOAT Valor da multa
MUL_PAGO VARCHAR
MUL_DATA_RECEBIMENTO DATE
IndexName IndexType Columns
PRIMARY PRIMARY MUL_ID
MULTAS_FKIndex2 Index MUL_ATE_ID
MULTAS_FKIndex2 Index MUL_EMP_ID
ITENS_EMPRESTIMOS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
IEM_ID INTEGER PK NN UNSIGNED Número de identificação do registro
AI
IEM_EMP_ID INTEGER NN UNSIGNED
IEM_ITE_ID INTEGER NN UNSIGNED Número de identificação do item
IndexName IndexType Columns
PRIMARY PRIMARY IEM_ID
ITENS_EMPRESTIMOS_FKIndex2 Index IEM_ITE_ID
ITENS_EMPRESTIMOS_FKIndex2 Index IEM_EMP_ID
Figura 40 - Dicionário de Dados (Empréstimo).
90
Na Figura 41 é apresentado o Dicionário de Dados referente ao Login, as tabelas que o
compõe e os respectivos atributos.
Login
USUARIOS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
USU_ID INTEGER PK NN UNSIGNED Número de Identificação do
Usuário AI
USU_NOME VARCHAR Nome completo do Aluno
USU_STATUS VARCHAR Situação do Aluno
USU_LOGIN VARCHAR
USU_SENHA VARCHAR
IndexName IndexType Columns
PRIMARY PRIMARY USU_ID
ATENDENTES
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
ATE_ID INTEGER PK NN UNSIGNED Número de identificação do
atendente AI
ATE_NOME VARCHAR Nome do Atendente
ATE_LOGIN VARCHAR
ATE_SENHA VARCHAR
IndexName IndexType Columns
PRIMARY PRIMARY ATE_ID
Figura 41 - Dicionário de Dados (Login).
91
A Figura 42 apresenta o Dicionário de Dados referente à Reserva, as tabelas que a compõe e
os respectivos atributos.
Reserva
RESERVAS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
RES_ID INTEGER PK NN UNSIGNED Número de Identificação da
reserva AI
RES_USU_ID INTEGER NN UNSIGNED
RES_DATA_RESERVA DATE Data da reserva
RES_VALIDADE DATE
RES_STATUS VARCHAR
IndexName IndexType Columns
PRIMARY PRIMARY RES_ID
RESERVAS_FKIndex1 Index RES_USU_ID
ITENS_RESERVAS
ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc
ITR_ID INTEGER PK NN UNSIGNED Número de Identificação do
registro AI
ITR_ITE_ID INTEGER NN UNSIGNED Número de Identificação do
itens da reserva
ITR_RES_ID INTEGER NN UNSIGNED Número de Identificação da
reserva
IndexName IndexType Columns
PRIMARY PRIMARY ITR_ID
ITENS_RESERVAS_FKIndex1 Index ITR_RES_ID
ITENS_RESERVAS_FKIndex2 Index ITR_ITE_ID
Figura 42 - Dicionário de Dados (Reserva).
92
4.3 Projeto e implementação do protótipo
Nas sessões posteriores será apresentado o projeto de implementação do protótipo da
aplicação Web adotando como estudo de caso a biblioteca da FATEC – São José dos Campos.
Foram implementados os casos de uso Efetuar Empréstimos, Efetuar Devoluções, Pesquisar
Itens e Cadastrar Itens.
4.3.1 Camada de visualização
Na criação da interface foi usada a linguagem HTML para criação das páginas e CSS para
formatação. Para auxiliar no desenvolvimento da interface gráfica foi utilizada a biblioteca
JavaScript JQuery. O uso dessa biblioteca ajuda na criação de interfaces de usuário, efeitos
dinâmicos, e permite usar AJAX na aplicação.
Uma tela da aplicação é demonstrada na Figura 43.
Figura 43 - Tela Inicial.
93
A biblioteca JQuery permite melhorar a interface da aplicação usando recursos da linguagem
JavaScript de maneira simplificada. JQuery foi usado, por exemplo, na Tela de Itens, para
permitir realizar uma busca sem a necessidade de recarregar toda a página para exibir os
resultados.
Uma parte da implementação dessa funcionalidade é descrita na Figura 44.
Figura 44 - Uso do Ajax.
Também foi usada a biblioteca JQuery para exibir os resultados em uma tabela que permite
ordenar os resultados sem a necessidade de recarregar a página. Para implementar essa opção
foi usado o plugin Tablesorter para a biblioteca JQuery. Um exemplo de tela usando
Tablesorter pode ser visto na Figura 45 e o código-fonte de implementação na Figura 46.
Figura 45 - Exemplo do uso do plugin Tablesorter.
94
Figura 46 - Código-fonte de implementação usando o plugin Tablesorter.
95
Na tela inicial da aplicação, conforme Figura 43, existem duas opções de Login, uma para os
usuários da biblioteca e outra para o administrador do sistema.
A área restrita para os usuários, mostrada na Figura 47, permite realizar buscas e reservar
itens.
Figura 47 - Área restrita do usuário.
A área restrita do administrador permite a realização de empréstimos, devolução, cadastro de
itens e consulta aos itens do acervo. A Figura 48 apresenta uma tela da área restrita do
administrador do sistema.
96
Figura 48 - Área restrita do administrador do sistema.
As telas com as funcionalidades referentes a cada um dos perfis mencionados encontram-se
no Apêndice A.
4.3.2 Camada de aplicação
4.3.2.1 MVC e Struts
Foi utilizado o framework Struts no protótipo da aplicação Web para auxiliar na
implementação do Padrão de Projeto MVC.
O protótipo apresenta os seguintes componentes: classes Java implementando o Controller da
aplicação (Action), páginas JSP implementando as Views, classes Java implementando o
97
Model da aplicação (ActionForm), um arquivo de configuração (struts-config.xml) definindo
aspectos de relacionamento entre as Actions e Views.
O Controller foi implementado utilizando classes Action para cada atividade desejada. Cada
classe Action contém uma classe ActionForward que encapsula a informação sobre a próxima
View a ser apresentada, e possui apenas o método execute(), que é responsável por retornar a
próxima visão a ser mostrada.
A classe ConsultasAction.java é apresentada na Figura 49.
Figura 49 - Código-Fonte de implementação da classe ConsultasAction.java.
A View, como foi apresentada na sessão 4.3.1, contém a implementação do JSP.
O Model contém a classes ActionForm que implementam todas as variáveis e os devidos
métodos get e set. Todos os dados que serão armazenados no banco de dados passam pelo
Form.
A classe ConsultasForm.java é demonstrada na Figura 50.
98
Figura 50 - Código-Fonte de implementação da classe ConsultasForm.java.
O fluxo de execução é o seguinte: o Controller é responsável por receber as requisições do
browser e invocar os objetos de negócio do Model para executar algum processo retornando
um resultado que servirá de base para que o Controller possa direcionar para o JSP que deverá
gerar a interface com o usuário.
A Action lê as configurações do arquivo struts-config.xml. Ao receber as solicitações do
usuário, chama o ActionForm correspondente à requisição, e de acordo com o resultado do
ActionForm, executa um JSP.
Parte do arquivo struts-config.xml contendo aspectos do relacionamento entre o Controller e a
View é descrita na Figura 51.
99
Figura 51 - Código-Fonte de implementação do arquivo struts-config.xml.
Com o uso do Struts pode-se evitar código referente à lógica de negócio no JSP, facilitando,
por exemplo, a manutenção da aplicação e o reuso de código a partir da criação de camadas.
Sua utilização permite que uma classe Model seja populada com os valores vindos da
interface, sem a necessidade de resgatar as propriedades individualmente e popular o objeto
com o método set.
100
4.3.3 Camada de dados
4.3.3.1 Banco de Dados
Como Sistema Gerenciador de Banco de Dados foi utilizado o Oracle 10g Express Edition
(Oracle XE). No esquema do banco de dados foram criados os segmentos de dados (tabelas)
apresentados na sessão 4.2.8.2 e as sequences.
Não foram criadas stored procedures e trigger, a maior parte da lógica de negócios está na
própria aplicação Java, dependendo pouco de funções específicas do banco de dados.
4.3.3.2 Hibernate
O framework Hibernate foi utilizado para realizar o mapeamento entre classes da aplicação
Java e tabelas do banco de dados.
Foi necessária a construção de uma camada extra para persistir os objetos no repositório, ou
seja, criou-se uma camada de persistência e o mapeamento foi implementado através de
arquivos XML.
Para realizar a integração com o banco de dados foi preciso criar a classe hibernate.cfg.xml e
informar no método property qual foi o banco de dados utilizado por meio do Hibernate
Dialect, o driver de conexão e a URL de conexão específica do banco de dados Oracle. Cada
uma dessas configurações foram armazenadas no SessionFactory, como é apresentado na
Figura 52.
101
Figura 52 - Código-Fonte da implementação da classe hibernate.cfg.xml referente à
conexão com banco de dados.
A segunda parte é a configuração de pool de conexões que basicamente mantém certo número
de conexões abertas para o banco de dados. Quando um usuário abre uma conexão usando
pool, ao invés de abrir uma nova conexão com o banco de dados por meio do driver JDBC,
uma das conexões que já estava aberta com o banco de dados é alocada para o usuário que
utiliza a conexão e realiza as operações desejadas. Ao encerrar a conexão esta fica aberta e
marcada como disponível. Essa configuração foi realizada como é descrito na Figura 53.
Figura 53 - Código-Fonte da classe hibernate.cfg.xml referente à
Configuração do pool de conexões.
Para realizar o mapeamento dos objetos da aplicação para o banco de dados foram criadas
classes com a extensão NomeMapeamento.hbm.xml, nos quais define-se as propriedades e os
relacionamentos de uma classe para o Hibernate.
102
A classe Emprestimos.hbm.xml é demonstrada na Figura 54. O elemento class descreve o
nome da classe que foi mapeada e para qual tabela do banco de dados. O elemento id denota o
atributo que deverá funcionar como chave primária e Generator guarda a informação de como
essas chaves são geradas. O gerador usado é uma sequence que foi criada no banco de dados.
Figura 54 - Código-Fonte da classe de mapeamento Emprestimos.hbm.xml.
Na Figura 55 e Figura 56, as tags <property> indicam propriedades dos objetos, os mais
importantes são os atributos name, que definem o nome da propriedade. O atributo column foi
utilizado porque a classe não possui o mesmo nome da coluna da tabela.
Figura 55 - Código-Fonte da classe de mapeamento Emprestimos.hbm.xml.
Figura 56 - Código-Fonte da classe de mapeamento Emprestimos.hbm.xml.
103
Para configurar e abrir as sessões do Hibernate foi necessário criar a classe HibernateUtil.java
na package Controller conforme demonstrado na Figura 57.
Figura 57 - Código-Fonte da classe HibernateUtil.java
O bloco estático instancia um objeto de configuração do Hibernate
(org.hibernate.cfg.Configuration), chama o método configure() que lê o arquivo
hibernate.cfg.xml e depois que está configurado, cria-se uma SessionFactory, que é a classe
responsável por abrir as sessões de trabalho do Hibernate e exemplo de implementação do
Padrão de Projeto Factory.
Este framework facilita o desenvolvimento de aplicações e evita a duplicação de código como
insert, select, update, delete no banco de dados. Permite maior reuso de código e maior
facilidade de manutenção.
4.3.3.3 DAO
Foi criada uma package, chamada DAO, que contém um conjunto de classes responsáveis
pela interface entre o componente que realiza a persistência (Hibernate) e o restante da
aplicação. Estas classes contêm métodos para persistir e recuperar dados, conforme é
apresentado na Figura 58.
104
Figura 58 - Código-Fonte da implementação da classe EmprestimoDao.java,
método listar().
As classes DAO gerenciam a conexão com o banco de dados para manipulação e
armazenamento dos dados. Toda implementação relacionada a instruções SQL está contida
nestas classes e não na lógica de negócio, isto isola a camada de dados facilitando a
manutenção.
O uso deste Padrão de Projeto auxilia a centralizar a persistência de objetos em um pequeno
conjunto de classes, evitando, por exemplo, que o código SQL se espalhe pelo código da
aplicação.
4.3.3.4 Singleton
Este Padrão de Projeto foi utilizado para que uma classe seja instanciada apenas uma vez.
Como exemplo, é apresentado na Figura 59 o método getSession() da classe de conexão
HibernateUtil.java.
105
public static Session getSession() {
return factory.openSession();
}
Figura 59 - Parte do Código-Fonte de implementação da classe HibernateUtil.java.
Este método é chamado na classe ItensDao.java da package DAO e não necessita ser
instanciado como mostra a Figura 60.
Figura 60 - Parte do Código-Fonte de implementação da classe ItensDao.java.
Sem o uso deste Padrão de Projeto toda vez que for necessário o uso do método getSession(),
a classe HibernateUtil.java precisaria ser instanciada.
Neste capítulo foram apresentados os documentos gerados na fase
de especificação de requisitos da aplicação e considerações sobre
a implementação do protótipo. No capítulo posterior serão
descritas as contribuições, experiências vivenciadas durante a
execução do trabalho e sugestões de trabalhos futuros.
106
5 CONSIDERAÇÕES FINAIS
Este capítulo tem como objetivo apresentar algumas considerações a
respeito do trabalho desenvolvido, contribuições e experiências. Está
subdividido em sessões que abordam contribuições, experiências,
publicações e sugestões de trabalhos futuros.
5.1 Contribuições
As contribuições deste trabalho são:
a) protótipo de uma aplicação Web que permite o controle automatizado da
biblioteca atendendo os principais requisitos dos usuários;
b) protótipo desenvolvido seguindo o paradigma da orientação a objeto;
c) protótipo utilizando a linguagem de programação Java que permite a
integração com a tecnologia RFID;
d) protótipo implementado empregando frameworks que apóiam o
desenvolvimento de uma aplicação Web;
e) protótipo implementado que adota Padrões de Projeto que possibilitam a
criação de um projeto orientado a objeto reutilizável e flexível;
f) protótipo da aplicação Web que propicia à biblioteca confiabilidade no
armazenamento de dados, agiliza o atendimento ao usuário e a realização de
inventários;
A partir destas contribuições, conclui-se que:
a) a tecnologia RFID deve ser considerada na gestão eletrônica de acervos,
tendo em vista às vantagens que oferece;
b) o paradigma de orientação a objeto propicia maior facilidade para
reutilização de código;
c) a linguagem de programação Java oferece robustez ao sistema e permite a
utilização das metodologias mais modernas para o desenvolvimento de
software;
107
d) o uso dos frameworks, associados aos padrões de projeto, ajudam a reduzir a
quantidade de código produzido e a aumentar a produtividade final na criação
do software;
e) os frameworks utilizados permitem maior facilidade no desenvolvimento e
manutenção do software;
f) a utilização de Padrões de Projeto possibilita o desenvolvimento de um
software flexível e agiliza o desenvolvimento;
g) a abordagem da modelagem em camadas mantém os componentes
separados e isso minimiza o acoplamento entre eles simplificando, por
exemplo, a evolução do software;
A seguir são apresentadas algumas experiências obtidas durante a realização do Trabalho:
a) Na tela de busca de itens foi criada uma tabela para exibir os resultados.
Para permitir ao usuário ordenar os resultados por determinada coluna sem a
necessidade de recarregar a página foi utilizado um plugin para a biblioteca
JQuery, o Tablesorter.
b) Para implementar as funcionalidades AJAX, foi necessário escolher uma
forma para transmitir os dados do servidor para a interface Web. Para resolver
esse problema foi usado o formato JavaScript Object Notation - Notação de
Objetos JavaScript (JSON). Esse formato foi escolhido por ser leve e mais fácil
que o XML.
5.1.1 Publicações
Um artigo foi publicado no Boletim Técnico da FATEC-SP (ISSN 1518-9082) conforme
Apêndice B.
5.2 Trabalhos futuros
Para trabalhos futuros, sugere-se:
108
a) complementação do protótipo desenvolvido por meio da implementação dos
casos de usos descritos;
b) inclusão do caso de uso localização de itens no acervo;
c) integração do protótipo com o Middleware utilizando o Sun Java System
RFID;
d) tratamento de protocolos de segurança de informação.
Neste capítulo foram apresentadas as contribuições, experiências
vivenciadas durante a execução do trabalho e sugestões de
trabalhos futuros.
109
REFERÊNCIAS
BAUER, C.; KING, G. Hibernate in action. Greenwich: Manning Publications, 2005.
BIBEAULT, B.; KATZ, Y. JQuery in action. Greenwich: Manning Publications, 2008.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 2.ed. Rio de Janeiro:
Elsiever, 2005.
BROWN, D.; DAVIS, C.M.; STANLICK, S. Struts 2 in action. Greenwich: Manning
Publications, 2008.
CRANE, D.; PASCARELLO, E.; JAMES, D. Ajax in action. Greenwich: Manning
Publications, 2006.
GAMMA, E.; HELM, R.; JONHSON, R.; VLISSIDE, J. Padrões de Projeto: soluções
reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, 2005.
GARRETT, J.J. Ajax: A new approach to web applications. Disponível
em:<http://adaptivepath.com/publications/essays/archives/000385.php>. Acesso em: 15 jun.
2009.
GLOVER, B.; BHATT, H. Fundamentos de RFID. Rio de Janeiro: Alta Books, 2008.
GOSLING, J.; MCGILTON, H. The Java Language Environment. Disponível em: <http://
java. sun.com/docs/white/langenv/index.html>. Acesso em: 03 jun. 2009.
PINHEIRO, J.M.S. Identificação por Radiofreqüência: aplicações e vulnerabilidades da
tecnologia RFID. Cadernos UniFoa, Volta Redonda, ano 1, n.2, nov.2006. Disponível em:<
http://www.unifoa.edu.br/pesquisa/caderno/edicao/02/18.pdf>. Acesso em: 24 fev.2009.
SANTINI, A. G. RFID: Conceitos, aplicabilidades e impactos. Rio de Janeiro: Ciência
Moderna, 2008.
<http://www.java.sun.com/docs/books/tutorial/getStarted/intro/definition.html>. Acesso em:
01 jun.2009, 20:32h.
110
<http://www.rfidjournal.com/faq/16/49>. Acesso em: 25 fev.2009, 15:34h.
<http://www.oracle.com>. Acesso em: 12 jun.2009, 19:50h.
SOMMERVILLE, I. Engenharia de Software. 8.ed. São Paulo: Pearson, 2007.
SUN MICROSYSTEMS. Sun Java System RFID Software 3.0 Developer's guide.Disponível
em: <https://sun-rfid.dev.java.net/files/documents/4596/29647/Developers_819-4686.pdf>.
TEMPLE, A.; MELLO, R.F.; CALEGARI, D.F.; SCHIEZARO, M. Programação Web com
JSP, Servlets e J2EE. Disponível em: <http://www.inf.ufsc.br/~bosco/downloads/livro-jsp-
servlets-j2ee.pdf>. Acesso em: 02 jun. 2009.
VIEIRA, A.F.G. Tecnologia de identificação por radiofrequência: fundamentos e aplicações
em automação de bibliotecas. Revista Eletrônica de Biblioteconomia e Ciência da
Informação, Santa Catarina, n.24, dez. 2007. Disponível em <
http://www.periodicos.ufsc.br/index.php/eb/article/view/430/416>. Acesso em: 27 fev.2009.
WANT, R. The Magic of RFID. ACMQueue, v.2, n.7, out.2004. Disponível em:
<http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=216>. Acesso
em: 25 fev.2009.
WALLS, C. Spring in action. 2.ed. Greenwich: Manning Publications, 2008.
111
APÊNDICES
APÊNDICE A – Manual do usuário.
1. Tela Inicial
A tela inicial da aplicação possibilita a realização do Login para usuários ou administrador e,
de acordo com o perfil, a aplicação permitirá o acesso a diferentes funcionalidades.
O usuário ou administrador poderá acessar uma página contendo um Tutorial, uma página
Sobre com algumas informações da Biblioteca, ou uma página para Pesquisa de itens do
acervo.
112
2- Área do Usuário
Após realizar o Login o usuário poderá acessar as funcionalidades Pesquisa de itens do acervo
e Reservas.
113
Na tela de Pesquisa o usuário poderá realizar pesquisa por título da obra, nome do autor ou
ISBN.
Será exibida uma tela com o resultado da busca e que habilita a reserva.
114
Na tela de Reservas o usuário poderá visualizar informações sobre o item reservado.
115
3- Área do Administrador
Após realizar o Login o administrador poderá acessar as funcionalidades Pesquisa de itens do
acervo, Cadastro de Itens, Empréstimos e Devoluções.
116
Na tela Pesquisa o administrador poderá consultar se itens estão disponíveis.
117
Na tela de Cadastro de Itens o administrador poderá realizar o cadastro de itens do acervo.
118
Na tela de Empréstimos o administrador poderá efetivar empréstimos realizados pelos
usuários.
119
Na tela de Devolução o administrador poderá efetivar as devoluções.
Os demais casos de uso não foram implementados no protótipo.
120
APÊNDICE B – Artigo publicado no SICT.
PROPOSTA DE MODELAGEM DE UM SISTEMA PARA
BIBLIOTECA UTILIZANDO RFID E JAVA
Alessandra Arantes de Souza Camargo1, Douglas Almeida Brito1, Rogério Marinke1,2 1Faculdade de Tecnologia do Estado de São Paulo (FATEC), São José dos Campos, Brasil
2Instituto Nacional de Pesquisas Espaciais (INPE), São José dos Campos, Brasil
[email protected], [email protected]
1. Introdução
A Faculdade de Tecnologia (FATEC) de São José dos Campos não possui atualmente um software que permita o
controle automatizado de sua biblioteca. Todo o trabalho de
empréstimo e devolução é realizado manualmente, causando
demora no atendimento ao usuário. Com o crescente número de publicações e de usuários é necessário formas eficazes para
o gerenciamento do acervo, visando proporcionar agilidade no
atendimento e confiabilidade no armazenamento de dados.
A tecnologia de identificação por rádio-frequência (RFID) tem se apresentado como um grande avanço no controle de
informações e pode ser introduzida em bibliotecas com o
objetivo de proporcionar a gestão eletrônica dos acervos e a
implementação de novos serviços [1]. A presente pesquisa tem o objetivo de propor a
modelagem de uma aplicação Web para bibliotecas utilizando
a tecnologia RFID. Será adotado como estudo de caso a
biblioteca da Faculdade de Tecnologia (FATEC) de São José dos Campos. É utilizada a metodologia RUP que descreve
processos de engenharia de software, gerando documentos
segundo a notação Unified Modeling Language (UML) [2].
Para a implementação foi adotada a linguagem de programação Java devido à possibilidade de integração com a
tecnologia RFID, portabilidade e frameworks disponíveis para
apoio no desenvolvimento [3].
2. RFID
A RFID é uma tecnologia de identificação automática que
utiliza as ondas de rádio para capturar os dados contidos em um dispositivo eletrônico ou etiqueta RFID e transmite a um
leitor. As etiquetas RFID podem armazenar informações sobre
os objetos aos quais estão anexados e quando estes objetos
entram numa área de cobertura de um leitor RFID, essas informações são transmitidas para o leitor que é responsável
por enviá-las para um software que poderá utilizar esses
dados. Um sistema RFID também necessita de um middleware
que gerencia os dados vindos das etiquetas e os repassa para uma aplicação ou para uma base de dados [1].
3. Resultados
Como resultado da análise do problema foi definido uma
proposta para a arquitetura do sistema que está dividida em
três camadas: camada de apresentação, camada de aplicação e camada de dados. A camada de apresentação é responsável
pela interface com o usuário e comunicação com as outras
camadas da aplicação, requisita serviços ao servidor da
aplicação e apresenta os resultados. No desenvolvimento das páginas Web foi utilizado o JQuery, biblioteca JavaScript que
permite o uso do Ajax melhorando a usabilidade e a
interatividade. A camada de negócios trata a lógica da
aplicação. Nesta camada foram empregados os padrões de
Figura 1 – Arquitetura do sistema.
projeto Model-View-Controller (MVC) e Singleton que permitem a criação de um projeto orientado a objeto
reutilizável e flexível [4]. Foram usados os frameworks Struts
e Spring que facilitam o desenvolvimento de aplicações e
auxiliam a implementação do padrão de projeto MVC. Para persistência dos dados foi utilizado o framework Hibernate,
que facilita o mapeamento dos atributos entre uma base de
dados relacional e o modelo objeto de uma aplicação. O
servidor de aplicação escolhido foi o GlassFish, pois oferece desempenho, confiabilidade e também apresenta suporte às
novas especificações Java Enterprise Edition. A camada de
dados foi desenvolvida utilizando o software Oracle 10g
Express Edition. A ferramenta Sun Java System RFID foi utilizada na implementação do middleware.
4. Conclusões
A tecnologia RFID deve ser considerada na gestão
eletrônica de acervos, tendo em vista às vantagens que oferece. A metodologia RUP aliada às características da
linguagem Java e aos frameworks adotados neste trabalho,
permitiram um desenvolvimento ágil com software de boa
qualidade. Alguns testes funcionais ainda estão sendo realizados, posteriormente, o software estará pronto para
implantação.
5. Referências
[1]GLOVER, B.; BHATT, H. Fundamentos de RFID, Alta
Books, 2008.
[2] BOOCH, G; RUMBAUGH, J;JACOBSON, I: UML, Guia do Usuário; Rio de Janeiro, Campus, 2000.
[3] TEMPLE, A.; R. F., MELLO; CALEGARI, D.T.;
SCHIEZARO, M. Programação Web com JSP, Servlets e
J2EE,USP, 2004. [4] GAMMA, E.; HELM, R. ; JONHSON, R. ; VLISSIDE,
J. Padrões de Projeto: soluções reutilizáveis de software
orientado a objetos, Bookman, 2005.
121
