FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS ALESSANDRA ARANTES DE SOUZA CAMARGO DOUGLAS DE ALMEIDA BRITO

Transcrição

1 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

2 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

3 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

4 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.

5 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.

6 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.

7 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

8 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 Figura 53 - Código-Fonte da classe hibernate.cfg.xml referente à Configuração do pool de conexões Figura 54 - Código-Fonte da classe de mapeamento Emprestimos.hbm.xml Figura 55 - Código-Fonte da classe de mapeamento Emprestimos.hbm.xml Figura 56 - Código-Fonte da classe de mapeamento Emprestimos.hbm.xml Figura 57 - Código-Fonte da classe HibernateUtil.java Figura 58 - Código-Fonte da implementação da classe EmprestimoDao.java, método listar() Figura 59 - Parte do Código-Fonte de implementação da classe HibernateUtil.java Figura 60 - Parte do Código-Fonte de implementação da classe ItensDao...105

9 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

10 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

11 x SUMÁRIO 1 INTRODUÇÃO Motivação Objetivos Objetivo geral Objetivos específicos Metodologia Organização do trabalho RFID Breve histórico Aplicações da tecnologia RFID Aplicação da tecnologia RFID em bibliotecas Identificação por rádio-frequência (RFID) Componentes de um sistema RFID Etiquetas RFID Leitores Middleware Visão geral de uma implementação RFID RFID e códigos de barras FERRAMENTAS PARA DESENVOLVIMENTO DO SISTEMA Java Java EE Sun Java System RFID Servidor de Aplicação AJAX JQuery Padrões de Projeto MVC Singleton Frameworks Struts Framework Hibernate Oracle 10g Express Edition... 46

12 xi 4 MODELAGEM E DESENVOLVIMENTO DO SISTEMA Processo de software Especificação de Requisitos de Software Requisitos funcionais do sistema Requisitos não funcionais Diagrama de casos de uso Descrição dos casos de uso Arquitetura de sistema Diagrama de classes Diagramas de sequência Modelo de dados Projeto e implementação do protótipo Camada de visualização Camada de aplicação Camada de dados CONSIDERAÇÕES FINAIS Contribuições Publicações Trabalhos futuros REFERÊNCIAS APÊNDICES...111

13 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 autoatendimento 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

14 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 Objetivo geral tecnologias Java e RFID. Propor a modelagem de uma aplicação Web para biblioteca utilizando as Objetivos específicos a) Determinar cenários de uso na biblioteca da Fatec de São José dos Campos;

15 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

16 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.

17 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),

18 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

19 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.

20 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) 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:

21 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.

22 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 ( 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 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).

23 22 Figura 1 - Etiqueta padrão. Fonte: SANTINI, 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.

24 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).

25 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 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.

26 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 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, 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.

27 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 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, 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

28 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 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.

29 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 ( 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.

30 29 Tabela 1 - Principais diferenças entre RFID e códigos de barras. RFID Transmissão de dados por rádio freqüência. Não se aplica. CÓDIGO DE BARRAS Diversas etiquetas RFID podem ser lidas simultaneamente. A leitura das etiquetas RFID pode ser feita mesmo se estiverem dentro de diversos materiais como papel, madeira, plásticos, entre outros. As etiquetas precisam simplesmente estar no campo de ação da antena de detecção. Permite inserir ou alterar os dados que foram armazenados na etiqueta. Maior alcance de leitura das etiquetas. A leitura das etiquetas é sequencial. Durante a leitura as etiquetas com código de barras devem estar expostas sem nenhum obstáculo entre elas e o leitor. A etiqueta precisa estar alinhada ao campo de visão do leitor de código de barras. Não se aplica. Menor alcance de leitura das etiquetas. Fonte: VIEIRA, 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.

31 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

32 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, 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.

33 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.

34 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.

35 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.

36 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.

37 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

38 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;

39 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 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

40 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. Ações do usuário 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. Altera estados Seleciona a view 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. Notificação de mudanças 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. 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.

41 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

42 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 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).

43 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.

44 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.

45 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 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.

46 45 Figura 12 - Funcionamento do Hibernate. Fonte: BAUER & KING, 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.

47 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 ( 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.

48 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.

49 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).

50 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,

51 50 indicando que o objeto que está no primeiro estado irá passar para o segundo estado mediante a ocorrência de um determinado evento 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.

52 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 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.

53 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 Diagrama de casos de uso A Figura 13 contém os casos de usos determinados na fase de levantamento de requisitos. Consultar Itens System Usuário da biblioteca Reservar Itens Efetuar Devolução RFID Pesquisar Itens Cadastrar Segmentos Efetuar Empréstimo Cadastrar Usuários Atendente Administrador Cadastrar Itens Consultar Situação de Usuários Registrar Multas Cadastrar Atendentes Figura 13 - Diagrama de casos de uso.

54 Descrição dos casos de uso 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 Função COM-001 Consultar itens Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Usuário Descreve as etapas necessárias para que o usuário retire um item do acervo para consulta. Número de identificação do item, número de identificação do usuário. A leitora do RFID faz a leitura da tag acoplada no item e envia o número de identificação para o sistema. Nome do item retirado para consulta. O item fica indisponível para ser retirado por outro usuário. 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. 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. O atendente informa ao sistema o número de identificação do item. Validação do usuário e do item. O usuário precisa estar cadastrado, o item precisa estar disponível. Permite a retirada do item para consulta.

55 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 Função RES-001 Reservar itens Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Usuário Descreve as etapas necessárias para que o usuário faça a reserva do item desejado. Número de identificação do item, número de identificação do usuário. Cadastro de itens. Nome do item reservado. A solicitação de reserva fica armazenada. 1. O usuário não está cadastrado. 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. 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. Validação do usuário. O usuário deve estar cadastrado, o item precisa estar cadastrado. O item fica reservado.

56 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 Função PES-001 Pesquisar itens Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Atendente, Usuário Descreve as etapas necessárias para pesquisa sobre um determinado item. Número de identificação do item, nome do item, autor. Verificação dos itens cadastrados. Informações acerca do item selecionado. Auxilia na efetivação de uma solicitação de consulta ou empréstimo de um item ao usuário. 1. O item não está cadastrado. 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. Não há. Validação do item. O item deve estar cadastrado no sistema. O usuário informa se deseja realizar uma consulta ou um empréstimo.

57 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 Função DEV-001 Efetuar devolução Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Atendente, Usuário Descreve as etapas necessárias para que o sistema registre a devolução de um item entregue por um usuário. Número de identificação do item. 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. Confirmação da devolução. O item fica liberado para novo empréstimo. 1. Falha na leitura da tag. 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. O atendente registra manualmente no sistema a devolução do item que é liberado para novo empréstimo. Validação do item. O empréstimo precisa estar cadastrado. Libera o item para novo empréstimo.

58 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 Função EMP-001 Efetuar empréstimo Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Atendente, Usuário Descreve as etapas necessárias para que o sistema registre o empréstimo de um item a um usuário. Número de identificação do item, número de identificação do usuário. 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. Confirmação do empréstimo. O item fica indisponível para ser retirado por outro usuário. 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. 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. 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. Validação do item e do usuário. O usuário precisa estar cadastrado, o item precisa estar disponível. Permite empréstimo do item.

59 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 Função CSU-001 Consultar situação dos usuários Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Atendente 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. Número de identificação do usuário. Cadastro de usuários. Situação do usuário. Possibilita a realização de consulta ou empréstimo de item. 1. O usuário não está cadastrado. O atendente informa o número de identificação do usuário ao sistema. Não há. O usuário deve estar cadastrado. Cadastro do usuário. Informar o número de identificação do item e qual operação o usuário deseja realizar, consulta ou empréstimo.

60 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 Função MUL-001 Registrar multas Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Atendente Descreve as etapas necessárias para o atendente registrar multas referentes a um usuário. Número de identificação do usuário. Cadastro de usuários. Registro de multa. Situação do usuário. 1. Usuário não cadastrado. O atendente informa o número de identificação do usuário, o sistema armazena a informação nos dados do usuário. Não há. O usuário efetua a devolução após a data registrada para entrega do item. Ultrapassar a data registrada para entrega. O usuário fica bloqueado para solicitar consulta e empréstimo.

61 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 Função USU-001 Cadastrar usuários Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Administrador Descreve as etapas necessárias para cadastrar e alterar dados sobre um usuário. Dados do usuário. Informações fornecidas pelo usuário. Confirmação de cadastro do usuário. Cadastro do usuário. 1. Usuário já cadastrado. O administrador efetua login no sistema, realiza o cadastro do usuário. Não há. Ter perfil de administrador. Os dados devem ser inseridos pelo administrador. Habilita o usuário a realizar empréstimo e consulta de itens do acervo.

62 Cadastrar atendentes A Tabela 10 apresenta uma descrição do caso de uso cadastrar atendentes. ID do caso de uso Função Tabela 10 - Descrição de Caso de Uso (Cadastrar atendentes). ATE-001 Cadastrar atendentes Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Administrador Descreve as etapas necessárias para cadastro, alteração e exclusão de dados de um atendente. Dados do atendente. Informações fornecidas pelo atendente. Confirmação de cadastro do atendente. Cadastro do atendente. 1. Atendente já cadastrado. O administrador efetua login no sistema, realiza o cadastro do atendente. Não há. Ter perfil de administrador. Os dados devem ser inseridos pelo administrador. Habilita o atendente a efetuar empréstimos, consultas de itens do acervo, realizar pesquisa de itens, consultar situação dos usuários.

63 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 Função ITE-001 Cadastrar itens Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Administrador Descreve as etapas necessárias para o cadastro de itens do acervo. Dados do item. Informações fornecidas pelo administrador. Confirmação de cadastro do item. Cadastro de itens. 1. Item já cadastrado. O administrador efetua login no sistema, realiza o cadastro do item. Não há. Ter perfil de administrador. Os dados devem ser inseridos pelo administrador. Habilita o item para empréstimos e consultas.

64 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 Função SEG-001 Cadastrar segmentos Ator Descrição Entradas Origem Saídas Destino Exceções Curso Normal Curso Alternativo Requer Precondição Pós-condição Administrador Descreve as etapas necessárias para o cadastro de segmentos dos itens do acervo. Descrição do segmento. Informações fornecidas pelo administrador. Confirmação de cadastro do segmento. Cadastro de segmentos. 1. Segmento já cadastrado. O administrador efetua login no sistema, realiza o cadastro do segmento. Não há. Ter perfil de administrador. Os dados devem ser inseridos pelo administrador. Habilita uso do segmento.

65 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.

66 65 Middleware RFID Event Manager RFID Information Server View Controller Model BROWSER 1: requisição ActionServlets Action ActionForm 5: Resposta 3: seleciona a view 2: chama a instância LÓGICA DE NEGÓCIO JSP/HTML JSP/HTML 4: retorna os dados para visualização Camada de Apresentação Camada de Aplicação DAO BANCO DE DADOS Camada de Dados Figura 14 - Arquitetura do sistema.

67 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 * 1 Usuários Administrador 1 * Itens_Reservas 1 1 * Consultas * 1 Atendentes 1 1 * Multas * 1 Itens 1 * 1 * Itens_Consultas * * Empréstimos * * 1 * 1 Tipos 1 Segmentos * Itens_Emprestimos Figura 15 - Visão Geral do Diagrama de Classes da Aplicação Web.

68 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).

69 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).

70 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).

71 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).

72 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).

73 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).

74 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).

75 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).

76 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).

77 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).

78 Diagramas de sequência 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() 7 : Exibir resultados() 6 : Carregar resultados() 5 : Retornar dados() 8 : Resultados não encontrados() 9 : Selecionar item desejado() 10 : Envio de dados() 11 : Persistir dados() 12 : Grava() 15 : Reserva efetuada com sucesso() 14 : Retornar confirmação() 13 : Retorna dados() 16 : Reserva não pode ser efetuada() Figura 26 - Diagrama de Sequência (Reserva).

79 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() 7 : Exibir resultados() 6 : Carregar resultados() 5 : Retornar resultados() 8 : Resultados não encontrados() 9 : Selecionar item desejado() 10 : Envio de dados() 11 : Persistir dados() 12 : Gravar() 15 : Empréstimo efetuado com sucesso() 14 : Retorna confirmação() 13 : Retorna dados() 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).

80 Devolução Figura 29 - Diagrama de Sequência (Devolução). Figura 30 - Diagrama de Sequência (Devolução - RFID).

81 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() 7 : Exibir resultados() 6 : Carregar resultados() 5 : Retornar dados() 8 : Resultados não encontrados() 9 : Selecionar item desejado() 10 : Envio de dados() 11 : Persistir dados() 12 : Grava() 15 : Consulta efetuada com sucesso() 14 : Retornar confirmação() 13 : Retorna dados() 16 : Consulta não pode ser efetuada() Figura 31 - Diagrama de Sequência (Consulta). Figura 32 - Diagrama de Sequência (Consulta - RFID).

82 Pesquisar itens Figura 33 - Diagrama de Sequência (Pesquisar Itens).

83 Consultar situação do usuário Figura 34 - Diagrama de Sequência (Consultar situação do usuário).

84 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() 7 : Exibir resultados() 6 : Carregar resultados() 5 : Retornar dados() 8 : Resultados não encontrados() 9 : Selecionar usuário() 10 : Envio de dados() 11 : Persistir dados() 12 : Grava() 15 : Multa registrada com sucesso() 14 : Retornar confirmação() 13 : Retorna dados() 16 : Multa não pode ser registrada() Figura 35 - Diagrama de Sequência (Registrar Multa).

85 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() 7 : Exibir confirmação() 6 : Carregar resultados() 5 : Retornar dados() 8 : Cadastro não pode ser efetuado() Figura 36 - Diagrama de Sequência (Cadastros).

86 Modelo de dados 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 Figura 37 - Visão Geral do Modelo Relacional do Banco de Dados.

87 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.

88 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 ITE_TIP_ID INTEGER NN UNSIGNED Tipo do item ITE_SEG_ID INTEGER NN UNSIGNED ITE_ISBN VARCHAR Número de identificação do item Identificação do segmento do item 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 AI SEGMENTOS ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc SEG_ID INTEGER PK NN UNSIGNED Número de identificação do Segmento SEG_NOME VARCHAR Nome do Segmento SEG_DESCRICAO VARCHAR IndexName IndexType Columns PRIMARY PRIMARY SEG_ID Descrição do Segmento AI TIPOS ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc TIP_ID INTEGER PK NN UNSIGNED Número de identificação do tipo TIP_NOME VARCHAR Nome do tipo IndexName IndexType Columns PRIMARY PRIMARY TIP_ID Figura 38 - Dicionário de Dados (Acervo). AI

89 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 CON_USU_ID INTEGER NN UNSIGNED Número de identificação da consulta CON_ATE_ID INTEGER NN UNSIGNED Atendente responsável CON_DATA CON_HORA DATE VARCHAR AI 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 ITC_ITE_ID INTEGER NN UNSIGNED ITC_CON_ID INTEGER NN UNSIGNED Número de identificação do registro Número de identificação do item da consulta Número de identificação da consulta AI 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).

90 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 EMP_USU_ID INTEGER NN UNSIGNED EMP_ATE_ID INTEGER UNSIGNED Número de identificação do empréstimo 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 AI MULTAS ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc MUL_ID INTEGER PK NN UNSIGNED MUL_EMP_ID INTEGER NN UNSIGNED MUL_ATE_ID INTEGER NN UNSIGNED Número de identificação da multa 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 AI ITENS_EMPRESTIMOS ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc IEM_ID INTEGER PK NN UNSIGNED IEM_EMP_ID INTEGER NN UNSIGNED IEM_ITE_ID INTEGER NN UNSIGNED IndexName IndexType Columns PRIMARY PRIMARY IEM_ID ITENS_EMPRESTIMOS_FKIndex2 Index IEM_ITE_ID ITENS_EMPRESTIMOS_FKIndex2 Index IEM_EMP_ID Número de identificação do registro Número de identificação do item AI Figura 40 - Dicionário de Dados (Empréstimo).

91 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 USU_NOME VARCHAR Nome completo do Aluno USU_STATUS VARCHAR Situação do Aluno USU_LOGIN USU_SENHA VARCHAR VARCHAR AI 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 ATE_NOME VARCHAR Nome do Atendente ATE_LOGIN ATE_SENHA VARCHAR VARCHAR IndexName IndexType Columns PRIMARY PRIMARY ATE_ID AI Figura 41 - Dicionário de Dados (Login).

92 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 RES_USU_ID INTEGER NN UNSIGNED RES_DATA_RESERVA DATE RES_VALIDADE DATE RES_STATUS VARCHAR Número de Identificação da reserva Data da reserva AI 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 ITR_ITE_ID INTEGER NN UNSIGNED ITR_RES_ID INTEGER NN UNSIGNED Número de Identificação do registro Número de Identificação do itens da reserva Número de Identificação da reserva AI 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).

93 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 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.

94 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.

95 Figura 46 - Código-fonte de implementação usando o plugin Tablesorter. 94

96 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.

97 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 Camada de aplicação 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

98 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.

99 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.

100 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.

101 Camada de dados 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 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 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.

102 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.

103 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.

104 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 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.

105 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 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.

106 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.

107 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;

108 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 Publicações Um artigo foi publicado no Boletim Técnico da FATEC-SP (ISSN ) conforme Apêndice B. 5.2 Trabalhos futuros Para trabalhos futuros, sugere-se:

109 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.

110 109 REFERÊNCIAS BAUER, C.; KING, G. Hibernate in action. Greenwich: Manning Publications, BIBEAULT, B.; KATZ, Y. JQuery in action. Greenwich: Manning Publications, BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 2.ed. Rio de Janeiro: Elsiever, BROWN, D.; DAVIS, C.M.; STANLICK, S. Struts 2 in action. Greenwich: Manning Publications, CRANE, D.; PASCARELLO, E.; JAMES, D. Ajax in action. Greenwich: Manning Publications, GAMMA, E.; HELM, R.; JONHSON, R.; VLISSIDE, J. Padrões de Projeto: soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, GARRETT, J.J. Ajax: A new approach to web applications. Disponível em:< Acesso em: 15 jun GLOVER, B.; BHATT, H. Fundamentos de RFID. Rio de Janeiro: Alta Books, GOSLING, J.; MCGILTON, H. The Java Language Environment. Disponível em: < java. sun.com/docs/white/langenv/index.html>. Acesso em: 03 jun 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 Disponível em:< Acesso em: 24 fev SANTINI, A. G. RFID: Conceitos, aplicabilidades e impactos. Rio de Janeiro: Ciência Moderna, < Acesso em: 01 jun.2009, 20:32h.

111 110 < Acesso em: 25 fev.2009, 15:34h. < Acesso em: 12 jun.2009, 19:50h. SOMMERVILLE, I. Engenharia de Software. 8.ed. São Paulo: Pearson, SUN MICROSYSTEMS. Sun Java System RFID Software 3.0 Developer's guide.disponível em: < TEMPLE, A.; MELLO, R.F.; CALEGARI, D.F.; SCHIEZARO, M. Programação Web com JSP, Servlets e J2EE. Disponível em: < Acesso em: 02 jun 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 Disponível em < Acesso em: 27 fev WANT, R. The Magic of RFID. ACMQueue, v.2, n.7, out Disponível em: < Acesso em: 25 fev WALLS, C. Spring in action. 2.ed. Greenwich: Manning Publications, 2008.

112 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.

113 Área do Usuário Após realizar o Login o usuário poderá acessar as funcionalidades Pesquisa de itens do acervo e Reservas.

114 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.

115 Na tela de Reservas o usuário poderá visualizar informações sobre o item reservado. 114

116 Á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.

117 Na tela Pesquisa o administrador poderá consultar se itens estão disponíveis. 116

118 Na tela de Cadastro de Itens o administrador poderá realizar o cadastro de itens do acervo. 117

119 Na tela de Empréstimos o administrador poderá efetivar empréstimos realizados pelos usuários. 118