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.