Sistema De Gerenciamento Bibliotecário (sigeb)

Transcript

54 CDDVD está referenciando uma classe do sistema, a classe de Audiovisuais. ID é um atributo de banco de dados usado para identificar cadastros. SQL é abordado como Linguagem de consulta estruturada, tradução para Structured Query Language. DAO é um padrão usado para persistência de dados com o objetivo de delimitar as regras de negócios do sistema em si das regras de acesso ao banco de dados. CRUD é apontado como Create, Read, Update e Delete, ambos para designar as funções básicas do banco de dados relacional. INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE – CAMPUS JOÃO CÂMARA. EMILSON MARINHO SILVA JÚNIOR JACKELINE CLEMENTINO DA SILVA SISTEMA DE GERENCIAMENTO BIBLIOTECÁRIO (SIGEB) JOÃO CÂMARA-RN 2012 EMILSON MARINHO SILVA JÚNIOR JACKELINE CLEMENTINO DA SILVA SISTEMA DE GERENCIAMENTO BIBLIOTECÁRIO (SIGEB) Relatório apresentado ao Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte - Câmpus João Câmara, como requisito parcial para conclusão do Curso Técnico Subsequente em Informática, conforme regulamento da Instituição. Professor Orientador: MSc. João Maria Araújo do Nascimento. JOÃO CÂMARA-RN 2012 EMILSON MARINHO SILVA JÚNIOR JACKELINE CLEMENTINO DA SILVA SISTEMA DE GERENCIAMENTO BIBLIOTECÁRIO (SIGEB) Relatório apresentado ao Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte - Campus João Câmara, como requisito parcial para conclusão do Curso Técnico Subsequente em Informática, conforme regulamento da Instituição. Aprovado em: ___/___/___. BANCA EXAMINADORA _____________________________________ MSc. João Maria Araújo do Nascimento – Orientador Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte. _____________________________________ MSc. Fábio Augusto Procópio de Paiva Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte. _____________________________________ Edmilson Barbalho Campos Neto Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte. "O valor de todo o conhecimento está no seu vínculo com as nossas necessidades, aspirações e ações; de outra forma, o conhecimento torna-se um simples lastro de memória, capaz apenas - como um navio que navega com demasiado peso - de diminuir a oscilação da vida quotidiana." (V. O. Kliutchevski, s.n) RESUMO O presente relatório aborda sobre o desenvolvimento de um sistema em Java para o gerenciamento bibliotecário em desktop, isto é, um software que realiza suas funcionalidades no computador sem a necessidade de internet. O projeto foi denominado como SIGEB (Sistema de Gerenciamento Bibliotecário). Para que o sistema fosse desenvolvido com base nas funcionalidades de uma determinada biblioteca, o projeto foi implementado a partir da Biblioteca Professora Maria das Vitórias Silva Vilar estabelecida na Escola Estadual Francisco de Assis Bittencourt, escola da rede pública de ensino, situada na cidade de João Câmara no estado do Rio Grande do Norte (RN). O propósito do desenvolvimento do sistema nessa biblioteca foi planejado para atender as suas reais necessidades que são os processos de cadastros de obras, empréstimos, reservas e devoluções, assim como, o cadastro de alunos, funcionários e das pessoas que não estão vinculadas à escola, mas têm acesso à biblioteca, pois esta é aberta à comunidade. O projeto também foi realizado para proporcionar um progresso no controle do acervo, assim como, viabilizar a automatização, segurança, a manutenção de registro e agilidade nas atividades rotineiras. O sistema foi desenvolvido na linguagem de programação Java, utilizando o framework Hibernate para mapear as classes do sistema para o banco de dados, neste caso, o SQL Server 2008. O Hibernate foi usado para reduzir o tempo de desenvolvimento relacionado à persistência de dados e abstrair os códigos SQL da aplicação, pois o framework Hibernate é capaz de transformar as tabelas do banco de dados em objetos Java ou vice-versa e guardar os códigos SQL no pacote de annotations. Quanto ao ambiente de desenvolvimento para a implementação do sistema, foi utilizado o NetBeans IDE 7.0, o qual serviu tanto para desenvolver os códigos, quanto para o desenvolvimento da interface gráfica. Após finalizar o projeto, foi possível abrir os horizontes quanto ao desenvolvimento de softwares que se trata de uma área tão intensa e profunda, com muitos recursos e ferramentas com o objetivo de auxiliar o desenvolvedor. Palavras-chave: Linguagem Java. Sistema Bibliotecário. Hibernate. RESUMEN Este informe se centra en el desarrollo de un sistema en Java para la gestión bibliotecaria para el software de desktop, es decir, que desempeña sus funciones en su computadora sin internet. El proyecto se denomina como SIGEB (Sistema de Gerenciamento Bibliotecário). Para que el sistema fue desarrollado en base a las características de una biblioteca particular, el proyecto se llevó a cabo en la Biblioteca Professora Maria das Vitórias Silva Vilar establecido en la Escola Estadual Francisco de Assis Bittencourt, la educación pública, en la ciudad de João Câmara en el estado de Rio Grande do Norte (RN). El objetivo del desarrollo de este sistema de bibliotecas fue diseñado para satisfacer las necesidades reales de los procesos que son registros de obras, préstamos, reservas y devoluciones, así como el registro de los estudiantes, de los funcionarios y las personas que no están vinculados a la escuela pero tiene acceso a la biblioteca, pues es abierto a la comunidad. El proyecto se llevó a cabo también para proporcionar un avance en el control del acervo, así como permitir la automatización, la seguridad, el mantenimiento de registros y la agilidad en las actividades de rutina. El sistema fue desarrollado en lenguaje de programación Java, utilizando el framework Hibernate para mapear clases a la base de datos del sistema, en este caso, SQL Server 2008. O Hibernate se utiliza para reducir el tiempo de desarrollo relacionados con la persistencia de los datos y la abstracción del código SQL de la aplicación, ya que el framework Hibernate es capaz de convertir las tablas de la base de datos en objetos Java o al contrario y guardar los códigos SQL en paquete del anotaciones. En cuanto al entorno de desarrollo para la aplicación del sistema, se utilizó el NetBeans IDE 7,0, que sirve tanto para desarrollar los códigos, cómo desarrollar lo design del sistema. Después de finalizar el proyecto, era posible abrir los horizontes para el desarrollo de software que se trata de un área tan profunda e intensa, con muchas características y herramientas para ayudar a los desarrolladores. Palabras clave: Lenguaje Java. Sistema Bibliotecario. Hibernate. LISTA DE ILUSTRAÇÕES Figura 1 - Cronograma de execução das atividades 12 Figura 2 - Principais casos de uso 15 Figura 3 - Generalização (Herança) entre as classes 16 Figura 4 - Classes do sistema relativas ao acervo 17 Figura 5 - Classes representativas das finalidades principais do sistema 17 Figura 6 - Diagrama de Entidade e Relacionamento 19 Figura 7 - Arquitetura de alto nível do Hibernate 21 Figura 8 - Arquitetura compreensiva do Hibernate 21 Figura 9 - Arquitetura do Projeto 23 Figura 10 - Arquitetura do modelo padrão usado no projeto 24 Figura 11 - Exemplo de classe Java com annotations: Funcionário 25 Figura 12 - Relacionamento muitos para muitos (M:N) entre Obra e Autor. 26 Figura 13 - Código-fonte para o relacionamento (M:N) entre Obra e Autor 27 Figura 14 - Código-fonte para o relacionamento (M:N) entre Autor e Obra 27 Figura 15 - Código-fonte da classe que contém as chaves primárias das tabelas 28 Figura 16 - Código-fonte da classe designada como PK 28 Figura 17 – Relacionamento um para muitos (1:N) 29 Figura 18 – Código-fonte do relacionamento uma para muitos 29 Figura 19 – Relacionamento de muitos para um (N:1) 30 Figura 20 – Código-fonte do relacionamento muitos para um na classe Reserva 30 Figura 21 - Código-fonte mostrando o annotation de herança para a superclasse 31 Figura 22 - Código-fonte mostrando o annotation de herança para a subclasse 32 Figura 23 - Código-fonte mostrando os annotations de herança para a subclasse 33 LISTA DE ABREVIATURAS E SIGLAS API Application Programing Interface CRUD Create, Read, Update, Delete DAO Data Access Object IDE Integrated Development Environment JDBC Java Database Connectivity SGBD Sistema Gerenciador de Banco de Dados SQL Structured Query Language UML Unified Modeling Language XML Extensible Markup Language SUMÁRIO 1 INTRODUÇÃO 10 2 CARACTERIZAÇÃO DO CAMPO EMPÍRICO 12 3 PROCEDIMENTOS METODOLÓGICOS 13 4 CRONOGRAMA DE ATIVIDADES 14 5 LEVANTAMENTO DE REQUISITOS 15 5.1 DIAGRAMA DE CASO DE USO 15 5.2 DIAGRAMA DE ClASSE 16 5.3 DIAGRAMA DE ENTIDADE E RELACIONAMENTO 19 6 FUNDAMENTAÇÃO TEÓRICA 21 6.1 HIBERNATE 21 7 PROJETO E IMPLEMENTAÇÃO 24 7.1 ARQUITETURA DO PROJETO 24 7.2 MAPEAMENTO DAS CLASSES DA APLICAÇÃO 25 7.3 RELACIONAMENTOS ENTRE OBJETOS USANDO HIBERNATE 27 7.3.1 Relacionamento muitos para muitos (m:n) 27 7.3.2 Relacionamento um para muitos (1:n) 30 7.3.3 Relacionamento muitos para um (n:1) 30 7.3.4 Herança 31 8 EXPECTATIVAS FUTURAS 35 9 CONCLUSÕES E RESULTADOS 36 REFERÊNCIAS 37 GLOSSÁRIO 38 APÊNDICE A – DIAGRAMA DE CASO DE USO 39 APÊNDICE B – DOCUMENTAÇÃO DO DIAGRAMA DE CASO DE USO 40 APÊNDICE C – DIAGRAMA DE CLASSE 50 APÊNDICE D – DIAGRAMA DE ENTIDADE E RELACIONAMENTO 51 APÊNDICE E – IMAGEMS DO CAMPO EMPÍRICO 52 ANEXO A – FICHA DE CADASTRO DE USUÁRIOS 53 ANEXO B – FICHA PARA REALIZAÇÃO DE EMPRÉSTIMOS 54 INTRODUÇÃO O projeto foi elaborado durante a prática profissional, no Curso Técnico de Informática Subsequente, no Instituto Federal de Educação, Ciência e Tecnologia do RN (IFRN), campus João Câmara. O documento apresentado tem como objetivo promover o desenvolvimento de um aplicativo em desktop destinado à Biblioteca Professora Maria das Vitórias Silva Vilar da Escola Estadual Francisco de Assis Bittencourt, situada no município de João Câmara no estado do Rio Grande do Norte (RN), que atende alunos do ensino médio no período matutino, vespertino e noturno. Visando um melhor controle do acervo e o bom atendimento aos usuários, assim como, viabilizar a automatização, segurança e agilidade nas atividades rotineiras. Além de atender as suas reais necessidades contemplando as suas diversas funcionalidades, também vai proporcionar a manutenção de registro de livros, assim como, o cadastro de alunos, funcionários da instituição e pessoas que dela não fazem parte, destacando-se os processos de empréstimo, reserva e devolução de obras cadastradas no sistema. A motivação para desenvolver um sistema para a biblioteca em questão foi proposto porque se observou a necessidade desta para efetuar suas funcionalidades básicas com maior segurança e agilidade, pois essas funções estavam sendo feitas de modo não seguro, principalmente para o acervo da biblioteca, porque não é feito cadastro e nem controle da quantidade de obras que a biblioteca possui e isto gera perdas de parte do acervo. O sistema de gerenciamento bibliotecário irá contribuir para a comunidade, os alunos e, principalmente, a escola. Para a escola, esta contribuição é retratada em três quesitos fundamentais: no acesso amplo, já que se trata de uma biblioteca aberta à comunidade, o acesso aumentará; na segurança, pois o acervo terá cadastro e controle de quantidade, assim como, os empréstimos serão efetuados de modo que os alunos terão punição se houver quebra na regra, pois atualmente a biblioteca não utiliza de maneira correta as punições por causa da falta de estrutura tecnológica, e, por fim, na melhoria do trabalho, ou seja, com o novo sistema os bibliotecários efetuarão as funcionalidades de maneira mais rápida por causa da agilidade que o sistema irá propor, e consequentemente extinguindo aquela monótona atividade de procurar fichas de cadastros e de empréstimos nas prateleiras de arquivos. Para a comunidade e os alunos da própria instituição, a contribuição que o sistema irá trazer é de segurança, porque para efetuar o empréstimo o aluno deve confirmar sua identidade, isso deve ser feito para que o percentual de falsificações seja diminuído. O desenvolvimento do sistema de gerenciamento bibliotecário para desktop foi feito usando a linguagem Java, framework Hibernate, por ser uma ferramenta que mantém o código limpo com relação aos códigos SQL e o banco de dados para a aplicação foi o SQL Server 2008. A plataforma de desenvolvimento utilizada foi NetBeans IDE 7.0.1. Quanto a sua estrutura, o relatório está organizado da seguinte forma: no capítulo 2 será apresentada a caracterização da biblioteca, foco do projeto. No capítulo 3 serão expostos os procedimentos metodológicos utilizados no desenvolvimento. No capítulo 4 será abordado o cronograma de atividades, demonstrando as atividades realizadas durante o processo de desenvolvimento e apresentando a ferramenta ClockingIT. No capítulo 5 será exposto o levantamento de requisitos apresentados na modelagem de diagramas que ilustram as funcionalidades do sistema. No capítulo 6 será discorrida a fundamentação teórica a qual faz alusão do que foi necessário estudar durante o desenvolvimento da prática profissional, neste caso, o framework Hibernate. No capítulo 7 será exposto o projeto em si, ou seja, como o sistema foi implementado, mostrando a arquitetura do projeto, abordando o modelo padrão seguido e o uso do Hibernate. No capítulo 8 serão abordados todos os trabalhos futuros que poderão ser inclusos no sistema, focando a contribuição que irá causar. No capítulo 9 serão expostas as conclusões gerais e específicas de todo o trabalho feito, falando o que foi aprendido, como e o que contribuímos ou o que acrescentamos para a escola. CARACTERIZAÇÃO DO CAMPO EMPÍRICO O desenvolvimento do sistema foi realizado tendo como campo de estudo a Biblioteca Professora Maria das Vitórias Silva Vilar edificada na Escola Estadual Francisco de Assis Bittencourt, situada no município de João Câmara/RN, atendendo desde então, alunos do ensino médio no período matutino, vespertino e noturno. A escola funciona atualmente com 15 salas de aula, sala da direção, secretaria acadêmica, sala de professores, sala de leitura, sala de vídeo, sala de informática, biblioteca, quadra de esportes, banheiros, cozinha, cantina e área livre (pátio). Em relação à biblioteca, foco do nosso trabalho, é aberta para a comunidade, ou seja, esta poderá frequentar a biblioteca normalmente e fazer suas pesquisas dentro do estabelecimento, podendo se cadastrar e realizar empréstimos. A biblioteca funciona em bom estado, ou seja, o ambiente é bem ventilado, bem decorado com notícias e informativos, atende a necessidade dos alunos e da comunidade em relação ao processo de ensino e aprendizagem. O espaço possui também equipamentos que auxiliam nas pesquisas dos alunos, tais como: computadores com acesso a internet. Também disponibiliza um acervo bastante variado, contendo: coleções, literatura, dicionários, enciclopédia, contos, poesias, obras regionais, entre outros. As obras são organizadas por seções. Seu funcionamento, em relação ao cadastro de usuários e o empréstimo de exemplares das obras são realizados manualmente com o preenchimento de uma ficha de cadastro, cada usuário cadastrado recebe uma carteirinha para poder realizar outros empréstimos. A renovação de cada exemplar só pode ser realizada uma vez, ou seja, o aluno tem um prazo de cinco dias para realizá-la, porém não há um controle eficaz. Em caso de perda ou roubo o mesmo terá que repor o exemplar com outro, mas como não há controle no cadastro das obras, dificilmente percebe-se a falta de algumas obras perdidas ou roubadas, sendo então, a maior dificuldade encontrada no funcionamento da biblioteca. PROCEDIMENTOS METODOLÓGICOS De acordo com a proposta desta prática profissional de desenvolver um sistema de gerenciamento bibliotecário, o trabalho estruturou-se em três fases: na primeira fase, foi realizada uma pesquisa bibliográfica focando na linguagem Java e no framework Hibernate, o levantamento de requisitos, a criação e a modelagem dos diagramas de caso de uso, de classe e de entidade e relacionamento para auxiliar na especificação do sistema. A segunda fase, cujo objetivo é programar e testar os códigos, foi realizada a construção da interface gráfica e a implementação dos códigos do sistema. E na terceira e última fase, foi desenvolvido a elaboração do relatório final da prática e a apresentação do sistema. A Unified Modeling Language (UML) contribuiu na construção e elaboração de diagramas para o desenvolvimento deste projeto, porque a "UML proporciona uma forma padrão para a preparação de planos de arquitetura de projetos de sistemas, incluindo os processos de negócios e funções do sistema" para Booch, Rumbaugh e Jacobson (2006). A partir deste conceito, foram modelados os Diagramas de Caso de Uso (DCU) e Diagrama de Classe (DC) com o objetivo de planejar e projetar como o sistema irá ser desenvolvido. Em relação à estrutura lógica do banco de dados foi elaborado o Diagrama de Entidade e Relacionamento (DER) com o objetivo de notificar como os dados serão armazenados de acordo com o conceito do mundo real. CRONOGRAMA DE ATIVIDADES Figura 1 - Cronograma de execução das atividades. As atividades realizadas durante o processo de desenvolvimento foram organizadas e planejadas dentro de um cronograma. Veja na figura 1 as atividades propostas: Figura 1 - Cronograma de execução das atividades. Durante a prática das atividades foi utilizado um recurso chamado ClockingIT como um auxílio para quebrar as atividades de alto nível em etapas. O ClockingIT é uma ferramenta de gerenciamento de projetos que permite um amplo controle das tarefas e metas a serem executadas em um tempo, o uso dessa ferramenta traz para a equipe organização e conhecimento das atividades que estão sendo realizadas, pois o Clocking IT notifica por e-mail todos os desenvolvedores cadastrados. Em suma, este recurso disponibiliza uma coordenação referente ao tempo de atividade realizada, estipulação de prazos para as metas, possui registro das atividades em logs e relatórios, há uma linha do tempo que busca todas as tarefas e metas e apresenta um gráfico que mostra o desempenho das tarefas executadas por cada desenvolvedor. LEVANTAMENTO DE REQUISITOS Levantamento de requisitos consiste em dominar a área específica que o software será desenvolvido e entender as necessidades do cliente, dessa forma é feita uma listagem das características e objetivos do sistema, por isso se torna importante para o desenvolvimento deste. Para fazer o levantamento das necessidades do cliente e entender o que o sistema vai automatizar, foi escolhida a técnica de entrevistas, pois se trata de uma técnica simples e mantém contato direto com o cliente o que possibilita uma maior compreensão do que ele precisa para seu sistema, diminuindo as chances de ser desenvolvido algo que não estava descrito nos requisitos. Na entrevista o cliente aponta quem são os usuários, quais as necessidades a serem solucionadas, em que ambiente funcionará o sistema, quais as funcionalidades que ele deseja e etc. Na análise de requisitos para o desenvolvimento do sistema em questão, as funcionalidades principais apontadas foram: cadastro de usuários, cadastro de obras, editoras, autores e seções, realização de empréstimos, reservas e devoluções das obras cadastradas, listar obras, usuários, reservas, empréstimos, entre outros. Usando a modelagem de diagramas, os requisitos funcionais do sistema foram modelados em diagramas de caso de uso, diagrama de classes e diagrama de entidade e relacionamento. DIAGRAMA DE CASO DE USO Primeiramente, será apresentado o diagrama de caso de uso, o qual apresenta os atores que fazem parte do sistema, além de suas ações que são ilustradas por elipses denominadas de casos de uso. Na figura 2 são mostrados os atores: aluno, usuário externo que abrange todos aqueles usuários que não fazem parte da instituição de ensino, ou seja, o público de fora; funcionário, e bibliotecário, sendo que este é o ator principal do sistema, pois realiza todas as ações. Analisando o diagrama, percebe-se que todos esses atores são generalização do ator usuário, esse relacionamento foi utilizado porque o caso de uso que mostra a ação, confirmar a senha de acesso, deve ser realizada por todos os usuários, pois ao solicitar um empréstimo todo usuário deve enviar uma senha para o sistema confirmando sua identidade. Os casos de uso principais mostrados aqui são: cadastro, atualização e exclusão de usuários, obras, editoras, autores e seções, realização de empréstimos, reservas e devolução, além destes também são mostrados os casos de uso de confirmar senha de acesso, efetuar login, alterar senha e o efetuar punição sendo este realizado pelo sistema: Figura 2 - Principais casos de uso. Figura 2 - Principais casos de uso. DIAGRAMA DE CLASSE Em sequencia, será apresentado o diagrama de classe com intuito de mostrar as entidades que compõe o sistema a ser desenvolvido, em nível de design, através da modelagem de classes. A figura 3, a seguir, mostra a generalização entre os usuários do sistema, ou seja, de acordo com o que é visto na figura, as classes Aluno, Usuário Externo, Funcionário e Bibliotecário recebem atributos e operações da classe Usuário, sendo assim um relacionamento de herança. Pode ser analisado também que a classe referente à Bibliotecário recebe o maior número de operações, pois esta classe demonstra que o bibliotecário é o usuário responsável por manusear todas as atividades do sistema. A única operação comum a todos é a de realizar a confirmação de acesso, esta operação é de confirmar a identidade do usuário no ato de realizar um empréstimo ou uma reserva. Figura 3 - Generalização (Herança) entre as classes. Figura 3 - Generalização (Herança) entre as classes. Na próxima figura, é mostrada a generalização dos tipos de obras, e as classes relacionadas ao acervo. Analisando a figura 4, é observado que há um relacionamento de muitos para muitos entre autor e obra, ou seja, uma obra tem vários autores e um autor tem várias obras. Também pode ser visto as associações entre a classe Obra e as classes: Editora, Seção, e Exemplar. Este relacionamento atribui que uma obra possui uma seção, uma editora, e vários exemplares. Considerando as multiplicidades do relacionamento de associação entre as classes citadas, é notado que uma seção e uma editora podem ter nenhuma ou muitas obras e a obra deve ter um exemplar ou um conjunto de exemplares. As classes que estão associadas à CDDVD, TrabalhosCientificos e Dicionário foram criadas para manter o maior nível de simplificação possível, então estas classes têm a função de demonstrar que o sistema possui controle no cadastro dos tipos relacionados a estes itens do acervo. Figura 4 - Classes do sistema relativas ao acervo. Figura 4 - Classes do sistema relativas ao acervo. Figura 5 - Classes representativas das finalidades principais do sistema.A seguir, as classes concernentes às funcionalidades do sistema podem ser vistas na figura 5: Figura 5 - Classes representativas das finalidades principais do sistema. Na figura 5, é visto que o usuário solicita empréstimos e reservas de um exemplar de uma obra específica, é notado também que não há relacionamento direto das funções básicas da biblioteca com a obra em si, ou seja, os empréstimos e reservas são realizados usando o exemplar da obra, sendo que cada obra está localizada em uma seção. Como o usuário pode realizar mais de um empréstimo e/ou reserva, a multiplicidade concernente às classes das funções básicas e a classe Exemplar é de muitos para muitos, isto é, um empréstimo pode ter vários exemplares e vice-versa. O mesmo ocorre com a reserva. DIAGRAMA DE ENTIDADE E RELACIONAMENTO Por fim, será apresentado o diagrama de entidade e relacionamento, similar ao diagrama de classe, porém há diferenças entre ambos: o diagrama de classe possui um alto nível de abstração e apresenta o comportamento das classes por meio de métodos. O diagrama de entidade e relacionamento é essencial para arquitetar quais as tabelas que o banco de dados irá suportar de acordo com o sistema que será implementado e ainda podem-se observar os relacionamentos entre as entidades que será o apoio para a criação das classes Java no sistema que será desenvolvido. Conforme podemos analisar (figura 6), há uma tabela Usuário que disponibiliza atributos para as tabelas Aluno, Usuário Externo, Bibliotecário e Funcionário, cada qual com suas características próprias e comuns, então ambas receberão o ID de Usuário, assim temos um relacionamento de um para um, a mesma forma se aplica a tabela Obra e as tabelas que mostram os tipos de obras, como Livro, Revista, Enciclopédia, Dicionário, Trabalho Científico e CDDVD. Podem-se observar também os relacionamentos entre as tabelas: Empréstimo e Exemplar; Reserva e Exemplar que possui multiplicidade de muitos para muitos, por exemplo, um empréstimo pode ter um ou mais exemplares, assim como a reserva, por isso a criação de uma tabela para cada relacionamento, esta tabela deve guardar as chaves primárias de cada tabela relacionada, isto vai refletir quando for feito o mapeamento objeto/relacional na aplicação com o banco de dados, pois em nível de sistema, denota que um empréstimo pode conter no mínimo um exemplar ou uma coleção de exemplares, do mesmo modo ocorre com a reserva. Temos também as tabelas: Obra e Autor, que possuem um relacionamento de muitos para muitos, e novamente é criada outra tabela entre elas para conter os Ids das tabelas em questão, também é visto os relacionamentos de um para muitos no caso das tabelas: Editora, Seção e Exemplar com seus respectivos Figura 6 - Diagrama de Entidade e Relacionamento.relacionamentos com a tabela Obra como podemos observar na figura a seguir: Figura 6 - Diagrama de Entidade e Relacionamento. As tabelas que estão relacionadas com as tabelas CDDVD, TrabalhoCientifico e Dicionário foram criadas para deixar o diagrama mais normalizado possível, ou seja, aumentar o nível de simplicidade para o controle do sistema, por exemplo, para cada trabalho científico há um tipo, o trabalho científico do tipo monografia, por exemplo. Para o caso de cadastro de CDDVD, existe a tabela que especifica o seu tipo, a qual vai mostrar que o item em questão pode ser um CD, DVD, Blu-ray, ou etc. FUNDAMENTAÇÃO TEÓRICA Para iniciar o desenvolvimento de um sistema é importante procurar ferramentas que auxiliem o trabalho de implementação, seguindo esta concepção foi utilizado o Hibernate como ferramenta para diminuir o uso de códigos de acesso ao banco de dados e os códigos Structured Query Language (SQL). HIBERNATE O Hibernate é um framework para mapeamento objeto/relacional para projetos Java, ou seja, transforma tabelas do banco de dados em objetos Java ou vice-versa, abstraindo o código SQL da aplicação. Além do mais, de acordo com Galhardo Fernandes e Ferreira Lima (2007, p.08), o Hibernate "também disponibiliza um poderoso mecanismo de consulta de dados, permitindo uma redução considerável no tempo de desenvolvimento da aplicação". Para utilizar o Hibernate, basta adicioná-lo no class path da aplicação, a plataforma de desenvolvimento NetBeans IDE 7.0.1, utilizada no desenvolvimento deste projeto, já possui o pacote de bibliotecas do Hibernate e seus recursos. Quando se trata de relacionamento entre os objetos da aplicação, este framework possui o Hibernate Annotations que facilita a vida do desenvolvedor, pois é a partir dos annotations que são feitos os relacionamentos entre as classes Java. Além disso, o Hibernate foi criado para que o número de arquivos necessários para o mapeamento dos objetos fosse reduzido, já que sem o pacote Annotations é necessário criar um arquivo de mapeamento para cada tabela da base de dados utilizada, e com Hibernate Annotations basta adicionar as anotações à classe Java. A figura 7, a seguir, mostra a arquitetura de alto nível do framework Hibernate, nela são apresentadas as camadas de aplicação, do Hibernate e a camada relativa ao banco de dados. Entre a camada de aplicação e do Hibernate há a camada com os objetos persistentes que abrange as classes DAO da aplicação. Analisando a estrutura, pode-se observar que a aplicação é conectada ao banco de dados por meio de arquivos de configuração designados na camada do Hibernate. Figura 7 - Arquitetura de alto nível do Hibernate. Figura 7 - Arquitetura de alto nível do Hibernate. Na próxima figura, é apresentada a arquitetura compreensiva, assim denominada porque é a abrangência de toda a interface de negócio e persistência, abstraindo a aplicação do JDBC e outras APIs adjacentes, assim o Hibernate executa o seu papel que é abstrair os códigos SQL: Figura 8 - Arquitetura compreensiva do Hibernate. Figura 8 - Arquitetura compreensiva do Hibernate. A camada de negócio está situada acima da camada de persistência, pois a sua responsabilidade é manter as regras e solicitações entre banco de dados e aplicação, ou seja, se comporta como cliente na camada de persistência. Porém, segundo Galhardo e Lima (2007, p.08), "vale salientar que algumas aplicações podem não ter a separação clara entre as camadas de negócio e de persistência". As principais interfaces são: Session, Session Factory, Transient Objects, Transaction, Transaction Factory, Persistent Objects e Connection Provider. A vantagem de utilizar o Hibernate está diretamente ligada ao percentual de redução de trabalho relacionado à persistência. Segundo a documentação do Hibernate, é mostrado que este diminui os códigos SQL e, principalmente, o trabalho em 95%, por causa de sua arquitetura objeto/relacional, porém não é vantajoso para aplicações que, na maior parte de desenvolvimento, fazem uso de regras de negócios diretamente no banco de dados e usa muitas stored procedures, triggers, e etc. PROJETO E IMPLEMENTAÇÃO ARQUITETURA DO PROJETO A figura 9, a seguir, mostra a arquitetura para o desenvolvimento do sistema de gerenciamento bibliotecário proposto a Biblioteca Prof.ª Maria das Vitórias Silva Vilar situada na Escola Estadual Francisco de Assis Bittencourt: Figura 9 - Arquitetura do Projeto. Figura 9 - Arquitetura do Projeto. A arquitetura do projeto mostra a camada de visão, a qual o usuário tem acesso; a camada de domínio, que contém todos os objetos relacionados de acordo com o banco de dados; a camada DAO, a qual faz referência à persistência da aplicação, e por fim, a camada do Hibernate. Com base em padrões de projeto, a arquitetura do sistema exibe um modelo padrão, o qual tem como objetivo separar a lógica da interface do usuário, permitindo desenvolver e testar separadamente cada parte. No desenvolvimento do projeto é seguido um modelo baseado no padrão de projeto chamado MVC: Model, View e Controller. Portanto, é descrito que o Model está relacionado com a camada de domínio, pois se trata do modelo da aplicação, o qual é solicitado quando o usuário escolhe um evento no sistema. O View é relativo à camada de visão que se trata da interface gráfica do usuário e o Controller descreve a camada de controle do sistema, sendo esta composta por métodos e eventos existentes na camada do Hibernate e na camada DAO. A figura a seguir ilustra como as camadas da arquitetura do projeto estão dispostas no modelo baseado do MVC: Figura 24 - Arquitetura do modelo padrão usado no projeto. Figura 24 - Arquitetura do modelo padrão usado no projeto. Analisando a arquitetura do projeto descrita na figura 10, em nível de relacionamento entre as camadas, é observado que o Hibernate separa a visão, que é a aplicação de interface do usuário, do banco de dados, abstraindo os códigos SQL e minimizando códigos repetitivos. A camada DAO tem função de cliente com relação à camada de visão, pois é ela que faz a conexão entre a aplicação e o Hibernate através dos annotations. Todos os métodos de inserir, excluir, atualizar compostos no CRUD e outros métodos da própria aplicação estão dentro da camada DAO. Isto é feito para que a camada de visão não fique sobrecarregada. MAPEAMENTO DAS CLASSES DA APLICAÇÃO Quando se trabalha com Hibernate é necessário fazer o mapeamento das classes, pois o banco de dados não reconhece dados orientados a objetos, portanto o mapeamento é importante para criar um identificador não natural para que a base de dados possa reconhecer os dados e criar os relacionamentos. Então, mapear significa relacionar cada tabela da base de dados a uma classe do projeto, isto é, buscar através da aplicação, as tabelas do banco de dados e transformá-las em classes Java. Há duas maneiras de fazer o mapeamento: via annotations ou XML, como foi descrito no capítulo 7, especificamente na figura 11 que mostra a arquitetura de alto nível do Hibernate, assim sendo, este possui dois arquivos para o mapeamento do banco de dados. Para o desenvolvimento deste projeto foi utilizado o Hibernate Annotations, pois é mais fácil e rápido de inserir o código e, sobretudo, não é preciso criar nenhum arquivo XML e nem qualquer outro arquivo. A figura abaixo mostra um exemplo de classe do projeto com mapeamento usando o annotations: Figura 11 - Exemplo de classe Java com annotations: Funcionário. Figura 11 - Exemplo de classe Java com annotations: Funcionário. Observando os annotations presentes na classe ilustrada na figura 11, descrevem-se as seguintes definições: @Entity: é o annotation que declara a classe como uma entidade persistente; @PrimaryKeyJoinColumn: nomeia qual coluna é a chave primária para a classe, neste caso, há uma herança entre a classe Usuário e Funcionário, por isso, no annotation está especificado o ID de Usuário, ou seja, funcionário herda atributos e operações de usuário; @Table: define qual a tabela do banco de dados que será mapeada, assim como define qual o banco de dados e o schema que essa tabela faz parte; @NamedQueries: são as queries SQL nomeadas para que não seja necessário usar códigos extensos de SQL dentro a aplicação; @Column: declara qual a coluna que será mapeada. RELACIONAMENTOS ENTRE OBJETOS USANDO HIBERNATE Os relacionamentos também são definidos como associações. Com o Hibernate-annotation é possível mapear todos os relacionamentos existentes entre as tabelas do banco de dados nas classes Java. Para tanto é usado os seguintes annotations para definir o tipo de associação: @ManyToMany, @OneToMany, @ManyToOne. Relacionamento muitos para muitos (m:n) Um relacionamento de muitos para muitos é definido com o annotation @ManyToMany. Para exemplificar este relacionamento, serão utilizadas duas classes da aplicação: a entidade Autor e Obra, pois no contexto do diagrama de entidade e relacionamento, a associação é de que uma obra possui um ou vários autores e vice-versa, sendo que é necessário o uso de outra classe para conter a chave primária de cada classe envolvida, desse modo: Figura 12 - Relacionamento muitos para muitos (M:N) entre Obra e Autor. Figura 12 - Relacionamento muitos para muitos (M:N) entre Obra e Autor. Observando o relacionamento, a entidade Obra possui uma coleção de autores e vice-versa. O código-fonte para este relacionamento na classe Obra é feito da seguinte forma: Figura 13 - Código-fonte para o relacionamento (M:N) entre Obra e Autor. Desde modo, pode ser observado que uma Obra possui uma coleção de autores e vice-versa. O código-fonte para este relacionamento na classe Obra é feito da seguinte forma: Figura 13 - Código-fonte para o relacionamento (M:N) entre Obra e Autor. Analisando o código-fonte, no annotation @ManyToMany é definido o tipo de busca por meio do fetch = FetchType.LAZY, que significa que quando for solicitado uma busca o conteúdo será trazido apenas uma vez. O @JoinTable indica qual a tabela conterá as colunas de identificação para o relacionamento, essas colunas são definidas por @JoinColumn. O annotation @Cascade mostra o tipo de comportamento que a classe deve assumir quando for executada uma inserção, atualização ou exclusão, o argumento utilizado foi o CascadeType.SAVE_UPDATE, informando que a ação para a classe com relação a outra será apenas salvar e atualizar. No final, é especificado que a classe recebe uma coleção de objeto do tipo Autor. Para a classe Autor, o código-fonte inserido foi o mesmo, só mudou a posição da definição do @JoinColumn, pois é importante analisar que primeiramente é definido a chave primária e depois a chave estrangeira. No annotation @JoinTable os atributos especificados são o nome da entidade que receberá as colunas especificadas no @JoinColumn e o atributo inverseJoinColumns, especificando qual a chave estrangeira. Observa-se também que é criada uma coleção para conter todos os objetos do tipo Obra: Figura 25 - Código-fonte para o relacionamento (M:N) entre Autor e Obra. Figura 25 - Código-fonte para o relacionamento (M:N) entre Autor e Obra. Figura 15 - Código-fonte da classe que contém as chaves primárias das tabelas. Na classe ObraAutor, criada por causa do relacionamento muitos para muitos, o código-fonte é: Figura 15 - Código-fonte da classe que contém as chaves primárias das tabelas. Neste caso, a chave composta na classe ObraAutor que é notificada pelo annotation @EmbeddedId. Essa chave composta faz referência a classe ObraAutorPK que é onde estarão guardadas as chaves primárias das duas classes em relacionamento, além disso é importante que esta classe seja implementada com a interface Serializable, pois indica a serialização das transações feitas na aplicação. A figura 16 ilustra como são passados os identificadores das duas classes em outra classe, pois o Hibernate não suporta chave composta: Figura 16 - Código-fonte da classe designada como PK. Figura 16 - Código-fonte da classe designada como PK. O annotation @Emdeddable significa que esta classe possui instâncias que são armazenadas como uma parte inseparável de uma entidade, ou seja, significa que a classe não persiste sozinha. Utiliza-se do annotation @ManyToOne para especificar um relacionamento de muitos para um, o que significa dizer que há muitas obras para um autor e vice-versa, é também usado o annotation @JoinColumn para informar qual a coluna referente a chave primária de cada classe, e por fim, o @Cascade com o atributo CascadeType.ALL, indicando que todas alterações serão refletidas na entidade relacionada no banco de dados. Relacionamento um para muitos (1:n) Um relacionamento de um para muitos é definido com o annotation @OneToMany. Para exemplificar este relacionamento, serão utilizadas duas classes da aplicação: a entidade TipoTrabalhoCientifico e TrabalhoCientifico, sendo que o relacionamento de um para muitos está na entidade TipoTrabalhoCientifico, ou seja, um tipo de trabalho científico possui muitos trabalhos científicos: Figura 17 - Relacionamento um para muitos (1:N). Figura 17 - Relacionamento um para muitos (1:N). O código-fonte do relacionamento na classe TipoTrabalhoCientifico é implementado da seguinte forma: Figura 18 - Código-fonte do relacionamento uma para muitos. Figura 18 - Código-fonte do relacionamento uma para muitos. Analisando o código-fonte, o annotation @OneToMany possui um atributo chamado mappedBy para indicar qual o campo que tem o relacionamento com a entidade TrabalhoCientifico. Pode-se analisar também que neste relacionamento é criada uma coleção que guardará todos os trabalhos científicos. Relacionamento muitos para um (n:1) Um relacionamento de muitos para um é definido com o annotation @ManyToOne. Para exemplificar este relacionamento, serão utilizadas duas classes da aplicação: a entidade Reserva e Usuário, sendo que o relacionamento de muitos para um está na entidade Reserva, ou seja, muitas reservas são feitas por um usuário: Figura 19 - Relacionamento de muitos para um (N:1). Figura 19 - Relacionamento de muitos para um (N:1). Figura 20 - Código-fonte do relacionamento muitos para um na classe Reserva. O código-fonte do relacionamento na classe Reserva é definido da seguinte maneira: Figura 20 - Código-fonte do relacionamento muitos para um na classe Reserva. Observando o código fonte do relacionamento de muitos para um, no annotation @ManyToOne há um atributo que especifica o tipo de busca por FetchType.EAGER, o que significa que sempre que for solicitado uma busca da classe em relacionamento, os dados desta serão trazidos, isto é, sempre que um usuário for listado, a reserva efetuada por este também será trazida. O @JoinColumn indica a coluna a qual faz parte do relacionamento, então a chave primária de Usuário será a chave estrangeira na classe Reserva. O annotation @Fetch especifica com o atributo FetchMode.JOIN, que a consulta de Reserva será feito por uma junção, ou seja, utiliza um Inner Join para carregar a coleção de usuários. Herança Se tratando de herança, o Hibernate utiliza de três maneiras: Tabela por classe concreta: cada classe concreta é mapeada para uma tabela diferente no banco de dados, sendo que em cada classe são definidas colunas para todos os atributos da classe, inclusive os atributos herdados; Tabela por hierarquia: a herança com este tipo mostra todas as classes mapeadas em uma única tabela; Tabela por subclasse: mapeia cada tabela, inclusive a classe mãe, para tabelas que herdam seus atributos. Nesta aplicação foi utilizada a herança de tabela por subclasse, onde são mapeadas, definindo a superclasse e as subclasses. Para definir a classe mãe se usa o annotation @Inheritance. Para exemplificar a herança, serão utilizadas duas classes da aplicação: a entidade Obra e Livro, onde Obra é definida como a superclasse e Livro, a subclasse. O código-fonte da classe Obra é mostrado na figura 21, nela, pode-se observar na linha grifada, que a herança é definida pelo atributo JOINED, o qual especifica que a entidade referida é a superclasse, a qual irá ceder atributos para as subclasses: Figura 21 - Código-fonte mostrando o annotation de herança para a superclasse. Figura 21 - Código-fonte mostrando o annotation de herança para a superclasse. Pode-se notar também o annotation @GeneratedValue, ele é responsável em determinar que o Id da classe será auto incremental, como na aplicação é usado banco de dados SQL Server 2008, o tipo de geração vai se definido por GenerationType.IDENTITY. É de grande importância saber que este annotation não deve ser inserido nas subclasses, pois estas herdam a chave primária da superclasse. O código-fonte da subclasse Livro é ilustrado na figura 22: Figura 22 - Código-fonte mostrando o annotation de herança para a subclasse. Figura 22 - Código-fonte mostrando o annotation de herança para a subclasse. Na linha grifada é mostrado o annotation @PrimaryKeyJoinColumn, definindo que a chave primária para a classe, neste caso, é o código da entidade Obra. Quando se é definido que uma classe herdará atributos de uma superclasse é importante que as subclasses tenham uma extensão para a superclasse e retirar os identificadores criados automaticamente no momento de mapear as tabelas do banco de dados, e no método toString deve-se referenciar a classe, buscando o código da superclasse. Veja a seguir o código-fonte completo da entidade Livro: Figura 23 - Código-fonte mostrando os annotations de herança para a subclasse. Figura 23 - Código-fonte mostrando os annotations de herança para a subclasse. Na subclasse permanecem apenas os atributos que são referentes à própria classe, por exemplo, nesta subclasse Aluno, conservam-se os atributos indicativos ao número do volume e do ISBN. Isso ocorre pelo fato de essas características serem apenas para esta subclasse, ou seja, não se encaixa em todas as subclasses que recebem herança da superclasse Obra, um exemplo encontrado é a subclasse Revista. EXPECTATIVAS FUTURAS As expectativas futuras aqui abordadas são relativas aos trabalhos futuros que serão acrescidos ao sistema de gerenciamento bibliotecário. Durante a prática profissional foi apenas desenvolvidos os objetivos relacionados às funcionalidades básicas do sistema, ou seja, controle de cadastro que abrange a inserção, atualização, exclusão e leitura de componentes, empréstimos, reservas e devoluções. Os componentes descritos são usuários, obras, seções, editoras, autores e categorias. Os trabalhos futuros para o sistema desktop se resumem a: Geração de relatórios PDF, caso seja necessário fazer levantamentos no sistema, como, por exemplo, uma lista de todos os usuários devedores; Geração de gráficos para mostrar o percentual de empréstimos, reservas e devoluções efetuadas por período mensal, anual ou semanal, onde o bibliotecário terá um controle maior das funcionalidades da biblioteca; Impressão de carteirinhas para certificar que o usuário já possui cadastrado na biblioteca, além disso, o usuário poderá inserir foto no ato do cadastro. A contribuição que estas modificações podem trazer para a biblioteca é mais segurança e controle. O sistema de gerenciamento bibliotecário também foi conceituado para ter suas funcionalidades Web. O sistema web disponibilizará aos usuários a realização de reservas e renovações online, facilitando e aumentando o acesso. Além disso, os usuários poderão ver todas as obras cadastradas no acervo da biblioteca, o que facilita no momento da necessidade de pesquisa de obra para reserva, por exemplo. Já que o usuário não tem acesso ao catálogo de obras do sistema desktop. A ideia de um desenvolvimento de uma aplicação Web é mantida, pois como a biblioteca está situada na escola, esta pode aproveitar o sistema online para fazer divulgações relacionadas à educação ou notícias referentes a própria escola, isso aumentará o número de usuários e, consequentemente o reconhecimento das atividades e trabalhos da escola. CONCLUSÕES E RESULTADOS Ter como campo de pesquisa a Biblioteca Professora Maria das Vitórias Silva Vilar, não só enriqueceu o nosso trabalho, como o tornou mais preciso e significativo, pois foi possível ter um embasamento mais forte frente a essa prática profissional. Pesquisar e estudar intensamente e acrescentar aos conhecimentos das práticas executadas em sala de aula aquilo que havíamos buscado com a visita ao campo empírico facilitaram um pouco no desenvolvimento do sistema que, de certa forma, auxiliaram na melhor compreensão do trabalho como um todo. Ao fim deste relatório compreendemos a real necessidade de modelar diagramas antes da implementação, pois será esta ferramenta que auxiliará na relação entre o cliente e o projeto. Também, a importância de um estudo mais profundo a respeito das ferramentas de trabalho, existe uma gama de frameworks, padrões de projetos e metodologias que, portanto, cabe a cada um aplicar um tipo ao seu projeto para obter um melhor desempenho. Vale salientar também, a seriedade que devemos ter quanto ao desenvolvimento, assim como um controle mais rígido através de metas de trabalho que devem ser alcançadas dentro de um prazo limite estabelecidas que nos ajudará no decorrer de todo o processo de desenvolvimento do sistema. Para conseguir um bom resultado no trabalho, o desempenho e a persistência no entendimento de alguns conteúdos, no nosso caso mais precisamente o uso do hibernate, foram essenciais, pois para se alcançar um resultado esperado é necessário e preciso um conhecimento aprofundado sobre o que e como executar uma prática de caráter profissional. A escola escolhida para a aplicação do sistema foi de suma importância, nela podermos não só realizar a implantação do sistema como também ajudar na melhoria e no acervo a biblioteca de maneira mais rápida e cômoda, e gerando uma maior segurança frente às obras disponíveis para empréstimos e reservas. Contudo, foi plausível, no primeiro momento, adquirir informações teóricas antes de realizar a implementação do sistema, conhecer mais a fundo outras ferramentas, recursos de trabalho, gerando uma maior precisão e eficácia na prática apresentada. Apesar de alguns prós e contras que ocorreram durante esse processo, o êxito foi alcançado, pois a ajuda do professor orientador foi de grande importância para o resultado final e nos fez abrir os olhos a esta área tão intensa e profunda que é o mundo da programação. REFERÊNCIAS Autores, V. Documentação do Hibernate 3. [s.d]. Disponível em GUJ - Guia de Usuários Java: . Acesso em: 1º de Fev. de 2012. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 2ª ed. Traduzido por F. Freitas da Silva; C. de Amorim Machado, Trads.) Rio de Janeiro: Elsevier, 2005. GALHARDO, Fernandes; R.; LIMA, G. A. Ferreira. Hibernate com Anotações. Natal, 2007. HORSTMANN, C. Padrões e Projetos Orientados a Objetos (2ª ed.). Traduzido por B. Copstein. Porto Alegre: Bookman, 2007. MACHADO, Felipe Nery Rodrigues; ABREU, Maurício P. de Projeto de Banco de Dados: uma visão prática. São Paulo: Ética, 1996. MABESI, Plínio. mabesi.com. [26 de Jul. de 2011]. Disponível em: . Acesso em: 1º de Mar. de 2012. MEDEIROS, Manoel Pimentel. JavaDoc: implementando documentação através do Netbeans. [20-?]. Disponível em: . Acesso em: 20 de Fev. de 2012. NETO, A. Vicente de Paula. Disponível em JavaFree.org: . Acesso em 12 de Fev. de 2012. PAIXÃO, Carlos Feliz. Disponível em: Grupo de Usuários Java (GUJ) – . Acesso em: 28 de Fev. de 2012. PRADO, S. Dicas de Carreira. [24 de Fev. de 2010]. Disponível em: . Acesso em: 24 de Fev. de 2012. PILONE, D., & MILES, R. Use a cabeça: desenvolvimento de software. Rio de Janeiro, Brasil: Alta Books, 2008. SABTOS, Ciro Meneses. Desenvolvimento de Aplicações Comerciais com Java e NetBeans. Rio de Janeiro: Ciência Moderna Ltda, 2010. SIERRA, Kathy & BATES, Bert. Use a Cabeça: Java. 2° ed. Rio de Janeiro, 2005. WINDER, R. R.; GRAHAM, R. Desenvolvendo Software em Java (3ª Edição ed.). (A. J. Coelho Corrêa da Silva, Trad.) Rio de Janeiro: LTC, 2009. GLOSSÁRIO Column: declara qual a coluna que será mapeada. Entity: anotação que declara a classe como persistente. Hibernate: framework para mapeamento objeto/relacional em Java, que abstrai o código SQL da aplicação. Hibernate-annotations: responsável por fazer o mapeamento. Hibernate-Configuration: responsável em conter as propriedades. Model, View e Controller: Modelo, Visão e Controlador. NamedQueries: são as queries SQL nomeadas para que não seja necessário usar códigos extensos de SQL. PrimaryKeyJoinColumn: nomeia qual coluna é a chave primária para a classe. Queries: consultas junto ao banco de dados. Session-factory: mantém o mapeamento objeto-relacional. Table: define qual a tabela do banco de dados que será mapeada. APÊNDICE A – DIAGRAMA DE CASO DE USO APÊNDICE B – DOCUMENTAÇÃO DO DIAGRAMA DE CASO DE USO Caso de Uso: Realizar Empréstimo Ator Principal: Bibliotecário Pré-condições: O usuário e a obra devem estar cadastrados no sistema. O usuário deve está sem punição, além disso, para realizar o empréstimo, o usuário em questão deve ter uma senha de acesso e a obra não pode estar reservada. O usuário efetua apenas três empréstimos por vez. Pós-condições: Entregar o exemplar na data estabelecida pelo sistema no ato do empréstimo que é contada com dias úteis. Caso contrário, o sistema efetuará a punição por cada dia de atraso. Descrição: O usuário da biblioteca seleciona o exemplar desejado, solicita o empréstimo deste ao bibliotecário. O bibliotecário por sua vez, inseri os dados do usuário e do exemplar selecionado no sistema, o sistema, por sua vez, verifica se o usuário está cadastrado no sistema, se afirmativo, solicita a identificação do usuário que será feita por meio de uma senha. Após a verificação do usuário, o sistema obtém os dados do exemplar e verifica se este é para empréstimo ou se trata do exemplar padrão que permanece na biblioteca, se for cadastrado para empréstimo, o sistema verifica a disponibilidade, se estiver disponível o empréstimo é realizado com sucesso, atualizando o status do exemplar emprestado para indisponível. Se não estiver disponível o usuário pode realizar uma reserva para o exemplar, caso este não tenha nenhuma reserva solicitada por outro usuário. Caso de Uso: Realizar Reserva Ator Principal: Bibliotecário Pré-condições: O usuário e o exemplar devem estar cadastrados no sistema, assim como, o exemplar não deve estar reservado e o usuário não pode ter punição, além disso, o usuário em questão deve ter uma senha de acesso. O número máximo de reservas que o sistema permite é três. Pós-condições: O sistema gera um prazo para buscar o exemplar reservado, caso contrário, a reserva é automaticamente cancelada. Descrição: O usuário solicita a reserva ao bibliotecário, o bibliotecário, por sua vez, entra no sistema, inserindo os dados do usuário e do exemplar escolhido. Primeiramente, o sistema verifica se há cadastro do usuário, se afirmativo, solicita a identificação do usuário, após isso, confere se o exemplar está cadastrado para empréstimo ou se trata do exemplar padrão que permanece na biblioteca, e por fim, se não possui reserva para outro usuário. Caso o exemplar esteja disponível, o sistema efetua a reserva com sucesso, atualizando o status do exemplar para indisponível para reserva. Caso de Uso: Realizar Devolução Ator Principal: Bibliotecário Pré-condições: O sistema deve verificar se o empréstimo foi efetuado e se o prazo estabelecido para a devolução está em dia. Pós-condições: O usuário pode efetuar um novo empréstimo, se não estiver punido por causa do atraso na entrega do exemplar para a biblioteca. Descrição: O usuário entrega o exemplar ao bibliotecário que solicita a devolução ao sistema que, por sua vez, atualiza o status do exemplar para disponível e efetua a punição, caso o usuário não tenha devolvido o exemplar na data especificada na nota de empréstimo. Caso de Uso: Efetuar Punição Ator Principal: _______________________ Pré-condições: Verificar se o exemplar está em atraso, assim que a devolução é solicitada. Pós-condições: Efetuar a punição/multa com dias sem realizar empréstimos. Descrição: No ato da devolução, o sistema verifica se o exemplar é devolvido na data especificada na nota de empréstimo, se afirmativo, a punição não ocorre. Se negativo, o sistema efetuará a penalidade, buscando a data da devolução prevista no ato do empréstimo e a data de devolução efetiva. No cálculo dos dias de atraso serão contados a partir do primeiro dia após a data estabelecida para a devolução. Caso de Uso: Realizar Confirmação com Senha de Acesso Ator Principal: Usuário Pré-condições: O usuário deve ter uma senha de acesso cadastrada no sistema, este cadastro é feito quando o usuário for inserir seus dados no sistema para ter acesso às funcionalidades da biblioteca. Pós-condições: Com a senha de acesso cadastrada o usuário pode efetuar empréstimos e reservas. Descrição: Quando o usuário solicitar o empréstimo, o bibliotecário pesquisa o nome do usuário, o sistema solicita uma senha para confirmar a identificação do usuário. O usuário, por sua vez, inseri sua senha de acesso, o sistema analisa se a senha confere com os dados descritos e faz a liberação do empréstimo se o usuário e senha coincidirem. Caso de Uso: Efetuar Login Ator Principal: Bibliotecário Pré-condições: O bibliotecário deve estar cadastrado no sistema. Pós-condições: Monitorar o sistema, podendo inserir, atualizar e remover dados. Assim como, gerar relatórios, realizar empréstimos, reservas e devoluções solicitadas pelo usuário. Descrição: O bibliotecário insere seu login e senha. O sistema constata se o login e senha conferem para o usuário corrente, se sim o sistema é liberado, se não o sistema apresenta uma caixa de diálogo informando ao bibliotecário que a senha e login não coincidem e/ou o mesmo não está cadastrado. Caso de Uso: Alterar Senha Ator Principal: Bibliotecário Pré-condições: O usuário esquecer sua senha de acesso ou solicitar uma nova senha. Pós-condições: O usuário fica apto para realizar empréstimos e reservas, opcionalmente. Descrição: Esta ação é acionada caso o usuário esquece sua senha ou necessita mudá-la. Quando o usuário solicita a alteração de senha, o bibliotecário busca os dados no sistema e solicita uma alteração ao sistema, este responde, enviando uma mensagem de conclusão com sucesso. Caso de Uso: Inserir Dados Ator Principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: O cadastro pode ser realizado após a autenticação do usuário. Descrição: Um novo usuário solicita o cadastro ao bibliotecário que preencherá a janela de cadastro e solicitará ao sistema a inserção de novos dados, o sistema, por sua vez, pega os dados colocados na tela e lança-os ao banco de dados. Caso de Uso: Atualizar Dados Ator Principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: A atualização de dados pode ser feitas depois que a autenticação do usuário é confirmada. Descrição: Um usuário já cadastrado no sistema solicita ao bibliotecário a atualização de seus dados cadastrados no sistema, o bibliotecário abre a tela de atualização, pesquisa o usuário em questão e solicita ao sistema a atualização dos dados, o sistema, por sua vez, busca o usuário no banco de dados e faz a atualização dos dados. Caso de Uso: Excluir Dados Ator Principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: A exclusão pode ser realizada após a autenticação do usuário. Descrição: O usuário que estiver inativo no sistema será excluído do mesmo. O bibliotecário abre a tela de listagem de usuários, pesquisa o usuário e solicita a exclusão dos dados do usuário inativo ao sistema, o sistema, por sua vez, apaga do banco de dados todas as informações do usuário inativo solicitado. Caso de uso: Gerar Relatório Ator principal: Bibliotecário Pré-condições: O bibliotecário deve ter usuário e senha cadastrados no sistema. Pós-condições: Depois da autenticação do login, o bibliotecário pode gerar qualquer tipo de relatório. Descrição: O bibliotecário solicita um relatório especificando o tipo que deseja gerar, isto é, se quer gerar relatório de usuários, autores, seções, obras, categorias, reservas ou empréstimos. Caso de uso: Listar Usuário Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita relatório de usuários, o sistema abre uma tela mostrando as possíveis listagens se por aluno, funcionário, bibliotecário, usuário externo ou listar todos os usuários. O bibliotecário faz a escolha e o sistema gera um arquivo PDF. Caso de uso: Listar Usuários Com Pendências Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita relatório de usuários com pendências, o sistema abre uma tela para que o bibliotecário faça a escolha do tipo de listagem se por aluno, funcionário, bibliotecário, usuário externo ou listar todos os usuários pendentes. O bibliotecário faz a escolha e o sistema gera um arquivo PDF. Caso de uso: Listar Usuários Devedores Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita relatório de usuários devedores, o sistema abre uma tela mostrando as possíveis listagens se por aluno, funcionário, bibliotecário, usuário externo ou listar todos os usuários devedores. O bibliotecário faz a escolha e o sistema gera um arquivo PDF. Caso de uso: Listar Obras Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita relatório de obras, o sistema abre uma tela mostrando as possíveis listagens se por livros, revistas, dicionários, enciclopédias, trabalhos científicos, CDs e DVDs ou listar todas as obras. Além disso, o bibliotecário poderá listar o tipo de item por autor, título, editora, seção ou ano de edição. O bibliotecário faz a escolha e o sistema gera um arquivo PDF. Caso de uso: Listar Obras Disponíveis Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita relatório de obras disponíveis, o sistema abre uma tela mostrando as possíveis listagens se por livros, revistas, dicionários, enciclopédias, trabalhos científicos, CDs e DVDs ou listar todas as obras. O bibliotecário faz a escolha e o sistema gera um arquivo PDF. Caso de uso: Listar Obras Reservadas Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita relatório de obras reservadas, o sistema abre uma tela mostrando as possíveis listagens se por livros, revistas, dicionários, enciclopédias, trabalhos científicos, CDs e DVDs ou listar todas as obras que estão com status reservado. O bibliotecário faz a escolha e o sistema gera um arquivo PDF. Caso de uso: Listar Obras Emprestadas Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita relatório de obras emprestadas, o sistema abre uma tela mostrando as possíveis listagens se por livros, revistas, dicionários, enciclopédias, trabalhos científicos, CDs e DVDs ou listar todas as obras que estão com status indisponível. O bibliotecário faz a escolha e o sistema gera um arquivo PDF. Caso de uso: Listar Autores Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita a listagem dos autores cadastrados, o sistema gera um arquivo PDF. Caso de uso: Listar Seções Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita a listagem das seções cadastradas, o sistema gera um arquivo PDF. Caso de uso: Listar Tipo CDDVD Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita a listagem das categorias cadastradas para especificar qual o tipo da multimídia, o sistema gera um arquivo PDF. Caso de uso: Listar Idioma Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita a listagem de idiomas cadastrados, o sistema gera um arquivo PDF. Caso de uso: Listar Tipo Trabalho Científico Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita a listagem dos tipos de trabalhos científicos cadastrados, o sistema gera um arquivo PDF. Caso de uso: Listar Reservas Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita a listagem de reservas realizadas. O sistema mostra uma tela para que o bibliotecário faça a escolha do período (Semanalmente, mensalmente ou anualmente) ou listar todas as reservas. O bibliotecário faz a escolha e o sistema gera um arquivo PDF. Caso de uso: Listar Empréstimos Ator principal: Bibliotecário Pré-condições: O bibliotecário deve efetuar login no sistema. Pós-condições: _______________________ Descrição: O bibliotecário solicita a listagem de empréstimos realizados. O sistema mostra uma tela para que o bibliotecário faça a escolha do período (Semanalmente, mensalmente ou anualmente) ou listar todos os empréstimos. O bibliotecário faz a escolha e o sistema gera um arquivo PDF. APÊNDICE C – DIAGRAMA DE CLASSE APÊNDICE D – DIAGRAMA DE ENTIDADE E RELACIONAMENTO APÊNDICE E – IMAGEMS DO CAMPO EMPÍRICO Biblioteca Professora Maria das Vitórias Silva Vilar ANEXO A – FICHA DE CADASTRO DE USUÁRIOS ANEXO B – FICHA PARA REALIZAÇÃO DE EMPRÉSTIMOS