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
Bibliotecas Digitais: Uma abordagem para
armazenamento e publicação de artigos
científicos
Trabalho de Conclusão de Curso apresen-tado 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
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.
minha monografia em página própria na In-ternet ou outro meio de divulgação de tra-balho científico.
Data: 17/11/2010 Assinatura:
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 incentiva-dora.
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 reali-zaçã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.
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
1 Parte de uma reposta a uma requisição onde pode-se observar o DC
em conjunto com o XML. . . 24
2 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
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
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.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.1 Resultados . . . 74
7 CONCLUSÕES E TRABALHOS FUTUROS 75
REFERÊNCIAS 77
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 buro-crá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 publi-cados, 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 pri-mar 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 funci-onalidades como submissão, avaliação e publicação de artigos.
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 exis-tê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) po-dem ser definidas como organizações que fornecem recursos para selecionar, estru-turar, oferecer acesso intelectual, distribuir, preservar a integridade e garantir a perma-nê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 publica-dos, bem como links para os textos dos trabalhos (ou mesmo o arquivo propriamente dito, como texto). Um exemplo de biblioteca digital é a BDBComp [LAENDER; RO-BERTO,2004].
consequên-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 digi-tais 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 so-mente 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 encontra-dos 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 res-peito 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 prin-cipais tecnologias para o desenvolvimento de Bibliotecas Digitais, obtendo maior con-trole, agilidade, facilidade e confiabilidade para a publicação de artigos. Auxiliando
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 ge-renciar 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 cadastra-dos darão notas e tecerão comentários sobre o artigo avaliado;
• Desenvolver ferramentas que auxiliem o usuário administrador a manter a bibli-oteca, 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;
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(OAI-PMH);
• 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 ex-plicar os conceitos de metadados, padrões de metadados, Dublin Core, tipos de inte-graçã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.
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 é cons-tituí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.
Autore(s) Ano Descrição Paul Otlet
e Henri La Fontaine
1895 Criaram Instituto Internacional de Bibliografia, cujo ob-jetivo era registrar em fichas a produção mundial de impressos: o Repertório Bibliográfico Universal[BDs e suas utopias]
H. G. Wells 1938 Sugeriu a criação de uma enciclopédia universal, que conteria a memória planetária completa para toda a humanidade. [AO 2008]
Vannevar Bush 1945 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 é mecani-zado de forma que pode ser consultado com extra-ordinária velocidade e flexibilidade. O memex é um suplemento pessoal ampliador da memória desse in-divíduo. [AO 2008]
IBM 1950 Criou as primeiras aplicações concretas de compu-tadores 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]
Institutos de Pesquisa
1960 Primeiras Bibliotecas Digitais. [AO 2008]
Theodor Holm Nelson
1960 Estabeleceu a idéia de hipertexto e a hipermídia. Es-ses conceitos foram desenvolvidos no contexto do seu projeto chamado Xanadu. [AO 2008]
Governo dos EUA
1994 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 mul-tiagê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 con-ceito das bibliotecas digitais atuais. Este foi vislumbrado por Bush como um dispositivo para uso individual que funcionasse como uma biblioteca mecanizada. Um disposi-tivo 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 ca-pacidade 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
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 Federa-tion 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 en-volve: uma coleção de objetos digitais (repositório); descrições destes objetos (meta-dados); 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 tra-balhos;
• O custo de implementação e manutenção muito inferior a uma biblioteca conven-cional.
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 avaliaimplementa-ção de BDs devem ser consolidados nas necessidades de informações,
características e contextos dos usuários que usarão ou poderão usar essas bibliote-cas.
Apesar dos diferentes pontos de vista apresentados, todos os autores citados, con-cordam que este tipo de biblioteca implica em novas funcionalidades no que diz res-peito á organização, recuperação e armazenamento de informações. As Bibliotecas Digitais devem disponibilizar serviços e produtos, possibilitando recuperar documen-tos compledocumen-tos 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 ta-refa 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 intra-nets. 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 re-positó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 preser-vação. Alguns exemplos de elementos de metadados são: título, autor, descrição, direitos autorais e data de crição.
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 pro-jetos 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 Lear-ning 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 multi-padrõ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 me-tadados 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 compu-taçã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
(Audiência, Proveniência e Detentor de Direitos), assim como um grupo de refinamen-tos de elemenrefinamen-tos (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 des-crições e um breve exemplo de cada são apresentados na tabela 2.
Elemento Descrição Exemplo Title O nome dado ao recurso.
Efetiva-mente, é o nome que curso é formal-mente conhecido.
Casa-Grande e Sen-zala
Subject O tópico do conteúdo do recurso. Ti-picamente, o subject pode ser ex-presso nas palavras-chave do re-curso.
escravidão, literatura, senhor de engenho
description Uma descrição do conteúdo do re-curso. Esse elemento pode incluir: um resumo, um índice ou um texto li-vre sobre o conteúdo1 do recurso.
Em 1933, Gilberto Freyre publica Casa-Grande e Senzala, um livro que revolu-ciona os estudos no Brasil, tanto pela no-vidade dos concei-tos quanto pela qua-lidade literária
Type A natureza ou o gênero do conteúdo do recurso.
texto
Source Uma referência de onde o recurso foi gerado.
Casa-Grande e Senzala, Primeira Ediç ao
Relation Uma referência para um outro recurso relacionado.
Nordeste: Aspectos da Influência da Cana
coverage Inclui um local (nome de um lugar ou coordenadas geográficas), um pe-ríodo no tempo ou jurisdição (enti-dade administrativa).
Recife-PE
Creator Entidade responsável pela criação do conteúdo do recurso. Pode ser uma pessoa, uma organização ou um ser-viço.
Gilberto Freyre
publisher Entidade responsável por disponibili-zar o recurso criado.
Editora Global
contribuitor Pessoa, organização ou serviço res-ponsável por contribuir com o con-teúdo do recurso criado.
Roger Bastide
Rights Informação sobre os direitos do re-curso.
Proibida Reprodução
Date Uma data que pode ser associada com a criação ou disponibilização do recurso.
1933
Format A física ou digital composição do re-curso. Pode incluir um tipo de mídia ou dimensões do recurso (tamanho ou duração).
1.5 MB
identifier Uma referência única para o recurso dado. Exemplos de identificação po-dem ser o ISBN de um livro, o ASIN de uma música, uma URL com o re-curso etc.
ISBN: 852601059X
language O idioma do conteúdo intelectual do recurso. É recomendável que se uti-lize os valores dos elementos defini-dos por.
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.
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 Compu-taçã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.
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, é pre-ciso escolher uma maneira de pesquisa para obter os metadados. Existem duas abor-dagens, ilustradas na (figura 2), mais difundidas para realizar essa tarefa: Harvesting e Federation.
• Federation: Essa abordagem tem como objetivo facilitar a interoperabilidade en-tre os sistemas, enen-tretanto, há um esforço requerido para manter e implantar o conjunto de especificações técnicas estabelecidas. Trata-se de uma aborda-gem onde um grupo de organizações concordam em construir os seus sistemas observando-se certas especificações técnicas através de algum instrumento for-mal. 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 partici-pantes 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 padroniza-dos, 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 es-clarecer 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 inter-face ú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 mini-mizar a complexidade de interoperabilidade de dados entre sistemas:
Figura 2: Ilustra os dois tipo de interoperabilidade apresentados, Federation e Harves-ting. [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 in-formaçõ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 vanta-gem deste tipo de abordavanta-gem é que as informações estão sempre disponíveis para a consulta, aumentando o desempenho do sistema. Por outro lado, os da-dos não estão sempre atualizada-dos.
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 con-versa entre as varias BDs, para solucionar esse problema foram criados alguns proto-colos como o OAI-PMH que se baseia no padrão DC.
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 pa-drõ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 "partici-pantes": 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
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 agre-gado [LAGOZE and de SOMPEL 2001]
2.7
Provedor de dados
Provedores de dados são sistemas que suportam o protocolo OAI-PMH para dis-ponibilizar 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 utili-zado;
• 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 de-finidas. Um Parser valida as requisições OAI e decide com base na requisição re-cebida quais as operações que devem ser executadas. Outro módulo gera as con-sultas 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
respostas indicativas de erro aos provedores de serviços. Um quinto módulo é res-ponsá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ên-cias 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.
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.
Verbo Descrição Argumentos GetRecors Recupera os
metada-dos de um item indivi-dual de um repositó-rio.
identifier. Obrigatório. Com ele, especifica-se o identificador único (ver seção 3.2.1) do item de um re-positório. metadataPrefix. Obrigató-rio. Especifica o padrão de metada-dos adotado que deve estar especifi-cado no Provedor de Dados.
Identify É usado para cole-tar informações so-bre um repositório.
Não há argumentos.
ListRecords Este verbo recupera os metadados de um repositório.
from. Opcional. Os dados coletados devem ser criados ou alterados a par-tir da data específica por este argu-mento. until. Opcional. Os dados co-letados devem ser criados ou altera-dos até a data especificada pelo argu-mento. metadataPrefix. Já explicado anteriormente. set. Opcional. Es-pecifica um conjunto, para o havester poder refinar a sua coleta. resumpti-onToken. Exclusivo. Argumento ne-cessário quando os provedores utili-zam o controle de fluxo na coleta dos metadados.
ListIdentifiers É uma abreviação do ListRecords, que re-torna apenas o hea-der (ver seção 3.2.1) de um repositório.
from. until. metadataPrefix. set. re-sumptionToken. ListMetadata Format Retorna os padrões de metadados utiliza-dos em um repositó-rio.
identifier. Opcional (apenas neste verbo). Retorna o padrão de metada-dos utilizado em um item específico.
ListSets É utilizado para re-tornar a estrutura de um repositório, lis-tando todos os con-juntos que compõe os metadados.
resumptionToken.
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 funciona-mento de uma biblioteca convencional, porém na Internet. A arquitetura de uma biblio-teca 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 alta-mente 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 capa-zes de agrupar os serviços oferecidos de acordo com a necessidade de cada comuni-dade de usuários, desde interfaces simples apenas para usuários gerais (educadores, estudantes, pesquisadores) até interfaces mais complexas para administradores e mo-deradores do sistema (contribuidores, revisores, administradores).
Dentre os serviços que uma biblioteca digital deve oferecer pode-se destacar qua-tro 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 bibliote-cas 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 es-tá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 Bibli-oteca Digital. No momento da submissão é necessário que os metadados sejam fornecidos, estes são responsáveis por referenciar arquivos de trabalhos no re-positó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.
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 (requi-sitos funcionais) e restrições (requi(requi-sitos 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 sis-tema 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 or-ganizados 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 cadas-trado 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 cadas-trados 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
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 con-figuraçã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 agrupamen-tos 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 pa-cote 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 ato-res, seguindo essa forma a figura 18 ilustra o diagrama de pacotes para o sistema [BEZERRA 2002].
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 funci-onalidades 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 mes-mos. As figuras de 6 a 9 mostram os diagramas de caso de uso propostos para o sistema.
Figura 6: Diagrama de Casos de Uso do módulo Básico.
Figura 8: Diagrama de Casos de Uso do módulo de Administração.
3.4
Descrição dos Atores
• Administrador: Responsável por gerenciar a biblioteca. Definir nota e
quanti-dade 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: Ator: Sumário Personalizar
página
Usuário comum Configurar e organizar a exibição do con-teúdo do site conforme seu interesse. Alterar dados
do perfil
Usuário comum Alterar dados cadastrais bem como alterar seus interesses de pesquisa.
Submeter artigo Usuário comum Submeter documentos para avaliação e possível publicação na biblioteca digital. Qualificar
arti-gos
Usuário comum Usuário pode pontuar artigos acessados na BD, qualificando-o.
Realizar consul-tas
Usuário comum Realizar consultas e pesquisar sobre te-mas de interesse.
Avaliar artigo Usuário avalia-dor
Verificar se os artigos submetidos por ou-tros usuários passam pelo critério de avali-ação pré-determinado.
Manter usuário Usuário Geren-ciador
Cadastrar, alterar, remover, buscar usuá-rios.
Manter catego-rias
Usuário Geren-ciador
Cadastrar, alterar, remover, buscar catego-rias da biblioteca.
Manter critério de avaliação
Usuário Geren-ciador
Definir critérios de avaliação para que arti-gos enviados por outros usuários possam ser avaliados e possivelmente publicados. Publicar artigo Tempo Depois de avaliado e aprovado sistema
pu-blica artigo na biblioteca virtual.
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.
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.
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
exe-cuçã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
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
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 hard-ware, ao softhard-ware, às pessoas, ao banco de dados e aos demais elementos do sis-tema (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.
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
sis-tema
Fl_Situacao Int Situação atual do artigo, define se um ar-tigo 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 re-curso
Dc_Source String Referência de onde o recurso foi gerado Dc_Relation String Referência para um outro recurso
relacio-nado
Dc_Coverage String Inclui um local (nome de um lugar ou coor-denadas geográficas)
Dc_Creator String Entidade responsável pela criação do con-teú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
dispo-nibilizaçã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 re-curso.
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 en-contra
4.3
Diagrama de Interação
Diagramas de Interação representam como grupos de objetos colaboram em al-gum comportamento [BEZERRA 2002]. Tipicamente, um diagrama de interação des-creve 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 traba-lho 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 Consultar Usuário
Figura 12: Diagrama de Sequência do caso de uso Manter Usuário (Consultar)
Diagrama de Sequência Altera Usuário
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
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.
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.
5
ESPECIFICAÇÃO DE PROJETO
A especificação de projeto visa a produzir uma solução para o problema identifi-cado 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 sufi-cientes 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 conheci-mento 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 de-composição deu-se de acordo com o acoplamento existente entre as classes. Com
essa decomposição, cada pacote poderá ser desenvolvido de forma paralela e inde-pende. 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 implemen-tados, sendo escolhidos para a continuidade do trabalho os pacotes de Administração, Submissão, Busca, Avaliação e Publicação.
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 sub-sistemas 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 im-plementam 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, Submis-são, Busca e Avaliação.
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.
Componente Domínio do Problema
A figura 21 ilustra o diagrama de classes do componente domínio do problema.
Componente Gerência de Tarefas
A figura 22 apresenta o diagrama de classes do componente de Gerência de Ta-refas. 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 neces-sidade 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 pro-jeto, junto as suas camadas.
Figura 23: Diagrama de Sequência Revisado - Inserir Usuário
Figura 25: Diagrama de Sequência Revisado - Alterar Usuário
Figura 27: Diagrama de Sequência Revisado - Listar Artigos
Componente Gerência de Dados Padrão DAO
O padrão DAO abstrai toda a complexidade relativa à interação com a fonte de da-dos sendo utilizada, que poder ser um banco de dada-dos 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
identificam-se os dados da entidade a atribuição de valores a uma entidade cons-tró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 pro-posto. 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.
Componente de Interface com o Usuário
A figura 31 mostra o diagrama de navegação do sistema proposto.
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.
Figura 32: Padrão de Interface Busca
