INSTITUTO FEDERAL DO PARANÁ HUDO CIM ASSENÇO LUCAS FOLMANN LIMA RODRIGO BRADASH OSTERNACK PAPYRUS: SISTEMA DE LICITAÇÃO DE LIVROS PARA BIBLIOTECA

Transcrição

1 INSTITUTO FEDERAL DO PARANÁ HUDO CIM ASSENÇO LUCAS FOLMANN LIMA RODRIGO BRADASH OSTERNACK PAPYRUS: SISTEMA DE LICITAÇÃO DE LIVROS PARA BIBLIOTECA CURITIBA 2011

2 HUDO CIM ASSENÇO LUCAS FOLMANN LIMA RODRIGO BRADASH OSTERNACK PAPYRUS: SISTEMA DE LICITAÇÃO DE LIVROS PARA BIBLIOTECA Trabalho de Conclusão de Curso apresentado à disciplina de Projetos como requisito parcial à conclusão do Curso Técnico em Informática Integrado ao Ensino Médio do Instituto Federal do Paraná. Orientador: Paulo Roberto Vieira Jr. Co-orientadora: Elaini Simoni Angelotti. CURITIBA 2011

3 RESUMO O processo de licitação de livros do Instituto Federal do Paraná (IFPR), realizado através de suas bibliotecas, aborda o recebimento das solicitações de livros vindos de professores e servidores públicos da instituição e o gerenciamento dessas solicitações. Após entrevistas com o responsável pelo gerenciamento desse processo de licitação, foram constatadas necessidades por parte dele com relação à organização do processo, podendo citar dentre as principais a dificuldade na pesquisa de informações, as constantes falhas no envio de formulários por parte de quem realiza a solicitação de livros e o desgastante processo de organizar uma licitação. Para suprir estas e outras necessidades, foi idealizado o Papyrus, um sistema web desenvolvido em linguagem Java, que tem a função de controlar o preenchimento e envio de formulários, assim como a organização de licitações, a fim de minimizar as falhas e simplificar o processo. Como ponto característico, o sistema fará pesquisas automáticas de dados de cada livro, incluindo seu valor, em websites de livrarias pré-estabelecidas (Livraria Cultura). Sendo o objetivo específico deste projeto a resolução do problema apresentado pelo entrevistado, ele não abordará as demais tarefas que um sistema comum de bibliotecas realiza, como por exemplo, o controle de locação de livros realizados por usuários da biblioteca. Palavras-chave: Licitação. Biblioteca. Pedido. Sistema. Pesquisa automática.

4 LISTA DE ILUSTRAÇÕES FIGURA 1 Diagrama de Casos de Uso FIGURA 2 Classes DAO FIGURA 3 Classes de Entidade, Facades e Managed Beans FIGURA 4 Diagrama de Entidades e Relacionamentos FIGURA 5 Diagrama do Modelo Relacional FIGURA 6 Página Inicial FIGURA 7 Menu de Sistema FIGURA 8 Menu de Cadastro FIGURA 9 Gerenciamento de Pessoas FIGURA 10 Tela de Cadastro de Pessoas, Etapa FIGURA 11 Tela de Cadastro de Pessoas, Etapa FIGURA 12 Tela de Cadastro de Pessoas, Etapa FIGURA 13 Gerenciamento de Licitações FIGURA 14 Tela de Cadastro de Licitações FIGURA 15 Gerenciamento de Livros FIGURA 16 Tela de Cadastro de Livros FIGURA 17 Gerenciamento de Pedidos FIGURA 18 Tela de Cadastro de Pedidos

5 LISTA DE TABELAS TABELA 1 - Descrição do caso de uso Gerenciar Pessoas TABELA 2 - Descrição do caso de uso Listar Pessoas TABELA 3 - Descrição do caso de uso Incluir Pessoas TABELA 4 - Descrição do caso de uso Alterar Pessoas TABELA 5 - Descrição do caso de uso Remover Pessoas TABELA 6 - Descrição do caso de uso Gerenciar Licitações TABELA 7 - Descrição do caso de uso Listar Licitações TABELA 8 - Descrição do caso de uso Incluir Licitações TABELA 9 - Descrição do caso de uso Alterar Licitações TABELA 10 - Descrição do caso de uso Remover Licitações TABELA 11 - Descrição do caso de uso Login TABELA 12 - Descrição do caso de uso Contatar Administrador TABELA 13 - Descrição do caso de uso Gerenciar Disciplinas TABELA 14 - Descrição do caso de uso Listar Disciplinas TABELA 15 - Descrição do caso de uso Incluir Disciplinas TABELA 16 - Descrição do caso de uso Alterar Disciplinas TABELA 17 - Descrição do caso de uso Remover Disciplinas TABELA 18 - Descrição do caso de uso Gerenciar Recebimentos TABELA 19 - Descrição do caso de uso Listar Recebimentos TABELA 20 - Descrição do caso de uso Incluir Recebimentos TABELA 21 - Descrição do caso de uso Alterar Recebimentos TABELA 22 - Descrição do caso de uso Remover Recebimentos TABELA 23 - Descrição do caso de uso Gerenciar Funções TABELA 24 - Descrição do caso de uso Listar Funções TABELA 25 - Descrição do caso de uso Incluir Funções TABELA 26 - Descrição do caso de uso Alterar Funções TABELA 27 - Descrição do caso de uso Remover Funções TABELA 28 - Descrição do caso de uso Gerenciar Cargos TABELA 29 - Descrição do caso de uso Listar Cargos TABELA 30 - Descrição do caso de uso Incluir Cargos TABELA 31 - Descrição do caso de uso Alterar Cargos TABELA 32 - Descrição do caso de uso Remover Cargos... 44

6 TABELA 44 - Descrição do caso de uso Cotar Pedidos TABELA 45 - Descrição do caso de uso Gerenciar Livro TABELA 46 - Descrição do caso de uso Listar Livro TABELA 47 - Descrição do caso de uso Incluir Livro TABELA 48 - Descrição do caso de uso Alterar Livro TABELA 49 - Descrição do caso de uso Remover Livro TABELA 50 - Descrição do caso de uso Gerenciar Pedido TABELA 51 - Descrição do caso de uso Listar Pedido TABELA 52 - Descrição do caso de uso Incluir Pedido TABELA 53 - Descrição do caso de uso Alterar Pedido TABELA 54 - Descrição do caso de uso Remover Pedido TABELA 55 - Descrição do caso de uso Gerenciar Itens TABELA 56 - Descrição do caso de uso Listar Item TABELA 57 - Descrição do caso de uso Incluir Item TABELA 59 - Descrição do caso de uso Remover Item TABELA 66 - Dicionário de dados da tabela Campi TABELA 67 - Dicionário de dados da tabela Biblioteca TABELA 68 - Dicionário de dados da tabela PessoaJuridica TABELA 69 - Dicionário de dados da tabela Pedido TABELA 70 - Dicionário de dados da tabela Item TABELA 71 - Dicionário de dados da tabela PessoaJuridicaLicitacao TABELA 72 - Dicionário de dados da tabela Licitacao TABELA 73 - Dicionário de dados da tabela Endereco TABELA 74 - Dicionário de dados da tabela Pessoa TABELA 75 - Dicionário de dados da tabela PessoaFisica TABELA 76 - Dicionário de dados da tabela Livro TABELA 77 - Dicionário de dados da tabela Professor TABELA 78 - Dicionário de dados da tabela ServidorPublico TABELA 79 - Dicionário de dados da tabela Disciplina TABELA 80 - Dicionário de dados da tabela ProfessorDisciplina TABELA 81 - Dicionário de dados da tabela Funcao TABELA 82 - Dicionário de dados da tabela Cargo TABELA 83 - Dicionário de dados da tabela Status TABELA 84 - Dicionário de dados da tabela ÁreaDoConhecimento... 91

7 TABELA 85 - Dicionário de dados da tabela RegistroRecebimento... 91

8 LISTA DE SIGLAS AACR2 - Anglo-American Cataloguing Rules, Second Edition ABNT - Associação Brasileira de Normas Técnicas API - Application Programming Interface CRUD - Create-Read-Update-Delete DAO - Data Access Object DER - Diagrama de Entidade e Relacionamento EJB - Enterprise Java Bean GUI - Graphical User Interface HD - Hard Disk HQL - Hibernate Query Language HTML - HyperText Markup Language IDE - Integrated Development Environment IFPR - Instituto Federal de Educação Ciência e Tecnologia do Paraná IOC - Inversion of Control ISBN - International Standard Book Number IU - Interface de Usuário JDBC - Java Database Connectivity JSF - Java Server Faces JSP - Java Server Pages MARC - Machine Readable Cataloging MB - Mega Byte MEC - Ministério da Educação MER - Modelo de Entidade-Relacionamento MR - Modelo Relacional MVC - Model, View, Controller ORM - Object-Relational Mapping PDF - Portable Document Format PUC-PR - Pontifícia Universidade Católica do Paraná RAM - Random Access Memory RNP - Rede Nacional de Ensino e Pesquisa SGBD - Sistema Gerenciador de Banco de Dados SQL - Structured Query Language TB - Tera Byte UML - Linguagem de Modelagem Unificada XML - Extensible Markup Language

9 SUMÁRIO 1 INTRODUÇÃO DIAGNÓSTICO ATUAL OBJETIVO GERAL E OBJETIVOS ESPECÍFICOS JUSTIFICATIVA SOLUÇÃO PROPOSTA DELIMITAÇÃO RECURSOS E TECNOLOGIAS FUNDAMENTAÇÃO TEÓRICA Plataforma Java Padrões de projeto Model, View, Controller Inversion of Control Data Access Object Facade JavaServer Faces Object-Relational Mapping Hibernate JBossSeam Sistema Gerenciador de Banco de Dados Trabalhos relacionados METODOLOGIA Ambiente de desenvolvimento Modelagem Testes ESPECIFICAÇÃO TÉCNICA DIAGRAMA DE CASO DE USO... 19

10 3.1.1 Especificação dos Casos de Uso DIAGRAMA DE CLASSES Classes DAO Classes de Entidade, Facades e Managed Beans MODELO LÓGICO DA BAS DADOS Diagrama de Entidade e Relacionamento Diagrama do Modelo Relacional Dicionário de dados IMPLEMENTAÇÃO DO SISTEMA E SUAS FUNCIONALIDADES MENU PESSOAS LICITAÇÕES LIVROS PEDIDOS CONSIDERAÇÕES FINAIS RESULTADOS E TRABALHOS FUTUROS REFÊRENCIAS GLOSSÁRIO ANEXOS

11 1 1 INTRODUÇÃO Este projeto de conclusão de curso consiste no desenvolvimento de um sistema, de nome Papyrus, que será feito especialmente para solicitação de livros na biblioteca do Instituto Federal do Paraná (IFPR). Atualmente o processo de solicitação de livros para a biblioteca é feito com base no envio de uma planilha por , preenchida pelos professores ou servidores públicos a partir de um modelo já existente, exemplificado pelo anexo A. Isto permite alguns erros, sendo que o principal deles é a falta de informações referente aos livros solicitados, como autor, International Standard Book Number (ISBN), editora, entre outros. Como alternativa a este processo, uma das principais características do sistema será a pesquisa automática de livros e preços, tendo como base a Livrarias Cultura. O sistema fará buscas automáticas deixando o processo mais fácil para o professor ou servidor público e minimizando os erros. 1.1 DIAGNÓSTICO ATUAL Atualmente, o processo de licitação de livros para a biblioteca do IFPR é controlado por meio de planilhas eletrônicas, administradas por um funcionário da biblioteca. Estas planilhas são referentes ao controle de pedidos de livros, cotação dos livros pelo fornecedor, saldo referente a cada fornecedor, controle de recebimento dos livros e o envio dos mesmo para as bibliotecas do IFPR. O controle de pedidos de livros é feito através de uma planilha que contém as seguintes informações: autor, título, edição, editora, ano, ISBN, quantidade, volume, valor unitário, valor total, site pesquisado, data da pesquisa, data do pedido e área de conhecimento, sendo esta última só preenchida pelo administrador. A solicitação de livros é feita através de s enviados, por professores ou servidores públicos, a um funcionário responsável pela administração da planilha. Após o recebimento dos s, o funcionário verifica se as informações foram corretamente preenchidas. Caso haja alguma informação faltando, ele faz a pesquisa do livro no site das livrarias Saraiva, Curitiba e Cultura. Caso o livro não seja encontrado em nenhuma das três livrarias, ele é marcado em vermelho na planilha e removido da licitação. A etapa seguinte é o envio desta planilha aos

12 2 fornecedores vencedores da licitação. Cada fornecedor recebe uma lista diferente, sendo que a separação das listas ocorrerá com base em algum dos campos da planilha citados anteriormente (autor, International Standard Book Number (ISBN), editora, etc.), o que é decidido durante o processo de licitação. Depois do recebimento das listas, os fornecedores verificam a disponibilidade dos livros solicitados. Caso o livro não esteja disponível, o fornecedor envia uma resposta ao funcionário com a relação dos livros que não poderão ser enviados com seus respectivos motivos. O funcionário então monta outra lista, contendo os livros que irão substituir aqueles que não poderão ser fornecidos, para suprir o saldo remanescente do fornecedor. No recebimento dos livros, o funcionário controla os livros recebidos, os encaminhados e os que estão para chegar através da planilha de controle de recebimento. Assim que o livro chega para o funcionário, ele irá registrar o recebimento do livro na sua planilha e encaminhará o livro para a sua respectiva biblioteca. 1.2 OBJETIVO GERAL E OBJETIVOS ESPECÍFICOS O objetivo geral do projeto é automatizar o processo de licitação de livros para a biblioteca do IFPR. Os objetivos específicos são definidos abaixo: a) Permitir o cadastro de professores, servidores públicos, fornecedores, campi, bibliotecas, licitações e livros; b) Enviar notificações automáticas por s nas seguintes situações: Notificar o professor e o servidor público, caso ocorra alteração do status das solicitações feitas por eles; Notificar o professor e o servidor público, caso ocorra a abertura do período de licitação; Notificar o professor e o servidor público, caso ocorra o encerramento do período de licitação; Notificar o fornecedor, caso ocorra alteração das licitações aprovadas para a licitação. c) Pesquisar automaticamente preços na Livrarias Cultura;

13 3 d) Pesquisar automaticamente livros na Livrarias Cultura; e) Controlar a recepção de livros; f) Permitir a verificação do status do pedido; g) Permitir a solicitação de livros. 1.3 JUSTIFICATIVA O sistema beneficiará o usuário e a instituição, simplificando e agilizando o processo de solicitação de livros, pois serão minimizadas as falhas no processo, uma vez que o sistema permitirá pesquisas automatizadas. Estas pesquisas irão fornecer os dados que faltarem na hora do cadastro de livros, automatizando um processo que atualmente é feito de forma manual pelo administrador da planilha.

14 4 2 SOLUÇÃO PROPOSTA O sistema irá cadastrar professores, servidores públicos, fornecedores, bibliotecas, campi, licitações e livros. Os professores e servidores públicos devidamente cadastrados poderão entrar no sistema e realizar solicitações de livros. As solicitações são ordenadas de acordo com a data de realização, e serão avaliadas pelo administrador. Só farão parte da licitação as solicitações aceitas pelo administrador. Após serem avaliadas pelo administrador as solicitações estarão disponíveis aos fornecedores vencedores da licitação, que também estarão cadastrados. Ao verificar o estoque, o fornecedor deverá informar ao sistema quais livros não poderão ser enviados, bem como suas respectivas justificativas. Se o saldo do fornecedor ainda não tiver sido alcançado, o administrador poderá incluir na licitação requisições entregues fora do prazo. O administrador ficará responsável por dar baixa nos livros recebidos e encaminhá-los às suas devidas bibliotecas, assim como atualizar o status das solicitações. Quando isto ocorrer, o sistema notificará via os professores e servidores públicos da situação de suas solicitações. 2.1 DELIMITAÇÃO No ambiente da biblioteca, este sistema não será responsável pela administração de livros locados da biblioteca por alunos, professores ou funcionários dos campi. Será limitado aos campi do estado do Paraná. 2.2 RECURSOS E TECNOLOGIAS No desenvolvimento do projeto será usado Java 1.6. Esta linguagem foi escolhida por ser independente de plataforma e por ser uma linguagem orientada a objetos. Para Integrated Development Environment (IDE) foi escolhido o Eclipse por ter melhor compatibilidade com os demais recursos que serão utilizados no projeto.

15 5 Também será utilizado o Sistema Gerenciador de Banco de Dados (SGBD) MySQL, este por sua vez escolhido por ser, segundo Suehring (2002), um dos sistemas de gerenciamento de banco de dados livres mais populares que existe e que, por ser otimizado para aplicações web, é amplamente utilizado na internet. Outro fator que ajuda na popularidade do MySQL é sua disponibilidade para praticamente qualquer sistema operacional, como Linux e outros sistemas baseados em Unix, além de Windows e Mac OS. Também será utilizado o padrão Data Access Object (DAO), porque o sistema irá precisar persistir os dados no banco de dados, e o principal benefício deste padrão é a fácil migração de uma base de dados. Outro padrão a ser utilizado será o Model, View, Controller (MVC) que também foi escolhido por fornecer benefícios ao sistema, entre eles o principal é o baixo acoplamento entre as classes. Pela necessidade de persistir os dados em uma base de dados, será utilizado o framework Hibernate, porque ele facilita e reduz a codificação necessária para a persistência dos dados. Será utilizado o framework Java Server Faces (JSF), que é especializado na criação de páginas web, agilizando o processo de implementação. 2.3 FUNDAMENTAÇÃO TEÓRICA Serão apresentadas algumas informações sobre as tecnologias que estarão presentes no projeto. O objetivo é deixar o leitor mais familiarizado com as tecnologias e terminologias apresentadas neste tópico Plataforma Java Segundo Horstmann e Cornell (2001), a linguagem de programação Java surgiu na internet em 1995 e ganhou rapidamente o status de celebridade, pois ela é uma linguagem elaborada com extrema solidez que tem ganho aceitação por parte de todos os principais fornecedores e envolvidos. Seus recursos de segurança e proteção atendem tanto aos programadores quanto aos usuários de programas Java. A plataforma Java tem inclusive suporte incorporado para realizar tarefas de

16 6 programação avançadas como programação em rede, conectividade de bancos de dados e multiprocessamento, de forma imediata. Desde 1995, a plataforma já passou por vários testes e revisões que a aprimoraram. A versão 1.2, por exemplo, que foi lançada em 1998, entre os vários aprimoramentos que teve, ela apresentou um que se destacou: o toolkit de interface de usuário chamado Swing, que permitia aos programadores escrever aplicativos graphical user interface (GUI) realmente portáveis. Ainda segundo Horstmann e Cornell (2001), a linguagem Java é totalmente orientada a objetos, mas foram acrescentados recursos à plataforma que eliminam a possibilidade de se criar código com os tipos mais comuns de erros, comparando-se a outras linguagens semelhantes como por exemplo o C++. Um exemplo de recursos acrescentado foi a coleta de lixo automática, que libera memória automaticamente. De acordo com a Oracle (2011), Java é a tecnologia mais ampla e ativa do planeta, usada por mais de 6,5 milhões de desenvolvedores e presente em mais de 4,5 bilhões de dispositivos. Ela é uma linguagem que funciona em quase todos os dispositivos, computadores e redes, como por exemplo laptops, datacenters, consoles de jogo, supercomputadores científicos, telefones celulares e até na internet Padrões de projeto Alexander 1 (1977, citado por GAMMA, 1994) diz, Cada padrão descreve um problema que ocorre muitas vezes em nosso ambiente e descreve a solução para este problema, de tal forma que você pode usar esta solução um milhão de vezes, sem nunca fazê-la da mesma forma. Embora Alexander esteja falando de arquitetura e construções, o princípio é o mesmo para padrões de projetos orientados a objetos. A diferença é que as soluções são expressadas em termos de objetos e interfaces ao invés de portas e paredes, mas a idéia principal é a mesma, uma solução para um problema dentro de um contexto. 1 ALEXANDER, C. et al. A Pattern Language: Towns, Buildings, Construction. 1. ed. New York: Oxford University Press, 1977.

17 7 Segundo Gamma (1994), os padrões de projetos podem ser divididos em 3 categorias: a) Criacional: são padrões relacionados a criação de objetos; b) Estrutural: padrões que lidam com a composição de classes ou objetos; c) Comportamental: padrões que caracterizam as formas pelas quais as classes ou objetos interagem e distribuem responsabilidades. Segundo o autor, os padrões de projetos tornam mais fácil a reutilização de projetos e arquiteturas bem sucedidas, além de ajudar a escolher alternativas que tornam um sistema reutilizável e a evitar alternativas e comprometam a reusabilidade Model, View, Controller (MVC) Segundo Eckstein (2007) o padrão MVC foi inicialmente introduzido por Trygve Reenskaug um desenvolvedor de Smalltalk na Xerox Palo Alto Research Center em Este padrão fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação. Segundo o mesmo autor, o MVC pode ser dividido em 3 elementos: a) Model: Representa os dados e regras sobre o acesso e a atualização destes dados. O model também mantém o estado persistente do negócio e fornece ao controller a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio model; b) View: Especifica exatamente como os dados do model devem ser apresentados. Se os dados mudam, a view precisa mudar a apresentação dos mesmos. Isso poder ser alcançado usando um push model no qual o model é responsável por lançar uma notificação de mudança a todos os Listeners interessados, ou usando um pull model onde a view é responsável por chamar o modelo quando é necessária a atualização dos dados;

18 8 c) Controller: Define o comportamento da aplicação, é ele que interpreta as ações do usuário e as mapeia para chamadas do model. Em um cliente de aplicações Web essas ações do usuário poderiam ser cliques de botões ou seleções de menus. As ações realizadas pelo model incluem ativar processos de negócio ou alterar o estado do model. De acordo com Eckstein (2007), uma mais recente implementação do MVC propõe que o controller permaneça entre o model e a view. A principal diferença entre esse modelo e o tradicional MVC é que nesse as notificações de mudanças no estado dos objetos do model são comunicados para a view através do controller. Portanto, o controller mediará o fluxo de dados entre os objetos do model e view em ambas as direções. Objetos da view, sempre utilizarão o controller como meio de interpretar as ações do usuário em mudança nas propriedades do model Inversion of Control (IOC) Segundo Fowler (2004), Inversion of Control (ou atualmente Dependency Injection) é um padrão de projeto que tem como solução o desacoplamento entre as classes, isto é, uma classe nunca deve instanciar outra classe dentro dela. Tendo como base o mesmo artigo, essa inversão de controle ocorre no sentido de que o controle a ser invertido é sobre os objetos da classe. Ele é invertido para um framework responsável pelas dependências de cada classe. Este framework por sua vez é configurado de uma forma que possa reutilizar o código apenas fornecendo as necessidades ao framework sem ter que refazer todo o código. O objetivo principal deste padrão é tornar a aplicação flexível, para que ela possa ser montada para atender a diferentes serviços e componentes de maneira configurável Data Access Object (DAO) Segundo a Sun Microsystems ( ), o Data Access Object é um padrão de projeto que abstrai a origem e o modo de obtenção ou gravação dos dados, de modo que o restante do sistema manipula os dados de forma

19 9 transparente. Isso ajuda muito em processos de migrações de fonte de dados e testes unitários. Dessa forma o DAO consegue manipular a conexão com a fonte de dados fazendo com que seja um único ponto de acesso. Com base no artigo citado anteriormente este padrão traz os seguintes benefícios: a) Transparência: Objetos de negócios podem usar a fonte de dados sem saber os detalhes da implementação desta fonte. O acesso é transparente porque os detalhes desta implementação estão escondidos dentro do DAO; b) Reduz a Complexidade dos Objetos de Negócio: Porque o DAO gerencia toda a complexidade de acesso aos dados, isto simplifica o código dos objetos de negócio e outros objetos que utilizam o DAO; c) Centraliza o Acesso aos Dados em uma Camada Separada: O DAO centraliza todo o código de conexão e manipulação de dados deixando o código da aplicação mais limpo e fácil de manuseá-lo; d) Fácil Migração: A camada DAO facilita para a aplicação para migrar para um diferente implementação de banco de dados. A migração envolve apenas as mudanças na camada DAO porque os objetos de negócio não tem conhecimento da forma como é implementado o banco de dados Facade Segundo Gamma (2000), o padrão Facade estrutura o sistema em subsistemas para assim reduzir a complexidade, uma vez que define uma interface de alto nível que facilita o uso do subsistema. O objetivo do padrão é de minimizar a comunicação e as dependências entre os subsistemas, para isso cria-se um objeto de fachada que fornece uma interface única e simplificada para as ações mais gerais de um subsistema. Ainda segundo o mesmo autor, as principais situações em que o uso do Facade se torna vantajoso são quando: a) A maioria dos padrões, quando aplicados em um sistema, resultam em mais e menores classes, para isso o Facade oferece uma visão mais simples desse sistema.

20 10 b) Existem muitas dependências entre clientes e as classes de implementação de uma abstração. A implementação de um Facade desacopla o subsistema dos clientes e outros subsistemas, promovendo assim a independência do subsistema. c) O Facade é utilizado para definir um ponto de entrada para cada nível do sistema. Se os subsistemas são dependentes, então o Facade simplifica as dependências entre eles, fazendo se comunicarem através de suas fachadas Java Server Faces (JSF) Segundo Geary e Horstmann (2004), o JSF é um framework que contém todos os códigos necessários para manipulação de eventos e organização de componentes. A sua vantagem prometida é proporcionar o desenvolvimento rápido de interfaces de usuário ao Java server-side. Segundo os mesmos autores citados anteriormente, o JSF é composto das seguintes partes: a) Um conjunto de componentes de interface de usuário (IU) pré desenvolvidos; b) Um modelo de programação dirigido por eventos; c) Um modelo de componentes que permite a desenvolvedores independentes fornecerem componentes adicionais. Para Geary e Horstmann (2004), estes são os principais serviços que o JSF oferece: a) Arquitetura MVC; b) Conversão de data; c) Validação e tratamento de erros; d) Internacionalização; e) Componentes personalizados; f) Suporte a ferramentas. Segundo a Oracle (2011), facilidade de uso é o objetivo principal do Java Server Faces. Uma arquitetura que define claramente uma separação entre a lógica

21 11 da aplicação e da apresentação, tornando fácil de conectar a camada de apresentação para o código do aplicativo. Este projeto permite que cada membro de uma equipe de desenvolvimento de aplicações web foque a sua parte no processo de desenvolvimento, e também oferece um modelo de programação simples para ligar as partes Object-relational mapping (ORM) Segundo Ambler (2011), existem incompatibilidades conceituais entre os bancos de dados relacionais e a orientação a objetos, uma vez que esta última é baseada em princípios da engenharia de software e a primeira é baseada em princípios matemáticos. Para resolver estas diferenças, de acordo com o mesmo autor, é utilizada a técnica de mapeamento objeto-relacional, o ORM. Esta técnica sugere a maneira como devemos persistir o estado de um objeto (seus atributos, relacionamentos e/ou heranças) em tabelas de banco de dados relacional (como por exemplo, o MySQL). Para Bauer e King (2007), ORM é a persistência automatizada (e transparente) de objetos em um aplicativo Java para as tabelas de um banco de dados relacional, usando metadados que descrevem o mapeamento entre os objetos e o banco de dados. O ORM, em sua essência, trabalha na transformação de dados de uma representação para outra, mas isto implica em problemas de desempenho. No entanto, se o ORM for implementado como um middleware 2, existem muitas oportunidades para otimização que não existiriam em uma persistência implementada a mão. Ainda para os mesmos autores, o ORM consiste em quatro partes: a) Uma Interface de Programação de Aplicações (API) para executar as operações básicas de adicionar, ler, atualizar e remover em objetos; b) Uma linguagem ou API para especificar consultas que se referem a classes ou propriedades das classes; c) Uma facilidade para a especificação de metadados de mapeamento; 2 Segundo a Rede Nacional de Ensino e Pesquisa (2006), Middleware é o neologismo criado para designar camadas de software que não constituem diretamente aplicações, mas que facilitam o uso de ambientes ricos em tecnologia da informação.

22 12 d) Uma técnica para a implementação ORM para interagir com objetos transacionais e outras funções de otimização. Ainda segundo os mesmos autores, na plataforma Java, o framework Hibernate, que implementa o padrão Java Persistence API, é o mais recomendado Hibernate Segundo Bauer e King (2007), o Hibernate é um framework de mapeamento objeto/relacional para Java. Este framework transforma os dados da estrutura lógica de um banco de dados em objetos definidos pelo desenvolvedor. Usando o Hibernate, não há a necessidade de escrever muito do código de acesso a banco de dados e de SQL, pois ele utiliza a sua própria Hibernate Query Language (HQL), acelerando a velocidade do seu desenvolvimento. Vale lembrar que, apesar do fato do Hibernate utilizar uma linguagem própria para realizar a persistência dos dados, podemos mudar a qualquer momento o SGDB utilizado. Conforme os mesmo autores, os principais motivos que fazem com que o Hibernate seja recomendado para a persistência de dados em Java são: a) Produtividade: Hibernate elimina muito do trabalho pesado e deixa você se concentrar no problema do negócio. Não importa qual seja a sua preferência quanto a estratégia de desenvolvimento de aplicativos, o Hibernate, usado em conjunto com as ferramentas apropriadas, irá reduzir significativamente o tempo de desenvolvimento; b) Manutenção: Menos linhas de código tornam o sistema mais compreensível, porque enfatiza a lógica do negócio. Ainda mais importante, um sistema com menos código é mais fácil de ser administrado. A persistência objeto/relacional automatizada reduz substancialmente o número de linhas de código. c) Desempenho: Dada uma tarefa de persistência, várias otimizações são possíveis. Algumas são muito mais fáceis com o SQL/JDBC escrito. A maioria delas, no entanto, são muito mais fáceis de conseguir com o Hibernate, além disso, permite que elas possam ser usadas o tempo todo.