LMR Sistema Gerenciador de Documentos
Transcrição
LMR Sistema Gerenciador de Documentos
UNIVERSIDADE GAMA FILHO PRÓ-REITORIA DE CIÊNCIAS EXATAS E TECNOLOGIA CURSO DE CIÊNCIA DA COMPUTAÇÃO LUCIANA CONCEIÇÃO DE ANDRADE MARIANA CAROLI DE SOUZA RAMYA FARIA MAFORT LMR Sistema Gerenciador de Documentos Rio de Janeiro 2010.02 LUCIANA CONCEIÇÃO DE ANDRADE MARIANA CAROLI DE SOUZA RAMYA FARIA MAFORT LMR Sistema Gerenciador de Documentos Trabalho de conclusão de curso apresentado à banca examinadora do curso de Ciência da Computação, da PróReitoria de Ciências Exatas e Tecnologia da Universidade Gama Filho, como requisito parcial para obtenção do título de bacharel em ciência da computação. Orientador(a): Prof(a). M.Sc. Jonh Edson Ribeiro de Carvalho Rio de Janeiro 2010.02 _________________ _. LUCIANA CONCEIÇÃO DE ANDRADE _____________________________________________________ MARIANA CAROLI DE SOUZA . __________________ . RAMYA FARIA MAFORT LMR SISTEMA GERENCIAMENTO DE DOCUMENTOS Este trabalho de conclusão de curso foi julgado adequado como requisito parcial, pela banca examinadora, para obtenção do título de bacharel em ciência da computação, tendo sido aprovado pelo curso de Ciência da Computação, da Pró-Reitoria de Ciências Exatas e Tecnologia da Universidade Gama Filho. Aprovado em _____/ _____/ ______ BANCA EXAMINADORA _________________ _. Orientador(a): Prof(a). M.Sc. Jonh Edson Ribeiro de Carvalho _________________ _. Prof(a). M.Sc. Neury Nunes Cardoso _________________ Rio de Janeiro 2010.02 _. AGRADECIMENTOS Agradecemos primeiramente a Deus, que esteve presente na nossa caminhada, nos encorajando e nos dando força para vencer e concluir o curso de Ciência da Computação. A toda nossa família, em especial, aos nossos pais: Paulo e Dirce; Nilzo e Eliane; Delcy e Aymar; pelo amor incondicional, apoio, estímulo e confiança que depositaram em nós, e pela educação que nos proporcionaram, estando ao nosso lado em todos os momentos. Aos nossos irmãos, Davi; Gabriela e Bernardo; Raquel e Rodrigo; pelo amor e incentivo que sempre nos deram. A todos os nossos amigos, e em especial Lorena Linhares e Michael Ramos, que fizeram parte desta trajetória. Ao coordenador Neury Nunes Cardoso, pela amizade, incentivo e paciência, que nos erguia sempre nos momentos de dificuldade. A todos os professores que estiveram conosco todos esses anos, a nossa gratidão pelos conhecimentos adquiridos, lembraremos de seus ensinamentos. FICHA CATALOGRÁFICA RESUMO A maneira mais primária de conseguir informação contida em documentos é inspecionar todos os documentos, um a um, até que sejam encontrados todos os documentos com as informações desejadas. Soluções tecnológicas surgem para substituir a tradicional organização de arquivos em pastas para catalogá-los. O sistema de gerenciamento de documentos proposto terá como finalidade permitir a rápida recuperação da informação, disponibilizando-a de forma segura e organizada. Através deste sistema economiza-se tempo na busca de documentos, o que potencialmente simboliza economia de tempo aliada à eficácia na recuperação de documentos relevantes aos usuários de sistemas de informação. Palavras-chave: Recuperação de Informação, Gerenciamento de Documentos, Banco de Dados. ABSTRACT The primary way of getting information from documents is to inspect all documents one by one, until all documents are found with the desired information. Technological solutions emerge to replace the traditional file organizing into folders to catalog them. The document management system proposed will aim to enable rapid retrieval of information by providing it in a safe and organized manner. This system saves time in searching for documents, which symbolizes potentially saving time coupled with the efficiency in retrieval of documents relevant to the users of information systems. Keywords: Information Retrieval, Document Management, Database. LISTA DE FIGURAS Figura 1 - Diagrama de Caso de Uso ................................................................................ 21 Figura 2 – Diagrama de Classe ......................................................................................... 29 Figura 3 – Diagrama de Sequência Efetuar Login ........................................................... 30 Figura 4 – Diagrama de Sequência Efetuar Logoff ........................................................... 30 Figura 5 – Diagrama de Sequência Visualizar Documento ............................................... 31 Figura 6 – Diagrama de Sequência Alterar Senha do Usuário .......................................... 31 Figura 7 – Diagrama de Sequência Incluir Usuário .......................................................... 32 Figura 8 – Diagrama de Sequência Incluir Documento .................................................... 32 Figura 9 – Diagrama de Sequência Gerar Relatório .......................................................... 33 Figura 10 – Arquitetura do Apache Lucene 2004 ............................................................. 42 Figura 11 – Principais processos do RI ............................................................................ 43 Figura 12 – Processos que envolvem indexação e busca .................................................. 44 Figura 13 – Processo de Indexação................................................................................... 45 Figura 14 – Processo de indexação de livros .................................................................... 45 Figura 15 – Processo de busca de livros ........................................................................... 47 Figura 16 – Divisões do Modelo Clássico ........................................................................ 49 LISTA DE TABELAS Tabela 1: Regra de Negócio (RN01) ................................................................................ 18 Tabela 2: Atores e funções ............................................................................................... 21 Tabela 3: Descrição do Caso de Uso (CSU001) ............................................................... 22 Tabela 4: Descrição do Caso de Uso (CSU002) ............................................................... 23 Tabela 5: Descrição do Caso de Uso (CSU003) ............................................................... 25 Tabela 6: Descrição do Caso de Uso (CSU004) ............................................................... 26 Tabela 7: Descrição do Caso de Uso (CSU005) ............................................................... 27 Tabela 8: Descrição do Caso de Uso (CSU006) ............................................................... 28 LISTA DE ABREVIATURAS ACID - Atomicity Consistency Isolation Durability ANSI - American National Standards Institute ASP - Active Server Pages CASE - Computer-Aided Software Engineering COLD- Computer Output to Laser Disk DDL - Data Definition Language DML - Data Manipulation Language EDMS- Engineering Document Management System EJB - Enterprise Java Beans ERM- Enterprise Report Management FTP - File Transfer Protocol GED- Gerenciamento Eletrônico de Documentos GIS - Geographic Information System GUI - Graphical User Interface HTTP - Hypertext Transfer Protocol IBM - International Business Machines IDE - Integrated Development Environment ISO - International Organization for Standardization JSP - JavaServer Pages JUDE - Java and Uml Developers’ Environment NCSA - National Center of Supercomputing Applications OMG - Object Management Group RI - Information Retrieval SOA - Arquitetura Orientada a Servicos SQL - Structured Query Language SRI - System of Information Retrieval UML - Unified Modeling Language XML - eXtensible Markup Language 10 SUMÁRIO 1 INTRODUÇÃO ........................................................................................................... 12 1.1 Motivação ................................................................................................................. 12 1.2 Justificativa ............................................................................................................... 12 1.3 Objetivo .................................................................................................................... 13 2 GERENCIAMENTO DE DOCUMENTOS .................................................................. 14 2.1 Evolução Histórica .................................................................................................... 14 2.2 Gerenciamento Eletrônico de Documentos ................................................................ 15 2.3 Principais Tipos de Solução de GED ......................................................................... 16 3 ALGORITMO DE RECUPERAÇÃO DAS INFORMAÇÕES ..................................... 18 3.1 Apache Lucene .......................................................................................................... 18 3.2 Processo de Indexação .............................................................................................. 20 3.3 Processo de Recuperação .......................................................................................... 22 3.3.1 Algoritmo de Busca ................................................................................................ 22 3.4 Ranqueamento ........................................................................................................... 23 3.5 Modelos de RI ........................................................................................................... 24 3.5.1 O modelo Booleano ................................................................................................ 25 3.5.2 O modelo Vetorial .................................................................................................. 25 3.6 Documentos Indexáveis ............................................................................................ 25 3.7 Outros frameworks .................................................................................................... 26 4 ANÁLISE DO SISTEMA DE GERENCIAMENTO DE DOCUMENTOS .................. 27 4.1 Metodologia .............................................................................................................. 27 4.2 Princípios de Orientação a Objetos............................................................................ 27 4.2.1 Objetos ................................................................................................................... 27 4.2.2 Classes e Instâncias ................................................................................................ 27 4.3 Requisitos Funcionais ............................................................................................... 28 11 4.4 Requisitos Não-Funcionais........................................................................................ 29 4.5 Regras de negócio ..................................................................................................... 29 5 MODELAGEM ............................................................................................................ 30 5.1 Modelagem baseada em UML ................................................................................... 30 5.2 Diagrama de Caso de Uso ......................................................................................... 30 5.2.1 Descrição dos atores do Caso de Uso ..................................................................... 32 5.2.2 Descrição dos Casos de Uso ................................................................................... 32 5.3 Diagrama de Classe .................................................................................................... 38 5.4 Diagrama de Sequência .............................................................................................. 39 6 IMPLEMENTAÇÃO DO SOFTWARE ....................................................................... 44 6.1 Ferramentas utilizadas no Projeto ............................................................................... 44 6.1.1 Linguagem de programação JAVA ......................................................................... 44 6.1.2 Plataforma ECLIPSE .............................................................................................. 45 6.1.3 Sistema Gerenciador de Banco de Dados PostgreSQL............................................ 45 6.1.4 Linguagem Estruturada SQL .................................................................................. 47 6.1.5 Servidor de Aplicação Web .................................................................................... 47 6.2 Ferramenta JUDE ...................................................................................................... 49 7 CONCLUSÃO ............................................................................................................. 51 12 1 INTRODUÇÃO 1.1 Motivação Com a necessidade cada vez mais crescente de fazer com que os variados tipos de informações existentes em acervos, tornem-se acessíveis a um número maior de pessoas de forma rápida e integrada, novas soluções tecnológicas são desenvolvidas, para capacitar o usuário a encontrar a informação que precisa. O volume de informações cresce diariamente, principalmente com o advento da internet. Assim, torna–se cada vez mais difícil a tarefa de busca da informação. Verificase uma quantidade muito grande de informações, que estão dispostas de maneira desorganizada, necessitando que o usuário analise-as exaustivamente até que encontre a informação de que necessita. O usuário, consequentemente, perde muito tempo tentando organizar estas informações para que possa assimilá-las corretamente ou para que possa encontrá-las mais rapidamente no futuro. Calvin Mooers, no início do ano de 1951, criou o termo “recuperação da informação” (RI), e também definiu os problemas dessa atividade: A recuperação da informação engloba tanto os aspectos intelectuais da descrição da informação e de sua especificação para a busca, como também os sistemas, técnicas ou equipamentos que são empregados para realizar a operação (MOOERS, 1959). 1.2 Justificativa Os sistemas de informação surgiram da popularização dos computadores, e se baseavam em técnicas de arquivamento e recuperação de informações de grandes arquivos. Existia a figura do "arquivador", que era a pessoa responsável em organizar os dados, registrá-los, catalogá-los e recuperá-los quando necessário. Um Sistema de Recuperação de Informação (SRI) pode ser definido como um conjunto de dados padronizados, armazenados em meio eletrônico, utilizados para identificar informação e fornecer sua localização (WELLISCH,1987). As principais vantagens de um sistema de informação bem construído são: otimização do fluxo de informação permitindo maior agilidade e organização, redução de 13 custos operacionais e administrativos e ganho de produtividade, maior integridade e veracidade da informação, maior estabilidade, maior segurança de acesso à informação. A explosão da informação se mantem forte: textos eletrônicos, bases de dados e redes difundiram-se, a demanda e a busca por informações cresceram exponencialmente e os problemas de recuperação da informação (RI) se multiplicaram. Isso explica a contínua pesquisa de RI, que configura-se uma área da computação associada ao armazenamento de documentos e a recuperação automática de informações. A RI pesquisa/busca por informações em documentos; pelos documentos propriamente ditos ou por metadados, ou seja, que descrevem documentos e buscam em um catálogo de indices. A área de Recuperação de Informação (RI) desenvolveu modelos para a representação de grandes coleções de textos que identificam documentos sobre tópicos específicos. Um sistema RI atua como se fosse um filtro sobre um conjunto de documentos, retornando ao usuário o resultado de um problema particular (REZENDE, 2005). 1.3 Objetivo Deste modo, este projeto sugere a utilização de um sistema capaz de mapear e encontrar a informação correta, confiável e em tempo hábil, agrupando automaticamente para o usuário. A presença de textos ou partes de textos não relevantes entre os arquivos consultados é praticamente certa. O principal objetivo de um sistema de RI é a recuperação de um número maior possível de documentos relevantes e o menor de documentos não relevantes. Assim, o objetivo final é o desenvolvimento de um sistema web que otimize o tempo de busca dos documentos que geralmente, são textos ou partes de textos impressos, arquivos digitais em diversos formatos como: Pacote Office, BR Office e pdf’s no formato OCR, entre outros. Nesse cenário, será permitido o controle das informações, retornando ao usuário o maior número possível de dados relevantes e o melhor gerenciamento dos documentos. Neste primeiro capítulo apresentamos a motivação do trabalho proposto, a justificativa e o objetivo. 14 2 GERENCIAMENTO DE DOCUMENTOS Neste capítulo, conceituaremos Gerenciamento Eletrônico de Documentos (GED), mostrando a evolução histórica das técnicas de gerenciamento de documentos, das tecnologias disponíveis e as principais questões pertinentes, tais como digitalização, indexação e frameworks. 2.1 Evolução Histórica A informação vem sendo registrada em papel há séculos gerando um volume imenso e que aumenta a cada dia. Ainda hoje, o papel é o maior problema operacional na maioria das empresas, órgãos governamentais e instituições. Para algumas empresas, dependendo da natureza e do tipo da informação, seu arquivamento e recuperação não são tarefa simples. Todos os tipos de formulários e documentos, são em sua grande maioria, processados manualmente. À partir de 1970, as grandes empresas já investiam em computador, apostando na agilidade na execução das atividades. Surgiu, então, a necessidade de desenvolver métodos para o aumento da produtividade nas empresas e principalmente, de melhorar a qualidade de sua produção. Segundo FRUSCIONE(1999), um dos mais fortes movimentos atuais da indústria de sistemas de informação é, sem dúvida, o acelerado crescimento da utilização de sistemas de gerência de documentos. Essa tecnologia vêm, cada vez mais, deixando de ser encarada como ferramenta para nichos específicos de mercado, e passando a ser vista como componente indispensável para a concepção e desenvolvimento de modernos sistemas de informação. Logo, a facilidade em armazenar, recuperar e conservar a integridade deste verdadeiro patrimônio intelectual torna-se um imperativo para manter as organizações produtivas e competitivas nos dias atuais. Segundo GATES (1999), as empresas que terão sucesso na década atual serão aquelas que utilizarem as ferramentas digitais para reinventar sua maneira de trabalhar. Essas empresas tomarão decisões com rapidez, atuarão com eficácia e vão atingir direta e positivamente seus clientes. 15 De acordo com STROPA(2010), o GED ou ECM (Enterprise Content Management) agiliza o processo de consulta de documentos através da imagem, auxilia o arquivamento e permite principalmente preservar o documento original, quando necessário além de dispor de trilhas de auditoria e rastreabilidade de acessos. 2.2 Gerenciamento Eletrônico de Documentos O Gerenciamento eletrônico de documentos (GED) provê um meio de facilmente gerar, controlar, armazenar, compartilhar e recuperar informações existentes em documentos. Os sistemas GED permitem aos usuários acessar os documentos de forma ágil e segura, normalmente via navegador web. Segundo a empresa de consultoria, Gartner Group, o Gerenciamento Eletrônico de Documentos (GED), é a tecnologia que provê um meio de facilmente armazenar, localizar e recuperar informações existentes em documentos e dados eletrônicos, durante todo o seu “Ciclo de Vida”, que consiste nas seguintes fases: criação; publicação e distribuição; uso ativo; pós-decisão; arquivo e descarte. Conforme BALDAM(2002), algumas razões para implementar um ambiente GED para o usuário e o cliente são: redução do tempo de processamento e manuseio do papel; aumento de satisfação do usuário; incremento à produtividade; melhoria da satisfação com o trabalho; acesso imediato e multiusuário a qualquer informação; melhoria da qualidade do trabalho; alta velocidade e precisão na localização de documentos; melhor atendimento ao cliente por proporcionar respostas mais precisas e instantâneas. Para a gestão documental: melhor controle dos documentos; redução do espaço físico de armazenagem; facilidade de implementar temporalidade documental; minimização de perda e extravio de documentos. Para a redução e proteção de investimentos: redução de custos com novos escritórios/depósitos/equipamentos; proteção do patrimônio; eliminação de retornos; proteção contra processos; eliminação de fraudes; proteção contra catástrofes que poderiam danificar o acervo. Segundo CANAVARRO(2003), uma das maiores vantagens do GED é a agilidade que os processos adquirem por conta das mudanças no acesso à informação. A velocidade com que ela passa a tramitar é um dos reflexos mais imediatos da digitalização, que torna uma 16 informação acessível simultaneamente para qualquer uma das partes envolvidas no processo, em qualquer lugar do mundo. 2.3 Principais Tipos de Solução de GED O foco principal do GED é gerenciar informação contida em documentos. Dependendo de algumas características particulares dos documentos, como: tipo físico, apresentação, tipo de uso desejado, etc., pode-se usar um outro tipo de aplicação de GED. As mais comumentes vistas no mercado e citadas por BALDAM (2002) são: processamento, arquivamento e recuperação de documentos (Document Imaging); gerenciamento de documentos (Document Management); Sistema de Gerenciamento de Documentos Técnicos (Engineering Document Management System – EDMS); Integração com outros sistemas de processamento de dados (Image Enable); ERM/COLD (Enterprise Report Management/Computer Output to Laser Disk); Processamento de formulários (Forms Processing) e Workflow. Usado normalmente para documentos prontos que não sofrerão mais alterações, o Document Imaging, sofre uma tendência muito grande de trabalhar com imagens, ou seja, documentos em papel que foram digitalizados(escanerizados) Já o Document Management, permite o controle do documento desde o momento de sua criação até o respectivo descarte (BALDAM, 2002). Um Sistema de Gerenciamento de Documentos Técnicos (EDMS) é aplicável a documentos ténicos: plantas, desenhos, especificações, relatórios, listas de materiais, normas de qualidade, etc. O Image Table, disponibiliza a imagem do documento junto ao processo do qual faça parte, para que complemente a informação necessária (BALDAM, 2002). O objetivo da aplicação ERM (Enterprise Report Management) é gerenciar relatórios oriundos de sistemas, como faturas de telefone, energia elétrica, água, etc. E o Processamento de Formulários (Forms Processing) são tecnologias aplicáveis na captura de dados de formulários, normalmente produzidos exclusivamente para este fim (BALDAM, 2002). O workflow, embora sempre associado com uma aplicação de GED, na realidade não o é. Trata-se de outra tecnologia e processo, não sendo o documento seu principal 17 componente. Normalmente entendido como “ferramenta que tem por finalidade automatizar processos, racionalizando-os e, consequentemente, aumentando a produtividade por meio de dois componentes implícitos: organização e tecnologia. workflow do inglês Fluxo de Trabalho, faz a informação necessária para cada atividade percorrer o processo previamente mapeado. workflow é essencialmente dinâmico” (CRUZ, 2000). 18 3 ALGORITMO DE RECUPERAÇÃO DAS INFORMAÇÕES As ferramentas de Recuperação de Informação, geralmente trabalham associadas a técnicas de indexação capazes de acessar e mapear rapidamente documentos em uma base de textos. Podem-se citar dois tipos de indexação utilizadas em conjunto com a Recuperação da Informação: indexação de texto completo e indexação por tags (REZENDE, 2005, p. 346). 3.1 Apache Lucene O Apache Lucene foi criado por Doug Cutting em 2000 e é um framework de alta performance, uma das mais famosas e mais usadas bibliotecas para indexação e busca textual, feito em Java, disponível em código aberto. Sob o domínio da Apache Foundation, a biblioteca, pode ser utilizada em qualquer aplicativo J2SE ou J2EE, de código aberto ou não. O Lucene oferece um agradável nível de abstração para um conjunto poderoso de técnicas baseadas no modelo Vetorial e Booleano. A biblioteca Lucene é composta por duas etapas: indexação e pesquisa. Baseando se em palavra-chave o algoritmo processa os dados gerando uma estrutura apta a realizar consultas. Abaixo a figura ilustra uma típica aplicação integrando o Lucene. Figura 10 – Arquitetura do Apache Lucene 2004 19 Lucene é de alta performance, escalável biblioteca de Recuperação da Informação (IR). Ele permite adicionar indexação e busca de recursos para seus aplicativos. Lucene é livre, tem projeto de código aberto implementado em Java, é um membro da Apache Jakarta popular família de projetos, licenciado sob a Apache liberal Licença de Software. Como tal, o Lucene é atualmente, e tem sido por alguns anos, a bibioteca gratuita mais popular Java IR (HATCHER, 2010). Lucene é um poderoso software que oferece um número de recursos de pesquisa. Lucene é usado para indexar e pesquisar dados armazenados em arquivos: páginas de web em servidores de Web remotos, documentos armazenados em sistemas locais de arquivo, arquivos de texto simples, documentos do Microsoft Word, HTML ou PDF, imagens, ou qualquer outro formato a partir do qual é possível extrair informações textuais (HATCHER, 2010). Para pesquisar grandes quantidades de texto rapidamente, deve-se primeiro indexar o texto e convertê-lo em um formato que vai deixá-lo rápido na busca, eliminando o processo sequencial e varrimento lento. Este processo é chamado de indexação, e sua saída é chamada de índice. Busca é o processo de procurar palavras em um índice para localizar documentos onde aparecem. A qualidade de uma pesquisa é normalmente descrita usando precisão e métricas de recall. Para mostrar indexação e capacidade de procura, um par de comando aplicações é utilizado Indexer e Searcher (HATCHER, 2010). Há basicamente duas funcionalidades importantes: • Processo de indexação • Processo de busca Figura 11 – Principais processos do RI 20 Figura 12 – Processos que envolvem indexação e busca 3.2 Processo de Indexação Quando usamos uma consulta básica, uma opção óbvia é usar a busca online, isto é, varrer o texto seqüencialmente, procurando pelas ocorrências dos termos da consulta. A busca online é apropriada quando trabalhamos com pequenos textos e é a única opção quando a coleção de textos é muito volátil, isto é, suscetível a alterações freqüentes ou quando não é possível armazenar o índice por falta de espaço (BAEZA-YATES e RIBEIRO-NETO, 1999, p.191). A indexação com o Lucene é dividida em 3 operações principais: converter data para texto; analisar o texto e salvar o texto para formar o índice. É possível que documentos com diferentes conjuntos de campos possam coexistir no mesmo índice. A figura 11 ilustra o processo de indexação. 21 Figura 13 – Processo de Indexação Figura 14 – Processo de indexação de livros 22 3.3 Processo de Recuperação Usando uma interface gráfica, o usuário descreve o que ele deseja procurar e o sistema processa esses dados, executando operações de texto e de consulta. O resultado é a tradução do que está sendo procurado pelo usuário em uma consulta. O sistema efetua uma busca sobre os índices e gera um ranqueamento, podendo avaliar o grau de relevância do registro recuperado. 3.3.1 Algoritmo de Busca O algoritmo de busca em um arquivo invertido pode ser dividido geralmente em três etapas: • Busca no vocabulário: as palavras e padrões presentes na consulta são isoladas em termos simples e procuradas no vocabulário; • Recuperação das ocorrências: a lista de ocorrências de todos os termos da consulta é recuperada; • Manipulação das ocorrências: as ocorrências são processadas para encontrar frases, resolver relações de proximidade e operações booleanas. Para Baeza-Yates e Ribeiro-Neto (1999, p. 196), o custo de resolver consulta é sublinear ao tamanho do texto. A complexidade é de O(nα), onde α varia conforme a consulta. Na prática, arquivos invertidos permitem realizar buscas em tempo sublinear, com espaço também sublinear. A construção e manutenção de um arquivo invertido são tarefas de custo relativamente baixo. Um arquivo invertido pode ser construído em tempo linear ao tamanho do texto. Todo o vocabulário conhecido até então é armazenado em uma estrutura de dados trie, que contém para cada palavra, uma lista de suas ocorrências. Uma trie é essencialmente uma árvore enária, cujos nós são vetores de M posições com componentes correspondendo a dígitos ou caracteres. Cada nó no nível l representa o conjunto de todas as chaves que começam com certa seqüência de l caractere. O nó especifica um ramo de M-vias, dependendo do (l+1)-ésimo caractere (KNUTH, 1973, p. 481). 23 A interface de pesquisa básica que Lucene fornece é tão simples como o para indexação. Apenas algumas classes são necessárias para executar a operação de pesquisa básica: De acordo com Queiroz (2005), a linguagem SQL é formada por duas sublinguagens: • IndexSearcher • Term • Query • TermQuery • Hits Figura 15 – Processo de busca de livros 3.4 Ranqueamento Um dos problemas centrais de sistemas de RI é saber quais documentos são relevantes à busca do usuário e quais não são. Esta tomada de decisão é feita geralmente por um algoritmo de ranqueamento que procura estabelecer uma ordenação crescente dos resultados obtidos: os primeiros documentos dessa ordenação são mais relevantes. (BAEZAYATES e RIBEIRO-NETO, 1999, p. 19) 24 Um algoritmo de ranqueamento, portanto, depende de um conjunto de premissas que julgam o nível de relevância de um documento. Isto significa que diferentes conjuntos de premissas geram diferentes modelos de RI. 3.5 Modelos de RI Os modelos clássicos consideram que cada documento é descrito como um conjunto de palavras-chave denominadas termos de índices. Um termo de índice é uma palavra cuja semântica resume o conteúdo de um documento. Para cada termo, pode-se atribuir um peso, isto é, um valor numérico que indicará o grau de relevância daquele termo ao descrever o conteúdo semântico de um documento. Existem três modelos clássicos na RI: os modelos booleano, vetorial e probabilístico. Além deles, existem também modelos alternativos que tentam refinar ou introduzir novos conceitos, mas neste trabalho nossa ênfase está no modelo vetorial por ser o mais utilizado. Figura 16 – Divisões do Modelo Clássico 25 3.5.1 O modelo Booleano O modelo Booleano é um modelo simples baseado na teoria dos conjuntos e na álgebra Booleana. As consultas são definidas por meio de expressões Booleanas compostas por termos de índice e os conectores not, and e or. Tais expressões podem ser representadas na forma disjuntiva normal (DNF). Neste modelo, os termos de índice ou estão presentes num documento ou não estão, portanto, os pesos dos termos de índice assumem valores binários. O modelo Booleano diz se cada documento é relevante ou não, ou seja, não existe a noção de parcialidade na verificação das condições da consulta. As vantagens do modelo Booleano são a simplicidade e o formalismo claro subjacente ao modelo. No entanto, a simplicidade do critério binário de decisão acaba restringindo a qualidade dos resultados obtidos, retornando um conjunto de documentos ou muito pequeno ou muito grande. Além disso, apesar da semântica das expressões booleanas ser clara, traduzir uma requisição de informação para uma expressão booleana nem sempre é uma tarefa simples, principalmente para usuários comuns. 3.5.2 O modelo Vetorial O modelo vetorial é um modelo algébrico para representar os termos de índices dos documentos e das consultas num espaço vetorial. Associado a cada um dos termos, atribui-se um peso, um valor não binário (ao contrário do modelo booleano) que, posteriormente, será utilizado no cálculo do grau de similaridade entre o documento armazenado no sistema e a consulta do usuário. Assim, dada uma consulta, o modelo vetorial avalia de forma ponderada o quanto um documento é relevante, possibilitando uma correspondência parcial entre a consulta e o documento, fato que não ocorre no modelo booleano. 3.6 Documentos Indexáveis • HTML (CyberNeko HTML Parser, JTidy, TagSoup, Jericho HTML Parser, TextExtractor); • XML (deve-se fazer o parse); • Arquivos Openoffice; 26 • Word, Excel, PowerPoint, Vision; • Pdf’s no formato OCR. 3.7 Outros frameworks Existem outros frameworks como o Microsoft Indexing Service que é um nível de serviço do sistema operacional que mantém um índice da maioria dos arquivos em um computador e os atualiza, sem intervenção do usuário. Necessita de licença por ser um serviço da plataforma Windows, sendo este, o principal motivo para descartá-lo. O próximo capítulo refere-se à etapa de análise, apresentando o levantamento de requisitos e as regras de negócio, o princípio de orientação a objetos, classes e instâncias. 27 4 ANÁLISE DO SISTEMA DE GERENCIAMENTO DE DOCUMENTOS Neste capítulo serão apresentados a metodologia do sistema, os levantamentos de requisitos funcionais e não funcionais do sistema. 4.1 Metodologia Foi aplicado o Paradigma da Orientação a Objeto para análise e modelagem do sistema. Com o intuito de desenvolver a proposta do projeto foi escolhida a linguagem de modelagem UML(Unified Modeling Language). Suas vantagens são: unificação entre dados e processos, consistência entre análise e desenvolvimento, reutilização de código, multidesenvolvimento e facilidade de manutenção. 4.2 Princípios de Orientação a Objetos A proposta de orientação a objetos é permitir que os programadores organizem os programas da mesma forma que as nossas mentes enxergam os problemas: não como um conjunto de espaços de memória, mas como um conjunto de coisas que fazem parte do problema (MATOS, 2003). 4.2.1 Objetos Em se tratando de programação, objetos são entidades abstratas.Trata-se de um agrupamento de características e ações de uma entidade. Essas características são agrupadas de forma que possamos identificar outros objetos parecidos. Por outro lado, suas ações ajudam também a classificar outras entidades como objetos semelhantes a ele (MATOS, 2003). 4.2.2 Classes e Instâncias Uma classe nada mais é que a criação de uma estrutura geral de onde objetos podem ser derivados. Em analogia com jargões de computação, uma classe seria o tipo de 28 dados de onde variáveis pudessem ser criadas. Em orientação a objetos, essas “variáveis” são instâncias de classes, ou seja, objetos (MATOS, 2003). A instância é o objeto criado baseando-se em uma classe já definida, cada instância de uma classe tem seus próprios valores para atributo. 4.3 Requisitos Funcionais Requisitos Funcionais são aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema. RF1. O sistema permitirá incluir, alterar e excluir os dados. Cada documento possui os seguintes atributos: código do registro, título, subtítulo, volume/exemplar, descrição, data da publicação, palavra-chave, data do cadastro e tipo de documento. O sistema deve atribuir um identificador único a cada documento. RF2. O sistema permitirá que o administrador incluir, alterar e excluir os dados de um usuário com os seguintes atributos: conta, senha, nome e email. RF3. O sistema deverá emitir os seguintes relatórios: • Lista dos usuários cadastrados; • Lista dos tipos de documentos. RF4. O sistema deverá conter um usuário do tipo Administrador, que será responsável pela manutenção. RF5. O sistema deverá permitir que o usuário altere sua senha. RF6. O sistema deverá permitir a consulta e exibição dos documentos, com os seguintes campos para a consulta: código do registro, título, subtítulo, volume/exemplar, descrição, data da publicação, palavra-chave, data do cadastro e tipo de documento. 29 4.4 Requisitos Não-Funcionais Os Requisitos Não-Funcionais fazem parte do desenvolvimento do software como custo, performance, confiabilidade, manutenibilidade, portabilidade, custos operacionais, entre outros. RNF1. A base de dados deve ser protegida para acesso apenas de usuários autorizados. RNF2. O tempo de resposta do sistema não deve ultrapassar 60 segundos. RNF3. O sistema utilizará plataforma Windows. RNF4. O sistema deverá ser capaz de ler os formatos: Pacote Office, BR Office e pdf’s no formato OCR. 4.5 Regras de negócio “Regras de negócio são políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização”. (BEZERRA, 2007 apud GOTTESDIENER, 1999). Algumas regras de negócio iniciais que foram identificadas no sistema e são listadas e detalhadas nos quadros a seguir: Tabela 1 – Regra de Negócio (RN01) Descrição Verificação de usuários cadastrados (RN01) Só serão permitidas consultas de documentos para os usuários com login e senha pré-cadastrados no sistema. Fontes Administrador Histórico Data de Identificação: 16/05/2010 Prosseguiremos com a modelagem do Sistema LMR baseada na linguagem de modelagem UML (Unified Modeling Language). São apresentados também os Diagramas de Casos de Uso, de Classes e de Sequências. 30 5 MODELAGEM Neste projeto será utilizada a modelagem baseada em UML, que tem como finalidade, explicar as características e o comportamento de um sistema. 5.1 Modelagem baseada em UML A UML (Unified Modeling Language) é uma linguagem unificada de modelagem visual para sistemas orientados a objetos, sendo empregada para a visualização, especificação, construção e documentação de sistemas de softwares. Segundo Gerchman (2006, p.1), “A linguagem UML é mantida pelo OMG (Object Management Group), entidade que agrupa diversas empresas e indivíduos atuantes na área de análise e projeto de software”. “A UML se limita, exclusivamente, a representar um sistema através de um conjunto de diagramas, onde cada diagrama se refere a uma visão parcial do sistema através de um conjunto de diagramas, onde cada diagrama se refere a uma visão parcial do sistema, que em conjunto forma um todo integrado e coerente”. (DEBONI, 1998, p.1). Os diagramas são uma apresentação gráfica para demonstrar os diversos tipos de modelagem pela UML. Os diagramas apresentam cada visão e contém informações sobre particularidades do sistema. Existem nove diagramas disponibilizados pela UML: diagrama de casos de uso, classes, objetos, estado, seqüência, colaboração, atividade, componente e execução (FURLAN, 1998). Para desenvolver o projeto, 3 diagramas foram fundamentais. São eles: Diagramas de casos de uso, diagrama de classe e diagrama de sequência. 5.2 Diagrama de Caso de Uso A modelagem de um Diagrama de Caso de Uso é uma técnica usada para descrever e definir os requisitos funcionais de um sistema. São escritos em termos de atores externos, caso de uso e o sistema modelado. Para representar uma entidade externa do sistema são utilizados atores como usuário, hardware, ou outros sistemas que interagem com o sistema modelado. Os atores, através dos casos de uso, iniciam uma 31 comunicação com o sistema, no qual o caso de uso seria a representação de uma sequência de ações que são executadas pelo sistema. Em essência, um Caso de Uso é uma interação típica entre um usuário e um sistema, um modo específico de utilização a partir de um ponto de vista segmentado de funcionalidade (FURLAN, 1998). Formalmente falando, caso de uso, segundo a UML, é: “um conjunto de sequências de ações que um sistema desempenha para produzir um resultado observável de valor a um ator específico” (FURLAN, 1998). Na figura 1, é apresentado o Diagrama de Caso de Uso do LMR. Nele são apresentados os Casos de Uso: CSU01 - Efetuar Login; CSU02 – Administrar Usuário; CSU03 – Manter Documentos; CSU04 – Visualizar Documentos; CSU05 – Gerar Relatórios; CSU06 – Efetuar Logoff. Figura 1 – Diagrama de Casos de Uso 32 5.2.1 Descrição dos atores do Caso de Uso Opcionalmente, os atores que participam da realização do caso de uso podem ser apresentados no diagrama de seqüência. Os atores são representados com a mesma notação gráfica utilizada no diagrama de casos de uso (MATOS, 2003). Baseando-se nos problemas requisitos e necessidades levantadas, os atores identificados no projeto são apresentados e detalhados na tabela abaixo. Tabela 2 – Atores e funções Ator Administrador Descrição Responsável por inserir arquivos no banco de dados do sistema; Gerenciamento de usuários; Manutenção do site; Atualização de dados. Usuário Qualquer pessoa que tenha interesse em consultar arquivos; visualiza os dados consultados, e esteja cadastrado no sistema. 5.2.2 Descrição dos Casos de Uso A seguir são apresentadas as descrições dos Casos de Uso no formato real e expandido. Tabela 3 – Descrição do Caso de Uso (CSU001) Efetuar Login (CSU001) Sumário: Este caso de uso possibilita ao usuário efetuar o login para acessar o sistema. Ator Primário: Usuário Pré-Condição: O usuário está cadastrado no sistema. Fluxo Principal: 1. O caso de uso tem início quando um usuário acessa o sistema através 33 de um navegador web. 2. O sistema solicita o login e a senha do usuário. 3. O usuário informa seu login e senha. 4. O sistema valida as informações apresentadas. 5. O sistema define as permissões de acesso. 6. O sistema permite o acesso e o caso de uso termina. Fluxo de Exceção (3): Login ou senha inválidos a. O usuário informa login ou senha inválidos. b. O sistema exibe uma mensagem de erro e o caso de uso retorna ao passo 2. Pós-Condições: Efetuar identificação com sucesso e acessar os serviços do sistema. Tabela 4 – Descrição do Caso de Uso (CSU002) Administrar Usuário (CSU002) Sumário: O administrador realiza o cadastro (inclusão, exclusão, alteração e consulta) dos dados do usuário no sistema. Ator Primário: Administrador Ator Secundário: Usuário Pré-Condição: O administrador está autenticado pelo sistema. Fluxo Principal: 1. O administrador realiza a manutenção do cadastro dos usuários. 2. O sistema apresenta as operações que podem ser realizadas: a inclusão, a alteração, a exclusão e a consulta dos usuários. 3. de uso. O administrador indica a opção a realizar ou opta por finalizar o caso 34 4. O administrador seleciona a opção desejada: Inclusão, Exclusão, Alteração ou Consulta. 5. Se o administrador deseja continuar com a manutenção, o caso de uso retorna ao passo 2; caso contrário, o caso de uso termina. Fluxo Alternativo (4): Inclusão a. O administrador requisita a inclusão de um usuário. b. O sistema apresenta um formulário em branco para que os dados do usuário (conta, senha, nome e e-mail) sejam incluídos. c. O administrador fornece os dados do novo usuário no sistema. d. O sistema verifica a validade dos dados: • Se dados forem válidos, inclui o novo usuário; caso contrário, o sistema reporta o fato solicita novos dados e repete a verificação. • Se os dados incluídos já existirem, o sistema informa que o usuário é cadastrado e retorna a opção a. Fluxo Alternativo (4): Exclusão a. O administrador realiza a pesquisa do usuário que se deseja excluir. b. O sistema realiza a remoção e o usuário deixa de existir no banco de dados. Fluxo Alternativo (4): Alteração a. O administrador realiza a pesquisa do usuário que se deseja alterar. b. O administrador altera um ou mais dados sobre do usuário e requisita a sua atualização. c. O sistema verifica a validade dos dados e, se eles forem válidos, altera os dados no sistema; caso contrário o sistema reporta o fato. Fluxo Alternativo (4): Consulta a. O administrador solicita a realização de uma consulta sobre o usuário. b. O sistema apresenta uma listagem com o nome de todos os usuários 35 cadastrados, permitindo que o administrador selecione o usuário desejado. c. O administrador seleciona um usuário. d. O sistema apresenta os dados do usuário em seu formulário. Pós-Condições: Um usuário foi incluído ou excluído, ou seus dados foram alterados ou consultados. Tabela 5 – Descrição do Caso de Uso (CSU003) Manter Documentos (CSU003) Sumário: Este caso de uso realiza o cadastro (inclusão, exclusão, alteração e consulta) dos documentos no sistema. Ator Primário: Administrador Pré-Condição: O administrador está autenticado pelo sistema. Fluxo Principal: 1. O administrador realiza a manutenção do cadastro dos documentos. 2. O sistema apresenta as operações que podem ser realizadas: a inclusão, a alteração, a exclusão e a consulta dos documentos. 3. O administrador indica a opção a realizar ou opta por finalizar o caso 4. O administrador seleciona a opção desejada: Inclusão, Exclusão, de uso. Alteração ou Consulta. 5. Se o administrador deseja continuar com a manutenção, o caso de uso retorna ao passo 2; caso contrário, o caso de uso termina. Fluxo Alternativo (4): Inclusão a. O administrador requisita a inclusão de um documento. b. O sistema apresenta um formulário em branco para que os dados do documento (código do registro, título, subtítulo, volume/exemplar, descrição, data da publicação, palavra-chave, data do cadastro e tipo de documento) sejam incluídos. 36 c. O administrador fornece os dados do novo documento. d. O sistema verifica a validade dos dados. Se dados forem válidos, inclui o novo documento; caso contrário, o sistema reporta o fato solicita novos dados e repete a verificação. Fluxo Alternativo (4): Exclusão a. O administrador realiza a pesquisa do documento que se deseja b. O sistema realiza a remoção e o documento deixa de existir no banco excluir. de dados. Fluxo Alternativo (4): Alteração a. O administrador realiza a pesquisa do documento que se deseja alterar. b. O administrador altera um ou mais dados sobre um documento e requisita a sua atualização. c. O sistema verifica a validade dos dados e, se eles forem válidos, altera os dados no sistema; caso contrário o sistema reporta o fato. Fluxo Alternativo (4): Consulta a. O administrador solicita a realização de uma consulta sobre o conteúdo dos documentos. b. O sistema apresenta uma listagem com todos os documentos cadastrados, permitindo que o administrador selecione o documento desejado. c. O administrador seleciona um documento. d. O sistema apresenta os dados do documento em seu formulário. Pós-Condições: Um documento foi incluído ou excluído, ou seus dados foram alterados ou consultados. 37 Tabela 6 – Descrição do Caso de Uso (CSU004) Visualizar Documentos (CSU004) Sumário: Este caso de uso permite ao usuário visualizar todos os documentos cadastrados no sistema. Ator Primário: Usuário Pré-Condição: O usuário está autenticado pelo sistema. Fluxo Principal: 1. O usuário solicita a visualização dos documentos cadastrados no 2. O sistema apresenta uma lista com todos os documentos. 3. O usuário seleciona o documento que deseja visualizar. 4. O sistema exibe os dados do documento selecionado. 5. O usuário visualiza o documento e o caso de uso termina sistema. Tabela 7 – Descrição do Caso de Uso (CSU005) Gerar Relatório (CSU005) Sumário: Este caso de uso permite ao administrador gerar os relatórios de todos os documentos e usuários cadastrados no sistema. Ator Primário: Administrador Pré-Condição: O administrador está autenticado pelo sistema. Fluxo Principal: 1. O administrador solicita a visualização dos relatórios do sistema. 2. O sistema exibe uma lista com todos os relatórios gerados. 3. O administrador seleciona o relatório que deseja visualizar. 4. O sistema exibe o relatório selecionado. 5. O administrador visualiza o relatório gerado, podendo imprimi-lo, e o 38 caso de uso termina. Tabela 8 – Descrição do Caso de Uso (CSU006) Efetuar Logoff (CSU006) Sumário: Este caso de uso possibilita ao usuário efetuar o logoff para sair do sistema. Ator Primário: Usuário Pré-Condição: O usuário está autenticado pelo sistema. Fluxo Principal: 1. O usuário seleciona a opção sair do sistema. 2. O sistema finaliza a sessão e as suas funções. 3. O sistema volta para a tela principal sem estar com o login do usuário ativo e o caso de uso termina. Fluxo Alternativo (1) a. Usuário sai do navegador e o sistema é encerrado automaticamente. 5.3 Diagrama de Classe Diagrama de classe descreve as classes formadoras que estruturam o sistema e suas relações. As relações existentes das classes podem ser associações, agregações ou heranças. As classes, além de possuírem um nome, têm também os atributos e as operações que são desempenhadas para o sistema. (DEBONI,1998). A relação é indicada de acordo com a dependência entre as classes, esta “pode ser forte como no caso da herança ou da agregação ou mais fraca como no caso da associação, mas indicam que as classes relacionadas cooperam de alguma forma para cumprir um objetivo para o sistema”. (DEBONI,1998, p.4). A seguir, é apresentado o Diagrama de Classe do sistema proposto com seus atributos e operações. 39 Figura 2 – Diagrama de Classe 5.4 Diagrama de Sequência “O Diagrama de Seqüência de eventos permite modelar estes processos através da troca de mensagens (eventos) entre os objetos do sistema. Os objetos são representados por linhas verticais e as mensagens como setas que partem do objeto que invoca outro objeto”. (DEBONI,1998). A seguir, são apresentados os Diagramas de Sequência do Sistema Gerenciador de Documentos LMR: 40 Figura 3 – Diagrama de Sequência Efetuar Login Figura 4 – Diagrama de Sequência Efetuar Logoff 41 Figura 5 – Diagrama de Sequência Visualizar Conteúdo Figura 6 – Diagrama de Sequência Alterar Senha do Usuário 42 Figura 7 – Diagrama de Sequência Incluir Usuário Figura 8 – Diagrama de Sequência Incluir Documento 43 Figura 9 – Diagrama de Sequência Gerar Relatório O próximo capítulo são apresentadas as ferramentas que serão utilizadas no projeto, assim como, as telas do sistema. 44 6 IMPLEMENTAÇÃO DO SOFTWARE 6.1 Ferramentas utilizadas no Projeto Ferramentas de Implementação: 6.1.1 Linguagem de programação JAVA Java é uma linguagem de programação orientada a objetos desenvolvida pela Sun Microsystems. A linguagem foi projetada para ser pequena, simples e portável a todas as plataformas e sistemas operacionais, tanto o código fonte como os binários. Esta portabilidade é obtida pelo fato da linguagem ser interpretada, ou seja, o compilador gera um código independente de máquina chamado byte-code. No momento da execução este byte-code é interpretado por uma máquina virtual instalado na máquina. Para portar Java para uma arquitetura hadware/s específica, basta instalar a máquina virtual (interpretador). Além de ser integrada à Internet, Java também é uma excelente linguagem para desenvolvimento de aplicações em geral. Dá suporte ao desenvolvimento de software em larga escala. “A linguagem Java utiliza a metodologia orientada a objetos, dando-nos a possibilidade de criar programas flexíveis e modulares, além de reutilizar códigos já criados.” (SOMERA, 2007, p.8). Segundo Deitel (2010), a linguagem Java é utilizada para criar páginas da web com conteúdo interativo e dinâmico, para desenvolver aplicativos corporativos de grande porte, para aprimorar a funcionalidade de servidores da World Wide Web (os computadores que fornecem o conteúdo que nossos navegadores da Web), fornecer aplicativos para dispositivos destinados ao consumidor final (como telefones celulares, Pager e assistentes pessoais digitais) e para muitas outras finalidades. Algumas vantagens levantadas para o uso da linguagem Java são: orientada a objetos, multiplataforma, multi-thread, segura, free, versátil e sem ponteiros. 45 Comparamos com outras linguagens, como ASP e verificamos desvantagens em relação ao Java, tais como: não é utilizado em múltiplos servidores web, dependência a plataforma Microsoft Internet Information Server (IIS) e não tem licença gratuita. 6.1.2 Plataforma ECLIPSE O Eclipse é uma plataforma para integração de ferramentas construídas por uma comunidade aberta de provedores. Escrita completamente em Java, a plataforma pode ser utilizada em estações de desenvolvimento que incluam os sistemas operacionais Linux, QNX, OSx e Windows. (MECENAS, 2004). Eclipse é um multi-idioma ambiente de desenvolvimento de software que inclui um ambiente de desenvolvimento integrado (IDE) e uma extensível plug-in do sistema. É escrito principalmente em Java e pode ser usado para desenvolver aplicações em Java e, por meio de diversos plug-ins, outras linguagens, incluindo C , C ++ , COBOL , Python , Perl e PHP. A principal característica da plataforma Eclipse é sua extrema capacidade de descobrir, integrar e rodar plug-ins. Plug-ins são pequenas unidades funcionais, codificadas em Java, normalmente desenvolvidas e distribuídas separadamente, que podem ser facilmente acopladas ao ambiente Eclipse. Comparamos com outras ferramentas como JBuilder, porém esta, tem como grande desvantagem o fato de não ser um software livre. Outra opção encontrada seria o NetBeans que também possui desvantagens como: poucos templates de código, código não alterável no GUI Builder do NetBeans, pouco controle no código da aplicação por parte do desenvolvedor, a IDE gera código automaticamente sem que o desenvolvedor o conheça e pouco controle sobre a criação de projetos via clicks. 6.1.3 Sistema Gerenciador de Banco de Dados PostgreSQL O PostgreSQL é um Sistema Gerenciador de Banco de Dados (SGBD) relacional e orientado a objeto, de código aberto e disponível gratuitamente. “É uma ferramenta encarregada de armazenar dados e gerenciar o acesso de cada informação de acordo com regras previamente definidas.” (MILANI, 2008, p.26) 46 O PostgreSQL, conhecido anteriormente como Postgres95, derivou do projeto Postgres na Universidade de Berkley por Michael Stonebraker.(CASTILHO, 2007) É um programa licenciado sobre as normas BSD (Berkeley Software Distribution), o que torna o seu código fonte disponível e o seu uso livre para aplicações comerciais ou não (ABADE, 2004). Segundo Abade (2004) o PostgreSQL é um banco de dados robusto, confiável, flexível e possui vários recursos fáceis de serem utilizados. “O objetivo básico do PostgreSQL é o armazenamento de dados de modo organizado e gerenciável, permitindo a guarda e o resgate de dados e informações de maneira rápida, segura e eficiente.” (ABADE, 2004, p. 12) Características do banco de dados PostgreSQL: • Exporta em XML (eXtensible Markup Language); • Suporte a transações ACID (Atomicity Consistency Isolation Durability); • Número ilimitado de linhas e índices em tabelas; • Extensão para GIS (Geographic Information System); • Interface Gráfica de Gerenciamento; • Uso otimizado de recursos do sistema operacional; • Backup online; • Suporte a conexão de banco de dados seguras (criptografia). Um dos principais diferenciais do PostgreSQL está na manipulação de “transactions” de forma padrão, enquanto para que outros sistemas como o MySQL possa realizar este tipo de operação deve ser utilizada outra. Em termos de clusterização, ambos os gerenciadores apresentam recursos muito interessantes para ambientes grandes e de alta disponibilidade, porém em ambientes onde existe um alto volume de transações por segundo o PostgreSQL apresenta uma escalabilidade maior amenizando assim o impacto na performance do sistema, já o MySQL trata todas as requisições de forma bastante robusta porém apresentando uma carga um pouco maior no servidor.De modo geral, em sistemas transacionais com consultas complexas e alto nível de processamento o 47 PostgreSQL é uma solução mais robusta que apresenta alta performance e escalabilidade. Já o MySQL é recomendável para sistemas com consultas mais simples e com alto número de consultas, apresentando alta performance e com administração mais simplificada. 6.1.4 Linguagem Estruturada SQL A linguagem SQL (Structured Query Language) foi desenvolvida pelo departamento de pesquisas da IBM (International Business Machines) no início dos anos 70 como uma linguagem de manipulação de dados (DML – Data Manipulation Language) quando foram desenvolvidas as primeiras idéias para o desenvolvimento de bancos de dados relacionais. (REIS, 1999) Segundo Reis (1999), a linguagem SQL em 1986, tornou-se uma linguagem padrão para banco de dados relacionais, publicado pela ANSI (American National Standards Institute) e retificado pela ISO (International Organization for Standardization) em 1987. De acordo com Queiroz (2005), a linguagem SQL é formada por duas sublinguagens: • Linguagem de definição de dados (DDL): possui comandos para que os dados a serem armazenados sejam definidos, estruturados e organizados; • Linguagem de manipulação de dados (DML): apresenta comandos para consulta, inclusão, exclusão e alteração de dados no banco de dados de maneira simultânea 6.1.5 Servidor de Aplicação Web Um servidor de aplicação ou em inglês, application server, é um servidor que disponibiliza um ambiente para a instalação e execução de certas aplicações. Os servidores de aplicação também são conhecidos como software de middleware. O objetivo do servidor de aplicações é disponibilizar uma plataforma que abstraia do desenvolvedor de software algumas das complexidades de um sistema computacional. No desenvolvimento de aplicações comerciais, por exemplo, o foco dos desenvolvedores 48 deve ser a resolução de problemas relacionados ao negócio da empresa, e não de questões de infraestrutura da aplicação. Por fim, têm que ser aplicações mais elaboradas, que assegurem níveis aceitáveis de integridade, confiabilidade, disponibilidade, desempenho e segurança. Permite centralizar uma ou mais aplicações sem que seja necessário instalá-la em todas as máquinas – clientes. Permite a execução de aplicação remota, pode-se usar um aplicativo que não esteja fisicamente instalado na máquina-cliente. (FOURNIER,1999). Optamos em utilizar o GlassFish que é um servidor de aplicação desenvolvido pela Sun Microsystems para a plataforma Java Enterprise Edition (Java EE). O GlassFish é o projeto mais ativo do java.net e um dos maiores projetos de código aberto que existem, em qualquer categoria. Enquanto um servidor de aplicação relativamente nova, GlassFish já é utilizado por um grande número de desenvolvedores e corporações. (GONÇALVES, 2009) É um servidor de aplicações, rápido e fácil de usar para o desenvolvimento e entrega de aplicações e serviços web, de código aberto, de nível corporativo que oferece desempenho, confiabilidade, produtividade e facilidade de uso superiores a uma fração do custo de servidores de aplicações proprietários. Como a implementação de referência Java EE é construída em código aberto, o GlassFish elimina a dependência de fornecedores, e permite que clientes aproveitem os mais recentes padrões e inovações do setor. (DOEDERLEIN, 2007) Características do Glassfish: Compatível com Java EE 5, melhora a produtividade do desenvolvedor, reduzem a quantidade de código que os desenvolvedores devem escrever, fundação para SOA (arquitetura orientada a serviços) e código aberto. (DOEDERLEIN, 2007) Uma outra alternativa, seria utilizar o Tomcat, que também é um servidor de aplicação web Java e de código aberto e que foi desenvolvido dentro do conceituado projeto pela Apache Software Foundation e que teve apoio e endosso oficial da Sun Microsystems. Tem como características principais: a capacidade de atuar também como servidor web, e também pode funcionar integrado a um servidor web dedicado como o Apache ou o IIS. Como servidor web, ele provê um servidor web HTTP puramente em Java. O Tomcat é robusto e eficiente o suficiente para ser utilizado mesmo em um ambiente de produção, porém não atende por não suportar tecnologias como o EJB (Enterprise Java Beans). 49 Ferramenta de modelagem: 6.2 Ferramenta JUDE A ferramenta Case (Computer-Aided Software Engineering) “abrange toda ferramenta baseada em computador e que auxilia atividades de engenharia de software, desde análise de requisitos e modelagem até programação e testes.” (SOMERA, 2007, p.26) A ferramenta JUDE (Java and Uml Developers’ Environment) é uma ferramenta case para modelagem UML, criada pela empresa japonesa ChangeVision. É uma ferramenta de código aberto com características que outras ferramentas open source não possuem, como adição de mensagens no diagrama de seqüência, sendo propagada através de alterações que se refletem no diagrama de classe. Segundo Pimenta (2010), esta ferramenta apresenta as seguintes funções básicas: desenvolvimento do Diagrama de Classe, Diagrama de Casos de Uso, Diagrama de Seqüência, Diagrama de Comunicação, Diagrama de Estado, Diagrama de Atividade, Diagrama de Componente, Diagrama de Implantação, Diagrama de Objetos e Diagrama de Pacotes. Permite, ainda, a criação de modelos a partir da importação de código Java através da funcionalidade Java Reverse (Importação de código Java para criar modelo) e a partir do desenvolvimento de modelos gerando código Java através da função Java Forward (Geração de código Java a partir do modelo). Existem outras ferramentas que poderiam ser utilizadas, como a Rational Rose Data Modeler, da IBM que fornece ambiente de modelagem sofisticado mas por estar disponível apenas para compra de licença, descartamos o seu uso. 6.3 Telas do site ( falta fazer) Anexa as telas aqui ou em anexos?! Tela principal do sistema: Contém um agrupamento de informações do sistema. Pesquisa - localizada na barra de menus. As palavras digitadas neste campo de pesquisa são procuradas em todas as fichas cadastradas no LMR. 50 Cadastro - o formulário para preenchimento da mesma será aberto e o usuário preencherá os campos para cadastramento. 51 7 CONCLUSÃO O Sistema de Gerenciamento de Documentos LMR objetiva otimizar todo processo de busca da informação. Sua implementação buscará satisfazer as necessidades dos usuários. Foram elaborados o levantamento e análise dos requisitos, a modelagem com desenvolvimento dos modelos de Caso de Uso, modelo de Classes e diagrama de seqüência durante a etapa de Análise. A implementação do sistema web proposto utilizará ferramentas como Java, Eclipse, Sistema Gerenciador de Banco de Dados, PostgreSQL e servidor web Apache, que são ferramentas livres, portanto de fácil obtenção. Será utilizado também, para o algoritmo de busca de documentos, um bom framework de busca textual, que será a solução mais tranquila e viável. Além de trazer velocidade, também traz outras características vantajosas nas buscas. Apostando nessa tendência do uso da tecnologia da informação como ferramenta de recuperação da informação, este projeto desenvolve uma ferramenta computacional que procura ser inovadora dentro da sua categoria, suprindo as necessidades dos usuários, com a possibilidade de consulta em documentos de forma pratica e rápida. Este sistema pode ser implantado em diversas empresas, para automação do processo de ordenação e apresentação de resultados. (Incluiremos aqui sugestões de trabalhos futuros) 52 REFERÊNCIAS BIBLIOGRÁFICAS ABADE, Márcia de Almeida. Integração de Bases de Autenticação LDPA com Bases Corporativas (PostgresSQL). 2004. Monografia (Curso de Administração em Redes Linux) – Departamento de Ciência da Computação, Universidade Federal de Lavras, Lavras. Disponível em: <http://www.ginux.ufla.br/files/mono-MarciaAbade.pdf>. Acesso em: 09 de maio de 2010. ALECRIM, Emerson. Conhecendo o Servidor Apache (HTTP Server Project). Disponível em: <http://www.infowester.com/servapach.php>. Acesso em: 13 de maio de 2010. BAEZA-YATES, Ricardo; RIBEIRO-NETO, Berthier. Modern Information Retrieval. 1 ed. Harlow: Addison Wesley, 1999. BALDAM, Roquemar; Valle, Rogerio; Marcos Cavalcanti. GED: Gerenciamento Eletrônico de Documentos. Érika, 2002 BEZERRA, Eduardo. Principio de Analise e Projeto de Sistemas com UML. Rio de Janeiro: Elsevier, 2007. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. Rio de Janeiro: Elsevier, 2005. BRITTAIN, Jason; DARWIN, Ian F. Tomcat: The Definitive Guide. 2 ed. Estados Unidos: O’Reilly, 2008. CANAVARRO, Marcela. Master.p.1,out,2003 Informação que vale ouro. Revista Eletrônica TI CASTILHO, Alecindro Steinke. Desenvolvimento do módulo de planejamento e acompanhamento de frota para a biblioteca do projeto Via Digital. 2007. Anteprojeto de pesquisa para Trabalho de Conclusão de Curso (Graduação em Sistema de Informação) – Centro Tecnológico, Universidade Federal de Santa Catarina, Florianópolis. Disponível em: <http://projetos.inf.ufsc.br/arquivos_projetos/projeto_676/tccControledeFrotas.pdf>. Acesso em: 02 de abril de 2010. CRUZ, T. E-Workflow. São Paulo: Cenadem, 2001. DEBONI, José Eduardo Zindel. Breve Introdução aos Diagramas da UML. Disponível em: <http://www.marcelocampos.com.br/academico/estagio2/download/aula003ex2.pdf>. Acesso em: 01 de maio de 2010. DEITEL, H.M. Java: como programar. 4.ed. Porto Alegre: Bookman, 2010. DOEDERLEIN, Osvaldo Pinali. GlassFish v2: O Novo Desafiante. Java Magazine, Rio de Janeiro, nr. 52, Dezembro, 2007. Disponível em: <http://www.ibmlaonthenews.com/clipview.php?idxclip=10674>. Acesso em: 12 de outubro 2010. DRUCKER, Peter F.; NONAKA, Ikujiro; ARGYRIS, Chris. Tradução por Serra, Afonso C. da Cunha. Gestão do conhecimento: On Knowledge management. 5.ed. Hardvard Business Review. 53 FOURNIER, Roger. A Methodology Development. Yourdon Press, 1999. for Client/Server and Web Application FRUSCIONE, James. Workflow automatizado: como desenvolver projetos gerais e planejamento de suporte. São Paulo: Cenadem, 1999. FURLAN, J. D. Modelagem de Objetos Através da UML. São Paulo: Makron Books, 1998. GATES, Bill. A empresa na velocidade do pensamento: como um sistema nervoso digital. São Paulo: Companhia das Letras, 1999. GERCHMAN, Júlio. UML 2.0 Testing Profile. Disponível <http://www.inf.ufrgs.br/~juliog/doc/u2tp.pdf>. Acesso em: 25 de maio de 2010. em: GONÇALVES, Antonio. Beginning Java™ EE 6 Platform with GlassFish™ 3: From Novice to Professional. Estados Unidos: Apress, 2008. GOTTESDIENER, Ellen. Business Rules as Requirements: Software Development. 1999. HATCHER, Erik; Gospodnetic, Otis. Lucene in Action: A Guide to the Java Search Engine. Estados Unidos: Manning, 2010 JAVA API Documentation. Sun Microsystems, 1995. LUCENE-JAVA WIKI. Disponível em: java/LuceneFAQ>. Acesso em: 30 de maio de 2010. <http://wiki.apache.org/lucene- MATOS, Alexandre Veloso de. UML: Prático e Descomplicado. São Paulo: Érica, 2003. MECENAS, Ivan. Eclipse3.1: Programando com Visual Editor. Rio de Janeiro: Alta Books, 2004. MILANI, André. PostgreSQL: Guia do Programador. Rio de Janeiro: Novatec, 2008. MOOERS, Calvin N. Information retrieval on structured content. Record Controls, 1959. OLIVEIRA, Gustavo de. Desenvolvimento e Gerenciamento de Sites Utilizando o CMS Drupal. Disponível em: <http://www.teuservidor.com/tcc_drupal_gustavo_de_oliveira.pdf>. Acesso em: 15 de março de 2010. ORTEGA, Cristina Dotta. Uma teoria dos sistemas de recuperação da informação. Disponível em: <http://www.eca.usp.br/prof/fmodesto/disc/RDI/cris/SRI.doc>.Acesso em: 30 de maio de 2010. PIMENTA, Denize Terra. Tutorial JUDE. Disponível em: <www.assembla.com/spaces/senac-pos/documents/.../TutorialJUDE51.pdf>. Acesso em: 25 de março de 2010. QUEIROZ, Gilberto Ribeiro de et al. Arquiteturas e linguagens. Disponível em: <http://mtc-m12.sid.inpe.br/col/sid.inpe.br/iris@1912/2005/07.04.16.31/doc/cap5.pdf>. Acesso em: 25 de maio de 2010. 54 REIS, Carla Alessandra Lima. Linguagem de Consulta SQL. Disponível em: <http://www.cefet-to.org/~marinaldo/FUND%20DE%20BANCO%20DE% 20DADOS/ SQL/SQL_apostila%5B1%5D.pdf>. Acesso em: 30 de abril de 2010. SIERRA, Kathy; BATES, Bert. Head First EJB. Estados Unidos: O’Reilly, 2003. REZENDE, Solange Oliveira. Sistemas Inteligentes: Fundamentos e Aplicações. São Paulo: Manole, 2005. RIBEIRO, Leandro. Estudo geral sobre Apache. Disponível em: <http://imasters.uol.com.br/artigo/3697/linux/estudo_geral_sobre_apache/>. Acesso em: 05 de maio de 2010. SOMERA, Guilherme. Treinamento profissional para Delphi. São Paulo: Digerati Books, 2007. STROPPA, Sonia. Palestra: Gestão Documental – A arte de transformar papéis em informações que geram valor agregado dentro das Organizações. Paraná, 2010. THE APACHE SOFTWARE FOUNDATION. <http://lucene.apache.org/>. Acesso em: 30 de maio de 2010. Disponível em: WELLISCH, H. H. Uma teoria dos sistemas de recuperação da informação. Brasília: IBICT, 1987. Disponível em: <http://www.eca.usp.br/prof/fmodesto/disc/RDI/cris/SRI.doc>. Acesso em: 27 de maio de 2010. WELLISCH, H. H. Uma teoria dos sistemas de recuperação da informação. Brasília: IBICT, 1987. WIVES, Leandro Krug. Agrupamento de Informações Textuais. Disponível em: <http://www.leandro.wives.nom.br/pt-br/publicacoes/semacad.pdf>. Acesso em: 27 de abril de 2010.