Bibliotecas Digitais: Uma abordagem para armazenamento e

CENTRO UNIVERSITÁRIO VILA VELHA
CURSO DE CIÊNCIA DA COMPUTAÇÃO
Filippe Zampiroli Lovatti
Bibliotecas Digitais: Uma abordagem para
armazenamento e publicação de artigos
científicos
VILA VELHA
2010
Filippe Zampiroli Lovatti
Bibliotecas Digitais: Uma abordagem para
armazenamento e publicação de artigos
científicos
Trabalho de Conclusão de Curso apresentado ao Centro Univertário Vila Velha como
requisito parcial para a obtenção do grau
de Bacharel em Ciência da Computação.
Orientador: Cristiano Biancardi
VILA VELHA
2010
Filippe Zampiroli Lovatti
Bibliotecas Digitais: Uma abordagem para
armazenamento e publicação de artigos
científicos
BANCA EXAMINADORA
Prof. Msc. Cristiano Biancardi
Centro Universitário Vila Velha
Orientador
Prof. Msc. Sandro Tonini da Silva
Centro Universitário Vila Velha
Prof. Msc. Susiléa A. Dos Santos
Lima
Centro Universitário Vila Velha
Trabalho de Conclusão de Curso
aprovado em 17/11/2010.
Eu, Filippe Zampiroli Lovatti, autorizo que a
UVV, sem ônus, promova a publicação de
minha monografia em página própria na Internet ou outro meio de divulgação de trabalho científico.
Data: 17/11/2010
Assinatura:
Aos meus pais, familiares, amigos e namorada.
AGRADECIMENTOS
Agradeço primeiramente a Deus por permitir e dar-me força para que esse trabalho
se realizasse.
Agradeço a minha família pelo apoio incondicional durante toda a faculdade, dando
todo o suporte necessário a minha formação.
A minha namorada Tayná Tavares Ambrosio por todo apoio durante a faculdade, e
principalmente, no decorrer desse trabalho sendo compreensiva e principal incentivadora.
Aos meus avôs, que foram imprescindíveis na minha educação. Principalmente ao
meu avô Alfonso, por ser uma referencia impar na minha vida.
Aos meus amigos feitos durante toda a faculdade, tanto em Ciência da Computação quanto em Engenharia de Petróleo, espero tê-los pelo resto da vida.
Aos amigos da Promov, que me deram suporte, e foram indispensáveis para realização desse trabalho.
Ao meu tio Elio e família que me recebeu em sua casa durante o desenvolvimento
desse projeto.
Ao suporte e paciência de todos os professores.
Por fim ao orientador Prof. Msc. Cristiano Biancardi pelo direcionamento para que
esse projeto se concretizasse.
LISTA DE TABELAS
1
Principais acontecimentos na história das BDs. . . . . . . . . . . . . . .
18
2
Os Elementos Dublin Core [de Menezes CARDOSO 2007]. . . . . . . .
22
3
Os verbos e seus argumentos [Forc, 2003]. . . . . . . . . . . . . . . . .
31
4
Descrição dos casos de uso propostos na solução. . . . . . . . . . . . .
39
5
Dicionário de dados Artigo
. . . . . . . . . . . . . . . . . . . . . . . . .
46
6
Dicionário de dados Avaliação . . . . . . . . . . . . . . . . . . . . . . .
47
7
Dicionário de dados Usuário . . . . . . . . . . . . . . . . . . . . . . . .
47
8
Dicionário de dados Categoria . . . . . . . . . . . . . . . . . . . . . . .
47
9
Dicionário de dados Artigo_Situação . . . . . . . . . . . . . . . . . . . .
47
10
Ícones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
11
Tempo de Execução das Tarefas (em segundos) . . . . . . . . . . . . .
74
12
Número de erros por tarefas . . . . . . . . . . . . . . . . . . . . . . . . .
74
LISTA DE FIGURAS
1
Parte de uma reposta a uma requisição onde pode-se observar o DC
em conjunto com o XML. . . . . . . . . . . . . . . . . . . . . . . . . . .
2
24
Ilustra os dois tipo de interoperabilidade apresentados, Federation e
Harvesting. [CUNHA 2008] . . . . . . . . . . . . . . . . . . . . . . . . .
26
3
Representação do esquema de um provedor de dados.[CONTESSA 2006] 29
4
Provedor de Serviços. [CONTESSA 2006] . . . . . . . . . . . . . . . . .
32
5
Diagrama de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
6
Diagrama de Casos de Uso do módulo Básico. . . . . . . . . . . . . . .
37
7
Diagrama de Casos de Uso do módulo de Avaliação. . . . . . . . . . . .
37
8
Diagrama de Casos de Uso do módulo de Administração. . . . . . . . .
38
9
Diagrama de Casos de Uso do módulo de Publicação. . . . . . . . . . .
38
10
Diagrama de Classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
11
Diagrama de Sequência do caso de uso Manter Usuário (Inserir) . . . .
49
12
Diagrama de Sequência do caso de uso Manter Usuário (Consultar) . .
50
13
Diagrama de Sequência do caso de uso Manter Usuário (Alterar) . . . .
50
14
Diagrama de Sequência do caso de uso Manter Usuário (Remover) . .
51
15
Diagrama de Sequência do caso de uso Publicar Artigo . . . . . . . . .
51
16
Diagrama de Transição de Estado . . . . . . . . . . . . . . . . . . . . .
52
17
Diagrama de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
18
Diagrama de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
19
Arquitetura Básica de Projeto Orientado a Objetos . . . . . . . . . . . .
56
20
Diagrama de Pacotes - Divisão em Camadas . . . . . . . . . . . . . . .
57
21
Diagrama de Classes Componente Domínio do Problema . . . . . . . .
58
22
Diagrama de Classes Gerência de Tarefas
. . . . . . . . . . . . . . . .
59
23
Diagrama de Sequência Revisado - Inserir Usuário . . . . . . . . . . . .
60
24
Diagrama de Sequência Revisado - Consultar Usuário . . . . . . . . . .
60
25
Diagrama de Sequência Revisado - Alterar Usuário . . . . . . . . . . .
61
26
Diagrama de Sequência Revisado - Remover Usuário . . . . . . . . . .
61
27
Diagrama de Sequência Revisado - Listar Artigos
. . . . . . . . . . . .
62
28
Diagrama de Sequência Revisado - Publicar Artigo . . . . . . . . . . . .
62
29
Diagrama de Classes do Componente de Gerência de Dados . . . . . .
63
30
Diagrama Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
31
Diagrama de Navegação
. . . . . . . . . . . . . . . . . . . . . . . . . .
65
32
Padrão de Interface Busca
. . . . . . . . . . . . . . . . . . . . . . . . .
67
33
Padrão de Interface Listar . . . . . . . . . . . . . . . . . . . . . . . . . .
67
34
Padrão de Interface do Painel de Controle . . . . . . . . . . . . . . . . .
68
35
Padrão de Interface Cadastro . . . . . . . . . . . . . . . . . . . . . . . .
68
36
Stored Procedure - Publica Artigo . . . . . . . . . . . . . . . . . . . . .
70
37
Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . .
71
38
Diagrama de Implantação . . . . . . . . . . . . . . . . . . . . . . . . . .
72
SUMÁRIO
RESUMO
1 INTRODUÇÃO
13
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . .
15
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.5 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2 REFERENCIAL TEÓRICO
17
2.1 Bibliotecas Digitais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.2 Metadados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3 Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.4 Interoperabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.5 Abordagens de Integração
. . . . . . . . . . . . . . . . . . . . . . . . .
25
2.6 Open Archives Initiative OAI-PMH . . . . . . . . . . . . . . . . . . . . .
27
2.7 Provedor de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.8 Provedor de serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.9 Construção de uma biblioteca digital . . . . . . . . . . . . . . . . . . . .
32
3 LEVANTAMENTO DE REQUISITOS
34
3.1 Descrição Geral do Ambiente . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2 Divisão em Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.3 Modelagem Casos de Uso
. . . . . . . . . . . . . . . . . . . . . . . . .
36
3.4 Descrição dos Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.5 Descrição dos Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . .
39
3.5.1 Avaliar artigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.5.2 Manter Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.5.3 Publicar artigo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4 ESPECIFICAÇÃO DE ANÁLISE
44
4.1 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.2 Dicionário de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.3 Diagrama de Interação . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.3.1 Diagrama de Sequência . . . . . . . . . . . . . . . . . . . . . . .
48
4.4 Diagrama de Transição de Estado . . . . . . . . . . . . . . . . . . . . .
52
4.5 Diagrama de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5 ESPECIFICAÇÃO DE PROJETO
54
5.1 Escolha da Tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.2 Arquitetura do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.3 Pacotes De Administração, Submissão, Busca e Avaliação . . . . . . .
56
5.3.1 Divisão em Camadas . . . . . . . . . . . . . . . . . . . . . . . .
56
5.4 Pacote de Publicação . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.4.1 SQL Server Agent . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.4.2 Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.5 Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.6 Diagrama de Implantação . . . . . . . . . . . . . . . . . . . . . . . . . .
71
6 TESTES
6.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
74
7 CONCLUSÕES E TRABALHOS FUTUROS
75
REFERÊNCIAS
77
ANEXO A - Plano de Teste
79
RESUMO
A publicação de trabalhos científicos além de promover o avanço da ciência, eleva o
reconhecimento dos autores por parte da comunidade científica. O processo burocrático para publicação e divulgação de trabalhos científicos somado à popularização
da mídia digital, faz com que as Bibliotecas Digitais sejam cada vez mais bem vistas
nos dias atuais. Um dos principais problemas apontados para publicação de artigos
científicos em revistas é o fato que muitas vezes estes podem se tornar obsoletos até
a publicação, devido ao demorado processo de avaliação ao qual estes artigos são
submetidos. Outro problema encontrado é que nem sempre bons trabalhos são publicados, isso ocorre pela falta de espaço nestas mídias. Com o objetivo de solucionar
esses problemas as Bibliotecas Digitais surgem como uma alternativa para agilizar o
processo de publicação dos artigos. A construção de uma Biblioteca Digital deve primar pela interface com o usuário, os serviços oferecidos e o repositório de metadados.
Com o proposito de desenvolver uma Biblioteca Digital foram estudados os principais
protocolos e padrões existentes assim como trabalhos relacionados. Com o resultado
desse estudo foi possível desenvolver o sistema de Biblioteca Digital respeitando as
premissas acima, eliminado deficiências encontradas em outras e incorporando funcionalidades como submissão, avaliação e publicação de artigos.
Palavras-chave: Biblioteca Digital. Artigo Científico. Publicação.
13
1
INTRODUÇÃO
Segundo [SILVA,2004], a medida da aceitação ou qualidade de um trabalho pode
ser dada pelo número de vezes em que ele é referenciado. Assim, nota-se a grande
importância que tem a divulgação dos trabalhos publicados por um pesquisador ou
por um grupo de pesquisa. Mas para a concretização desse fato é necessária a existência de processos e mecanismos eficientes que permitam aos autores publicar seus
trabalhos.
Em geral, a comunidade científica divulga e publica os resultados dos trabalhos
em artigos submetidos a congressos, conferências, simpósios ou periódicos. Este
tipo de publicação feita em mídia digital ou impressa, sujeita à avaliação de comitês
especializados, pode tornar o processo de publicação mais lento e complexo fazendo
com que trabalhos fiquem obsoletos, por outro lado, isso aumenta a qualidade relativa
dos artigos. Isto se deve ao fato de haver uma seleção dos melhores trabalhos para
publicação. Essa seleção gera outro problema: trabalhos de qualidade não publicados.
Além disso, muitas vezes há a necessidade de resolução de problemas burocráticos
relacionados a direitos autorais, os quais podem dificultar ainda mais o processo de
divulgação das publicações.
Na tentativa de solucionar os problemas descritos acima, bibliotecas digitais vêm
sendo utilizadas. Segundo a Digital Library Federation, bibliotecas digitais (BDs) podem ser definidas como organizações que fornecem recursos para selecionar, estruturar, oferecer acesso intelectual, distribuir, preservar a integridade e garantir a permanência das coleções digitais, de tal forma que elas estejam disponíveis para uma ou
várias comunidades. Nelas há repositórios de metadados sobre os trabalhos publicados, bem como links para os textos dos trabalhos (ou mesmo o arquivo propriamente
dito, como texto). Um exemplo de biblioteca digital é a BDBComp [LAENDER; ROBERTO,2004].
Assim diversas bibliotecas digitais surgiram com essa iniciativa, como consequên-
14
cia direta disso aumentou o número de publicações através das mesmas. Contudo
surge um dificultador no que diz respeito a busca por tais trabalhos onde é necessário o acesso a cada uma separadamente. Visando resolver este problema a Iniciativa
de Arquivos Abertos (OAI - Open Archives Initiative) sugere que tais bibliotecas digitais disponibilizem seus metadados através de um serviço padrão de forma que seja
possível a implantação do sistema de disponibilização e coleta metadados.
Nas bibliotecas atuais são encontradas deficiências. Algumas delas servem somente como repositórios digitais, não oferecendo ou disponibilizando em partes serviços como busca, navegação, submissão, interoperabilidade, avaliação e a publicação
de trabalhos. Além disso outros serviços de gerenciamento como: controle de acesso,
avaliação de trabalhos pelos leitores e personalização do ambiente não são encontrados por completo nas bibliotecas digitais.
Dentro deste contexto este trabalho tem por objetivo estudar bibliotecas digitais
que estão relacionadas a submissão, publicação e avaliação de trabalhos assim como
propor, modelar e implementar um sistema que resolva as deficiências encontradas e
incorpore outros serviços.
1.1
Motivação
Observando o mercado de software foi encontrando uma carência no que diz respeito a sistemas de Bibliotecas Digitais que englobam submissão, avaliação e publicação de artigos.
Através de uma pesquisa, foram encontrados alguns softwares que realizam tais
tarefas, porém de forma manual e ineficiente.
Além da falta de softwares no mercado, o processo manual de submissão e avaliação torna o processo lento e burocrático, que muitas vezes tornam estudos obsoletos
até sua publicação.
1.2
Justificativa
Diante esta carência do mercado de software, este projeto visa relacionar as principais tecnologias para o desenvolvimento de Bibliotecas Digitais, obtendo maior controle, agilidade, facilidade e confiabilidade para a publicação de artigos. Auxiliando
15
também, na submissão e avaliação, tendo padrão, agilidade e controle das solicitações, sendo de fácil utilização para com seus usuários.
1.3
Objetivos
1.3.1
Objetivo Geral
O Objetivo principal deste é desenvolver um sistema de informações em ambiente
web de Bibliotecas Digitais, contemplando aspectos de submissão, avaliação, publicação e interoperabilidade.
1.3.2
Objetivos específicos
Os objetivos específicos desse trabalho são:
• Criar um sistema web, com gerenciamento de perfis: Usuário comum, usuário
avaliador e usuário administrador;
• Permitir qualquer visitante ter acesso rápido aos artigos contidos na biblioteca
através de um sistema de buscas, com opção de realizar buscas avançadas;
• Permitir ao usuário comum submeter artigos, editar artigos já submetidos e gerenciar seu perfil;
• Desenvolver um módulo de interoperabilidade em conformidade com o protocolo
OAI-PMH e que utilize o Dublin Core como padrão de metadados;
• Criar um método para avaliação de artigo, onde usuários previamente cadastrados darão notas e tecerão comentários sobre o artigo avaliado;
• Desenvolver ferramentas que auxiliem o usuário administrador a manter a biblioteca, através de rotinas como: criar categoria, definir quantidade de avaliações
e nota mínima para um artigo ser publicado e definir usuário como avaliador;
• Realizar testes de usabilidade no sistema implementado, visando melhorá-lo.
16
1.4
Metodologia
Para alcançar todos os objetivos foram executados as seguintes atividades:
• Efetuar pesquisas sobre os conceitos de Bibliotecas Digitais;
• Estudar o protocolo Open Archives Initiative Protocol Metadata Harvestinhg(OAIPMH);
• Analisar o padrão para descrição de metadados Dublin Core;
• Estudar trabalhos relacionados, identificando pontos positivos e negativos;
• Modelar um ambiente web para submissão, avaliação e publicação de artigos;
• Implementar uma ferramenta que dê suporte à submissão, avaliação e publicação de trabalhos.
1.5
Organização do Trabalho
A seguir é apresentada uma breve descrição sobre a organização dos próximos
capítulos deste trabalho.
O capítulo 2 apresenta algumas definições sobre Bibliotecas Digitais, além de explicar os conceitos de metadados, padrões de metadados, Dublin Core, tipos de integração de dados e Iniciativa de Arquivos Abertos e protocolo (OAI-PMH).
O capítulo 3 apresenta o Levantamento dos Requisitos do sistema. São descritas
as funcionalidades do sistema, seus casos de usos e atores.
No capítulo 4 é descrita a especificação da Análise. Na análise são modelados os
requisitos através dos diagramas de classes e seqüência.
O capítulo 5 contém toda a especificação do Projeto do sistema, abordando soluções tecnológicas e a modelagem detalhada do sistema para posterior implementação.
O capítulo 6 contém a parte de Testes. São apresentados os testes realizados e
seus resultados.
O capítulo 7 contém a conclusão do trabalho, bem como os trabalhos futuros.
17
2
REFERENCIAL TEÓRICO
Nesta seção, serão abordados os conceitos de Bibliotecas Digitais e padrão de
Metadados, serão citados assuntos relevantes sobre integração de dados no tema
proposto para o trabalho e, por fim, serão apresentados conceitos para construção de
uma Biblioteca Digital.
2.1
Bibliotecas Digitais
Para falar de Bibliotecas Digitais (BD) deve-se conhecer primeiro um pouco da sua
historia e quais os personagens principais para que essa idéia se tornasse realidade.
A biblioteca convencional é aquela em que a maioria dos itens do seu acervo é constituída de documentos em papel. Ela existe desde a invenção da escrita. É claro que,
antes do advento da imprensa de tipos móveis, em 1440, o seu acervo era formado
por outros tipos de materiais (como o tablete de argila, o papiro e o pergaminho). Uma
característica da biblioteca convencional é que tanto a coleção como os seus catálogos utilizam o papel como suporte de registro da informação. Todavia, no final do
século XIX, houve uma grande revolução na biblioteca, com a introdução do catálogo
em fichas e o abandono do catálogo sob a forma de livro[CUNHA 2008] Nas últimas
décadas, o computador tem sido utilizado de forma cada vez mais crescente e, desde
os anos 1970, muitas bibliotecas implantaram catálogos em linha, passaram a acessar
bancos de dados, iniciaram o uso regular do periódico eletrônico e o acesso a textos
completos de artigos de periódicos, a verbetes de enciclopédias e a itens de outras
fontes de referência. A partir de 1994, por exemplo, com a implantação da World Wide
Web (WWW) e do fenomenal crescimento da Internet, as possibilidades de acessar e
recuperar informações aumentaram de forma nunca antes imaginada [CUNHA 1999].
Os principais acontecimentos assim como seus autores seguem na (tabela 1) abaixo
apresentada.
18
Autore(s)
Paul
Otlet
e
Henri
La
Fontaine
Ano
1895
H. G. Wells
1938
Vannevar Bush
1945
IBM
1950
Institutos
de
Pesquisa
Theodor Holm
Nelson
1960
Governo
EUA
1994
dos
1960
Descrição
Criaram Instituto Internacional de Bibliografia, cujo objetivo era registrar em fichas a produção mundial de
impressos: o Repertório Bibliográfico Universal[BDs e
suas utopias]
Sugeriu a criação de uma enciclopédia universal, que
conteria a memória planetária completa para toda a
humanidade. [AO 2008]
Arquitetou o memex que é um dispositivo através do
qual um indivíduo armazena todos os seus livros,
seus registros e suas comunicações, ele é mecanizado de forma que pode ser consultado com extraordinária velocidade e flexibilidade. O memex é um
suplemento pessoal ampliador da memória desse indivíduo. [AO 2008]
Criou as primeiras aplicações concretas de computadores no apoio a funções de bibliotecas. Como
a utilização de cartões perfurados para dar suporte
às operações de processos técnicos da biblioteca.
[AO 2008]
Primeiras Bibliotecas Digitais. [AO 2008]
Estabeleceu a idéia de hipertexto e a hipermídia. Esses conceitos foram desenvolvidos no contexto do seu
projeto chamado Xanadu. [AO 2008]
Investimento pesado na área de Bibliotecas Digitais
com montantes na ordem de mais de 24 milhões
de dólares, para constituição de um programa multiagência, denominado Digital Library Initiative (DLI).
[AO 2008]
Tabela 1: Principais acontecimentos na história das BDs.
O Memex pode ser considerado como o primeiro pensamento semelhante ao conceito das bibliotecas digitais atuais. Este foi vislumbrado por Bush como um dispositivo
para uso individual que funcionasse como uma biblioteca mecanizada. Um dispositivo capaz de amarzenar livros, dados e mensagens, de forma que toda informação
pudesse ser consultada de forma veloz e flexível. Ainda de acordo com o modelo
proposto por Bush para o Memex, ele deveria funcionar como um grande depósito
de informações, que fosse capaz de armazenar grande quantidade de informações e
demorasse centenas de anos para completar o espaço disponível. Além da alta capacidade de armazenamento um outro fator crucial seria o mecanismo de busca, se
um usuário desejasse consultar por um livro, digitaria o código no teclado e o título
19
apareceria em seguida, projetado sobre uma das telas. [BUSH 1945]
O termo Biblioteca Digital possui conotações que variam de acordo com o ponto
de vista de autores e estudiosos da área. De acordo com a Digital Library Federation Bibliotecas Digitais são organizações que produzem recursos e inclui pessoas
especializadas para selecionar, estruturar e oferecer acesso intelectual a coleções de
trabalhos digitais, alám de distribuir, preservar e garantir a integridade dos arquivos
destes trabalhos. As Bibliotecas Digitais devem ser capazes de garantir a legibilidade
e disponibilidade dos trabalhos para uso de uma ou mais comunidades.
Conforme [BAEZA and YATES 1999], Biblioteca Digital é uma combinação que envolve: uma coleção de objetos digitais (repositório); descrições destes objetos (metadados); um conjunto de usuários e sistemas que oferecem uma variedade de serviços,
tais como captura, indexação, catalogação, busca, navegação, recuperação, entrega,
arquivamento e preservação. Em seguida destaca-se os principais benefícios que
uma BD tem em relação a uma biblioteca convencional.
• Acesso 24 horas por dia, 7 dias por semana, 365 dias por ano;
• Retiradas, devoluções e recolocações automáticas nas prateleiras digitais;
• Várias pessoas podem utilizar o mesmo recurso simultaneamente;
• Fornece relatórios detalhados para analisar a utilização da biblioteca em níveis
sem precedentes;
• O mecanismo de busca permite pesquisa de palavras em um livro ou em uma
coleção inteira de livros;
• Não ha necessidade de aumento do espaço físico com a inclusão de novos trabalhos;
• O custo de implementação e manutenção muito inferior a uma biblioteca convencional.
Conforme Gary Marchionini e seus co-autores, em [et al MARCHIONIINI 2002],
BDs (Bibliotecas Digitais) servem comunidades de pessoas e são criadas e mantidas
por e para pessoas. As pessoas e as informações que as BDs precisam são centrais
para todas as bibliotecas, digitais ou não. Todos os esforços no projeto, implementação e avaliação de BDs devem ser consolidados nas necessidades de informações,
20
características e contextos dos usuários que usarão ou poderão usar essas bibliotecas.
Apesar dos diferentes pontos de vista apresentados, todos os autores citados, concordam que este tipo de biblioteca implica em novas funcionalidades no que diz respeito á organização, recuperação e armazenamento de informações. As Bibliotecas
Digitais devem disponibilizar serviços e produtos, possibilitando recuperar documentos completos e bibliográficos, possuindo tipos diversos de registros (imagem, áudio,
texto) e utilizando sistemas inteligentes que ajudam na recuperação da informação.
No caso específico da recuperação da informação contida nas publicações, tal tarefa sempre foi o principal objetivo dos instrumentos elaborados pelas BDs e sistemas
de informação. Com o surgimento de novas tecnologias, surgiram também, novas
formas de organizar, estruturar e disponibilizar a informação, como exemplo dessas
tecnologias pode-se citar os metadados.
2.2
Metadados
A origem do termo “metadados” se inicia nos anos 60, mas aparece com maior
frequência na literatura sobre sistemas de gerenciamento de bases de dados a partir
dos anos 80, sendo empregado para identificar as informações auto-descritivas e de
auto-controle dos dados contidos nas bases [VELLUCCI 2002].
A necessidade da utilização de metadados na organização eletrônica é crescente
como a necessidade de disponibilizar e descobrir informações na internet e nas intranets. Os metadados possibilitam a integração para compartilhamento de recursos e
aplicações entre os sistemas de informação e de gestão de conhecimento.
A definição mais comum sobre metadados é “dado estruturado sobre dado”, ou
dito de outra maneira, é a informação estruturada que descreve o conteúdo dos repositórios que armazenam recursos, digitais e não-digitais. Exemplos de recursos
incluem imagens, livros, obras de arte, músicas e artigos científicos.
Os metadados possuem um conjunto de elementos para o propósito de descrição,
administração, requisitos legais, funcionalidade técnica, uso e convenção, e preservação. Alguns exemplos de elementos de metadados são: título, autor, descrição,
direitos autorais e data de crição.
De acordo com [BAEZA and YATES 1999], metadados são atributos de dados ou
21
documentos, normalmente descritivos. Os metadados, tipicamente, são mantidos em
um catálogo algumas vezes registrado de acordo com algum padrão de descrição de
metadados.
Um padrão consiste em um conjunto de elementos, sendo que para cada um é
dado um nome explicativo, rótulo e definição. Às vezes, uma anotação é fornecida
para documentar a história da mudança do elemento e o mapeamento entre este e
outros elementos em outras normas [de Menezes CARDOSO 2007]. Com o rápido
crescimento da Internet ocorreu uma ploriferação de padrões de metadados, cada um
construído para atender uma comunidade, tipos de materiais e necessidades de projetos específicos [ZENG and CHAN 2006]. Dentre os padrões de metadados, pode-se
destacar alguns como o Dublin Core [DC 2010], o MARC [LOC 2010], o IEEE Learning Object Metadata [IEEE 2010], e o IMS. É importante destacar que, usualmente,
estes padrões utilizam XML para sua representação. Um exemplo de um metadado
no padrão Dublin Core pode ser observado na (figura 1).
Conforme estudo realizado em [KRUTSON et al. 2003] os padrões Dublin Core e
MARC são os mais utilizados hoje em dia, este estudo contemplou 227 instituições e
constatou que 23% das bibliotecas utilizam o padrão Dublin Core; 26% utilizam multipadrões incluindo o padrão MARC, 16% utilizam apenas o padrão MARC. Como um
dos objetivos deste trabalho é disponibilizar os metadados segundo a Iniciativa de
Arquivos Abertos [KRUTSON et al. 2003], será usado o padrão Dublin Core.
2.3
Dublin Core
Com o objetivo de criar uma ferramenta para descrição de metadados que fosse
fácil de ser utilizada, em 1995, na cidade de Dublin, Irlanda, foi criado o Dublin Core
Metadata Intiative (DCMI), que resultou na criação de um padrão internacional de metadados conhecido como Padrão Dublin Core e composto por 15 elementos básicos.
O padrão foi desenvolvido por especialistas de áreas como biblioteconomia e computação no OCLC/NCSA Metadata Workshop, realizado em março de 1995. O objetivo
do grupo era criar uma ferramenta para descrição de metadados de fácil utilização e
que tornasse possível encontrar informações eletrõnicas de forma análoga ao provido
por um sistema de busca de uma biblioteca.
O padrão DC (Dublin Core) inclui dois níveis: Simples e Qualificado. O Dublin
Core Simples inclui quinze elementos, o Qualificado inclui três elementos adicionais
22
(Audiência, Proveniência e Detentor de Direitos), assim como um grupo de refinamentos de elementos (também chamados qualificadores), que refinam a semântica dos
elementos de maneira que sejam úteis nas descobertas de recursos.
Os principais elementos do padrão DC [de Menezes CARDOSO 2007], suas descrições e um breve exemplo de cada são apresentados na tabela 2.
Elemento
Title
Subject
description
Type
Source
Relation
Descrição
O nome dado ao recurso. Efetivamente, é o nome que curso é formalmente conhecido.
O tópico do conteúdo do recurso. Tipicamente, o subject pode ser expresso nas palavras-chave do recurso.
Uma descrição do conteúdo do recurso. Esse elemento pode incluir:
um resumo, um índice ou um texto livre sobre o conteúdo1 do recurso.
A natureza ou o gênero do conteúdo
do recurso.
Uma referência de onde o recurso foi
gerado.
Uma referência para um outro recurso
relacionado.
Exemplo
Casa-Grande e Senzala
escravidão, literatura,
senhor de engenho
Em 1933, Gilberto
Freyre publica CasaGrande e Senzala,
um livro que revoluciona os estudos no
Brasil, tanto pela novidade dos conceitos quanto pela qualidade literária
texto
Casa-Grande
e
Senzala,
Primeira
Ediç ao
Nordeste: Aspectos
da Influência da
Cana
Tabela 2: Os Elementos Dublin Core [de Menezes CARDOSO 2007].
23
coverage
Creator
publisher
contribuitor
Rights
Date
Format
identifier
language
Inclui um local (nome de um lugar
ou coordenadas geográficas), um período no tempo ou jurisdição (entidade administrativa).
Entidade responsável pela criação do
conteúdo do recurso. Pode ser uma
pessoa, uma organização ou um serviço.
Entidade responsável por disponibilizar o recurso criado.
Pessoa, organização ou serviço responsável por contribuir com o conteúdo do recurso criado.
Informação sobre os direitos do recurso.
Uma data que pode ser associada
com a criação ou disponibilização do
recurso.
A física ou digital composição do recurso. Pode incluir um tipo de mídia
ou dimensões do recurso (tamanho
ou duração).
Uma referência única para o recurso
dado. Exemplos de identificação podem ser o ISBN de um livro, o ASIN
de uma música, uma URL com o recurso etc.
O idioma do conteúdo intelectual do
recurso. É recomendável que se utilize os valores dos elementos definidos por.
Recife-PE
Gilberto Freyre
Editora Global
Roger Bastide
Proibida Reprodução
1933
1.5 MB
ISBN: 852601059X
pt-br
Este padrão é uma ferramenta para facilitar a interoperabilidade entre os sistemas
de BDs. Na (figura 1) pode-se observar a estrutura do DC em conjunto com XML.
Nota-se que os metadados estão entre tags XML que formam a base necessária para
a interoperabilidade.
24
Figura 1: Parte de uma reposta a uma requisição onde pode-se observar o DC em
conjunto com o XML.
2.4
Interoperabilidade
Interoperabilidade é um termo presente em diversas áreas da Ciência da Computação, sendo que, no domínio das Bibliotecas Digitais, se refere a capacidade de uma
BD trabalhar em conjunto com outras na tentativa de prover serviços de alta qualidade
ao usuários [SULEMAN, 2002].
No começo da década de 90 existiam algumas BDs na internet, mas elas e suas
informações estavam dispersas na rede. Para (Marcondes 99) “De nada adianta a
informação existir, se quem dela necessita não sabe da sua existência ou se ela não
puder ser encontrada”. Nessa época para um usuário fazer uma pesquisa nessas
bibliotecas era necessário entrar site a site e realizar sua busca. Criou-se então um
cenário onde era imprescindível para o sucesso das BDs a interoperabilidade uma com
a outra, fornecendo assim uma quantidade incrível de informação em um só lugar.
Conforme [BIRMINGHAM 00], interoperabilidade é a capacidade das Bibliotecas
25
Digitais trocarem e compartilharem documentos, consultas e serviços. Através dessa
troca e compartilhamento são realizadas interações entre os sistemas das Bibliotecas
Digitais.
Para haver interoperabilidade entre os repositórios espalhados pela internet, é preciso escolher uma maneira de pesquisa para obter os metadados. Existem duas abordagens, ilustradas na (figura 2), mais difundidas para realizar essa tarefa: Harvesting
e Federation.
• Federation: Essa abordagem tem como objetivo facilitar a interoperabilidade entre os sistemas, entretanto, há um esforço requerido para manter e implantar
o conjunto de especificações técnicas estabelecidas. Trata-se de uma abordagem onde um grupo de organizações concordam em construir os seus sistemas
observando-se certas especificações técnicas através de algum instrumento formal. Na abordagem Federation a BD envia a consulta para os repositórios e ao
coletar os metadados os reúne e exibe ao usuário.
• Harvesting: Por ser uma arquitetura mais aberta, onde as organizações participantes não precisam seguir um conjunto de especificações técnicas o esforço é
menor que o apresentado na abordagem Federation. Os metadados de diversos
provedores de informação tornam-se “visíveis” através de protocolos padronizados, como o OAI-PMH e são coletados automaticamente de forma periódica ou
quanto um usuário realiza uma consulta inexistente em sua base de dados, os
resultados são armazenados em uma base centralizada de metadados, onde
são efetuadas as buscas de forma integrada.
Relacionadas a essas duas formas de interoperabilidade, torna-se necessário esclarecer duas abordagens de integração de dados a Abordagem Virtual e Abordagem
Materializada.
2.5
Abordagens de Integração
O principal objetivo da integração de dados é disponibilizar ao usuário uma interface única para o acesso a informações disponíveis em diferentes bases de dados.
Para que isso fosse possível diferentes abordagens foram propostas para tentar minimizar a complexidade de interoperabilidade de dados entre sistemas:
26
Figura 2: Ilustra os dois tipo de interoperabilidade apresentados, Federation e Harvesting. [CUNHA 2008]
• Abordagem Virtual: Nessa abordagem, as fontes que contêm os dados só são
requisitadas quando as consultas são efetuadas. Uma vantagem da Abordagem
Virtual é que as informações estão sempre atualizadas, já que a resposta da
consulta é requisitada à fonte original. Por outro lado, esta abordagem não é
recomendada quando os servidores forem instáveis, pois pode deixar os serviços
inacessíveis.
• Abordagem Materializada: Diferente da Abordagem Virtual, esta recupera as informações das fontes de dados previamente, e as armazena em um repositório
central. O usuário faz, então, sua consulta a esse repositório. A grande vantagem deste tipo de abordagem é que as informações estão sempre disponíveis
para a consulta, aumentando o desempenho do sistema. Por outro lado, os dados não estão sempre atualizados.
No inicio a interoperabilidade entre BDs era feita de forma isolada, ou seja, cada
biblioteca disponibilizava seu protocolo de comunicação o que dificultava a plena conversa entre as varias BDs, para solucionar esse problema foram criados alguns protocolos como o OAI-PMH que se baseia no padrão DC.
27
2.6
Open Archives Initiative OAI-PMH
No término dos anos 90, existiam na internet alguns repositórios em diversas
áreas, principalmente artigos científicos. Entretanto todos eles apresentavam dois
aspectos que dificultavam a disseminação dos documentos armazenados. O primeiro
é que o usuário encontrava diferentes interfaces, o que tornava o processo de busca
mais complicado, e o segundo aspecto é que não havia uma forma automatizada de
compartilhar dados. Assim, em busca pela solução destes problemas, Paul Ginsparg,
Rick Ruce e Hebert Van de Sompel, realizaram um encontro em outubro de 1999 em
Santa Fé, Novo México com a finalidade de encontrar soluções para a questão da
integração entre bases na web [LAGOZE and de SOMPEL 2001]. O resultado desta
conferência foi a formação do OAI (Open Archives Initiative), visando a criação de padrões e estruturas para permitir o acesso a uma grande quantidade de documentos
eletrônicos arquivados na Internet.
O Open Archives Initiative possui algumas características principais, que são:
• Acesso aberto aos recursos de informação (ou pelo menos aos metadados que
descrevem os recursos);
• Interface consistente entre os repositórios e os seus coletores de dados;
• Baixa barreira do protocolo, ou seja, exigência de menos esforço para a sua
implementação, por se basear em tecnologias já bastante difundidas (e.g.: HTTP,
XML, Dublin Core).
No protocolo OAI-PMH não só os metadados descritivos, mas os recursos também
podem ser disponíveis para coleta, apesar de não ser uma exigência do protocolo. Por
exemplo, pode-se ter um repositório de vídeos que disponibiliza apenas os metadados
do recurso (e.g: título do vídeo, autor, resumo) ou o vídeo em si juntamente com
os seus metadados. O OAI-PMH também pode ser usado para grupos fechados,
compartilhamento dos seus metadados e em aplicações comerciais.
Conforme já mencionado, a base da Iniciativa é o protocolo OAI-PMH, que faz
com que os participantes da Iniciativa possam compartilhar seus metadados através
de regras bastante claras e simples. Além destas regras, há dois grupos "participantes": os Provedores de Dados e os Provedores de Serviços. Os Provedores de
Dados são participantes que mantêm repositórios de informação, e implementam o
28
protocolo OAI-PMH para expor os metadados de seus documentos. Já os Provedores
de Serviço utilizam o protocolo para coletar os metadados dos Provedores de Dados,
armazená-los em uma base centralizada, e oferecer algum serviço de valores agregado [LAGOZE and de SOMPEL 2001]
2.7
Provedor de dados
Provedores de dados são sistemas que suportam o protocolo OAI-PMH para disponibilizar metadados. Eles podem ou não oferecer acesso ao conteúdo completo dos
recursos, tendo em vista a sua finalidade principal, que é oferecer metadados.
Em [OAFORUM, 2005] são apresentados os principais pré-requisitos (nem todos
são obrigatórios) para o desenvolvimento de um provedor de dados. São eles:
• Metadados sobre os recursos (os itens propriamente ditos). Eles podem ser
armazenados em um banco de dados relacional, por exemplo;
• Um servidor Web acessível pela Internet;
• Uma linguagem de programação que suporte acessos ao banco de dados utilizado;
• Uma URL base;
• Um identificador único para cada item;
• Um ou mais formatos para os metadados (pelo menos o Dublin Core);
• Datestamps para os metadados (datas de criação e de modificação);
• Uma organização hierárquica dos metadados(opcional);
• Controle de fuxo (opcional, mas recomendado para repositórios de grande porte).
Um provedor de dados é formado por módulos, cada qual com funções bem definidas. Um Parser valida as requisições OAI e decide com base na requisição recebida quais as operações que devem ser executadas. Outro módulo gera as consultas ao banco de dados do repositório, e extrai dela os metadados necessários
de acordo com o formato utilizado. Um terceiro módulo gera as respostas com os
metadados codificados em XML. Um gerador de erros tem a função de retornar as
29
respostas indicativas de erro aos provedores de serviços. Um quinto módulo é responsável pelo controle de fluxo para o gerenciamento de respostas muito longas. A
(figura 3) apresenta os módulos básicos de um provedor de dados, em uma arquitetura
simplificada[CONTESSA 2006].
Figura 3: Representação do esquema de um provedor de dados.[CONTESSA 2006]
Outro ponto importante para os provedores de dados é a compressão. Através
dela é possível diminuir a quantidade de bytes transmitidos e melhorar o desempenho
das respostas do protocolo. A compressão no OAI-PMH é feita no nível do protocolo
HTTP. O próprio harvester é o responsável por indicar nas requisições suas preferências de compressão (ou seja, no cabeçalho HTTP). Se nada for especificado, nenhuma
compressão será usada na transmissão dos metadados.
2.8
Provedor de serviços
Os Provedores de Serviços são sistemas que coletam e organizam os metadados
dos repositórios OAI e os disponibilizam para o usuário final [Gar03]. Como já foi
dito anteriormente, os Provedores de Serviços realizam requisições no formato HTTP
para os Provedores de Dados, que por sua vez disponibilizam os dados em formato
XML. Esses dados são coletados e normalmente armazenados dentro de uma base
de dados. Essa coleta também é comumente chamada de Harvesting. A (figura 4)
mosta uma representação básica de um provedor de serviços.
Para fazer a coleta de dados o Provedor de Serviços realiza as requisições em
30
formato HTTP, através de uma URL básica. Além da URL básica, é preciso identificar o
que será coletado e como a mesma será realizada. Para isto, o OAI define seis verbos
que especificam detalhes da coleta dos repositórios e alguns argumentos (tabela 3),
a fim de refinar o harvester.
Neste trabalho, até então, teve-se uma visão geral sobre BDs e pode-se observar
com mais precisão a parte de interoperabilidade entre elas, contudo, se faz necessário
apresentar os passos básicos para construção de uma BD e os serviços oferecidos
por ela.
31
Verbo
GetRecors
Descrição
Recupera os metadados de um item individual de um repositório.
Identify
É usado para coletar informações sobre um repositório.
Este verbo recupera
os metadados de um
repositório.
ListRecords
ListIdentifiers
ListMetadata
Format
ListSets
É uma abreviação do
ListRecords, que retorna apenas o header (ver seção 3.2.1)
de um repositório.
Retorna os padrões
de metadados utilizados em um repositório.
É utilizado para retornar a estrutura de
um repositório, listando todos os conjuntos que compõe
os metadados.
Argumentos
identifier.
Obrigatório.
Com ele,
especifica-se o identificador único
(ver seção 3.2.1) do item de um repositório. metadataPrefix. Obrigatório. Especifica o padrão de metadados adotado que deve estar especificado no Provedor de Dados.
Não há argumentos.
from. Opcional. Os dados coletados
devem ser criados ou alterados a partir da data específica por este argumento. until. Opcional. Os dados coletados devem ser criados ou alterados até a data especificada pelo argumento. metadataPrefix. Já explicado
anteriormente. set. Opcional. Especifica um conjunto, para o havester
poder refinar a sua coleta. resumptionToken. Exclusivo. Argumento necessário quando os provedores utilizam o controle de fluxo na coleta dos
metadados.
from. until. metadataPrefix. set. resumptionToken.
identifier. Opcional (apenas neste
verbo). Retorna o padrão de metadados utilizado em um item específico.
resumptionToken.
Tabela 3: Os verbos e seus argumentos [Forc, 2003].
32
Figura 4: Provedor de Serviços. [CONTESSA 2006]
2.9
Construção de uma biblioteca digital
O desenvolvimento de uma biblioteca digital diferencia-se dos demais sistemas
gestores de conteúdo on-line por apresentar serviços que caracterizam o funcionamento de uma biblioteca convencional, porém na Internet. A arquitetura de uma biblioteca digital consiste em três camadas principais: interface com o usuário, os serviços
oferecidos e o repositório de metadados. é importante que essa arquitetura seja altamente customizável, configurável e adaptativa, refletindo a diversidade de aplicações
que se espera para as bibliotecas digitais.
Com relação as interfaces do sistema da biblioteca, as mesmas devem ser capazes de agrupar os serviços oferecidos de acordo com a necessidade de cada comunidade de usuários, desde interfaces simples apenas para usuários gerais (educadores,
estudantes, pesquisadores) até interfaces mais complexas para administradores e moderadores do sistema (contribuidores, revisores, administradores).
33
Dentre os serviços que uma biblioteca digital deve oferecer pode-se destacar quatro principais: busca, navegação, submissão e avaliação
• Busca: um mecanismo criado para que o usuário ao acessar o sistema possa
realizar pesquisa e encontrar informações sobre o assunto de interesse. As
buscas tradicionais, que são módulos comuns para todas as bibliotecas, não
fazem frente à complexidade crescente das necessidades dos usuários e ao
volume exponencial de informações que devem ser gerenciadas. As bibliotecas digitais precisam se deslocar, num futuro próximo, do atual estado passivo,
onde oferece um grau mínimo de adaptação aos seus usuários, para um estágio mais proativo e dinâmico nos processos de entrega e de conformação
da informação para usuários individuais e grupos de usuário e no apoio ao
esforço de comunidades em capturar, estruturar e compartilhar conhecimento
[CALLAN and SMEATON 2003];
• Navegação: o resultado retornado pelas buscas efetuadas pelo usuário deve
conter links que referenciam o trabalho original, facilitando a navegação e o
acesso ao conteúdo;
• Submissão de trabalho: permite que o usuário publique trabalhos em uma Biblioteca Digital. No momento da submissão é necessário que os metadados sejam
fornecidos, estes são responsáveis por referenciar arquivos de trabalhos no repositório da biblioteca. Este serviço torna possível a interação e participação da
comunidade na utilização do sistema, garantindo a sua sustentabilidade;
• Avaliação de trabalho: Para garantir a qualidade dos documentos publicados,
é interessante que as bibliotecas digitais contem comprofissionais para avaliar
a qualidade dos diversos documentos submetidos por usuários antes de serem
publicados, entretanto, nem todas as bibliotecas digitais procedem dessa forma.
Além disso, outros serviços de gerenciamento, tais como criação de contas através
de cadastro de usuários, dentre outros serviços administrativos também devem ser
oferecidos pela biblioteca digital.
34
3
LEVANTAMENTO DE
REQUISITOS
Neste seção, será feito o levantamento de requisitos que é a etapa responsável
pela compreensão do problema, ou seja, são definidas as necessidades dos futuros
usuários. Os modelos gerados nessa fase procuram definir as funcionalidades (requisitos funcionais) e restrições (requisitos não funcionais) que devem ser consideradas
para atender os usuários.
A partir desse capitulo será utilizado a Unified Modeling Language (Linguagem de
Modelagem Unificada - UML). UML trata-se de uma linguagem-padrão cujo objetivo é
visualizar, especificar, construir e documentar todas as informações necessárias para
o desenvolvimento de modelos de sistemas complexos de software orientado a objeto
[BEZERRA 2002].
3.1
Descrição Geral do Ambiente
O projeto tem como objetivo o desenvolvimento de uma biblioteca digital, neste sistema serão disponibilizados os serviços de busca, navegação, submissão e avaliação
de dados.
O serviço de busca permitirá que o usuário localize documentos de interesse para
sua pesquisa através de uma interface de consulta. Esses, por sua vez, serão organizados em seções e cada qual possuirá, ao menos, um usuário avaliador cuja
responsabilidade é a de garantir a qualidade do documento. Qualquer usuário cadastrado poderá submeter documentos e, em casos de não aprovação após análise do
avaliador, não serão publicados no acervo bibliotecário. Os documentos serão cadastrados junto a Metadados, que são palavras chaves que facilitarão a localização dos
próprios. Os Metadados seguirão o padrão DC e serão disponibilizados através de um
provedor de dados, com a finalidade de promover a interoperabilidade de acordo com
35
a iniciativa de arquivos abertos.
A instalação e configuração do sistema da biblioteca digital é responsabilidade do
usuário administrador, que poderá fazê-lo através de um wizard de instalação e configuração, programa no qual será definido o perfil da biblioteca. Este mesmo usuário
tem permissão para criar seções, definir os usuários que serão avaliadores de cada
seção, personalizar o frontend do sistema, gerenciar usuários e documentos.
Sempre que algum documento for submetido ao sistema, uma requisição chegará
para os usuários avaliadores da seção a qual pertence o documento. Para que o
documento seja publicado o mesmo deve passar por avaliadores cadastrados e atingir
a média mínima configurada no sistema.
Usuários cadastrados no sistema poderão personalizar o frontend, assim como
alterar a disposição dos módulos do sistema na tela para que, desta forma, possa
organizá-los da forma que julgar mais adequada.
A biblioteca virtual será desenvolvida com compatibilidade ao padrão OAI-PMH,
entretanto o Provedor de Serviços não será uma funcionalidade do sistema.
3.2
Divisão em Pacotes
O Diagrama de Pacotes descreve os pedaços do sistema divididos em agrupamentos lógicos mostrando as dependências entre estes. O diagrama é ilustra a arquitetura
de um sistema mostrando o agrupamento de suas classes [BEZERRA 2002]. Um pacote pode representar um sistema, um subsistema, uma biblioteca ou uma classe,
pacotes se relacionam com outros pacotes através de uma relação de dependência.
Esse diagrama pode ser utilizado em qualquer fase do processo de modelagem e tem
como objetivo organizar os modelos.
Segundo bezerra uma das possíveis maneiras de se fazer divisão do sistema
em subsistemas é separá-lo de acordo com os casos de uso associados aos atores, seguindo essa forma a figura 18 ilustra o diagrama de pacotes para o sistema
[BEZERRA 2002].
36
Figura 5: Diagrama de Pacotes
3.3
Modelagem Casos de Uso
O diagrama de caso de uso definido pela UML (Unified Modeling Language) tem o
objetivo especificar o comportamento do sistema ou parte(s) dele e descrever as funcionalidades do sistema sem revelar a estrutura e o comportamento interno do mesmo
[BEZERRA 2002]. Um caso de uso pode ser visto como um conjunto de cenários,
onde cada cenário é uma sequência de passos a qual descreve uma interação entre
um usuário e o sistema. Os casos de uso são representados em forma de elipse e
seus nomes devem sempre ser verbos, pois assim facilitam o entendimento dos mesmos. As figuras de 6 a 9 mostram os diagramas de caso de uso propostos para o
sistema.
37
Figura 6: Diagrama de Casos de Uso do módulo Básico.
Figura 7: Diagrama de Casos de Uso do módulo de Avaliação.
38
Figura 8: Diagrama de Casos de Uso do módulo de Administração.
Figura 9: Diagrama de Casos de Uso do módulo de Publicação.
39
3.4
Descrição dos Atores
• Administrador: Responsável por gerenciar a biblioteca. Definir nota e quantidade avaliações e gerenciar usuários são algumas de suas funções.
• Avaliador: Responsável por avaliar artigos da categorias que ele é avaliador.
• Usuário Comum: Realiza buscas por artigos, uma vez cadastrado ele pode
gerenciar seu perfil, submeter artigos entre outras ações.
• Tempo: Responsável por publicar os artigos avaliados.
3.5
Descrição dos Casos de Uso
Uma breve descrição dos casos de usos pode ser vista na tabela 4:
Caso de Uso:
Personalizar
página
Alterar dados
do perfil
Submeter artigo
Ator:
Usuário comum
Qualificar artigos
Realizar consultas
Avaliar artigo
Usuário comum
Manter usuário
Manter categorias
Manter critério
de avaliação
Usuário Gerenciador
Usuário Gerenciador
Usuário Gerenciador
Publicar artigo
Tempo
Usuário comum
Usuário comum
Usuário comum
Usuário avaliador
Sumário
Configurar e organizar a exibição do conteúdo do site conforme seu interesse.
Alterar dados cadastrais bem como alterar
seus interesses de pesquisa.
Submeter documentos para avaliação e
possível publicação na biblioteca digital.
Usuário pode pontuar artigos acessados
na BD, qualificando-o.
Realizar consultas e pesquisar sobre temas de interesse.
Verificar se os artigos submetidos por outros usuários passam pelo critério de avaliação pré-determinado.
Cadastrar, alterar, remover, buscar usuários.
Cadastrar, alterar, remover, buscar categorias da biblioteca.
Definir critérios de avaliação para que artigos enviados por outros usuários possam
ser avaliados e possivelmente publicados.
Depois de avaliado e aprovado sistema publica artigo na biblioteca virtual.
Tabela 4: Descrição dos casos de uso propostos na solução.
40
Abaixo seguem as descrições completas dos casos de uso. Vale ressaltar que
todas as descrições foram feitas, porém por uma questão de estética, somente os
casos de uso mais complexos serão descritos no trabalho.
3.5.1
Avaliar artigo
Identificação: UC01 - Avaliar artigo
Sumário: O avaliador realiza avaliações sobre os artigos submetidos.
Ator Primário: Usuário Avaliador
Pré-condições: O avaliador deve estar autenticado no sistema e ser avaliador da
categoria que o artigo pertence.
Fluxo Principal:
1. O caso de uso inicia quando o avaliador requisita avaliar artigos.
2. O sistema apresenta quais artigos estão disponíveis.
3. O avaliador indica qual artigo quer avaliar.
4. O sistema mostra a tela onde será dada a nota e os comentários serão feitos.
5. O avaliador insere nota e comentários e clica em Salvar, o caso de uso termina.
Fluxo Alternativo: Não Há.
Fluxo de Exceção: (E1) Caso o ator não informe a nota ou não faz comentários
o sistema avisa que campos obrigatórios não foram preenchidos.
Pós-condições: Uma avaliação foi inserida no sistema.
3.5.2
Manter Usuário
Identificação: UC02 - Manter Usuário
Sumário: O Administrador realiza a manutenção (remoção, alteração e consulta)
dos dados sobre o usuário.
Ator Primário: Administrador
41
Pré-condições: O Administrador deve estar autenticado no sistema.
Fluxo Principal:
1. O caso de uso inicia quando o Administrador requisita a manutenção do usuário.
2. O sistema apresenta as operações que podem ser realizadas: Tornar um usuário
avaliador de alguma categoria, tornar o usuário um administrador e remover um
usuário.
3. O Administrador seleciona qual das opções ele quer realizar.
Fluxo Alternativo: (A1) Administrador
1. O administrador seleciona um usuário, e solicita ao sistema que torne o usuário
um administrador.
2. O sistema pede uma confirmação e caso seja verdadeira altera os dados, caso
contrario aborta a operação. Nas duas situações o caso de uso termina.
(A2)Tornar Avaliador
1. O administrador seleciona um usuário.
2. O sistema apresenta a lista das Categorias.
3. O administrador seleciona quais categorias o usuário deve ser moderador.
4. O sistema pede uma confirmação e caso seja verdadeira altera os dados, caso
contrario aborta a operação. Nas duas situações o caso de uso termina.
(A3)Remoção
1. O administrador seleciona um usuário, e solicita ao sistema que o remova.
2. O sistema verifica se o usuário pode ser removido, se puder passa para o próximo passo, caso contrario aborta a operação e o caso de uso termina.(E1)
3. O sistema pede uma confirmação e caso seja verdadeira realiza a remoção, caso
contrario aborta a operação. Nos dois casos o caso de uso termina.
Fluxo de Exceção: (E1) Usuário com artigos
42
1. Caso o administrador tente remover um usuário que tenha um artigo publicado o
sistema não aceitará a remoção e exibirá um alerta.
Pós-condições: Uma usuário foi modificado ou removido do sistema.
3.5.3
Publicar artigo
Identificação: UC03 - Publicar artigo
Sumário: O ator Tempo dispara um evento que executa a Stored Procedure.
Ator Primário: Tempo
Pré-condições: O serviço do SQL Server Agent deve estar instalado e em execução para que os trabalhos possam ser executados.
Fluxo Principal:
1. O caso de uso inicia todos os dias em uma hora determinada pelo administrador.
2. O SQL Server verifica quais artigos sofreram alguma avaliação, atribui uma média estes e verifica se existe alguma restrição ao artigo em questão.
Fluxo Alternativo:
(A1) Artigo não tem a quantidade mínima de avaliações definidas no sistema
1. O SQL Server não irá avaliar o artigo.
(A2) Artigo com média maior que a nota mínima e sem restrição
1. O SQL Server altera a situação do artigo para Publicado.
(A3) Artigo com média maior que a nota mínima e com restrição
1. O SQL Server altera a situação do artigo para Aceito com Restrição.
(A4) Artigo com média menor que a nota mínima
1. O SQL Server altera a situação do artigo para Rejeitado.
43
Fluxo de Exceção: (E1) Caso ocorra algum erro durante o processo de publicação de artigos o SQL Server avisará o administrador através de e-mail.
Pós-condições: Um ou mais artigos tem nova situação no sistema ou não foram
avaliados.
44
4
ESPECIFICAÇÃO DE ANÁLISE
A especificação de análise é focada na investigação do problema proposto. O
principal objetivo da fase de análise é levar o analista ao entendimento de como o
sistema em questão funciona (WAZLAWICK, 2004).
É uma atividade que engloba a maioria das tarefas de engenharia de software,
tendo como objetivo identificar a necessidade do usuário, atribuir funções ao hardware, ao software, às pessoas, ao banco de dados e aos demais elementos do sistema (PRESSMAN, 2007). Serão apresentados os diagramas de classe, interação,
transição de estados e pacotes.
4.1
Diagrama de Classes
O diagrama de classe serve para ilustrar classes, interfaces e suas associaçães.
Eles são usados para a modelagem estática dos objetos [BEZERRA 2002]. Uma
classe possui três partes distintas, o nome que define a classe, os atributos e as
operações pertencentes a esta classe. Não necessariamente o diagrama de classe
precisa, a princípio, possuir atributos ou operações. Assim, os diagramas de classe
podem exibir nas fases inicias da análise apenas o nome das classes, e em uma fase
seguinte os atributos e operações. A figura 10 apresenta o diagrama de classes do
sistema proposto.
A figura 10 representa o Diagrama de Classes do sistema.
45
Figura 10: Diagrama de Classe.
46
4.2
Dicionário de Dados
As tabelas 5 a 9 apresentam o dicionário de dados das classes do sistema.
Classe Artigo
Contém informações sobre o artigo
ATRIBUTO
TIPO
DESCRIÇÃO
Id_Usuario
Int
Identifica o usuário que submeteu o artigo
Id_Categoria
Int
Identifica a qual categoria o artigo pertence
Dt_Submissao
Date
Data em que o artigo foi submetido ao sistema
Fl_Situacao
Int
Situação atual do artigo, define se um artigo esta publicado ou não
Dc_Title
String
Titulo do artigo
Dc_Subject
String
Uma descrição do conteúdo do Artigo.
Pode incluir um resumo
Dc_Type
String
A natureza ou o gênero do conteúdo do recurso
Dc_Source
String
Referência de onde o recurso foi gerado
Dc_Relation
String
Referência para um outro recurso relacionado
Dc_Coverage
String
Inclui um local (nome de um lugar ou coordenadas geográficas)
Dc_Creator
String
Entidade responsável pela criação do conteúdo do recurso
Dc_Publisher
String
Entidade responsável por disponibilizar o
recurso criado
Dc_Contribuitor
String
Pessoa, organização que contribuir com o
conteúdo do recurso criado.
Dc_Rights
String
Informação sobre os direitos do recurso
Dc_Date
String
Uma data que pode ser a criação ou disponibilização do recurso
Dc_Format
String
O tamanho digital composição do recurso
Dc_Identifier
String
O ISBN de um livro, o ASIN de uma música, uma URL com o recurso etc
Dc_Language
String
O idioma do conteúdo intelectual do recurso.
Tabela 5: Dicionário de dados Artigo
47
Classe Avaliação
Contém informações sobre a avaliação
ATRIBUTO
TIPO
DESCRIÇÃO
Id_Usuario_avaliador Int
Identifica o usuário que avaliou o artigo
Id_Artigo
Int
Identifica o artigo avaliado
Vl_Nota_Avaliacao
Float
Nota dada ao artigo pelo avaliador
Ds_Comentarios
String
Comentarios feitos pelo avaliador sobre o
artigo, critica ou sugestão
Fl_Situacao
Int
Situação da avaliação, permite saber se a
avaliação é valida ou não
Fl_Restricao
Int
Identifica alguma restrição para publicação
do artigo
Tabela 6: Dicionário de dados Avaliação
Classe Usuario
Contém informações sobre o usuário
ATRIBUTO
TIPO
DESCRIÇÃO
Nm_Usuario
String
Nome do Usuário
Ds_Login
String
Nome usado para fazer Login no sistema
Ds_Email
String
e-mail do usuário
Fl_Tipo_Usuário
Int
Define se o usuário é avaliador ou se é um
gerenciador da biblioteca
Fl_Status
Int
Define se o usuário esta ativo
Dt_Cadastro
Date
Data de cadastro do usuário no sistema
Tabela 7: Dicionário de dados Usuário
Classe Categoria
Contém informações sobre a categoria
ATRIBUTO
TIPO
DESCRIÇÃO
Ds_Categoria
String
Nome da categoria
Fl_Situacao
Int
Define se a categoria esta ativa
Tabela 8: Dicionário de dados Categoria
Classe Artigo_Situacao
Contém informações sobre a Artigo_Situacao
ATRIBUTO
TIPO
DESCRIÇÃO
Ds_Situacao
String
Descrição da situação que o artigo se encontra
Tabela 9: Dicionário de dados Artigo_Situação
48
4.3
Diagrama de Interação
Diagramas de Interação representam como grupos de objetos colaboram em algum comportamento [BEZERRA 2002]. Tipicamente, um diagrama de interação descreve o comportamento de um único caso de uso. O diagrama mostra vários objetos e
as mensagens que são passadas entre estes objetos em um caso de uso, permitindo
assim modelar os aspectos dinâmicos de um sistema. Existem dois tipos de diagrama
de interação, diagrama de comunicação e sequência, no caso especifico deste trabalho será apresentado apenas o diagrama de sequência.
4.3.1
Diagrama de Sequência
Segundo [BEZERRA 2002], o diagrama de sequência mostra a interação existente
num conjunto de objetos e seus relacionamentos, dando ênfase à ordenação temporal
de mensagens.
Nas figuras 11 a 15 são apresentados os diagramas de sequência construídos na
fase de analise.
Os casos de uso Manter Artigo, Manter Categoria, Alterar dados perfil, Alterar
Configurações do Sistema, Submeter Artigo e Realizar Consulta seguem o mesmo
modelo dos diagramas apresentados abaixo, por isso não serão mostrados.
Diagrama de Sequência Inserir Usuário
49
Figura 11: Diagrama de Sequência do caso de uso Manter Usuário (Inserir)
50
Diagrama de Sequência Consultar Usuário
Figura 12: Diagrama de Sequência do caso de uso Manter Usuário (Consultar)
Diagrama de Sequência Altera Usuário
Figura 13: Diagrama de Sequência do caso de uso Manter Usuário (Alterar)
51
Diagrama de Sequência Remover Usuário
Figura 14: Diagrama de Sequência do caso de uso Manter Usuário (Remover)
Diagrama de Sequência Publicar Artigo
Figura 15: Diagrama de Sequência do caso de uso Publicar Artigo
52
4.4
Diagrama de Transição de Estado
O Diagrama de Transição de Estado permite descrever o ciclo de vida de objetos
de uma classe, os eventos que causam a transição de um estado para outro e a
realização de operações resultantes [BEZERRA 2002]. Os diagramas de transição
de estado não são definidos para todas as classes de um sistema, mas apenas para
aquelas que possuem um número definido de estados e os eventos que causam a
transição de um estado para outro são conhecidos.
A figura 16 ilustra o diagrama de transição de estados da classe Artigo.
Figura 16: Diagrama de Transição de Estado
53
4.5
Diagrama de Pacotes
O propósito de um diagrama de pacotes é prover uma visão de nível mais alto
do sistema, mostrando sua decomposição em subsistemas. O ponto de partida para
essa decomposição é o domínio do problema e, portanto, a decomposição utilizada
no modelo de casos de uso foi transposta para o modelo de classes, como mostra a
figura 17.
Figura 17: Diagrama de Pacotes
54
5
ESPECIFICAÇÃO DE PROJETO
A especificação de projeto visa a produzir uma solução para o problema identificado na fase de análise [WAZLAWICK 2004].Segundo Pressman [PRESSMAN 2007],
a especificação do projeto é o processo de se aplicar várias técnicas e princípios ao
propósito de se definir um dispositivo, um processo ou um sistema com detalhes suficientes para permitir sua realização física.
5.1
Escolha da Tecnologia
A seguir, são apresentados os requisitos tecnológicos para desenvolvimento do
protótipo do sistema proposto:
• Plataforma de desenvolvimento .Net 4.0 [Microsoft 2010];
• Ambiente de desenvolvimento VisualStudio 10 [Microsoft 2010];
• Sistema de Gerenciamento de Banco de Dados: SQLServer 2008 R2 [Microsoft 2010].
A escolha das tecnologias utilizadas nesse trabalho levou em conta o conhecimento prévio de algumas delas, a facilidade de aprendizado das demais e a integração
entre todas.
5.2
Arquitetura do Sistema
Desta seção em diante o sistema foi dividido em cinco pacotes, referentes aos
subsistemas de Administração, Submissão, Busca, Avaliação e Publicação. Tal decomposição deu-se de acordo com o acoplamento existente entre as classes. Com
55
essa decomposição, cada pacote poderá ser desenvolvido de forma paralela e independe. A divisão foi feita buscando a máxima coesão entre as classes e o mínimo
acoplamento entre os pacotes [BEZERRA 2002]. A figura 18 ilustra o diagrama de
pacotes do sistema.
Figura 18: Diagrama de Pacotes
Devido a restrições de tempo e mão-de-obra nem todos pacotes serão implementados, sendo escolhidos para a continuidade do trabalho os pacotes de Administração,
Submissão, Busca, Avaliação e Publicação.
56
5.3
Pacotes De Administração, Submissão, Busca e
Avaliação
5.3.1
Divisão em Camadas
Neste trabalho, foram utilizadas duas formas complementares de agrupamento de
classes em pacotes: primeiramente pelo domínio do problema, aproveitando os subsistemas definidos na fase de análise, e depois por estereótipos, tendo sido utilizados
os estereótipos propostos por Coad e Yourdon [Coad93]. Sendo assim, o diagrama
de pacotes de nível mais alto, mostrado na figura 18, é praticamente o mesmo da fase
de análise, exceto pela remoção do pacote de interoperabilidade, que foi retirado por
questões de limitação de tempo e mão-de-obra.
O projeto da arquitetura do sistema, deve considerar quatro componentes básicos,
como mostra a figura 19 [BEZERRA 2002]:
Figura 19: Arquitetura Básica de Projeto Orientado a Objetos
• Componente do Domínio do Problema: corresponde aos subsistemas responsáveis por implementar diretamente os requisitos dos usuários;
• Componente de Interface com Usuário: corresponde aos subsistemas que implementam as interfaces com o usuário;
• Componente de Gerência de Tarefa: corresponde aos subsistemas responsáveis
por controlar e coordenar tarefas;
• Componente de Gerência de Dados: corresponde aos subsistemas responsáveis pelo armazenamento e recuperação de objetos (persistência dos objetos).
A figura 20 ilustra o diagrama de pacotes dos referentes a Administração, Submissão, Busca e Avaliação.
57
Figura 20: Diagrama de Pacotes - Divisão em Camadas
De acordo com a figura 20, a camada de interface com o usuário (IU) faz uma
requisição a gerência de tarefas (GT) onde esta, direciona para a camada de domínio
do problema (DP) responsável pela regra de negócio ou para a camada de gerência
de dados (GD) que é responsável pela persistência dos dados.
58
Componente Domínio do Problema
A figura 21 ilustra o diagrama de classes do componente domínio do problema.
Figura 21: Diagrama de Classes Componente Domínio do Problema
59
Componente Gerência de Tarefas
A figura 22 apresenta o diagrama de classes do componente de Gerência de Tarefas. Vale ressaltar que a classe Artigo_Situação não foi mapeada pois trata-se de
uma classe estática potanto seus dados serão inseridos manualmente.
Figura 22: Diagrama de Classes Gerência de Tarefas
Diagramas de Sequência Revisados
No decorrer da modelagem e desenvolvimento do protótipo, observou-se a necessidade do refinamento das interações do sistema. Sendo assim, serão apresentados
os diagramas de sequência detalhado do módulo de Administração em nível de projeto, junto as suas camadas.
As figuras 23 a 28 ilustram os Diagramas de Sequência revisados.
60
Figura 23: Diagrama de Sequência Revisado - Inserir Usuário
Figura 24: Diagrama de Sequência Revisado - Consultar Usuário
61
Figura 25: Diagrama de Sequência Revisado - Alterar Usuário
Figura 26: Diagrama de Sequência Revisado - Remover Usuário
62
Figura 27: Diagrama de Sequência Revisado - Listar Artigos
Figura 28: Diagrama de Sequência Revisado - Publicar Artigo
63
Componente Gerência de Dados
Padrão DAO
O padrão DAO abstrai toda a complexidade relativa à interação com a fonte de dados sendo utilizada, que poder ser um banco de dados relacional, orientado a objetos,
ou mesmo dados provenientes de serviços disponibilizados por sistemas externos.
Como a interface de um DAO não se altera quando sua implementação precisa ser
modificada, este padrão permite alterar a fonte de dados sendo utilizada numa aplicação sem afetar os componentes de negócios que fazem uso deste [SUN, 2010].
A figura 29 apresenta o diagrama de classes do Componente de Gerência de
Dados. Nesse diagrama também é omitido a classe Artigo_Situação por ser uma
classe estática.
Figura 29: Diagrama de Classes do Componente de Gerência de Dados
Diagrama Relacional
O Diagrama Relacional baseia-se em dois conceitos: Entidade e Relação.
• Entidade: É um elemento caracterizado pelos dados que são recolhidos na
sua identificação vulgarmente designado por tabela. Na construção da tabela
64
identificam-se os dados da entidade a atribuição de valores a uma entidade constrói um registro da tabela.
• Relação: Determina o modo como cada registro de cada tabela se associa a
registros de outras tabelas.
As tabelas do banco de dados são representadas através de classes e os registros
de cada tabela são representados como instâncias das classes correspondentes. A na
figura 30 será apresentado o modelo relacional do banco de dados para o sistema proposto. Foi acrescentado a todas as tabelas o atributo "Id_Tabela"como chave primária,
essa identificação não tem significado no domínio de negócio. Porem a abordagem
é utilizada para manter uma padronização e por ser uma das melhores maneiras de
associar identificadores a objetos mapeados para tabelas.
Figura 30: Diagrama Relacional
65
Componente de Interface com o Usuário
A figura 31 mostra o diagrama de navegação do sistema proposto.
Figura 31: Diagrama de Navegação
66
Padrão de Interface
A tabela 10 apresenta os ícones do sistema e suas respectivas descrições.
Ícone
Descrição
Perfil do usuário
Submeter artigo
Artigos que o usuário submeteu
Avaliar Artigo
Gerenciar usuários
Gerenciar artigos
Gerenciar categorias
Gerenciar configurações
Ler / Fazer Download do PDF
Tabela 10: Ícones
As figuras 32, 33, 34 e 35 monstram o padrão de interface das telas a ser utilizado
no desenvolvimento do sistema proposto.
67
Figura 32: Padrão de Interface Busca
Figura 33: Padrão de Interface Listar
68
Figura 34: Padrão de Interface do Painel de Controle
Figura 35: Padrão de Interface Cadastro
69
5.4
Pacote de Publicação
O pacote de Publicação de Artigos será implementado através de uma Stored
Procedure e executado pelo SQL Server Agent. As duas tecnologias serão descritas
a seguir.
5.4.1 SQL Server Agent
O SQL Server Agent é um serviço do Microsoft SQLServer 2008 R2 que permite
automatizar algumas tarefas administrativas. O SQL Server Agent executa trabalhos,
monitora o SQL Server e processa alertas. O serviço do SQL Server Agent deve estar
instalado e em execução para que os trabalhos administrativos locais ou multiservidor
possam ser executados automaticamente [Microsoft 2010].
5.4.2 Stored Procedure
Stored Procedure (procedimento armazenado) é um conjunto de comandos SQL
que podem ser armazenados no servidor. Stored procedures encapsulam tarefas repetitivas, aceitam parâmetros de entrada e retornam um valor de status (para indicar
aceitação ou falha na execução). O procedimento armazenado pode reduzir o tráfego na rede, melhorar a performance, criar mecanismos de segurança entre outros
[Microsoft 2010].
A figura 36 mostra a Stored Procedure criada para a publicação dos artigos.
70
Figura 36: Stored Procedure - Publica Artigo
71
5.5
Diagrama de Componentes
O Diagrama de componentes ilustra como as classes deverão se encontrar organizadas através da noção de componentes de trabalho. O diagrama tem por objetivo
apresentar a disposição dos componentes físicos de um sistema. Componente é uma
parte física do sistema, como o código fonte, biblioteca, tabela de banco de dados e
outros [BEZERRA 2002]. A figura 37 exibe a organização dos componentes do sistema.
Figura 37: Diagrama de Componentes
5.6
Diagrama de Implantação
A figura 38 apresenta o Diagrama de implantação do sistema proposto. Este diagrama representa a topologia física juntamente com os componentes dessa topologia
72
[BEZERRA 2002].
Os elementos de um diagrama de implantação são os nós e as conexões. Um nó
é uma unidade física que representa um recurso computacional e normalmente possui
uma memoria e alguma capacidade de processamento. Os nós são ligados uns aos
outros através de conexões. As conexões mostram mecanismos de comunicação
entre os nós.
Figura 38: Diagrama de Implantação
73
6
TESTES
Segundo [Fer 2002], um número de quatro a cinco colaboradores é capaz de identificar grande parte dos problemas de usabilidade de um sistema. Deste modo, foi
tomada a decisão de reunir um grupo de quatro participantes para realização dos
testes.
Assim sendo, foram escolhidos colaboradores de diferentes perfis e conhecimentos no uso de sistemas Web, para avaliar o sistema sob ponto de vista de usuários
distintos. Vale ressaltar que dois deles, são entendidos quanto à utilização da Internet
sobre sistemas de busca e cadastros. O outro participante possui entendimento baixo
sobre esse tipo de sistema, justamente por essas características que se deu tal escolha para que pudesse adaptar esse tipo de sistema para esse perfil de usuário. E o
último colaborador possui nível de entendimento mediano pertinente a sistemas como
o proposto.
No período de testes, foi proposto a cada colaborador uma lista de itens a serem
feitos dentro da Biblioteca (documento que pode ser verificado no Anexo A - Plano
de Teste). Com auxílio de uma planilha, os seguintes dados foram anotados para
concretizar os resultados finais: tempo consumo para execução da tarefa, número de
erros, se conseguiu ou não realizar a tarefa e algumas observações que possam ser
importantes. Depois dos testes, além dos dados coletados durante o procedimento,
outras informações são necessárias para se medir a usabilidade do sistema. Logo
após tais testes em uma conversa sem formalidades, foram levantadas outras dúvidas
a serem discutidas sobre a biblioteca.
Finalizados os testes, e em consequência recolhimento de informações, realizouse uma pesquisa sobre as reais necessidades de Usabilidade da Biblioteca. Em conclusão, o software foi bem aceito pelos colaboradores, que não tiverem problemas
em executar a maioria dos testes solicitados. Todavia, algumas modificações foram
sugeridas e os detalhes dos resultados dos testes serão vistos a seguir.
74
6.1
Resultados
Os resultados dos testes de usabilidade da Biblioteca foram baseados nos seguintes itens: tempo consumido para execução da tarefa, número de erros, se conseguiu
ou não realizar a tarefa e resposta do questionário de avaliação pelos participantes.
Na tabela abaixo, serão apresentadas as medidas coletadas na execução das
tarefas realizadas no teste de usabilidade.
TAREFAS
Pior Nível
Nível Alvo
Usuário 1
Usuário 2
Usuário 3
Usuário 4
Média
1
18
10
6
7
9
8
8
2
25
15
9
9
15
12
11
3
120
60
55
43
132
117
87
4
35
20
17
16
19
22
19
5
240
200
178
129
257
228
198
6
60
40
28
37
32
31
32
7
60
40
32
38
43
38
38
8
30
15
8
5
11
9
8
9
25
15
8
9
12
9
10
10
110
40
22
35
55
60
43
11
60
40
27
34
48
32
35
12
100
60
57
48
59
46
53
Tabela 11: Tempo de Execução das Tarefas (em segundos)
Na tabela Abaixo é apresentado o número de erros de cada colaborador nas tarefas propostas.
TAREFAS
Pior Nível
Nível Alvo
Usuário 1
Usuário 2
Usuário 3
Usuário 4
Média
1
2
0
0
0
0
0
0
2
3
1
0
0
1
0
0
3
2
1
0
0
2
1
0
4
1
0
0
0
0
0
0
5
4
2
1
1
3
1
0
6
2
0
0
1
0
1
0
7
2
0
0
1
0
1
0
8
1
0
0
0
0
0
0
9
2
0
0
0
0
0
0
10
3
1
1
0
3
1
0
11
2
1
0
0
0
1
0
12
3
1
1
0
1
1
0
Tabela 12: Número de erros por tarefas
Como pode-se perceber nos dados coletados, em termos gerais, a aceitação
quanto à usabilidade do sistema foi boa. Mesmo participantes com pouco entendimento conseguiram executar todas as tarefas, na maior parte destas, abaixo do pior
nível aceitável de tempo estipulado.
75
7
CONCLUSÕES E TRABALHOS
FUTUROS
Este trabalho verificou e avaliou diversas Bibliotecas Digitais existentes, dentre
elas a BDBComp, SciELO e BDTB. Além disso, foi apresentado a importância das
Bibliotecas Digitais comparada a revistas e congressos como meio de publicação de
artigos científicos. A publicação de trabalhos científicos nessas mídias se mostra um
processo lento e burocrático, o que pode fazer com que bons trabalhos não sejam
publicados por falta de espaço ou que se tornem obsoletos até a publicação. Neste
contexto as Bibliotecas Digitais foram apontadas como uma solução eficiente para este
problema, uma vez que estas estão disponíveis por possuírem políticas próprias de
funcionamento, avaliação e publicação, além disso, podem ser utilizadas por qualquer
instituição.
Entretanto, dentre as diversas Bibliotecas Digitais avaliadas foram constatadas diversas deficiências. Objetivando a correção das deficiências encontradas por este
estudo foi proposto, modelado e implementado um sistema web de Biblioteca Digital.
Desde o início do projeto a proposta foi desenvolver um sistema simples, para que
mesmo usuários com pouca experiência fossem capazes de utilizar todos os recursos
disponíveis, porem eficiente no que se propõe a fazer. Dos objetivos estipulados no
inicio deste trabalho todos foram alcançados, exceto o módulo de interoperabilidade,
porem, o resultado final é muito satisfatório uma vez que os módulos de busca, submissão, avaliação, administração e publicação foram criados. Módulos esses de suma
importância para o funcionamento da biblioteca e que raramente são encontrados em
trabalhos similares.
Durante o período de desenvolvimento desse trabalho foi possível perceber que
todo conhecimento adquirido durante o curso foi de suma importância. O resultado
alcançado foi satisfatório, uma vez que o sistema resolve as principais deficiências
encontradas.
76
Como trabalhos futuros pretende-se desenvolver os módulos de interoperabilidade
e personalização de interface para usuários que por restrições de tempo e mão-deobra não foram implementados.
77
REFERÊNCIAS
[AO 2008] AO, L. F. S. (2008). Bibliotecas digitais e suas utopias. volume 2, pages 2–
36. Salvador, 2 edition. Disponível em: http://www.portalseer.ufba.br/index.
php/revistaici/article/view/2661/2166. Acesso em: MAIO/2010.
[BAEZA and YATES 1999] BAEZA, R. A. and YATES, B. A. R. N. (1999). Modern information retrieval. In ACM Press. Addison - Wesley.
[BEZERRA 2002] BEZERRA, E. (2002). In Princípios de Análise e Projeto Orientado
a Objetos. Campus.
[BUSH 1945] BUSH, V. (1945). As we may think. In Atlantic Montly. Disponível em
http://www.theatlantic.com/doc/194507/bush. Acesso em: MAIO/2010.
[CALLAN and SMEATON 2003] CALLAN, J. and SMEATON, A. (2003). Personalisation and recommender systems in digital libraries. In Joint NSF-EU DELOS
Working Group Report. Disponível em: http://www.ercim.org/publication/
ws-proceedings/DelosNSF/Personalisation.pdf. Acesso em: MAIO/2010.
[CONTESSA 2006] CONTESSA, D. F. (2006). Um serviço de geração de metadados
compatível com o padrão oai para o sistema jems. Disponível em: http://hdl.
handle.net/10183/8615. Acesso em: MAIO/2010.
[CUNHA 1999] CUNHA, M. B. (1999). Desafios na construção de uma biblioteca digital. ciência da informação. volume 28, pages 257–268. 3 edition. Disponível em:
www.ibict.br/cionline e www.scielo.br. Acesso em: MAIO/2010.
[CUNHA 2008] CUNHA, M. B. (2008).
Diferenças e convergências. perspect. ciênc. inf.
In Das Bibliotecas Convencionais às Digitais, volume 13.
Belo Horizonte, 1 edition.
Disponível em: http://www.scielo.br/scielo.
php?pid=S1413-99362008000100002&script=sci_arttext&tlng=en. Acesso em:
MAIO/2010.
[DC 2010] DC (2010). Dublin core metadata initiative. Disponível em: http://www.
dublincore.org. Acesso em: MAIO/2010.
[de Menezes CARDOSO 2007] de Menezes CARDOSO, M. J. (2007). Interoperabilidade entre repositórios digitais utilizando o protocolo oai-pmh. In Clio-i. Disponível em: http://www.cin.ufpe.br/~rbcp/dissertacoes/dissertacaoCARDOSO.
pdf. Acesso em: MAIO/2010.
[et al MARCHIONIINI 2002] et al MARCHIONIINI, G. (2002). In a. bishop et al. digital library use: social practice in design and evaluation. In The people in digital
78
libraries, Multifaceted approaches to assessing needs and impact. MIT Press forthcoming. Disponível em: http://ils.unc.edu/~march/revision.pdf. Acesso em
MAIO/2010.
[Fer 2002] Ferreira, Katia Gomes. (2002). Teste de usabilidade. Monografia de Final
de Curso. Especialização em Informática. Departamento de Ciência da Computação. Universidade Federal de Minas Gerais.
[IEEE 2010] IEEE (2010). Ieee learning object metadata. Disponível.
[KRUTSON et al. 2003] KRUTSON, E., PALMER, C., and TWIDALE, M. (2003). Tracking metadata use for digital collections. In DCMI Conference.
[LAGOZE and de SOMPEL 2001] LAGOZE, C. and de SOMPEL, H. V. (2001). The
open archives initiative: build- ing a low-barrier interoperability framework. In ACM/IEEE Joint Conference on Digital Libraries.
[LOC 2010] LOC (2010). Library of congress. marc standards. Disponível em: http:
//www.loc.gov/marc/. Acesso em: MAIO/2010.
[Microsoft 2010] MSDN Library, an essential source of information for developers using Microsoft tools. Disponível em: http://msdn.microsoft.com/en-us/
library/ms123401.aspx. Acesso em: AGOSTO/2010.
[PRESSMAN 2007] Pressman, Roger S. (2007). Engenharia de Software. Pearson
Makron Books. São Paulo.
[SUN, 2010]
Data Access Object.
Disponível em:
http://www.oracle.
com/technetwork/java/dataaccessobject-138824.html. Acesso em: SETEMBRO/2010.
[VELLUCCI 2002] VELLUCCI, S. L. (2002).
Annual review of information science and technology. In Metadata, volume 36, pages 503–389. Disponível
em: http://dublincore.org/documents/usageguide/glossary.shtml. Acesso
em: MAIO/2010.
[ZENG and CHAN 2006] ZENG, M. L. and CHAN, L. M. (2006). Metadata interoperability and standardization. a study of methodology part i. In D-Lib Magazine.
[WAZLAWICK 2004] Wazlawick, Raul Sidnei. (2004). Análise e Projeto de Sistemas
de Informação Orientados a Objetos. In Editora Campus. Rio de Janeiro.
79
ANEXO A - Plano de Teste
ITEM TAREFA
1
2
3
4
5
6
7
8
9
10
11
12
Buscar um artigo
Abrir o Artigo
Fazer um cadastro no Sistema
Fazer Login no Sistema
com o usuário criado
Submeter um Artigo
Ver seus artigos enviados
Mudar senha pessoal
Sair do sistema
Fazer Login com o usuário
Admin senha 1234
Tornar o Usuário que foi
cadastrado anteriormente
como avaliador da categoria 1
Alterar a nota mínima para
um artigo ser publicado
Avaliar um Artigo
FACILIDADE COMENTARIOS
DE USO