UNIVERSIDADE CATÓLICA DE GOIÁS
DEPARTAMENTO DE COMPUTAÇÃO
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
BIBLIOTECA VIRTUAL
UTILIZANDO FRAMEWORK MENTAWAI
PABLO SILVA BORGES
RICARDO AUGUSTO RIBEIRO DE MENDONÇA
GOIÂNIA/GO
JUNHO/2007
ii2
UNIVERSIDADE CATÓLICA DE GOIÁS
DEPARTAMENTO DE COMPUTAÇÃO
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
BIBLIOTECA VIRTUAL
UTILIZANDO FRAMEWORK MENTAWAI
Trabalho de Conclusão de Curso apresentado por Pablo Silva
Borges e Ricardo Augusto Ribeiro de Mendonça à Universidade
Católica de Goiás, como requisito parcial para obtenção do título
de Bacharéis em Ciência da Computação a ser aprovada pela
Banca Examinadora:
Professor Vicente Paulo de Camargo, UCG – Orientador
Goiânia, 14 de junho de 2007.
iii
3
BIBLIOTECA VIRTUAL
UTILIZANDO FRAMEWORK MENTAWAI
PABLO SILVA BORGES
RICARDO AUGUSTO RIBEIRO DE MENDONÇA
Trabalho de Conclusão de Curso apresentado por Pablo Silva Borges e Ricardo Augusto
Ribeiro de Mendonça à Universidade Católica de Goiás, como parte dos requisitos para obtenção
do título de Bacharel em Ciência da Computação.
____________________________________
Professor Vicente Paulo de Camargo
Orientador
_________________________________
Professor Dr. José Luiz de Freitas Júnior
Coordenador de Projeto Final de Curso
iv
4
DEDICATÓRIA
Ao professor Vicente Paulo de Camargo,
orientador
depositada.
acadêmico,
Aos
pelo
nossos
apoio
amigos
e
pelo
confiança
apoio
e
compreensão. Às nossas famílias, pelo incentivo em
todas as fases de nossas vidas.
v5
AGRADECIMENTOS
Agradecemos primeiramente a Deus, pela oportunidade de dar esse salto tão
importante em nossas vidas acadêmicas e profissionais, sempre com saúde e força de vontade.
Agradecemos a todos os professores e colaboradores com os quais tivemos a
oportunidade e o prazer de aprender.
Em especial, agradecemos aos nossos amigos e familiares pela compreensão e
incentivo durante o período de pesquisas e elaboração deste projeto final.
E a todos aqueles que de alguma forma ajudaram e apoiaram-nos nos mais diversos
momentos que passamos.
vi6
RESUMO
Atualmente, com a difusão da internet e a exploração de suas características, como o
uso de aplicações Web, sente-se a necessidade, nos diversos ramos de atuação empresarial, de
adequação à realidade tecnológica que cada vez se torna mais presente no nosso meio.
Surgem assim mudanças de paradigma entre as organizações, a fim de conquistar o cliente e
facilitar cada vez mais a manipulação e, principalmente, a disponibilização das informações.
Diante dessa realidade, várias ferramentas têm surgido todos os dias com o objetivo
de suprir tal deficiência. O projeto de Biblioteca Virtual vem se caracterizar como uma
ferramenta versátil, que utiliza os mais variados e eficientes mecanismos de gerenciamento,
manipulação e tratamento das informações com o intuito de agilizar as funções
administrativas dos operadores e oferecer aos usuários todas as facilidades e particularidades
que uma aplicação Web possui, como a disponibilização da informação em tempo real,
qualquer que seja o lugar através do qual se dá o acesso. Seguindo padrões como RUP, para
projeto e desenvolvimento da aplicação, e MARC, para manipulação das informações dos
acervos adquiridos, e utilizando-se de um framework específico.
Palavras-Chave: Biblioteca, Virtual, aplicação Web, padrão MARC, padrão RUP.
vii
7
ABSTRACT
Currently, with internet diffusion and its characteristics’ exploration, like Web
applications use, there’s need of adjusting to the technological reality that becomes, day after
day, more present between us. In this way, paradigm changes appear among organizations in
order to conquer clients and make easier and easier the manipulation and availability of
information to them.
Over this reality, many tools have appeared every day with the objective of supplying
such deficiency. The Virtual Library project comes to characterize itself as a versatile tool,
which uses the most varied and efficient mechanisms of management, manipulation and
treatment of information with intention of speeding the operators’ administrative functions
and offering to users all the facilities and particularities that a Web application has, like realtime availability of information. Following standards as RUP, to design and development of
application, and MARC, for manipulating information about acquired books, and by making
use of a specific framework, the system provides all functionalities of a well structured
common library, with this difference: its accessibility, that just requires internet connection.
Keywords: Library, Virtual, Web application, MARC standard, RUP standard.
viii
8
BIBLIOTECA VIRTUAL
UTILIZANDO FRAMEWORK MENTAWAI
SUMÁRIO
LISTA DE ABREVIATURAS E SIGLAS
xi
LISTA DE FIGURAS
xii
1.
INTRODUÇÃO
13
2.
UMA VISÃO SOBRE AS FORMAS DE BIBLIOTECA
15
2.1.
A EVOLUÇÃO DA BIBLIOTECA
15
2.2.
O PADRÃO MARC
17
2.2.1.
Componentes de um registro MARC
19
2.2.2.
Formato MARC – Benefícios e Vantagens
21
2.2.3.
O MARC no Brasil
23
2.2.4.
Complementos
24
3.
DESENVOLVIMENTO DE SOFTWARE ORIENTADO A OBJETOS
25
3.1.
ORIENTAÇÃO A OBJETOS
25
3.2.
UML
25
3.3.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
26
3.4.
RUP - RATIONAL UNIFIED PROCESS
27
3.4.1.
Conceitos Básicos
28
3.4.2.
Estrutura do RUP
30
3.4.3.
Elementos Essenciais do Processo
31
3.4.4.
Fases
33
3.4.5.
Complementos
34
3.5.
WEB 2.0
34
3.6.
DESIGN PATTERNS
36
3.6.1.
37
Padrões de Projeto na programação Web
9ix
3.6.2.
3.7.
4.
Vantagens e Desvantagens do uso de Design Patterns
39
FRAMEWORKS
39
3.7.1.
Frameworks Específicos
40
3.7.2.
Frameworks de Visão
42
O SISTEMA DE BIBLIOTECA VIRTUAL
44
4.1.
VISÃO DO PROJETO BIBLIOTECA VIRTUAL
45
4.1.1.
Escopo
46
4.1.2.
Posicionamento
47
4.1.3.
Descrições dos Envolvidos e Usuários
49
4.2.
4.3.
REQUISITOS DO SISTEMA BIBLIOTECA VIRTUAL
51
4.2.1.
Requisitos Funcionais
51
4.2.2.
Requisitos Não Funcionais
58
4.2.3.
Glossário
58
DOCUMENTO DE ANÁLISE DO SISTEMA BIBLIOTECA
60
VIRTUAL
4.4.
4.3.1.
Relação dos Requisitos
60
4.3.2.
Organização dos Requisitos
61
4.3.3.
Expansão dos Casos de Uso
63
4.3.4.
Modelo Conceitual
74
DOCUMENTO DE PROJETO DO SISTEMA BIBLIOTECA
75
VIRTUAL
4.5.
4.4.1.
Diagrama de Seqüência
75
4.4.2.
Diagrama de Classes do Projeto
84
4.4.3.
Modelo de Entidade e Relacionamento (MER)
85
ARQUITETURA DO SISTEMA BIBLIOTECA VIRTUAL
85
4.5.1.
Apresentação
86
4.5.2.
Controle
87
4.5.3.
Negócio
87
4.5.4.
Persistência
87
4.5.5.
Entidade
88
10x
4.5.6.
5.
Visão Geral
CONCLUSÃO
89
91
REFERÊNCIAS BIBLIOGRÁFICAS
92
GLOSSÁRIO
94
ANEXO I
CAMPOS DE UM REGISTRO MARC
99
ANEXO II
EXEMPLO DE REGISTRO NO FORMATO MARC
106
xi
11
LISTA DE ABREVIATURAS E SIGLAS
AOP
ASCII
CALCO
Programação Orientada a Aspectos
American Standard Code for Information Interchange
Catalogação Legível por Computador
CGI
Common Gateway Interface
CMM
Capability Maturity Model
CSS
Cascading Style Sheets
CVS
Concurrent Versioning System
EJB
Enterprise JavaBean
HTML
HyperText Markup Language
IBICT
Instituto Brasileiro de Informação em Ciência e Tecnologia
IoC
Inversão de Controle
IDE
Integrated Development Environment
JEE
Java Enterprise Edition
JSF
Java Server Faces
JSP
Java Server Pages
JSTL
MARC
JSP Standard Tag Library
Machine Readable Cataloging Record
MVC
Model View Controller
OPAC
Online Public Access Catalog
RUP
Rational Unified Process
SEI
Software Engineering Institute
PDS
Plano de Desenvolvimento de Software
UML
Unified Modeling Language
XML
eXtensible Markup Language
WWW
World Wide Web
12
xii
LISTA DE FIGURAS
Figura 1 − Simbologia do padrão MARC.
18
Figura 2 − Exemplo de um registro MARC, ainda uma string no formato de
comunicação MARC.
Figura 3 − Desenvolvimento Iterativo/Incremental.
19
27
Figura 4 − Exemplo de Fases e Dimensões do RUP.
30
Figura 5 − Arquitetura do Struts.
41
Figura 6 − Diagrama de caso de uso do Sistema de Biblioteca Virtual.
73
Figura 7 − Modelo conceitual do Sistema de Biblioteca Virtual.
74
Figura 8 − Diagrama de seqüência autenticar associado.
75
Figura 9 − Diagrama de seqüência autenticar bibliotecário.
76
Figura 10 − Diagrama de seqüência manter acervo.
77
Figura 11 − Diagrama de seqüência manter acervo por MARC 21.
78
Figura 12 − Diagrama de seqüência manter associado.
79
Figura 13 − Diagrama de seqüência manter bibliotecário.
80
Figura 14 − Diagrama de seqüência manter empréstimo.
81
Figura 15 − Diagrama de seqüência manter reserva.
82
Figura 16 − Diagrama de seqüência registrar devolução.
83
Figura 17 − Diagrama de classes do Sistema de Biblioteca Virtual.
84
Figura 18 − Modelo de Entidade e Relacionamento do Sistema de Biblioteca Virtual.
85
Figura 19 − Arquitetura MVC.
86
Figura 20 − Arquitetura do Sistema Biblioteca Virtual.
89
13
BIBLIOTECA VIRTUAL
UTILIZANDO FRAMEWORK MENTAWAI
CAPÍTULO 1
INTRODUÇÃO
Cada vez mais a era digital se faz presente em nosso meio, seja ele acadêmico,
profissional ou comercial. Nos diversos ramos empresariais já vêm se criando a concepção de
que, ou se acompanha a tendência tecnológica que o mundo vive, ou não se terá espaço no
mercado futuro. Baseado nisso, hoje dificilmente encontra-se uma empresa de médio ou até
pequeno porte que não possua ao menos um Web site.
Atualmente a difusão da internet torna-se cada vez mais acentuada e explorada sob
diversos prismas, haja vista que ela possui um poder uniforme de propagar a informação,
maior que qualquer outro meio de comunicação. Nesse aspecto difundiu-se o conceito do uso
de aplicações Web, que manipulariam a informação e a disponibilizaria sem que fosse
necessária a presença física do operador do sistema [2].
Surgem, assim, mudanças de paradigma entre as organizações a fim de conquistar o
cliente e facilitar cada vez mais a manipulação e a disponibilização das informações a ele.
Especificamente sobre a biblioteconomia, o maior problema é de fácil visualização: a
dificuldade de acesso ao acervo, não por falta de estrutura física das bibliotecas - pelo
contrário, muitas são conhecidas pela sua grandiosidade -, mas principalmente por um dos
fatores que mais influencia a vida das pessoas no mundo globalizado de hoje - a falta de
tempo [1].
Imagine, por exemplo, a facilidade de se consultar, de qualquer lugar, a qualquer
hora, informações sobre obras necessárias para realização de um trabalho acadêmico,
necessitando apenas de uma conexão com a internet - sem a necessidade de perder horas no
trânsito para se locomover até uma biblioteca, com uma reunião marcada em poucos minutos,
ou a biblioteca mais próxima se localizar na cidade vizinha, e, ao chegar ao local, descobrir
que o material já estava sob empréstimo.
14
Essa é uma realidade que já ocorre nos dias atuais, nas diversas bibliotecas existentes
no país, mas o conhecimento das características de controle de acervos de uma biblioteca
ainda não é muito disseminado o que dificulta a sua compreensão.
Esse trabalho propõe o desenvolvimento de um sistema de biblioteca que utilizará
mecanismos de gerenciamento, manipulação e tratamento das informações, baseando-se em
padrões reconhecidos, como RUP (Rational Unified Process), para projeto e desenvolvimento
de aplicações.
O Sistema também usará tecnologias de ponta, como a Web 2.0, que permite ao
usuário operar o sistema mais facilmente, de forma prática e intuitiva. Além disso, serão
escolhidos um ou mais frameworks que facilitem e dêem qualidade ao desenvolvimento da
aplicação. Como as bibliotecas utilizam o padrão MARC para catalogação de acervos e
também para comunicação entre bibliotecas para troca de informações, esse sistema
apresentará o padrão MARC para auxiliar na catalogação eletrônica das informações, visto
que esse padrão é pouco difundido no mundo acadêmico e também na esfera empresarial.
O referido trabalho é composto basicamente de cinco capítulos.
O primeiro capítulo faz uma breve introdução sobre o diferencial da realização do
trabalho, descrevendo também sua estrutura organizacional.
O segundo capítulo descreve sobre as formas de biblioteca, tanto as antigas quanto as
emergentes. Também dispõe sobre o padrão MARC, utilizado pela maioria dos sistemas de
bibliotecas, bem como suas pré-evoluções e derivações.
O terceiro capítulo faz referência às tecnologias utilizadas no desenvolvimento do
software, como Orientação a Objetos, UML, RUP e frameworks que poderão ser escolhidos
(ou combinados) para o desenvolvimento da aplicação em questão.
O quarto capítulo dispõe sobre o Sistema de Biblioteca Virtual, suas características,
objetivos e aspirações dos autores com o desenvolvimento do projeto.
Por fim, o quinto e último capítulo apresenta a conclusão, bem como sugestões para
trabalhos futuros.
15
CAPÍTULO 2
UMA VISÃO SOBRE AS FORMAS DE BIBLIOTECA
2.1. A EVOLUÇÃO DA BIBLIOTECA
As inovações tecnológicas têm-se mostrado cada vez mais presentes nas atividades
de nosso dia a dia, haja vista que todas as áreas de atuação estão em constante evolução para
que consigam ter um melhor desempenho e qualidade em suas atividades. Grande parte das
tarefas que há muito tempo vêm sendo desenvolvidas manualmente, em um processo
desgastante, cansativo e não muito eficiente, passaram, com o advento da internet, das redes
de computadores e dos sistemas integrados, a ser automatizadas e a tornar mais fácil a vida
não só de quem provém os serviços, mas de quem os obtém.
No entanto, antes de tudo, faz-se necessário discorrer sucintamente sobre a biblioteca
convencional, suas características e principalmente suas limitações, que levaram à
necessidade da interferência da tecnologia nesse meio.
As tecnologias da imprensa, máquina de escrever, telefone, telex, mimeógrafo,
microfilme, cartão perfurado nas margens, computador, disco ótico, redes eletrônicas e agora
a internet afetaram e tem afetado a biblioteca ao longo do tempo. Algumas dessas tecnologias,
tais como o microfilme e o disco ótico, tiveram suas primeiras aplicações testadas dentro de
uma biblioteca [3].
Assim, apesar das dificuldades financeiras que tradicionalmente a biblioteca
enfrenta, por não oferecer um lucro explicito e apenas fornecer fonte de pesquisa aos
interessados, as novas tecnologias foram, paulatinamente, incorporadas às suas atividades,
provocando mudanças internas e na maneira de prover produtos e serviços aos usuários. Não
que não houvesse restrições por parte dos envolvidos na sua organização, mas o problema é
que a tecnologia chegou atropelando, se infiltrando nas mais diversas áreas. E nos últimos
anos tal mudança tecnológica tem sido cada vez maior num espaço temporal cada vez menor.
Diferentes perspectivas para o gerenciamento de recursos de informação estão sendo
discutidas, podendo-se destacar o conceito de “biblioteca virtual”.
16
Na área da Biblioteconomia e da Documentação, o conceito de virtual vem sendo
usado toda vez que se deseja ressaltar a utilização de infra-estrutura tecnológica de base
eletrônica e rede de computadores e ainda há muita confusão entre os conceitos de biblioteca
informatizada, biblioteca digital e biblioteca virtual.
Na busca por uma explicação para os impactos da tecnologia na geração, publicação
e disponibilidade de documentos com base na tecnologia do computador, a história da
biblioteca pode ser dividida em três períodos principais: [11]
A biblioteca tradicional, de Aristóteles até o início da automação de bibliotecas;
A biblioteca moderna ou informatizada, em que os computadores foram usados
para serviços básicos, como catalogação e organização do “estoque” / acervo;
A biblioteca eletrônica (ou biblioteca do futuro), pensada como uma nova
estratégia para o resgate de informações. Neste ponto, distinguem-se dois prismas: a
biblioteca virtual, onde é possível consultar informações sobre os acervos e reservá-los para
um empréstimo futuro, e a biblioteca digital, onde o texto completo dos documentos está
disponível on-line. No entanto, ambas podem ser acessadas remotamente de uma localidade
qualquer, por meio de uma rede de computadores, favorecendo a acessibilidade universal.
Nesta concepção revolucionária, de biblioteca digital, os “livros virtuais” não
sofrerão mais os problemas de suas contrapartes físicas, podendo ser duplicados quantas
vezes se desejar. A própria biblioteca será “infinita”, pois não haverá limites para o número de
acervos que possa conter, desde que estruturada e disponibilizada em computadores
poderosos, interligados a redes de alta velocidade.
Porém, o foco desse trabalho é a biblioteca virtual. Ela proporciona o gerenciamento
das tarefas internas desenvolvidas pelos operadores da biblioteca, facilitando o acesso a
outros sistemas de informação, a troca de mensagens e a recuperação de arquivos, bem como
a importação de acervos de outras instituições, segundo o padrão MARC, tornando o acervo
próprio sempre atualizado e completo. Além disso, permite que usuários externos acessem as
informações sobre os acervos presentes, interajam com o sistema e façam reservas on-line, de
acordo com a disponibilidade atual, dando praticidade a essa operação.
A partir destas definições, o entendimento de biblioteca virtual fica mais claro, uma
vez que os autores da área não têm um conceito único de biblioteca virtual nem de biblioteca
digital. Uns afirmam que há diferença entre elas, outras as vêem como sinônimas. De forma
clara e objetiva, a “virtual” diria respeito mais à forma de acesso às informações presentes no
acervo da biblioteca, sem a presença física dos envolvidos no processo, enquanto a “digital”
17
faria jus à forma como a informação e os documentos requisitados seriam disponibilizados, de
forma independente de uma estrutura física, pois todo o acervo seria digitalizado.
2.2 O PADRÃO MARC
O padrão MARC foi criado nos anos 70 pela Library of Congress, com a finalidade
de possibilitar que registros bibliográficos pudessem ser manipulados em computadores. O
MARC recebeu modificações ao longo do tempo e passou a ser denominado USMARC nos
anos 80 e MARC 21 no final dos anos 90. É utilizado na organização de catálogos de
bibliotecas em todo o mundo.
A sigla MARC significa Machine Readable Cataloging Record, ou seja, registro
catalográfico legível por computador. Registro catalográfico significa um registro
bibliográfico, tradicionalmente apresentado em uma ficha catalográfica que inclui uma
descrição (título, responsabilidade, edição, dados sobre o material, descrição física, etc.), a
entrada principal e as entradas secundárias (“pontos de acesso” que permitem recuperar itens
em um catálogo), cabeçalhos de assunto (descritores retirados de listas padronizadas de
termos que descrevem o conteúdo do item) e os números de chamada (código de
classificação, em geral alfanumérico, que reúne itens de mesmo assunto em um mesmo local
físico) [5].
O padrão MARC é composto por diversos campos padronizados, que contém
representação de dados e metadados bibliográficos. Cada campo é identificado por uma
seqüência de três dígitos (etiqueta), por exemplo: 100 para o campo autor, 130 para o campo
título, 300 para o campo descrição física, etc. E tais campos podem, ainda, conter subcampos.
O registro MARC contém sinalizadores que marcam o registro armazenado e
auxiliam na leitura e interpretação desse registro. Os sinalizadores indicam o início e o
término dos campos e subcampos. Por exemplo, ao invés de palavras, usam-se os códigos 260
$a $b $c para marcar o campo que contém os subcampos “área de publicação”, “local de
publicação”, “nome da editora” e “data de publicação” em cada registro. Os “sinalizadores”
MARC auxiliam os computadores na leitura e interpretação do registro, marcando o registro
bibliográfico para armazenamento em meio magnético [13].
A Figura 1 apresenta um fragmento de um registro, mostrando os sinalizadores de
texto e seus correspondentes no padrão MARC.
18
Figura 1: Simbologia do padrão MARC [5]
A Figura 1 mostra os sinalizadores para campos, indicadores e subcampos. O número
“100” corresponde à etiqueta que representa o campo onde está o nome do autor.
Os indicadores correspondem a duas posições de caracteres localizados após cada
etiqueta. Na primeira linha da Figura 1, os indicadores para o campo “100” são os caracteres
“1” e “#” (o símbolo # significa que o indicador não é usado). Um indicador de valor “1” no
campo de título, correspondente ao “100” e significa que deverá haver uma entrada de título
no catálogo.
Cada tipo de dado em um campo é chamado “subcampo” e é precedido pelo código
do subcampo, representado por letras minúsculas. Na Figura 1, o campo “300” tem o
subcampo “a” que representa o número de páginas. O código do subcampo é precedido por
um delimitador. Delimitadores são caracteres usados para separar subcampos e podem ser
representados por diferentes símbolos (@, (), $, _, etc.). Na Figura 1, o delimitador é o sinal
“$”.
Existem diferentes formas pelas quais um registro bibliográfico pode ser
representado: uma ficha catalográfica tradicional (cartão), as telas dos sistemas
informatizados de bibliotecas OPAC, já descritas, e as telas de edição de dados de softwares
que trabalham com o padrão MARC. Além desses, o padrão MARC possui um formato de
comunicação que segue a norma ISO 2709, e é utilizado quando o objetivo é o intercâmbio de
registros bibliográficos. O formato de armazenamento interno é convertido para o formato de
comunicação para que os registros possam ser transferidos entre sistemas [5].
A seguir serão descritos mais detalhadamente os componentes de um registro
MARC.
19
2.2.1 Componentes de um registro MARC
A Figura 2 exemplifica um registro MARC.
Figura 2: Exemplo de um registro MARC, ainda uma string no formato de
comunicação MARC [5]
No formato de comunicação, precedendo a parte do registro bibliográfico que
contém os dados, existem duas seqüências de caracteres chamadas “líder” e “diretório”. Além
delas, há de se ressaltar uma terceira seqüência: os campos variáveis.
2.2.1.1 Líder
Armazena informações necessárias ao processamento do registro. Contém códigos
ou números identificados pela posição relativa do caracter. O líder possui tamanho fixo de 24
caracteres e é o primeiro campo de um registro MARC.
20
2.2.1.2 Diretório
Série de entradas que contém a etiqueta (tag), tamanho e posição inicial de cada
campo variável em um registro. Cada entrada do diretório possui 12 caracteres e a sequência
de diretórios é encerrada por um caracter delimitador de campo (ASCII 30).
2.2.1.3 Campos variáveis
O conteúdo propriamente dito é armazenado em campos variáveis, os quais são
identificados por etiquetas compostas por três algarismos. Cada campo termina com um
caracter delimitador de campo. O último campo variável num registro termina co3m um
caracter delimitador de campo e um caracter delimitador de registro (ASCII 29).
Existem dois tipos de campos variáveis: campos variáveis de controle e campos
variáveis de dados.
a) Campos variáveis de controle. Composto pelo grupo 00X. São estruturalmente
diferentes dos campos variáveis de dados. Não possuem indicadores nem códigos de
subcampos. Podem conter um único elemento de informação ou uma série de dados
com tamanho fixo, identificados pela posição relativa dos caracteres.
b) Campos variáveis de dados. Composto pelo grupo 0XX-9XX. Armazenam
informações não estruturadas, de tamanho variável. Neste grupo são utilizados dois
tipos de designação de conteúdo: indicadores e códigos de subcampos. O grupo 9XX
está reservado para implementações locais.
Indicadores: São as duas posições iniciais de caracter do início de cada campo
variável. Contém valores que interpretam ou suplementam os dados armazenados no
campo. Os indicadores são independentes e podem ser caracteres ou algarismos.
Quando o uso de indicadores não é aplicável, o caracter branco (ASCII 32) é usado
para preencher a posição. O uso de espaço em branco numa posição definida de
indicadores pode possuir significado ou indicar que nenhuma informação foi
indicada.
Códigos de subcampo: Conjunto de dois caracteres que precedem cada
elemento de dados que requeira tratamento separado em um campo. Um código de
subcampo consiste de um delimitador (ASCII 31 para MARC e ASCII 94 para
CDS/Isis) seguido por identificador de elemento de dados. Identificador de elemento
21
de dados pode ser caracteres numéricos ou alfabéticos em caixa baixa. Subcampos
são definidos de forma independente para cada subcampo, mas preservam o mesmo
significado sempre que possível. Subcampos são definidos para fins de identificação,
não de arranjo.
2.2.2 Formato MARC – Benefícios e Vantagens
Os benefícios e vantagens para uma biblioteca que adere ao padrão MARC 21,
certamente vão além dos que serão destacados a seguir neste trabalho.
Muitos se perguntam por que devem usar o formato MARC, se podem obter
resultados igualmente satisfatórios através de uma solução bem mais simples, sem se
preocupar com tantos detalhes, aparentemente inúteis. Esta poderá ser a indagação de um
profissional de informática, encarregado de estudar uma solução para a automação da
biblioteca local, porem cabe aos bibliotecários não se deixar levar pelas facilidades e
resultados imediatos, considerando com atenção as seguintes questões: [5]
a) Importância do registro bibliográfico. Os catalogadores sabem que a
catalogação original de um título dá muito trabalho, portanto, custa caro, pois requer
profissionais qualificados e experientes, geralmente de salário mais alto e demanda
tempo. Por isso, uma vez catalogado determinado título, os dados devem ter sua
integridade preservada, isto é, os registros bibliográficos devem ser considerados um
bem valioso e permanente da Biblioteca. Podemos considerar que, basicamente, a
automação de uma biblioteca envolve três elementos: Registros bibliográficos em
meio magnético (base bibliográfica); Software para a manipulação adequada dos
registros bibliográficos; e equipamentos (computadores) para armazenar e processar
os dados. Cada um destes elementos demanda custos que irão variar de acordo com o
tamanho e necessidades da biblioteca. Tanto o software como os computadores
tornam-se obsoletos em um espaço de tempo cada vez mais curto, devido à constante
evolução tecnológica, e requer investimentos para sua eventual substituição. A base
bibliográfica, porém, não deve estar sujeita a um re-trabalho ao longo do tempo e isto
se consegue através da adoção de um formato padrão, como o MARC 21, pois o
mesmo garante a completa portabilidade dos dados bibliográficos, no caso de uma
troca de sistema. Esta questão pode ser melhor compreendida na experiência relatada
por Paranhos, quando afirma:
22
“... a UFPR, por participar da Rede Bibliodata..., ao adquirir seu sistema aplicativo
para gerenciamento das bibliotecas em 2001, já dispunha de 55.000 registros
referentes a livros em formato padrão MARC, que puderam ser imediatamente
importados no sistema...
Assim, a construção da base bibliográfica é o investimento de caráter permanente no
processo de informatização de bibliotecas. Sistemas aplicativos, cada vez mais
potentes, representam alternativas para eventuais mudanças em seu uso;
equipamento tem caráter evolutivo rápido, demandando reserva de recursos para
substituição e/ou atualização tecnológica. Já a base bibliográfica, dependendo de
como é construída, pode implicar em re-trabalho, conforme se tenha respeito ou não
a padrões na prática biblioteconômica e no software aplicativo selecionado: se a
base é construída em respeito a padrões, é um ativo permanente que não vai exigir
re-trabalho na hipótese de migração entre sistemas que também o adotem.”
b) Aquisição de registros já catalogados. A expressão: “catalogação cooperativa”
ou “catalogação por cópia”, do termo em inglês: “copy cataloging” é bastante
comum. Refere-se à incorporação na base local de registros a partir de outras bases,
catalogados por outras instituições. Desta maneira consegue-se ter vantagens em
termos de tempo (a catalogação de um título será muito mais rápido) e
conseqüentemente de menor custo. Isto fica evidente, quando há adesão a um padrão
como o MARC 21, pois a maioria dos títulos existentes já foi catalogada em MARC
e se encontram em alguma base de dados. Embora nem todas as bases permitam a
cópia gratuita de registros, existem muitas em que isto é possível e outros a um custo
relativamente baixo, de forma que sempre é melhor copiar do que fazer uma
catalogação original. A catalogação cooperativa tem como ideal que um livro seja
catalogado uma única vez na sua origem e todas as bibliotecas que vierem a adquirilo, copiem seu registro bibliográfico de alguma fonte disponível [12].
c) Escolha do software. É notório que os softwares mais importantes de automação
de bibliotecas, tanto do mercado nacional como internacional, implementam o
formato MARC. Daí a adesão a este padrão para a construção da base bibliográfica,
facilitará no momento da escolha de um sistema de automação. As opções de
software são muitas, mas é importante salientar que a avaliação mais favorável deve
ser para aquele que permite a importação e exportação de registros no formato
MARC. Com isto, a migração dos dados da base bibliográfica será tranqüila, sem
descaracterizar os registros e sem perda de informações.
23
d) Benefícios para os usuários. O objetivo maior da informatização de uma
biblioteca deve ser a satisfação dos seus usuários. Um dos principais fatores que
levam à satisfação dos usuários é, sem dúvida, relacionado à recuperação da
informação. O sistema de recuperação precisa dar respostas satisfatórias às perguntas
do usuário, isto é, recuperar o que se deseja, nem mais, nem menos, o que em termo
técnicos é conhecido por baixa revocação e alta precisão. O formato MARC poderá
contribuir para que isto aconteça, através de sistemas de recuperação que se valem da
identificação de cada elemento da informação bibliográfica, como os dados
codificados, campos e subcampos que atribuem significado ao conteúdo,
maximizando a precisão e minimizando a revocação. Branton e Chen-Gaffey [13]
confirmam isto em um tutorial publicado na Internet, dizendo:
“Standardized bibliographic data input, utilizing MARC formats, insures the
integrity of the online public catalog in storage and retrieval of information. When
we talk about MARC, we hope to convey its importance to those who create and
maintain MARC data in the online public catalog. Without good, accurate MARC
records, patrons cannot find the great resources in the library. An OPAC, to some
extent, hides the intricacies of MARC from the patron, but without MARC, the
patron would not find the resources. MARC format cataloging has proven, for over
thirty years, to be the most reliable foundation in building databases for the OPAC.”
2.2.3 O MARC no Brasil
A introdução do MARC no Brasil se deu através de projetos de formatos MARC
compatíveis, como o formato CALCO da Fundação Getúlio Vargas, Formato IBICT e o Mini
CALCO da Universidade Federal de Minas Gerais. O Projeto CALCO (termo que é um
acrônimo do termo MARC, pois quer dizer CAtalogação Legível por COmputador) deu
origem à Rede Bibliodata que, devido ao formato CALCO, inicialmente chamava-se “Rede
Bibliodata/CALCO”, dando início às suas atividades em 1980. Em 1996 a base de dados do
sistema Bibliodata/CALCO foi migrada para o formato USMARC e todas as bibliotecas
cooperantes passaram a usar este formato (USMARC) como padrão para catalogação
bibliográfica. A partir de 2000 passou a adotar o formato MARC 21. O Catálogo Coletivo
Bibliodata representa hoje a maior base bibliográfica em formato MARC 21 do Brasil e, sem
dúvida, da América Latina, tornando-se uma Utilidade Bibliográfica brasileira que serve
24
como provedora de registros bibliográficos em MARC 21 para muitas bibliotecas brasileiras,
principalmente bibliotecas universitárias [7].
Apesar de já terem passado mais de vinte anos desde a introdução do MARC, ou
MARC compatível, no Brasil, a adesão a este padrão ainda encontra resistências por parte de
muitas bibliotecas e bibliotecários, bem como fornecedores de software de automação de
bibliotecas. Isto acontece, talvez, por acharem o MARC muito complexo e difícil de
implementar, ou por desconhecerem os benefícios diretos e indiretos que a adesão a um
padrão como este poderá trazer. Alguém poderá argumentar que tudo o que o MARC pode
proporcionar em termos de resultados para atender as necessidades de uma biblioteca, é
perfeitamente possível obter através de um sistema desenvolvido localmente, sob medida e de
forma simplificada. Quando isto acontece, geralmente, mais cedo ou mais tarde, o trabalho
precisa ser refeito, pois vale a máxima que afirma: “A simplificação na entrada impõe
restrições na saída” [7].
2.2.4 Complementos
O padrão MARC tem um papel preponderante no desenvolvimento do Sistema de
Biblioteca Virtual de que trata este trabalho, haja vista que é um padrão robusto utilizado pela
grande maioria das instituições bibliotecárias bem estruturadas, que são o foco da aplicação.
Ele será utilizado para importação e exportação de dados do acervo, de forma automática,
bem como para a padronização de todo e qualquer obra ou documento que venha a fazer parte
de tal acervo.
Informações adicionais sobre o MARC, como conteúdo dos campos utilizados em seu
registro e até um exemplo de elaboração de tal registro a partir de dados da obra, estão
disponíveis nos Anexos I e II deste trabalho.
25
CAPÍTULO 3
DESENVOLVIMENTO DE SOFTWARE ORIENTADO A OBJETOS
3.1 ORIENTAÇÃO A OBJETOS
A orientação a objetos, também conhecida como Desenvolvimento Orientado a
Objetos, é um paradigma de análise, projeto e programação de sistemas de software baseado
na composição e interação entre diversas unidades de software chamadas de objetos [14].
A análise e projeto orientados a objetos têm como meta identificar o melhor conjunto
de objetos para descrever um sistema de software. O funcionamento deste sistema se dá
através do relacionamento e troca de mensagens entre estes objetos.
Hoje existem duas vertentes no projeto de sistemas orientados a objetos. O projeto
formal, normalmente utilizando técnicas como a notação UML e processos de
desenvolvimento como o RUP; e a programação extrema (XP - Extreme Programming), que
utiliza pouca documentação, programação em pares e testes unitários [14].
Na programação orientada a objetos, implementa-se um conjunto de classes que
definem os objetos presentes no sistema de software. Cada classe determina o comportamento
(definidos nos métodos) e estados possíveis (atributos) de seus objetos, assim como o
relacionamento com outros objetos.
3.2 UML
A Unified Modeling Language (UML) é uma linguagem de modelagem não
proprietária de terceira geração. A UML não é um método de desenvolvimento, o que
significa que ela não diz a seqüência das ações a serem desenvolvidas ou como desenhar o
sistema, mas ele lhe auxilia a visualizar seu desenho e a comunicação entre objetos.
Basicamente, a UML permite que desenvolvedores visualizem os produtos e serviços
de seu trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML também
especifica significados, isto é, semântica. É uma notação independente de processos, embora
26
o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a
UML.
A UML é uma linguagem para especificação, documentação, visualização e
desenvolvimento de sistemas orientados a objetos. Sintetiza os principais métodos existentes,
sendo utilizada para modelagem de sistemas orientados a objetos. Por meio de seus diagramas
é possível representar sistemas de softwares sob diversas perspectivas de visualização.
Facilita a comunicação de todas as pessoas envolvidas no processo de desenvolvimento de um
sistema - gerentes, coordenadores, analistas, desenvolvedores - por apresentar um vocabulário
de fácil entendimento.
3.3 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Muitas organizações têm, aos poucos, entendido a importância de um processo de
desenvolvimento de software bem documentado e bem definido para o sucesso de seus
projetos de software.
O desenvolvimento do CMM (Capability Maturity Model) pelo Instituto de
Engenharia de Software (Software Engineering Institute - SEI) se tornou um norte, um padrão
que muitas organizações começaram a seguir quando não possuíam uma base definida.
Através dos anos, os desenvolvedores dessas organizações têm obtido conhecimento em tal
processo, e a partir disso criado e disseminado internamente seus próprios processos de
desenvolvimento de software. A documentação usada internamente seria seguida no
desenvolvimento de vários desses softwares. Infelizmente, na prática, esses processos internos
quase nunca são seguidos, pois se chega a um ponto em que passam a ser raramente
atualizados, e se tornam obsoletos. Outras organizações de desenvolvimento de software não
têm processo algum, e precisam de um ponto de partida, um processo inicial para colocá-las
no caminho do rápido e eficiente desenvolvimento de produtos de software cada vez melhores
[8].
Um processo é um conjunto de passos parcialmente ordenados com a intenção de
atingir uma meta. Em engenharia de software, a meta é criar um software ou aperfeiçoar um
existente; em engenharia de processos, a meta é desenvolver ou aperfeiçoar um processo.
Em termos de modelagem de negócios, o processo de desenvolvimento de software é
um processo de negócios. Ele descreve uma família de processos de desenvolvimento de
software relacionados que compartilha uma estrutura comum, uma arquitetura de processos
27
comum. Ele proporciona uma abordagem disciplinada para a atribuição de tarefas, como
ilustra a Figura 3, e de responsabilidades dentro de uma organização de desenvolvimento.
Figura 3: Desenvolvimento Iterativo/Incremental [8]
Quando um sistema de software é desenvolvido começando do zero, o
desenvolvimento é o processo de criação de um sistema a partir dos requisitos. Porém, depois
que os sistemas tiverem tomado forma, os desenvolvimentos subseqüentes serão o processo
de adaptação do sistema aos requisitos novos ou modificados. Isso se aplica durante todo o
ciclo de vida do sistema.
3.4 RUP - RATIONAL UNIFIED PROCESS
O Rational Unified Process® (também chamado de processo RUP®) é um processo
de desenvolvimento de software. Sua meta é garantir a produção de software de alta qualidade
que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento
previsíveis.
Nas subseções a seguir, apresentam-se alguns conceitos básicos, estrutura e fases do
RUP [8].
28
3.4.1 Conceitos Básicos
3.4.1.1 Papel
O conceito mais central no processo de desenvolvimento de software é o conceito de
Papel. O Papel define o comportamento e as responsabilidades de um indivíduo ou de um
conjunto de indivíduos que trabalham juntos como uma equipe, no contexto de uma
organização de engenharia de software.
3.4.1.2 Atividade
Os papéis possuem atividades que definem o trabalho que executam. Uma atividade
é algo que um papel faz e produz um resultado significativo no contexto do projeto.
A atividade tem uma finalidade clara, normalmente expressa em termos da criação
ou atualização de alguns artefatos como um modelo, uma classe, um plano.
3.4.1.3 Passos
As atividades são divididas em passos. Os passos podem pertencer a três categorias
principais:
- Passos de reflexão: nos quais o indivíduo que executa o papel compreende a
natureza da tarefa, reúne e examina os artefatos de entrada e formula a saída.
- Passos de execução: nos quais o indivíduo que executa o papel cria ou atualiza
alguns artefatos.
- Passos de revisão: nos quais o indivíduo que executa o papel analisa os resultados
em relação a alguns critérios.
3.4.1.4 Orientações de Trabalho
As atividades podem possuir Orientações de Trabalho associadas, que apresentam
conselhos práticos e técnicas úteis para o papel que executa a atividade.
29
3.4.1.5 Artefato
As atividades possuem artefatos de entrada e saída. Um artefato é um produto de
trabalho do processo: os papéis usam os artefatos para executar atividades e produzem
artefatos ao executarem as atividades. Os artefatos são de responsabilidade de um único papel
e promovem a idéia de que todas as informações no processo devem ser de responsabilidade
de uma pessoa específica, apesar de muitas outras podem utilizá-lo e, talvez, até atualizá-lo se
tiverem permissão.
Observe que "artefato" é o termo utilizado no RUP. Outros processos utilizam termos
como produto de trabalho, unidade de trabalho e outros, para designar o mesmo elemento.
3.4.1.6 Template
Templates são "modelos" ou protótipos de artefatos. Associados à descrição do
artefato estão um ou mais templates que podem ser utilizados para criar os artefatos
correspondentes. Os templates estão vinculados à ferramenta que será usada.
3.4.1.7 Relatório
Os modelos e os elementos de modelo podem ter relatórios associados a eles. Com a
ajuda de uma ferramenta, um relatório extrai informações sobre os modelos e os elementos de
modelo.
3.4.1.8 Fluxo de Trabalho
Uma simples enumeração de todos os papéis, atividades e artefatos não constitui um
processo; é necessária uma forma para descrever as seqüências significativas das atividades
que produzem algum resultado importante e para mostrar as interações entre os papéis. O
fluxo de trabalho é uma seqüência das atividades que produzem um resultado de valor
observável.
30
3.4.2 Estrutura do RUP
A Figura 4 mostra a estrutura do RUP. Por exemplo, nas iterações iniciais, dedica-se
mais tempo aos requisitos. Já nas iterações posteriores, gasta-se mais tempo com
implementação.
O processo proposto pelo RUP possui 2 estruturas, ou se preferir, 2 dimensões:
- O eixo horizontal é a Dimensão de Tempo. Ele mostra o progresso de um projeto
através do tempo, representando o aspecto dinâmico do processo quando ele é aprovado e
descrevendo fases, marcos e iterações.
- O eixo vertical é a Dimensão de Conteúdo. Ele representa o aspecto estático do
processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de
trabalho, artefatos e papéis do processo.
Figura 4: Exemplo de Fases e Dimensões do RUP [8]
31
3.4.3 Elementos Essenciais do Processo
3.4.3.1 Visão - Desenvolver uma visão
No RUP, o artefato Visão captura requisitos de nível alto e restrições de design, para
fornecer ao leitor uma compreensão do sistema a ser desenvolvido. Ele fornece informações
para o processo de aprovação do projeto e está, portanto, diretamente relacionado ao Caso de
Negócio. Ele comunica os principais questionamentos relacionados ao projeto e funciona
como um regulador com base no qual todas as decisões futuras deverão ser validadas.
3.4.3.2 Plano - Gerenciar para o Plano
O Plano de Desenvolvimento de Software (PDS) coleta todas as informações
necessárias para gerenciar o projeto.
O PDS é usado para planejar a programação do projeto e as necessidades de recursos
e para acompanhar o andamento da programação. Ele aborda áreas como: Organização do
Projeto, Programação (Plano do Projeto, Plano de Iteração, Recursos, Ferramentas), Plano de
Gerenciamento de Requisitos, Plano de Gerenciamento de Configuração, Plano de Resolução
de Problemas, Plano de Garantia de Qualidade , Plano de Teste, Casos de Teste, Plano de
Avaliação e Plano de Aceitação do Produto.
3.4.3.3 Riscos - Diminuir os Riscos
É essencial identificar e combater os itens de risco mais alto no início do projeto e
acompanhá-los, juntamente com outras questões relacionadas.
Juntamente com cada risco, deve haver um plano para diminuí-lo. Isso serve como
um ponto focal para o planejamento das atividades do projeto e é a base em torno da qual as
iterações são organizadas.
3.4.3.4 Caso de Negócio - Examinar o Caso de Negócio
O Caso de Negócio fornece as informações necessárias, do ponto de vista de um
negócio, para determinar se vale ou não a pena investir no projeto.
32
A principal finalidade do Caso de Negócio é desenvolver um plano econômico para
realizar o projeto Visão. Uma vez desenvolvido, o Caso de Negócio é usado para fazer uma
avaliação precisa do Retorno do Investimento (ROI) fornecido pelo projeto. Ele fornece a
justificativa para o projeto e estabelece suas restrições econômicas. E também fornece
informações para os tomadores de decisões econômicas sobre o valor do projeto e é usado
para determinar se o projeto deve continuar.
3.4.3.5 Arquitetura - Projetar uma Arquitetura de Componentes
No RUP, a arquitetura de um sistema de software (em um determinado ponto) é a
organização ou a estrutura dos componentes significativos do sistema que interagem, através
de interfaces, com componentes compostos de interfaces e de componentes sucessivamente
menores.
Cada visão arquitetural aborda algum conjunto específico de interesses, específico
para os envolvidos no processo de desenvolvimento: usuários, designers, gerentes,
engenheiros de sistema, analistas de manutenção e outros. Isso serve como um meio de
comunicação entre o arquiteto de software e outros membros da equipe do projeto, com
relação a decisões significativas do ponto de vista da arquitetura, tomadas a respeito do
projeto.
3.4.3.6 Protótipo - Criar e Testar o Produto Gradativamente
O RUP é uma abordagem iterativa de criação, de teste e de avaliação de versões
executáveis do produto, a fim de afastar os problemas e resolver os riscos e as questões o mais
cedo possível.
3.4.3.7 Avaliação - Avaliar os Resultados Regularmente
A comunicação aberta contínua com dados objetivos obtidos diretamente de
atividades em andamento e as configurações do produto em desenvolvimento são importantes
em qualquer projeto. As Avaliações de status regulares oferecem um mecanismo para
abordar, comunicar e resolver questões de gerenciamento, questões técnicas e riscos do
projeto.
33
3.4.3.8 Mudanças - Gerenciar e Controlar Mudanças
Assim que o primeiro protótipo for colocado diante dos usuários (e geralmente
mesmo antes disso), as mudanças serão solicitadas. Para controlar essas mudanças e
efetivamente gerenciar o escopo do projeto e as expectativas dos envolvidos, é importante que
todas as mudanças em qualquer artefato de desenvolvimento sejam propostas por meio de
Solicitações de Mudança e gerenciadas com um processo consistente.
3.4.3.9 Suporte ao Usuário - Implantar um Produto Utilizável
A finalidade de um processo é produzir um produto utilizável. Todos os aspectos do
processo devem ser adaptados considerando essa meta. Normalmente, o produto é mais do
que apenas o software. No mínimo, deve haver um Manual do Usuário, talvez implementado
através da ajuda on-line.
3.4.3.10 Processo - Adotar um Processo que se Ajuste ao Projeto
É essencial que seja escolhido um processo que se ajuste ao tipo de produto que está
sendo desenvolvido. Mesmo após a escolha de um processo, ele não deve ser seguido
cegamente. O bom senso e a experiência precisam ser aplicados para configurar o processo e
as ferramentas, de forma a atender às necessidades da organização e do projeto.
3.4.4 Fases
Após os conceitos apresentados até o momento, definindo os passos a serem
seguidos durante o ciclo de vida de um projeto, as fases indicam a ênfase que é dada no
projeto em um dado instante.
Para capturar a dimensão do tempo de um projeto, o RUP divide o projeto em quatro
fases diferentes:
1. Concepção: ênfase no escopo do sistema;
2. Elaboração: ênfase na arquitetura;
3. Construção: ênfase no desenvolvimento;
4. Transição: ênfase na implantação.
34
O RUP também baseia-se nos 4 P's: Pessoas, Projeto, Produto e Processo.
As fases são compostas de iterações. As iterações são janelas de tempo; as iterações
possuem prazo definido enquanto as fases são objetivas.
Todas as fases geram artefatos. Estes serão utilizados nas próximas fases e
documentam o projeto. Além de permitir melhor acompanhamento.
3.4.5 Complementos
A partir do apresentado, entende-se que com a utilização de uma metodologia de
desenvolvimento de software como o RUP, é possível obter:
- Qualidade de software;
- Produtividade no desenvolvimento, operação e manutenção de software;
- Controle sobre desenvolvimento dentro de custos, prazos e níveis de qualidade
desejados;
- Estimativa de prazos e custos com maior precisão.
Apesar dos benefícios, deve-se ter a consciência que os benefícios não virão de
maneira imediata. É necessário adquirir treinamento adequado, adaptação da metodologia no
contexto ao qual ela será utilizada, apoio especializado para as equipes de desenvolvimento e
tempo para a absorção da metodologia.
Dado a isso, o RUP foi escolhido para nortear o desenvolvimento do Projeto do
Sistema de Biblioteca Virtual proposto por este trabalho.
3.5 WEB 2.0
O termo Web 2.0 refere-se à segunda geração de serviços e aplicativos da Web e aos
recursos, tecnologias e conceitos que permitem um maior grau de interatividade e colaboração
na utilização da Internet. As aplicações desta geração disponibilizam interfaces tão dinâmicas
quanto as existentes nas tradicionais aplicações desenvolvidas para desktops, em
contraposição com as páginas praticamente estáticas da primeira geração de aplicações para
Web, a "Web 1.0". Muitos desenvolvedores discordam do termo e de sua conceitualização,
alegando que o mesmo é vago e refere-se a tecnologias e/ou conceitos há muito existentes,
não passando de uma jogada de marketing para simplesmente nomear e classificar o que for
novo e (principalmente) popular na Web.
35
A Web 2.0 deve possuir as seguintes premissas básicas:
A internet como plataforma para processar, produzir ou consumir informação,
onde um computador conectado à internet é ferramenta básica e principal de trabalho.
Melhor experiência do usuário: a Web 2.0 propõe uma experiência de uso
semelhante à de aplicativos para desktop, frequentemente fazendo uso de uma combinação de
tecnologias surgidas no final da década de 1990, que incluem Web services, APIs (1998),
AJAX (programação) (1998), Web syndication (1997), entre outras. Estas tecnologias
aumentaram a velocidade e a facilidade de uso de aplicativos Web, sendo responsáveis por um
aumento significativo no conteúdo (colaborativo ou meramente expositivo) existente na
Internet. Estas também permitiram que usuários comuns, que até então não possuíam
conhecimentos necessários para publicar conteúdo na Internet - pela ausência de ferramentas
de uso simplificado - publicassem e consumissem informação de forma rápida e constante.
Notadamente têm-se os blogs e wikis como expoentes desta massificação. Permitiu ainda o
desenvolvimento de interfaces ricas, completas e funcionais, sendo que alguns aplicativos
Web, ainda em versão beta, são considerados por muitos como "desktops on-line",
proporcionando ao usuário um ambiente de trabalho inteiramente baseado na WWW,
acessível de qualquer computador com conexão à Internet.
Valorização do conteúdo colaborativo e da inteligência coletiva: o conteúdo deve
ser produzido e consumido por qualquer um, de forma simples e direta. A Wikipedia e os
blogs são exemplos vivos desta premissa.
Fim dos ciclos de lançamento e atualização de softwares tradicionais. Em
oposição ao que acontece com softwares tradicionais, em caixas, com instaladores e
dependentes de um sistema operacional, aplicativos Web podem ser atualizados de forma
constante, linear e independente da ação do usuário final. No caso de atualizações de
segurança e desempenho, por exemplo, o usuário da aplicação seria imediatamente
beneficiado pela atualização da aplicação, não necessitando baixar um patch ou atualização.
Quanto mais simples a programação, melhor. Em tempos de mudanças rápidas, ter
uma estrutura de software enxuta, que permita ser expandida em módulos e também
aperfeiçoada ao mesmo tempo em que é usada é um diferencial positivo. Metodologias e
conceitos como o Getting Real e Agile tem-se popularizado entre as empresas que
desenvolvem aplicativos ditos "Web 2.0".
36
3.6 DESIGN PATTERNS
Design Patterns, ou Padrões de Projeto de Software, descrevem soluções para
problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um
padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta
solução e suas conseqüências.
Os padrões de projeto visam facilitar a reutilização de soluções de desenho - isto é,
soluções na fase de projeto do software, sem considerar reutilização de código. Também
acarretam um vocabulário comum de desenho, facilitando comunicação, documentação e
aprendizado dos sistemas de software.
Os Padrões de Projeto foram organizados em famílias: padrões de criação, padrões
estruturais e padrões comportamentais [17].
Os padrões de criação definem a configuração e inicialização de objetos e classes.
São eles:
Abstract Factory: Provê uma interface para a criação de famílias de objetos
correlatos ou dependentes sem a necessidade de especificar a classe concreta destes objetos.
Builder: Isola a construção de um objeto complexo de sua representação, de
forma que o mesmo processo de construção possa ser capaz de criar diferentes representações.
Factory Method: Define uma interface para a criação de objetos, mas deixa as
subclasses decidirem qual classe irão instanciar. O Factory Method permite que uma classe
transfira para as subclasses a responsabilidade pela criação de novas instâncias.
Prototype: Especifica o tipo de objeto a criar através de uma instância protótipo e
cria novos objetos através da cópia deste protótipo.
Singleton: O objetivo deste padrão é garantir que uma classe possua apenas uma
única instância e para tal, fornece um ponto global de acesso para a mesma.
Os padrões estruturais lidam com as interfaces e a implementação das classes e dos
objetos:
Adapter: Converte a interface de uma classe em outra interface que os clientes
esperam. O padrão Adapter permite que classes que não poderiam trabalhar juntas devido a
interfaces incompatíveis trabalhem juntas.
Bridge: Desacopla uma abstração de sua própria implementação de forma que as
duas possam mudar de forma independente.
37
Composite: Compõe objetos em estrutura de árvore para representar hierarquias
do tipo todo-parte. Este padrão permite que as classes cliente tratem os objetos individuais e
as composições de maneira uniforme.
Decorator: Atribui, dinamicamente, responsabilidades a outros objetos.
Facade: Uma única classe representando todo um subsistema.
Flyweight: Uma instância refinada, utilizada para compartilhamento eficiente.
Proxy: Um objeto que representa outro objeto.
Os padrões comportamentais lidam com as interações dinâmicas entre grupos de
classes e objetos:
Chain of Responsibility: Uma forma de passar requisições por uma cadeia de
objetos.
Command: Encapsular uma solicitação de comando na forma de um objeto.
Interpreter: Uma forma de incluir elementos de linguagem num programa.
Iterator: Acessa seqüencialmente os elementos de uma coleção.
Mediator: Define uma comunicação simplificada entre classes.
Memento: Captura e restaura o estado interno de um objeto.
Observer: Uma forma de notificar mudanças efetuadas em certa quantidade de
classes.
State: Altera o comportamento de um objeto quando seu estado muda.
Strategy: Encapsula um algoritmo dentro de uma classe.
Template Method: Atribui cada passo de um algoritmo para uma subclasse.
Visitor: Define uma nova operação para uma classe sem mudá-la.
3.6.1 Padrões de Projeto na programação Web
Com a utilização cada vez maior da linguagem Java e principalmente de toda a
plataforma JEE (Java Enterprise Edition) os Design Patterns têm se tornado mais populares,
uma vez que para construir uma aplicação de grande porte utilizando J2EE é imprescindível a
utilização de Patterns adequados, que têm por objetivo aumentar a modularidade e a
escalabilidade das aplicações.
O Design Pattern MVC (Model-View-Controller) permite que você separe o modelo
de dados das várias formas que o dado pode ser acessado e manipulado. Um sistema MVC é
dividido em um modelo de dados, um conjunto de visões e um conjunto de controladores. As
38
visões fornecem a interface do usuário. Por exemplo, em uma aplicação para Web na
plataforma Java, uma visão consiste em códigos JSP. O controlador é geralmente
implementado como um ou mais servlets Java. O modelo consiste de um EJB (Enterprise
JavaBean) que fornece acesso direto ao banco de dados relacional.
MVC é útil principalmente para aplicações grandes e distribuídas onde dados
idênticos são visualizados e manipulados de formas variadas. Como o MVC facilita a divisão
de trabalho por conjuntos de habilidades, este Pattern é bastante adequado para empresas de
desenvolvimento que suportam desenvolvimento modular e concorrente com muitos
desenvolvedores. Promovendo a portabilidade de interfaces e do back-end, o padrão MVC
também torna fácil testar e manter suas aplicações. A chave para o MVC é a separação de
responsabilidades. As visões podem usar o modelo de dados para exibir resultados, mas elas
não são responsáveis por atualizar o banco de dados. Os controladores são responsáveis por
selecionar uma visão apropriada e por fazer alterações no modelo de dados. O modelo, por
sua vez, é responsável por representar os dados da aplicação. Algumas vezes o modelo de
dados também incluirá a lógica de negócio (as regras para manipular os dados de negócio), e
algumas vezes a lógica de negócio existirá na camada do controlador.
Na verdade existem quatro componentes em uma aplicação MVC, não três, já que o
cliente é uma parte integrante de toda a operação. O cliente envia uma requisição para o
servlet, que interage com o modelo de dados para efetuar a ação requisitada pelo cliente. O
controlador então passa informações para uma visão, que as formata de acordo com as
necessidades do cliente. Dependendo dos tipos de clientes suportados, uma atividade pode ter
muitas visões. Desacoplar as visões do processo de requisição torna mais fácil criar novas
visões para novos formatos. Uma aplicação poderia apresentar uma interface HTML e depois
adicionar visões WML (para dispositivos wireless) e visões XML (para Web services)
futuramente.
O Pattern DAO (Data Access Object, Acesso aos Dados do Objeto) é uma solução
simples em que os desenvolvedores implementam um objeto que é unicamente responsável
por receber informação de um armazenamento persistente, onde quer que ele esteja. Isto
abstrai a visão do dado usada por uma aplicação do layout da tabela, esquema XML ou
arquivo em disco.
Uma equipe poderia produzir três objetos DAO por um projeto particular: um para
ler o banco de dados, um para ler dos arquivos XML recebidos da Web e um para fornecer
dados de teste para serem usados por desenvolvedores trabalhando em outros aspectos do
39
sistema. Se todos os três objetos são descendentes de uma única classe abstrata Java que
define os vários métodos de acesso, os objetos podem ser substituídos na aplicação final
dependendo das necessidades atuais. Os objetos podem também ser usados em outros projetos
baseados no mesmo modelo.
Além de fornecer flexibilidade extra, um DAO pode ser usado para aumentar a
velocidade da camada de apresentação (ou visão) em uma aplicação maior pulando uma
camada EJB. Ler diretamente do banco de dados é sempre mais rápido do que ir através da
camada EJB, que tem que ler o banco de qualquer forma. Fazer isto diretamente com a API
JDBC (Java Database Conectivity) é uma prática perigosa, já que ela liga o modelo de dados
à camada de apresentação de tal forma que qualquer alteração na implementação do modelo
de dados requer reescrever grandes partes da camada de apresentação, o que geralmente não é
muito prático. Ao se utilizar um DAO obtém-se o máximo de velocidade com muito menos
esforço de manutenção [19].
3.6.2 Vantagens e Desvantagens do uso de Design Patterns
As vantagens da utilização de Design Patterns são visíveis: primeiro, a utilização de
Design Patterns força uma forma otimizada e clara de comunicação entre os desenvolvedores,
fortalece a documentação e apresenta maiores possibilidades de exploração para alternativas
de soluções para o projeto; segundo, melhora na qualidade geral do sistema, pois reduz a
complexidade do código oferecendo uma abstração das classes e instâncias; e por último,
reduz o tempo de aprendizado de novas bibliotecas ou funções.
Porém, existem desvantagens óbvias de sua utilização. A adoção tardia de Design
Patterns pode tornar sua implementação mais custosa em prazos e custos. Portanto, quanto
mais cedo a definição dos Patterns ocorrer, melhor. Os Patterns podem ser difíceis de
implementar (em um primeiro momento, principalmente durante sua curva de aprendizado) e
geralmente implicam na adoção de outros Patterns, mas, os resultados são sempre bem
expressivos com relação à qualidade e versatilidade [17].
3.7 FRAMEWORKS
Um framework, em desenvolvimento de software, é uma estrutura de suporte
definida com a qual outro projeto de software pode ser organizado e desenvolvido. Um
40
framework pode incluir programas de apoio, bibliotecas de código, linguagens de script e
outros softwares que podem ajudar a desenvolver e acoplar diferentes componentes de um
projeto de software [4].
Frameworks são projetados com o intuito de facilitar o desenvolvimento de software,
permitindo que os projetistas e os programadores gastem mais tempo com o levantamento de
requisitos do software do que lidando com os mais tediosos detalhes de baixo nível ao prover
um sistema de apoio ao desenvolvimento. Ele possibilita pular esse passo. Por exemplo, uma
equipe usando Apache Struts para desenvolver um Web site bancário pode se focar em como
uma retirada de conta corrente acontece ao invés de pensar em como controlar a navegação
entre páginas de uma maneira que não ocorram bugs. Entretanto, há queixas comuns de que
ao se usar frameworks eles adicionam muito “lixo” ao código, e que a superioridade de
frameworks em aproveitamento de tempo não pode ser efetivamente considerada, pois na
verdade perde-se o tempo que seria gasto em projeto e desenvolvimento de rotinas para o
software apenas aprendendo a se utilizar o framework.
Fora do escopo de aplicações de computador, um framework pode ser considerado
como os processos e tecnologias utilizadas para resolver um assunto complexo. Ele é o
esqueleto sob o qual vários objetos são integrados para fornecer uma dada solução.
Dessa forma, serão apresentados, a seguir, alguns frameworks baseados na
linguagem de programação Java, escolhida para o desenvolvimento da aplicação proposta
nesse trabalho.
3.7.1 Frameworks Específicos
A utilização de um framework baseado no padrão de projeto MVC pode simplificar
muito a construção de aplicações Web em Java. Para que os desenvolvedores focalizem mais
esforços na representação do domínio da aplicação do que nas tecnologias empregadas, os
frameworks implementam diversos padrões de projeto e boas práticas, abstraindo do
desenvolvedor parte da complexidade envolvida no processo de desenvolvimento de
aplicações.
Por ser um padrão de arquitetura muito extensível, o MVC inspirou a criação de
vários frameworks, dos quais alguns dos mais conhecidos são: Apache Struts; Apache
Cocoon; Spring MVC; WebWork; os brasileiros JBanana, Mentawai e Vraptor; e o
JavaServer Faces, definido pelo Java Community Process (JCP).
41
Com tantas opções disponíveis, a escolha de um framework MVC para utilização em
projetos de desenvolvimento não é uma tarefa trivial. É preciso analisar os principais produtos
e avaliar os pontos fortes e os pontos fracos de cada um. A escolha depende das características
e particularidades de cada projeto.
3.7.1.1 Apache Struts Web Application Framework
O framework Struts tem o objetivo de constituir uma implementação MVC padrão
para a comunidade Java.
Baseadas na arquitetura MVC, aplicações Struts têm três categorias de componentes:
(1) componentes de controle, incluindo um servlet e um processador de requisições; (2)
JavaServer Pages (JSP) e Tag Libraries da camada de visão e (3) componentes de negócios e
de acesso a dados da camada de modelo. A figura 5 ilustra a arquitetura de uma aplicação
MVC baseada no Struts.
Figura 5: Arquitetura do Struts [18]
No Design Pattern MVC, o fluxo da aplicação é mediado por um controlador central.
O controlador delega requisições para um dos tratadores apropriados, que estão localizados no
modelo, que representa a lógica de negócio e o estado da aplicação. A requisição então é
42
respondida, através do controlador, e apresentada na visão, da maneira adequada. No Struts,
essas respostas são orientadas através de mapeamentos, que são carregados através de um
arquivo de configuração (struts-config.xml). Isso faz com que não haja dependência entre a
visão e o modelo, que auxilia na criação e na manutenção da aplicação.
3.7.1.2 Mentawai Web Framework
O Mentawai foi o primeiro framework Web MVC em Java a adotar, implementar,
documentar e incentivar todo e qualquer tipo de configuração única e exclusivamente através
de configuração programática, abolindo por completo o uso de XML e Annotations para as
configurações.
Outro pilar em que o Mentawai se apoiou desde o início foi o comprometimento em
abstrair e simplificar as principais tarefas recorrentes de todo projeto Web. Ao invés de
direcionar o usuário para qualquer outro framework, o Mentawai oferece soluções ou
abstrações para as funcionalidades básicas de toda aplicação Web: pool de conexões com o
banco de dados, autenticação, autorização, envio de e-mail, upload de arquivo, paginação,
tags e outros [20].
O Mentawai usa o paradigma das Actions (org.mentawai.core.Action). Uma action
possui um input por onde ela recebe os dados de uma requisição Web e um output por onde os
resultados da execução de uma action podem ser acessados. Uma action depois de executada
gera um resultado e para cada resultado existe uma conseqüência.
A maioria das funcionalidades do framework é implementada através de Filtros
(org.mentawai.core.Filter). Um filtro intercepta uma action e pode modificar seu input e
output, antes e depois da execução da action. O uso de filtros torna as actions simples e
desacopladas, resultando em códigos mais simples de manter e testar.
O Mentawai é utilizado por diversas empresas e pessoas no Brasil e no exterior, e
possui uma comunidade ativa, sempre fiel aos princípios da produtividade, simplicidade,
abstração e configuração programática.
3.7.2 Frameworks de Visão
Serão abordados três frameworks de visão que facilitam o desenvolvimento de
aplicações na camada de apresentação, são eles: DWR, Spry e YUI.
43
O DWR (Direct Web Remoting) é um framework AJAX escrito em Java bastante
simples de utilizar. Sua função é mapear classes escritas em Java (no servidor) e criar seus
equivalentes em Javascript. O DWR cuida também de todas as chamadas remotas realizadas
pelo browser. Para acionar estas chamadas é necessário escrever um pouco de Javascript, mas
nada que assuste.
O Spry é o framework da Adobe para desenvolvimento usando AJAX. O Spry foi
projetado com a intenção de facilitar o desenvolvimento, ele inclui bibliotecas de código,
linguagens de script e outros recursos para ajudar a desenvolver diferentes componentes de
um projeto.
O Spry se divide em três principais especificidades: Spry data, Spry widgets e Spry
effects. Através do Spry data, os dados poderão ser integrados a uma página através de
arquivos XML, com opção de filtros e ordenação. Utilizando o Spry widgets, os elementos de
interface serão adicionados à página, como listas, tabelas, abas, validação de formulário e
repetição de regiões determinadas em uma página. Já com o Spry effects, os efeitos visuais
poderão ser adicionados nos elementos das páginas, como crescer, encolher, esmaecer e
realçar.
O YUI é o framework AJAX do Yahoo!. O YUI é utilizado para o desenvolvimento
de aplicações Web usando DOM, DHTML e, claro, o AJAX, incluindo diversos recursos para
trabalhar com o CSS.
44
CAPÍTULO 4
O SISTEMA DE BIBLIOTECA VIRTUAL
O Sistema de Biblioteca Virtual, proposto por este trabalho, possui um diferencial:
que é a utilização do padrão MARC. Esse padrão tende a elevar o nível de qualidade dos
sistemas que manipulam acervos, diminui a incidência de erros de modelagem e facilita a
migração e intercâmbio de dados. Além disso, esse sistema incorpora a aplicação de
tecnologias que visam melhorar o desempenho do software.
A aplicação deverá ser desenvolvida para ambiente Web, haja vista que a
acessibilidade e a portabilidade proporcionadas pela plataforma Web ajudará o Sistema a
fornecer as funcionalidades propostas.
Para o desenvolvimento do projeto, serão analisados três fatores principais: a
linguagem de programação a ser escolhida, o processo de desenvolvimento de software que
dará suporte e padrão ao desenvolvimento da aplicação e quais frameworks, baseados em tal
linguagem de programação, seriam utilizados para seu desenvolvimento.
Ao analisar as necessidades do Sistema, verificou-se que deverá ser utilizado o
paradigma de Orientação a Objetos. Além disso, deverá ter características como portabilidade,
para que independa da plataforma onde a aplicação for instalada, e segurança, para que os
programas executados em nível de rede possuam restrições de execução, garantindo uma
maior confiabilidade no processo. Agregado a isso, será muito útil uma linguagem que possua
bibliotecas variadas acerca de funções comuns nos sistemas, agilizando e dando robustez ao
processo de desenvolvimento da aplicação. A linguagem deverá fornecer também suporte a
desenvolvimento Web.
Baseado nessas premissas foi selecionada a linguagem de programação Java, robusta
e confiável, dando maior apoio ao desenvolvimento do software.
Com as informações obtidas sobre frameworks baseados em Java, juntamente com as
informações sobre as necessidades do Sistema, partiu-se para a escolha de qual ferramenta
será utilizada em seu desenvolvimento.
Geralmente aplicações que atendem a vários usuários precisam se conectar a um ou
mais bancos de dados para obter, atualizar ou incluir algum tipo de informação. Porém a
45
criação de conexões com o banco de dados consome recursos fundamentais para o bom
funcionamento do sistema. A solução adotada para resolver este problema é o Connection
Pool, um padrão que tem como objetivo minimizar a utilização de recursos para preservar a
estabilidade e a escalabilidade das aplicações.
Considerando que o desenvolvimento Web em Java torna-se cada vez mais
complexo, pois se gasta muito tempo para configurar arquivos XML e menos tempo para
fazer a aplicação e que a quantidade excessiva de XML também traz outro problema: o
aumento da curva de aprendizado, então para aprender e utilizar um framework para Web,
baseado em XML, necessita-se estudar outra sintaxe proprietária e não padronizada.
Mediante as características descritas anteriormente, o framework MVC escolhido
para o desenvolvimento do sistema foi o Mentawai, que ficará responsável pela camada de
controle da aplicação. Juntamente com o Mentawai, serão utilizados os frameworks DWR e
Spry, ambos de visão. O DWR contribuirá nas facilidades que o AJAX proporciona e o Spry
na construção e disposição dos itens de interface.
4.1 VISÃO DO PROJETO BIBLIOTECA VIRTUAL
O conceito de Biblioteca Virtual está relacionado com o conceito de acesso, por meio
de redes, a recursos de informação disponíveis em sistemas de base computadorizada,
normalmente remotos.
A atividade da biblioteca centra-se principalmente no empréstimo de publicações
para alunos da universidade. O empréstimo é registrado pelos funcionários da biblioteca, que
também consultam diariamente os empréstimos cujos prazos foram ultrapassados. Todo este
processo será realizado pelo sistema que ainda permitirá aos alunos pesquisarem os livros
existentes na biblioteca. Todo este processo será realizado pelo sistema para facilitar a vida do
leitor, através do mundo digital.
Ressalta-se que essa forma de funcionamento já é a existente nos sistemas
eletrônicos de diversas bibliotecas brasileiras, no entanto, o diferencial aqui, é a utilização e
explicação do padrão MARC e também a integração de diversos frameworks para Web.
46
4.1.1 Escopo
Biblioteca Virtual é a integração eletrônica de novos serviços com os serviços
tradicionais de bibliotecas. Utilizando-se de redes de computadores e recursos eletrônicos é
possível consultar e verificar a disponibilidade do acervo, além de migrar e facilitar o
intercâmbio de dados com outras instituições.
Objetiva-se a identificar o limite de funcionalidade do software.
Serão realizados vários cadastros de informações relacionadas ao acervo da
biblioteca, como livro, mídia, periódico, categoria, assinatura de periódicos, direitos e acesso
ao sistema, editora, responsável da obra, funcionário, tipo de acervo, assunto e aquisição,
entre outros.
Os associados terão quatro atividades importantes: reserva, empréstimo, consulta e
devolução. Os bibliotecários terão relatórios referentes aos associados, fornecedores, tipos de
acervo, bibliotecários, responsáveis da obra, editoras, empréstimos, reservas, etiquetas de
identificação da obra, categorias, idiomas, mídias, livros, periódicos e outros.
O usuário comum ou associado poderá pesquisar ou verificar disponibilidade de
livros, revistas e mídias através de um portal Web. Nesse mesmo software, o bibliotecário
habilitado poderá buscar a variedade de acervos disponíveis através do padrão de Normas
MARC.
O sistema comporta-se como um administrador e facilitador das tarefas
desenvolvidas por um bibliotecário, agilizando e gerenciando o processo interno, tendo como
usabilidade uma ferramenta de procura e suporte na navegação do software, auxiliando tanto
na rapidez da obtenção da informação quanto na inclusão digital.
Os usuários envolvidos no sistema serão os leitores, atendentes e bibliotecários,
todos poderão pesquisar os itens do acervo. Os leitores também terão a opção de consultar o
status de algum item e fazer o agendamento do mesmo. O atendente poderá registrar a
reserva, o empréstimo, a devolução e a renovação de itens do acervo para um determinado
leitor, bem como incluir, alterar e excluir os dados do leitor. Além de possuir os mesmos
privilégios do atendente, o bibliotecário ainda terá o controle sobre o acervo bibliográfico,
como incluir, alterar e excluir os itens. Ele também terá a opção de reter algum item para
consulta e liberá-lo para o empréstimo.
47
4.1.2 Posicionamento
4.1.2.1 Descrição do Problema
O problema
Um item do acervo é emprestado a um leitor e não
é devolvido na data final de empréstimo.
Afeta
Biblioteca
Cujo impacto é
Gravidade Alta, pois se não houver um controle
bem realizado por parte do bibliotecário o item
poderá ser perdido e, além disso, enquanto ele fica
emprestado, não há a disponibilidade do mesmo na
biblioteca.
Uma boa solução seria
Com a utilização do software o controle desse tipo
de situação ficará mais rápido, pois o funcionário
da biblioteca terá a seu dispor todos os dados
relacionados ao leitor no sistema, podendo bloqueálo sempre que consultar os empréstimos atrasados.
O problema
Um aluno pegou três itens do acervo emprestado e
está adquirindo mais itens, ou seja, o limite de três
itens foi ultrapassado.
Afeta
Biblioteca
Cujo impacto é
Gravidade Alta, pois o empréstimo de mais de três
itens estará ferindo uma regra da biblioteca e, além
disso, estará diminuindo a disponibilidade de
acervo para os usuários.
Uma boa solução seria
A cada realização de empréstimo é verificado se o
usuário já possui algum item emprestado e o
sistema ficará responsável por limitar a quantidade
de itens que um leitor poderá pegar.
48
O problema
A verificação de existência de uma publicação e até
a procura da mesma é um processo um pouco
demorado devido à quantidade do acervo existente
na biblioteca. E às vezes o controle não é eficiente
por se tratar de uma atividade manual.
Afeta
Usuário
Cujo impacto é
Gravidade Baixa, às vezes a procura por uma
publicação pode demorar um pouco e, além disso, a
consulta pode não ser tão eficiente o que estaria
prejudicando o leitor que deseja o empréstimo de
uma publicação.
Uma boa solução seria
Com a criação do software o processo de consulta
da publicação torna-se automatizado o que alavanca
a velocidade na consulta de existência de uma
publicação e se ela está disponível para
empréstimo.
O problema
Manutenção das publicações com suas respectivas
áreas de conhecimento.
Afeta
Bibliotecário
Cujo impacto é
Gravidade Média, a associação de uma publicação
com suas respectivas áreas de conhecimento, caso
não seja bem realizada, trará dificuldades quanto à
consulta da publicação.
Uma boa solução seria
Automatização no processo de associação de uma
publicação a uma área de conhecimento, isso
tornará o processo mais seguro e mais fácil de
manter.
49
4.1.2.2 Sentença de Posição do Produto
A sentença de posição do produto comunica o objetivo do aplicativo e a importância
do projeto para todo o pessoal envolvido.
Para
Universidades, Faculdades, Colégios.
Quem
A necessidade do produto é para fins acadêmicos,
onde os leitores possuirão acesso à biblioteca através
da internet.
A Biblioteca Virtual
é uma ferramenta para auxiliar na gerência e
consulta de acervo.
Que
O principal benefício será que os leitores não terão
que sair de casa para poder consultar e agendar uma
publicação.
Diferente de
Cadastrar todo o acervo item a item.
Nosso produto
O sistema de Biblioteca Virtual utilizará o padrão
MARC, onde o acervo poderá ser populado através
da base de dados de outras bibliotecas.
4.1.3 Descrições dos Envolvidos e Usuários
Para fornecer, de maneira eficiente, produtos e serviços que atendam às reais
necessidades dos usuários e envolvidos, é necessário identificar e considerar todos os
envolvidos como parte do processo de Modelagem de Requisitos. É necessário também
identificar os usuários do sistema e assegurar que a comunidade de envolvidos os represente
adequadamente. Esta seção fornece um perfil dos envolvidos e dos usuários que integram o
projeto, e dos principais problemas que, de acordo com o ponto de vista deles, poderão ser
abordados pela solução proposta.
50
4.1.3.1 Resumo dos Envolvidos
Nome
Descrição
Responsabilidades
Instituições e
Instituições e
A adoção deste padrão diminui a
Bibliotecas.
Bibliotecas que adotem
incidência de erros, tende a elevar o
o padrão MARC, um
nível de qualidade das bases e facilita
formato de descrição
a migração de dados.
bibliográfica
universalmente aceito e
igualmente acessível a
todos.
4.1.3.2 Resumo dos Usuários
Caso o usuário não esteja representado diretamente, será identificado o envolvido
responsável por representar o seu interesse.
Nome
Descrição
Responsabilidades
Atendente
As principais atividades
Registro de empréstimos.
são: a reserva de
Consultar livros no acervo.
publicações, o registro
de empréstimos,
Informar status do leitor.
devoluções e quaisquer
Receber doações.
atividades que envolvam
Gerar relatórios
a biblioteca e o leitor.
Bibliotecário
É responsável por
cadastrar, atualizar e
manter o acervo.
Cadastrar livros.
Atualizar livros.
Reter livros.
Coordenar os atendentes.
Gerar relatórios.
Envolvido
51
Leitor
Poderá consultar o
acervo, obter
informações, agendar
um empréstimo e
adquirir o empréstimo
da publicação.
Consultar o acervo da biblioteca.
Fazer o empréstimo de algum
item.
Entregar-lo.
Fazer doação de alguma
publicação.
Pagar multa se for necessário.
4.2 REQUISITOS DO SISTEMA BIBLIOTECA VIRTUAL
A finalidade desta seção é descrever os requisitos do SBV - Sistema de Biblioteca
Virtual para fornecer uma visão completa e abrangente do software. Aqui estão descritos
requisitos funcionais, não funcionais e outros fatores que visam facilitar o entendimento do
software.
4.2.1 Requisitos Funcionais
4.2.1.1 Administração de Usuários
Refere-se ao processo de manutenção do cadastro de usuários da biblioteca no
sistema.
SBV 001
O sistema deverá permitir o seu operador cadastrar os usuários interessados em obter
empréstimos de itens da biblioteca. O usuário interessado em seu registro junto à biblioteca
deverá fornecer os seguintes dados: nome completo, endereço completo, telefone residencial,
comercial, celular, nível de escolaridade, documento de identidade, número do CPF e
endereço de e-mail.
52
SBV 002
O sistema deverá permitir que usuários cadastrados registrem dependentes, que
poderão retirar itens da biblioteca em seu nome e sob sua responsabilidade.
SBV 003
O sistema deverá administrar a conta de usuários, de forma a garantir o
cumprimento do regimento da biblioteca. A conta dos usuários deverá manter registro de
itens retirados pelo usuário, bem como as respectivas datas de devolução.
SBV 004
O sistema deverá registrar no cadastro de usuários qualquer atraso na devolução de
itens emprestados e bloquear empréstimos futuros no caso de o usuário, ou qualquer de seus
dependentes, repetirem atrasos nas devoluções por três vezes.
SBV 005
O sistema deverá permitir que seu operador libere os empréstimos a um usuário
bloqueado, mediante o pagamento de uma multa, para a qual o sistema deverá imprimir o
respectivo recibo.
SBV 006
O sistema deverá possibilitar a alteração do valor da multa a que se refere o requisito
anterior.
SBV 007
O sistema deverá liberar automaticamente os empréstimos ao usuário faltoso,
transcorridos três meses da última devolução com atraso.
SBV 008
O sistema deve permitir a inclusão, alteração e remoção de leitores da biblioteca,
com os seguintes atributos: nome, endereço, cidade, estado, telefone, e-mail, documento de
identificação, categoria de leitor e data de nascimento.
53
SBV 009
O sistema deve permitir a inclusão, alteração e remoção das diversas categorias de
leitores, com os seguintes atributos: código da categoria, descrição da categoria e número
máximo de dias que essa categoria de leitor pode emprestar uma obra. Exemplos de categorias
de leitores são: aluno de graduação, aluno de pós-graduação, professor, funcionário e usuário
externo.
SBV 010
O sistema deve permitir a inclusão, alteração e remoção de funcionários da
biblioteca, com os seguintes atributos: nome, endereço, cidade, estado, telefone e data de
nascimento.
4.2.1.2 Administração do Acervo
Refere-se ao processo de compra e recebimento de novos itens de acervo para
biblioteca.
SBV 011
O sistema deverá possibilitar ao comprador registrar cumulativamente no sistema os
itens que deverão ser adquiridos. As aquisições serão feitas mensalmente e apenas de alguns
dos itens relacionados (devido à limitação de verba).
SBV 012
O sistema deverá gerar pedido de compra dos itens registrados para as respectivas
quantidades anotadas pelo comprador.
SBV 013
O sistema para registro dos itens a serem adquiridos, deverá consultar bases de dados
dos fornecedores, a partir da onde serão extraídos os dados necessários para a compra.
54
SBV 014
O sistema deverá, quando da geração do pedido de compra, armazenar os itens
registrados e cuja compra não foi efetuada para posterior emissão de relatório – relatório de
aquisições.
SBV 015
O sistema deverá permitir que o comprador registre no sistema os itens recém
chegados, atribuindo-lhe automaticamente o código de localização em função das
informações de compra: assunto, classificação e área de conhecimento.
SBV 016
O sistema deverá disponibilizar para os atendentes, uma tela de registro visando
informar quando os livros recém registrados no sistema estiverem em seus lugares nas
prateleiras da biblioteca. Só então os novos itens estarão disponíveis para empréstimo.
SBV 017
O sistema deverá permitir ao atendente retirar um item de circulação, registrando
uma ocorrência no sistema.
SBV 018
O sistema deverá permitir que o atendente registre e acompanhe o estado de
ocorrência até que o item retorne à circulação.
SBV 019
O sistema deve permitir a inclusão, alteração e remoção das diversas categorias de
obras literárias, com os seguintes atributos: código da categoria, descrição da categoria,
número máximo de dias que esse tipo de obra pode ficar emprestado e taxa diária de multa
por atraso na devolução. Exemplos de categorias são: livro, periódico, revista, nota didática,
jornal, relatório técnico, tese de doutorado e dissertação de mestrado.
SBV 020
O sistema deve permitir a inclusão, alteração e remoção das obras literárias da
biblioteca. Cada obra possui os seguintes atributos: código, ISBN, título da obra, código da
55
categoria de obra literária, autores, palavras-chave, data de publicação, número de edição,
editora e número de páginas. Cada obra pode possuir uma ou mais cópias na biblioteca.
Assim, o sistema deve atribuir um identificador único a cada uma das cópias.
4.2.1.3 Administração de Empréstimos
SBV 021
O sistema deverá possibilitar o registro de empréstimos em nome de usuários ou seus
dependentes, armazenando o código do item, a data de empréstimo e a data de devolução.
SBV 022
O sistema deverá possibilitar o registro de empréstimos, autorizados em nome de
usuários não cadastrados, armazenando o nome do responsável, que deverá ser uma
instituição de ensino ou outra biblioteca registrada no sistema.
SBV 023
O sistema deverá possibilitar aos usuários a consulta de suas contas através de
conexão via internet.
SBV 024
O sistema deverá autenticar usuários através de senha, mantida no cadastro de
usuários.
SBV 025
O sistema deverá permitir que usuários efetuem uma única prorrogação para cada
empréstimo registrado em seu nome, ou em nome de um de seus dependentes, através de
acesso via internet.
SBV 026
O sistema deverá permitir a parametrização do período máximo de prorrogação
permitido, administrando eventuais períodos de prorrogação concedidos antes da alteração do
parâmetro.
56
SBV 027
O sistema deve permitir o processamento da reserva da obra literária, com os
seguintes atributos: data da reserva, data prevista para retirada da obra, data prevista para
devolução, identificação do leitor, código da obra, funcionário responsável pela reserva. A
reserva só deve ser permitida se houverem obras disponíveis no período indicado. Caso
contrário o sistema deve emitir uma mensagem de alerta e a reserva não pode ser confirmada.
SBV 028
O sistema deve permitir o empréstimo de uma obra literária por um leitor. Cada
empréstimo possui os seguintes atributos: data de empréstimo da obra, data prevista para
devolução, identificação do leitor (previamente cadastrado), funcionário responsável pelo
empréstimo e identificação da cópia da obra emprestada. O sistema deve calcular a data
prevista para devolução com base na categoria da obra, limitando o tempo de acordo com a
categoria do leitor. Se tiver sido feita a reserva prévia da obra, então, durante o empréstimo,
informa-se o nome do leitor e os dados da reserva são recuperados automaticamente pelo
sistema e alterados pelo funcionário, se necessário.
SBV 029
O sistema deverá permitir que o operador registre a devolução de um item tomado
por empréstimo por um usuário.
SBV 030
O sistema deverá ser capaz de localizar o registro do empréstimo no sistema através
do código do item, sendo que este será o dado informado quando da inserção do registro de
devolução.
SBV 031
O sistema deverá gerar, a pedido do operador, relatório com todas as devoluções do
dia.
SBV 032
O sistema deverá gerar, ao comando do operador, relatório contendo os registros de
empréstimos em atraso.
57
SBV 033
O sistema deve permitir a devolução da obra por um leitor, com os seguintes
atributos: identificação da cópia da obra emprestada, da devolução da obra. O sistema deve
automaticamente calcular uma multa se a data de devolução for superior à data prevista para
devolução da obra. O valor da multa é calculado multiplicando-se o número de dias de atraso
pela taxa diária de atraso, de acordo com a categoria da obra.
4.2.1.4 Relatórios e Consultas
SBV 034
O sistema deve permitir a impressão de uma listagem das obras emprestadas no
momento, agrupadas por categoria de obra, contendo o nome do leitor, título da obra, data de
retirada e data prevista para devolução.
SBV 035
O sistema deve permitir a impressão de um relatório contendo as obras em atraso no
período (por exemplo, semana ou quinzenal), contendo, para cada dia do período, o nome do
leitor, o telefone, o e-mail, a data de empréstimo e a data prevista para devolução.
SBV 036
O sistema deve permitir a impressão de uma listagem das reservas efetuadas para a
data atual, contendo o nome do leitor, telefone para contato, e-mail e título da obra.
SBV 037
O sistema deve permitir ao leitor imprimir um histórico de seus empréstimos de
obras. Para tal o leitor deve ter sido previamente cadastrado e deve portar um código de
identificação e uma senha. Esse histórico deve conter uma linha para cada obra emprestada
pelo leitor, contendo o título da obra, a data de retirada e devolução e o valor da multa em
cada ocasião.
SBV 038
O sistema deve permitir a consulta on-line da situação da obra literária. Uma obra
está ocupada se existe um leitor que a emprestou no momento. Uma obra está disponível se
58
não está ocupada no período e o número de reservas para tal obra no período é inferior ao
número total de cópias de obras. Essa consulta deve mostrar uma linha para cada obra,
constando, em cada uma dessas linhas, o título da obra, o número de cópias existentes, o
número de obras ocupadas, o número de obras reservadas e o número de obras disponíveis.
4.2.2 Requisitos Não Funcionais
CONFIABILIDADE
O sistema deve ter capacidade para recuperar os dados perdidos na última operação
que realizou em caso de falha.
O sistema deve fornecer facilidades para realização de backup dos arquivos do
sistema.
O sistema deve possuir senhas de acesso e identificação para diferentes tipos de
usuários: administrador do sistema, funcionários da biblioteca e leitores que têm acesso ao
sistema na biblioteca.
EFICIÊNCIA
O sistema deve responder as consultas on-line em menos de 5 segundos.
O sistema deve iniciar a impressão de relatórios solicitados dentro de no máximo 20
segundos após sua requisição.
QUALIDADE DA INFORMAÇÃO
O sistema deve garantir que os dados foram e são populados corretamente.
PORTABILIDADE
O sistema será compatível com os seguintes browsers: Internet Explorer e Mozilla
Firefox.
O sistema deve ser capaz de armazenar os dados em SGBD MySQL.
4.2.3 Glossário
TERMO
Atendente
DESCRIÇÃO
Operador
59
Bases de dados de fornecedores
Arquivos em meio magnético instalado e registrado
junto ao sistema para consulta dos itens disponíveis
para venda. O sistema deve ser capaz de acessar tais
informações fornecidas em um padrão préestabelecido.
Cadastro de usuário
Arquivo mantido pelo sistema no qual são registrados
todos os dados relativos ao usuário da biblioteca.
Código do item
Código através do qual são registrados todos os
dados relativos ao usuário da biblioteca.
Conta
Relação de empréstimos e devoluções efetuadas a um
usuário em determinado período de tempo.
Data de devolução
A data marcada para que o usuário devolva à
biblioteca um item que tomou por empréstimo.
Dependente
Usuário da biblioteca registrado sob a supervisão de
outro usuário que irá se responsabilizar por seus atos
junto à biblioteca.
Devolução
Ato de formalizar a devolução, por parte de um
usuário, de um item tomado por empréstimo na
biblioteca.
Empréstimo
O ato de formalizar a entrega de um livro da
biblioteca a um usuário cadastrado. Segue regras
específicas firmadas no regulamento da biblioteca.
Empréstimo autorizado
Empréstimo concedido a usuário não cadastrado com
a especificação de um responsável: instituição ou
biblioteca.
Empréstimo em atraso
Empréstimos que até a data prevista para a devolução
ainda não possuem o respectivo registro de
devolução.
Estado da ocorrência
Descrição incluída pelo operador indicativo do
estágio em que se encontra a ocorrência.
Item
Elemento disponível para empréstimo na biblioteca.
Pode ser um livro, um CD, um periódico (revista) ou
60
uma fita de vídeo.
Ocorrência
Registro da razão para a retirada de um item de
circulação. São exemplos de ocorrências os envios de
um livro para a oficina, para reparos, a retenção
temporária de um item somente para consulta, entre
outros.
Operador
Funcionário da biblioteca responsável pela utilização
do sistema para concessão de empréstimos, registro
de devoluções ou cadastramento de usuários.
Pedido de compra
Relação com os itens a serem adquiridos junto aos
fornecedores.
Prorrogação
Evento de alteração da data de entrega de um item
registrado em um empréstimo para uma data futura,
distante da data de entrega atual, um número máximo
de dias registrado como parâmetro no sistema.
Recibo
É o documento a ser gerado pelo sistema para ser
entregue ao usuário quando efetuar algum pagamento
à biblioteca, seja ele de multa ou outra taxa qualquer.
Usuário
Indivíduo que se cadastra junto à biblioteca para
poder retirar itens sob empréstimo.
Usuário faltoso
É o usuário que teve seu direito de retirar itens sob
empréstimo suspendo pelo não cumprimento das
regras impostas pelo regimento.
4.3 DOCUMENTO DE ANÁLISE DO SISTEMA BIBLIOTECA VIRTUAL
4.3.1 Relação dos Requisitos
4.3.1.1 Relação dos Requisitos Funcionais
Código
RF 001
RF 002
RF 003
Nome
Manter associado
Manter bibliotecário
Manter categoria
Tipo
Funcional
Funcional
Funcional
61
RF 004
RF 005
RF 006
RF 007
RF 008
RF 009
RF 010
RF 011
RF 012
RF 013
RF 014
RF 015
RF 016
RF 017
RF 018
RF 019
RF 020
RF 021
RF 022
RF 023
Manter idioma
Manter editora
Manter produtora
Manter fornecedor
Manter autor
Consulta acervo
Manter mídia
Manter periódico
Manter livro
Manter tombo mídia
Manter tombo periódico
Manter tombo livro
Manter reserva
Manter empréstimo
Registrar devolução
Importar dados MARC 21
Manter renovação
Emitir relatório de acervo pendente
Emitir relatório de débitos
Emitir relatório histórico de locações
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
Funcional
4.3.1.2 Relação dos Requisitos Não Funcionais
Código
RNF 001
RNF 002
RNF 003
RNF 004
RNF 005
RNF 006
Nome
Recuperar dados usuário
Realizar backup
Identificação do usuário
Tempo de resposta
Compatibilidade
Armazenamento
Tipo
Confiabilidade
Confiabilidade
Confiabilidade
Eficiência
Portabilidade
Portabilidade
4.3.2 Organização dos Requisitos
Nota: I = inclusão, A = alteração, E = exclusão, C = consulta.
4.3.2.1 Relação dos Casos de Uso
Nome
Atores
Descrição
Autenticar Usuário
Bibliotecário e
Associado
Efetuar autenticação do
usuário no sistema.
Manter Associado
Bibliotecário e
Permite utilizar operações de
Referências
Cruzadas
RF 001,
RF 002,
RNF 003
RF 001,
62
Associado
manutenção (I,A,E,C).
Permite utilizar operações de
manutenção (I,A,E,C).
RNF 003
RF 002,
RNF 003
RF 004,
RF 005,
RF 007,
RF 008,
RF 019,
RNF 003
RF 004,
RF 005,
RF 007,
RF 008,
RF 019,
RNF 003
RF 004,
RF 006,
RF 007,
RF 008,
RF 019,
RNF 003
RF 013,
RF 014,
RF 015,
RNF 003
RF 013,
RF 014,
RF 015,
RF 020,
RNF 003
Manter Bibliotecário
Bibliotecário
Manter Livro
Bibliotecário
Permite utilizar operações de
manutenção (I,A,E,C).
Manter Periódico
Bibliotecário
Permite utilizar operações de
manutenção (I,A,E,C).
Manter Mídia
Bibliotecário
Permite utilizar operações de
manutenção (I,A,E,C).
Manter Reserva
Bibliotecário e
Associado
Efetuar a reserva do acervo (I,
E, C).
Manter Empréstimo
Bibliotecário
Efetuar o empréstimo do
acervo e realizar renovações
(I,A,C).
Registrar Devolução
Bibliotecário
Registrar devolução do acervo
RF 017,
locado e checar os débitos
RNF 003
(I,C).
4.3.2.2 Conceitos
Conceito
Autenticação
Bibliotecário
Associado
Livro
Periódico
Mídia
I A E C Observação
Autenticação dos usuários
x
envolvidos no sistema.
Responsável pela parte de
x x x x
gerência do sistema.
Consulta e faz o empréstimo do
x x x x
acervo.
x x x x Livros cadastrados na biblioteca.
Periódicos cadastrados na
x x x x
biblioteca.
x x x x Mídias cadastradas na biblioteca.
63
Reserva
x
x
Empréstimo
x x
Devolução
x
MARC 21
x x
Efetua a reserva de um
determinado acervo.
Registra o empréstimo e realiza
x
possível renovação do acervo.
Registra a devolução do acervo e
x
consulta débitos existentes.
Efetua a importação dos dados
de outra biblioteca através de um
arquivo texto.
x
4.3.2.3 Consultas / Relatórios
Nome
Relatório de acervo pendente.
Relatório de débitos.
Relatório de histórico de locações.
Relatório de associados.
Relatório de bibliotecários.
Relatório de livros, mídias e periódicos.
Relatório de devoluções.
Relatório de reservas.
Relatório de empréstimos.
4.3.3 Expansão dos Casos de Uso
4.3.3.1 Descrição dos Casos de Uso
UC 001 – AUTENTICAR USUÁRIO
Caso de Uso: Autenticar Usuário.
Descrição: Efetua a autenticação do associado ou bibliotecário no sistema.
Atores: Bibliotecário e Associado.
Interessados: Instituição de Ensino.
Pré-Condições: Para que ocorra a autenticação é necessário que o usuário (associado ou
bibliotecário) esteja cadastrado no sistema. O associado deve informar matrícula e senha. Já
o bibliotecário deve informar login e senha.
Pós-Condições: Permissão de acesso as funcionalidades do sistema.
Requisitos correlacionados: RF 001, RF 002, RNF 003
Fluxo Principal:
Evento de Usuário
Resposta de Sistema
64
1. O associado ou o bibliotecário efetua a 2. Confirmação da autenticação do usuário
entrada no sistema.
no sistema de acordo com o seu perfil.
Tratamento de Exceções:
Evento de Usuário
Resposta de Sistema
1.1. Os dados do usuário estão incorretos.
1.1.1. O sistema informa que os dados foram
digitados incorretamente. Retorna ao passo
1.
1.2. O usuário encontra-se bloqueado no sistema.
1.2.1. O sistema alerta o usuário informando
que o mesmo está bloqueado e solicita sua
presença na biblioteca para a regularização
de seu cadastro. Retorna ao passo 1.
UC 002 – MANTER ASSOCIADO
Caso de Uso: Manter Associado.
Descrição: Efetua a inclusão, alteração, exclusão e consulta do associado no sistema.
Atores: Bibliotecário e Associado.
Interessados: Instituição de Ensino.
Pré-Condições: Para a inclusão do associado são necessários os seguintes dados: nome,
CPF, matrícula, data de nascimento, senha, endereço, telefone e e-mail. Após o cadastro do
associado pelo bibliotecário, o associado poderá alterar os dados de endereço, telefone e email. O bibliotecário poderá excluir o associado. Se o associado estiver com pendências na
biblioteca o mesmo será bloqueado. A consulta de associados poderá ser feita pelo
bibliotecário.
Pós-Condições: Uma mensagem será apresentada ao usuário ou os associados serão
listados.
Requisitos correlacionados: RF 001, RNF 003
Fluxo principal:
Evento de Usuário
Resposta de Sistema
1. O associado ou o bibliotecário efetua a 2. Confirmação da autenticação do usuário
entrada no sistema.
no sistema de acordo com o seu perfil.
4. O sistema valida os dados informados,
3. Na inclusão o bibliotecário informa os
efetua a inclusão e emite uma mensagem de
dados do associado.
sucesso.
5. Na alteração, se o usuário for o 6. O sistema valida os dados informados,
bibliotecário, ele realizará as alterações nos efetua a alteração e emite uma mensagem de
dados do associado.
sucesso.
7. Na alteração, se o usuário for o associado, 8. O sistema valida os dados informados,
ele poderá apenas alterar os dados de efetua a alteração e emite uma mensagem de
endereço, telefone e e-mail.
sucesso.
65
9. Na exclusão somente o bibliotecário
10. O sistema confirma a exclusão.
poderá efetuá-la.
Tratamento de Exceções:
Evento de Usuário
Resposta de Sistema
3.1. Os dados do associado estão incompletos.
3.1.1. O bibliotecário deverá informar todos 3.1.2. O sistema não possibilita a inclusão do
os dados do usuário.
associado. Retorna ao passo 3.
UC 003 – MANTER BIBLIOTECÁRIO
Caso de Uso: Manter Bibliotecário.
Descrição: Efetua a inclusão, alteração, exclusão e consulta do bibliotecário no sistema.
Atores: Bibliotecário.
Interessados: Instituição de Ensino.
Pré-Condições: Para a inclusão do bibliotecário são necessários os seguintes dados: nome,
CPF, data de nascimento, login, senha, endereço, telefone e e-mail. O bibliotecário logado
terá a opção de alterar seus dados pessoais. Haverá uma consulta de bibliotecários.
Pós-Condições: Uma mensagem será apresentada ao usuário ou os bibliotecários serão
listados.
Requisitos correlacionados: RF 002, RNF 003
Fluxo principal:
Evento de Usuário
Resposta de Sistema
1. O bibliotecário efetua a entrada no 2. Confirmação da autenticação do usuário
sistema.
no sistema de acordo com o seu perfil.
4. O sistema valida os dados informados,
3. Na inclusão o bibliotecário informa os
efetua a inclusão e emite uma mensagem de
dados do bibliotecário a ser cadastrado.
sucesso.
5. Na alteração, o bibliotecário logado, 6. O sistema valida os dados informados,
poderá alterar apenas os dados de endereço, efetua a alteração e emite uma mensagem de
telefone e e-mail.
sucesso.
7. Na exclusão, o bibliotecário com
permissão,
poderá
excluir
outro 8. O sistema confirma a exclusão.
bibliotecário.
Tratamento de Exceções:
Evento de Usuário
Resposta de Sistema
3.1. Os dados do bibliotecário estão incompletos.
3.1.1. O bibliotecário deverá informar todos 3.1.2. O sistema não possibilita a inclusão do
os dados do usuário a ser cadastrado.
bibliotecário. Retorna ao passo 3.
66
UC 004 – MANTER LIVRO
Caso de Uso: Manter Livro.
Descrição: Efetua a inclusão, alteração, exclusão e consulta do livro no sistema.
Atores: Bibliotecário, Associado e MARC 21.
Interessados: Instituição de Ensino.
Pré-Condições: Para a inclusão do livro são necessários os seguintes dados: título original,
subtítulo, CDU, cutter, nome dos autores, editora, volume, coleção, número de série,
descrição da série e assunto. Para o cadastro de tombo são necessários os seguintes dados:
nome livro, ISBN, edição, descrição da edição, forma de aquisição, ano de publicação,
observações, situação, edição local e valor do livro. O cadastro do livro poderá ser feito
através da importação do acervo de outra biblioteca com o padrão MARC 21. Para a
alteração, todos os dados deverão ser informados. A situação do tombo poderá ser alterada
para disponível ou para bloqueado. O tombo poderá ser excluído. A consulta do livro
poderá ser feita pelo título, autor ou assunto.
Pós-Condições: Após a inclusão, alteração ou exclusão será emitida uma mensagem. Feito
a consulta o sistema buscará os livros baseados nos parâmetros que foram informados.
Requisitos correlacionados: RF004, RF 005, RF 007, RF 008, RF 019, RNF 003
Fluxo principal:
Evento de Usuário
1. O usuário efetua a entrada no sistema.
Resposta de Sistema
2. Confirmação da autenticação do usuário
no sistema de acordo com o seu perfil.
4. O sistema valida os dados informados,
efetua a inclusão e emite uma mensagem de
sucesso.
6. O sistema valida os dados informados,
efetua a inclusão e emite uma mensagem de
sucesso.
3. Na inclusão todos os dados referentes ao
livro deverão ser informados pelo
bibliotecário.
5. Na inclusão de um tombo o bibliotecário
terá que selecionar o livro no qual o tombo
pertence e informar o restante dos dados.
7. Na inclusão do tombo de um livro pelo
8. O sistema valida os dados e insere o livro
padrão MARC, um arquivo deverá ser
no acervo.
importado e validado.
10. O sistema valida os dados informados,
9. Na alteração do livro todos os dados
efetua a alteração e emite uma mensagem de
deverão ser preenchidos pelo bibliotecário.
sucesso.
11. Na exclusão o tombo poderá ser excluído
12. O sistema confirma a exclusão ou
ou seu status alterado (bloqueado,
alteração do tombo.
disponível) pelo bibliotecário.
13. A consulta do livro será baseada nos
14. O sistema efetua a busca do livro no
parâmetros
(título,
autor,
assunto),
acervo através dos parâmetros informados
informados pelo usuário (associado ou
pelo usuário.
bibliotecário).
Tratamento de Exceções:
Evento de Usuário
3.1. Os dados do livro estão incompletos.
Resposta de Sistema
67
3.1.1. O bibliotecário deverá informar todos
os dados do livro a ser cadastrado.
5.1. Os dados do tombo estão incompletos.
5.1.1. O bibliotecário deverá selecionar o
livro no qual o tombo pertence e informar
todos os dados do tombo a ser cadastrado.
7.1. O arquivo não pode ser validado.
7.1.1. O bibliotecário deverá realizar o
upload do arquivo com os dados a serem
incluídos.
11.1. Exclusão do livro.
11.1.1. O bibliotecário não poderá excluir
um tombo que esteja emprestado.
3.1.2. O sistema não possibilita a inclusão do
livro. Retorna ao passo 3.
5.1.2. O sistema não possibilita a inclusão do
tombo. Retorna ao passo 5.
7.1.2. O sistema não possibilita a inclusão do
tombo. Retorna ao passo 7.
11.1.2. O sistema não possibilita a exclusão
do tombo. Retorna ao passo 11.
UC 005 – MANTER PERIÓDICO
Caso de Uso: Manter Periódico.
Descrição: Efetua a inclusão, alteração, exclusão e consulta do periódico no sistema.
Atores: Bibliotecário, Associado e MARC 21.
Interessados: Instituição de Ensino.
Pré-Condições: Para a inclusão do periódico são necessários os seguintes dados: data
inicial e final da assinatura, valor da assinatura, período de distribuição e editora. Para o
cadastro de tombo são necessários os seguintes dados: forma de aquisição, edição, ano da
publicação, volume, número do periódico, data da publicação, ISSN, situação, estante,
observação. O cadastro do periódico poderá ser feito através da importação do acervo de
outra biblioteca com o padrão MARC 21. Para a alteração, todos os dados deverão ser
informados. A situação do periódico poderá ser alterada para disponível ou para bloqueado.
O tombo poderá ser excluído. A consulta do periódico poderá ser feita pela data, editora ou
nome do periódico.
Pós-Condições: Após a inclusão, alteração ou exclusão será emitida uma mensagem. Feito
a consulta o sistema buscará os periódicos baseados nos parâmetros que foram informados.
Requisitos correlacionados: RF004, RF 005, RF 007, RF 008, RF 019, RNF 003
Fluxo principal:
Evento de Usuário
Resposta de Sistema
2. Confirmação da autenticação do usuário
1. O usuário efetua a entrada no sistema.
no sistema de acordo com o seu perfil.
3. Na inclusão todos os dados referentes ao 4. O sistema valida os dados informados,
periódico deverão ser informados pelo efetua a inclusão e emite uma mensagem de
bibliotecário.
sucesso.
5. Na inclusão de um tombo o bibliotecário
6. O sistema valida os dados informados,
terá que selecionar o periódico no qual o
efetua a inclusão e emite uma mensagem de
tombo pertence e informar o restante dos
sucesso.
dados.
68
7. Na inclusão do tombo de um periódico
8. O sistema valida os dados e insere o
pelo padrão MARC, um arquivo deverá ser
periódico no acervo.
importado e validado.
10. O sistema valida os dados informados,
9. Na alteração do periódico todos os dados
efetua a alteração e emite uma mensagem de
deverão ser preenchidos pelo bibliotecário.
sucesso.
11. Na exclusão o tombo poderá ser excluído
12. O sistema confirma a exclusão ou
ou seu status alterado (bloqueado,
alteração do tombo.
disponível) pelo bibliotecário.
13. A consulta do periódico será baseada nos 14. O sistema efetua a busca do periódico no
parâmetros (data, editora, nome), informados acervo através dos parâmetros informados
pelo usuário (associado ou bibliotecário).
pelo usuário.
Tratamento de Exceções:
Evento de Usuário
3.1. Os dados do periódico estão incompletos.
3.1.1. O bibliotecário deverá informar todos
os dados do periódico a ser cadastrado.
5.1. Os dados do tombo estão incompletos.
5.1.1. O bibliotecário deverá selecionar o
periódico no qual o tombo pertence e
informar todos os dados do tombo a ser
cadastrado.
7.1. O arquivo não pode ser validado.
7.1.1. O bibliotecário deverá realizar o
upload do arquivo com os dados a serem
incluídos.
11.1. Exclusão do periódico.
11.1.1. O bibliotecário não poderá excluir
um tombo que esteja emprestado.
Resposta de Sistema
3.1.2. O sistema não possibilita a inclusão do
periódico. Retorna ao passo 3.
5.1.2. O sistema não possibilita a inclusão do
tombo. Retorna ao passo 5.
7.1.2. O sistema não possibilita a inclusão do
tombo. Retorna ao passo 7.
11.1.2. O sistema não possibilita a exclusão
do tombo. Retorna ao passo 11.
UC 006 – MANTER MÍDIA
Caso de Uso: Manter mídia.
Descrição: Efetua a inclusão, alteração, exclusão e consulta da mídia no sistema.
Atores: Bibliotecário, Associado e MARC 21.
Interessados: Instituição de Ensino.
Pré-Condições: Para a inclusão da mídia são necessários os seguintes dados: CDU,
subtítulo, título original, volume, coleção, cutter, número de série, tipo de mídia e
produtora. Para o cadastro de tombo são necessários os seguintes dados: edição, forma de
aquisição, ano da publicação e observação. O cadastro da mídia poderá ser feito através da
importação do acervo de outra biblioteca com o padrão MARC 21. Para a alteração, todos
os dados deverão ser informados. A situação do tombo poderá ser alterada para disponível
ou para bloqueado. O tombo poderá ser excluído. A consulta da mídia poderá ser feita pelo
69
título, produtora ou tipo.
Pós-Condições: Após a inclusão, alteração ou exclusão será emitida uma mensagem. Feito
a consulta o sistema buscará as mídias baseados nos parâmetros que foram informados.
Requisitos correlacionados: RF004, RF 006, RF 007, RF 008, RF 019, RNF 003
Fluxo principal:
Evento de Usuário
1. O usuário efetua a entrada no sistema.
Resposta de Sistema
2. Confirmação da autenticação do usuário
no sistema de acordo com o seu perfil.
4. O sistema valida os dados informados,
efetua a inclusão e emite uma mensagem de
sucesso.
6. O sistema valida os dados informados,
efetua a inclusão e emite uma mensagem de
sucesso.
3. Na inclusão todos os dados referentes à
mídia deverão ser informados pelo
bibliotecário.
5. Na inclusão de um tombo o bibliotecário
terá que selecionar a mídia no qual o tombo
pertence e informar o restante dos dados.
7. Na inclusão do tombo de uma mídia pelo
8. O sistema valida os dados e insere a mídia
padrão MARC, um arquivo deverá ser
no acervo.
importado e validado.
10. O sistema valida os dados informados,
9. Na alteração da mídia todos os dados
efetua a alteração e emite uma mensagem de
deverão ser preenchidos pelo bibliotecário.
sucesso.
11. Na exclusão o tombo poderá ser excluído
12. O sistema confirma a exclusão ou
ou seu status alterado (bloqueado,
alteração do tombo.
disponível) pelo bibliotecário.
13. A consulta da mídia será baseada nos
14. O sistema efetua a busca da mídia no
parâmetros
(título,
produtora,
tipo),
acervo através dos parâmetros informados
informados pelo usuário (associado ou
pelo usuário.
bibliotecário).
Tratamento de Exceções:
Evento de Usuário
3.1. Os dados da mídia estão incompletos.
3.1.1. O bibliotecário deverá informar todos
os dados da mídia a ser cadastrada.
5.1. Os dados do tombo estão incompletos.
5.1.1. O bibliotecário deverá selecionar a
mídia no qual o tombo pertence e informar
todos os dados do tombo a ser cadastrado.
7.1. O arquivo não pode ser validado.
7.1.1. O bibliotecário deverá realizar o
upload do arquivo com os dados a serem
incluídos.
11.1. Exclusão da mídia.
11.1.1. O bibliotecário não poderá excluir
um tombo que esteja emprestado.
Resposta de Sistema
3.1.2. O sistema não possibilita a inclusão da
mídia. Retorna ao passo 3.
5.1.2. O sistema não possibilita a inclusão do
tombo. Retorna ao passo 5.
7.1.2. O sistema não possibilita a inclusão do
tombo. Retorna ao passo 7.
11.1.2. O sistema não possibilita a exclusão
do tombo. Retorna ao passo 11.
70
UC 007 – MANTER RESERVA
Caso de Uso: Manter reserva.
Descrição: Efetua a inclusão, exclusão e consulta de reservas efetuadas pelos os usuários
no sistema.
Atores: Bibliotecário e Associado.
Interessados: Instituição de Ensino.
Pré-Condições: A reserva poderá ser feita pelo bibliotecário ou pelo associado, isso se o
acervo estiver disponível e o associado não estiver bloqueado. A exclusão da reserva
poderá ser feita pelo usuário (bibliotecário ou associado). A consulta efetuada pelo
bibliotecário terá o seguinte parâmetro: matrícula.
Pós-Condições: O usuário efetua a reserva e consulta as mesmas.
Requisitos correlacionados: RF 013, RF 014, RF 015, RNF 003
Fluxo principal:
Evento de Usuário
1. O usuário efetua a entrada no sistema.
Resposta de Sistema
2. Confirmação da autenticação do usuário
no sistema de acordo com o seu perfil.
4. O sistema valida os dados informados,
efetua a reserva e emite uma mensagem de
sucesso.
6. O sistema valida os dados informados,
efetua a reserva, registra o bibliotecário
logado e emite uma mensagem de sucesso.
3. Ao efetuar a reserva pelo associado deverá
ser escolhido o acervo e a data prevista para
o empréstimo.
5. Ao efetuar a reserva pelo bibliotecário
deverá ser escolhido o acervo, o associado e
a data prevista para o empréstimo.
7. A exclusão da reserva poderá ser feita
pelo bibliotecário e pelo associado a 8. O sistema confirma a exclusão da reserva.
qualquer momento.
9. O bibliotecário efetuará a consulta de 10. O sistema valida a matrícula do
reservas pela matrícula do associado.
associado, efetua a busca e retorna os dados.
Tratamento de Exceções:
Evento de Usuário
3.1. O acervo não está disponível.
3.1.1. O usuário é informado que o acervo
selecionado está indisponível.
5.1. O associado está bloqueado.
5.1.1. O bibliotecário é informado que o
associado está bloqueado e deve regularizar
sua situação.
Resposta de Sistema
3.1.2. O sistema não possibilita a reserva do
acervo. Retorna ao passo 3.
5.1.2. O sistema não possibilita a reserva do
acervo. Retorna ao passo 5.
71
UC 008 – MANTER EMPRÉSTIMO
Caso de Uso: Manter empréstimo.
Descrição: Efetua a inclusão, renovação e consulta dos empréstimos efetuados pelo o
associado.
Atores: Bibliotecário e Associado.
Interessados: Instituição de Ensino.
Pré-Condições: O empréstimo somente será realizado pelo bibliotecário. Para que o
empréstimo seja efetuado é necessário que o acervo não esteja reservado ou bloqueado e
que o associado não esteja com situação pendente. A renovação do empréstimo será
concluída caso não houver reservas registradas para o acervo emprestado. Para efetuar a
consulta ao histórico de empréstimos o bibliotecário deverá informar a matrícula do
associado.
Pós-Condições: O bibliotecário efetua o empréstimo. Os usuários visualizam o histórico.
Requisitos correlacionados: RF 013, RF 014, RF 015, RF 020, RNF 003
Fluxo principal:
Evento de Usuário
1. O usuário efetua a entrada no sistema.
Resposta de Sistema
2. Confirmação da autenticação do usuário
no sistema de acordo com o seu perfil.
3. Somente o bibliotecário poderá realizar o
4. O sistema valida os dados informados,
empréstimo. O bibliotecário informa o
efetua o empréstimo, registra o bibliotecário
acervo e o associado para concluir o
logado e emite uma mensagem de sucesso.
empréstimo.
6. O sistema verifica se o usuário não possui
5. O bibliotecário informa o acervo a ser débitos, efetua a renovação, registra o
renovado.
bibliotecário logado e emite uma mensagem
de sucesso.
7. O bibliotecário efetuará a consulta ao
8. O sistema valida a matrícula do associado,
histórico de empréstimos pela matrícula do
efetua a busca e retorna os dados.
associado.
Tratamento de Exceções:
Evento de Usuário
3.1. O acervo não está disponível.
3.1.1. O bibliotecário é informado que o
acervo selecionado está indisponível.
3.2. O associado está bloqueado.
3.2.1. O bibliotecário é informado que o
associado está bloqueado e deve regularizar
sua situação.
Resposta de Sistema
3.1.2. O sistema não possibilita o
empréstimo do acervo. Retorna ao passo 3.
3.2.2. O sistema não possibilita o
empréstimo do acervo. Retorna ao passo 3.
72
UC 009 – REGISTRAR DEVOLUÇÃO
Caso de Uso: Registrar devolução.
Descrição: Efetua a devolução de um acervo que se encontra emprestado.
Atores: Bibliotecário.
Interessados: Instituição de Ensino.
Pré-Condições: A devolução somente será registrada pelo bibliotecário. O bibliotecário
verifica se há empréstimo para o associado, caso haja, o sistema calculará o possível débito,
se houver débito, o associado deverá quitá-lo, assim o acervo estará disponível para futuras
locações.
Pós-Condições: O bibliotecário visualiza mensagem retornada do sistema.
Requisitos correlacionados: RF 017, RNF 003
Fluxo principal:
Evento de Usuário
Resposta de Sistema
1. O bibliotecário efetua a entrada no 2. Confirmação da autenticação do usuário
sistema.
no sistema de acordo com o seu perfil.
3. O bibliotecário lista os empréstimos de
4. O sistema verifica a existência de débitos
determinado associado e informa o acervo a
para o associado.
ser devolvido.
5. O bibliotecário confirma o valor a ser
6. O sistema efetua a devolução e emite uma
pago e registra o pagamento efetuado pelo
mensagem de sucesso.
associado.
Tratamento de Exceções:
Evento de Usuário
Resposta de Sistema
3.1. O empréstimo não está cadastrado.
3.1.2. O sistema não possibilita a devolução
3.1.1. O bibliotecário é informado que o
do acervo e verifica se o mesmo não está
empréstimo não está cadastrado.
cadastrado na biblioteca. Retorna ao passo 3.
5.1. O associado está em débito com a biblioteca.
5.1.1. O bibliotecário informa que o 5.1.2. O sistema não possibilita a devolução
pagamento não foi efetuado.
do acervo. Retorna ao passo 5.
73
4.3.3.2 Diagrama dos Casos de Uso
Figura 6: Diagrama de caso de uso do Sistema de Biblioteca Virtual
74
4.3.4 Modelo Conceitual
Figura 7: Modelo conceitual do Sistema de Biblioteca Virtual
75
4.4 DOCUMENTO DE PROJETO DO SISTEMA BIBLIOTECA VIRTUAL
4.4.1 Diagramas de Seqüência
DS 001 – AUTENTICAR ASSOCIADO
Figura 8: Diagrama de seqüência autenticar associado
76
DS 002 – AUTENTICAR BIBLIOTECÁRIO
Figura 9: Diagrama de seqüência autenticar bibliotecário
77
DS 003 – MANTER ACERVO
Figura 10: Diagrama de seqüência manter acervo
78
DS 004 – MANTER ACERVO POR MARC 21
Figura 11: Diagrama de seqüência manter acervo por MARC 21
79
DS 005 – MANTER ASSOCIADO
Figura 12: Diagrama de seqüência manter associado
80
DS 006 – MANTER BIBLIOTECÁRIO
Figura 13: Diagrama de seqüência manter bibliotecário
81
DS 007 – MANTER EMPRÉSTIMO
Figura 14: Diagrama de seqüência manter empréstimo
82
DS 008 – MANTER RESERVA
Figura 15: Diagrama de seqüência manter reserva
83
DS 009 – REGISTRAR DEVOLUÇÃO
Figura 16: Diagrama de seqüência registrar devolução
84
4.4.2 Diagrama de Classes do Projeto
Figura 17: Diagrama de classes do Sistema de Biblioteca Virtual
85
4.4.3 Modelo de Entidade e Relacionamento (MER)
Figura 18: Modelo de Entidade e Relacionamento do Sistema de Biblioteca Virtual
4.5 ARQUITETURA DO SISTEMA BIBLIOTECA VIRTUAL
Arquitetura é uma representação abstrata do comportamento de componentes de um
sistema. É uma visão de alto nível do sistema.
O modelo arquitetural para construção de software em 3 camadas (Cliente, Servidor
de Aplicação, Servidor de Banco de Dados) é uma evolução do antigo modelo em 2 camadas
86
(Cliente/Servidor) e oferece uma série de benefícios, dentre os quais podemos destacar a
flexibilidade e a escalabilidade.
Visando o desenvolvimento da aplicação de software para a plataforma Web
utilizando a tecnologia Java, definiu-se uma arquitetura de software baseada no padrão MVC
(Model – View – Controller), como mostra a figura 19.
1
N
Apresentação
Objeto
E
1
N
T
1
N
0 .. N
I
Negócio
D
Objeto
A
1
D
E
1
0 .. N
Objeto
N Persistência
1
1
BD
Figura 19: Arquitetura MVC
4.5.1 Apresentação
A camada de apresentação é responsável pela geração de páginas Web e acesso a
conteúdo dinâmico, que é geralmente obtido através de dados vindos do banco de dados.
Ela representa a camada View (ou visão) do padrão MVC e é composta por interfaces
de usuário Web, construídas a partir de HTML, Javascript ou JSP.
87
4.5.2 Controle
A camada de controle representa a camada Controller (ou controle) do padrão MVC.
Ela é composta por um Servlet, que gerência todo o acesso às aplicações, e por diversas
classes de controle, que gerenciam as mudanças de apresentação causadas por eventos de
usuário ou eventos temporais. Conterá apenas a lógica para mostrar os dados da camada de
entidade, cuidando das validações e da forma de apresentação dos mesmos para o usuário.
4.5.3 Negócio
A camada de negócio representa as regras de negócio encapsuladas na camada Model
(ou modelo) do padrão MVC. Ela é composta por classes de negócio que encapsulam as
regras e ações relativas exclusivamente ao negócio.
A camada de negócio trata de classes com serviços de lógica, ou seja, das regras de
negócio do sistema, tais como: cálculos, chamadas a um método ou a um conjunto de
métodos persistentes.
Ela pode também fazer chamadas a si mesma ou às classes de persistência. No caso
de chamadas a métodos de uma outra classe, a comunicação só poderá ser feita de camada de
negócio para camada de negócio. Ou seja, uma camada de negócio não chama métodos de
persistência de outra classe, somente àquela que ela referencia diretamente [14].
A camada de negócio conterá apenas métodos que aplicarão regras de negócio nos
objetos da camada de entidade. Os atributos ficarão na camada de entidade.
A comunicação com a camada de entidade pode ser indireta, através da camada de
persistência, passando o objeto entidade como parâmetro e recebendo os dados do objeto
instanciado, ou acessando diretamente a camada de entidade.
Quando uma entidade for composta e o analista decidir persistir (incluir, alterar,
excluir) os itens individualmente, a classe de negócio delegará a responsabilidade de
manipular as persistências das classes para a sua própria classe de persistência.
4.5.4 Persistência
A camada de persistência representa a manipulação de dados realizada na camada
Model do padrão MVC. Ela é composta por classes de persistência que encapsulam todas as
88
sentenças de manipulação de dados em aplicações legadas, bancos de dados ou outras fontes
de dados.
A camada de persistência trata exclusivamente das classes com serviços de busca e
armazenamento dos dados. É composta de instruções de acesso a dados (SQL).
A camada de persistência não faz chamada de métodos de negócio, somente chamada
a métodos próprios.
Ela passa a conter somente métodos, uma vez que os atributos estão na camada de
entidade.
Quando uma classe entidade for composta, a sua classe de persistência será
responsável por gerenciar a persistência de seus componentes. Os componentes terão suas
próprias classes de persistência, porém gerenciados pela classe persistência da classe
composta.
4.5.5 Entidade
A camada de entidade representa os dados manipulados na aplicação, persistidos na
camada Model do padrão MVC. Ela é composta por classes de entidade que encapsulam todos
os dados na forma de atributos.
Esta camada é formada por atributos e por dois métodos: um método de mapeamento
objeto relacional, que atribui às propriedades do objeto os respectivos campos constantes no
modelo relacional; e por último, um método que configura valores padrão (default) para os
atributos.
Os atributos das classes entidade poderão ainda representar coleções de outras
entidades.
A camada de entidade não deve ser confundida com o modelo entidaderelacionamento, pois esta é na verdade uma camada de representação utilizada para mostrar
dados de uma ou mais entidades-relacionamento de acordo com a orientação a objeto.
As classes de entidade são especializadas em representar os dados, por isso,
dependem de serviços fornecidos pelas classes da camada de persistência.
89
4.5.6 Visão Geral
A arquitetura do sistema SBV (SISTEMA BIBLIOTECA VIRTUAL) é organizada
em 3 camadas e 5 pacotes principais, como mostra a figura 20.
Figura 20: Arquitetura do Sistema Biblioteca Virtual
4.5.6.1 Pacote de Apresentação
Os componentes desta camada devem ser construídos utilizando-se HTML,
Javascript, Spry, AJAX e JSP. O código escrito em HTML e Javascript deve ficar
armazenado em arquivos separados (extensões .jsp e .js, respectivamente) que possuirão o
mesmo nome da classe de controle que os gerencia. As diversas telas de um programa ficarão
armazenadas no mesmo arquivo de código HTML.
90
4.5.6.2 Pacote de Controle
Os componentes desta camada são formados por classes que devem ser construídas
em Java. O servlet utilizado é chamado de Controller e coordena o acesso a todas as classes
de controle. A classe de controle é responsável pela interface com a camada de apresentação:
validação, tratamento e formatação de dados de entrada e saída; e pela comunicação com as
camadas de negócio e persistência.
4.5.6.3 Pacote de Negócio
Os componentes desta camada são formados por classes que devem ser construídas
em Java. As classes de negócio encapsulam todas as regras e lógicas de negócio. Geralmente
as classes de negócio ficam como interface entre as classes de controle e a camada de
persistência.
4.5.6.4 Pacote de Persistência
Os componentes desta camada são formados por classes que devem ser construídas
em Java. As classes de persistência encapsulam puramente o acesso às fontes de dados e a sua
devolução de forma e formato correto.
Estas fontes de dados podem ser Sistemas de Gerenciamento de Banco de Dados
acessados através de SQL ou sistemas legados quaisquer. A camada de persistência se ocupa
e se preocupa com a conexão e desconexão das fontes de dados através de classes específicas
para estes fins. Aqui não existem regras de negócio ou validação/formatação de dados de
Entrada/Saída.
4.5.6.5 Pacote de Entidade
Os componentes desta camada são formados por classes que devem ser construídas
em Java. As classes de entidade encapsulam os dados capturados ou a serem enviados para as
fontes de dados.
91
CAPÍTULO 5
CONCLUSÃO
Visto que há atualmente tecnologias que permitem a criação de uma Biblioteca
Virtual, juntamente com o conhecimento teórico adquirido com a análise sobre ferramentas e
padrões existentes, o desenvolvimento do sistema é completamente possível e viável.
O conhecimento adquirido durante a elaboração do projeto foi importantíssimo para
formar uma base sólida a respeito de padrões como RUP, o qual certamente será utilizado
profissionalmente no futuro. Além dele, convém ressaltar o padrão para documentação de
registros bibliográficos, conhecido como MARC, que possibilita a interação entre os acervos
de bibliotecas. Tal padrão ainda não possui uma documentação bem estruturada de fácil
disponibilidade, pois o acesso a tais informações ainda é restrito, principalmente pelo seu
custo. Além disso, a busca pelo conhecimento dos diversos padrões e tecnologias aplicados
no projeto foi de grande importância para o amadurecimento do aprendizado dos autores
desse trabalho.
Com todas as suas características e particularidades, como a documentação do
padrão MARC e as tecnologias que o diferenciam das aplicações afins existentes, o
desenvolvimento do projeto foi importante por possibilitar a integração de diversas
tecnologias em um único sistema, comprovando que é possível utilizá-lo em escala comercial
e como referência em futuras pesquisas.
92
REFERÊNCIAS BIBLIOGRÁFICAS
[1] CUNHA, Murilo B. da. Desafios na construção de uma biblioteca digital. Ciência da
Informação,
Brasília,
v.
28,
n.
3,
p.
257-268,
Set./Dez.
1999.
URL:
http://www.scielo.br/scielo.php?script=sci_arttext&pid=S010019651999000300003&lng=pt&nrm=iso&tlng=pt
[2] GEARY, David. Core JavaServer TM Faces. Alta Books, 2005.
[3] DRABENSTOTT, Karen M., BURMAN, Celeste M. Revisão Analítica da Biblioteca do
Futuro.
URL:
http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0100-
19651997000200012&lng=es&nrm=iso
[4] DEITEL, H.M. Java: como programar. Pearson Prentice Hall, 2005.
[5] FURRIE, Betty. What is a Marc record and why is it important? Em: Understanding
Marc Bibliographic: machine readable cataloging. Washington : Follett, 2000. URL:
http://lcweb.loc.gov/marc/umb/um01to06.html
[6] Guia JSTL. Disponível em < http://www.portaljava.com/ >. Acesso em: 26 de nov. de
2006.
[7] HÜBNER, Edwin. ISISMARC - Uma solução que faltava. Julho, 2005.
[8] LARMAN, Craig. Utilizando UML e Padrões. Bookman, 2007.
[9] HUSTED, Ted. Struts em Ação. Ciência Moderna, 2004.
[10] KRUCHTEN, P. The Rational Unified Process: An Introduction, Addison Wesley, 3ª
Ed., 2003.
93
[11] LANDONI, Monica et al. Hyper-books and visual-books in an electronic library. The
Electronic Library, v. 11, n. 3, p. 175-176, Junho, 1993.
[12] LÉVY, Pierre. O que é o virtual? São Paulo: Ed. 34, 1996.
[13] MARC Standards. Disponível em: < http://www.loc.gov/marc/ >. Acesso em: 06 de nov.
de 2006.
[14] McLAUGHLIN, Brett. Análise e Projeto Orientado ao Objeto. Alta Books, 2007.
[15] SOUZA, Clarice Muhlethaler de. Referência e Virtualidade.
[16] VIANA, Michelangelo Mazzardo Marques. Biblioteca Virtual.
[17] GAMMA, Erich. Design Patterns: Elements of Reusable Object-Oriented Software,
Pearson, 1995.
[18]
Struts:
Implementation.
Disponível
em:
<
http://www.oracle.com/technology/sample_code/tutorials/bc4jvsm/struts/impl.htm >. Acesso
em: 29 de maio de 2007.
[19] ALUR, Deepak. Core J2EE Patterns, Campus, 2004.
[20] Revista Mundo Java, edição 21, Frameworks Brazucas.
94
GLOSSÁRIO
Agile
Agile software development (ou simplesmente Agile) é um conjunto de metodologias
de desenvolvimento de software que vem se popularizando com a Web 2.0 e que
providencia uma estrutura conceitual para reger projetos de engenharia de software.
O principal objetivo do desenvolvimento ágil é tentar minimizar o risco pelo
desenvolvimento do software em curtos períodos, chamados de interação.
AJAX
AJAX é a abreviação para "Asynchronous Javascript and XML". O objetivo dessa
técnica é criar aplicações Web mais interativas e dinâmicas melhorando assim a
experiência do usuário. AJAX não é uma tecnologia, mas sim um termo que se refere
ao uso de um grupo de tecnologias integradas (HTML/XHTML + XML/XSLT +
CSS + DOM + Javascript + XMLHttpRequest).
Annotation
Annotation é um tipo especial de interface. Uma annotation é definida usando a
palavra reservada “interface” precedida de “@”.
API
Interface de Programação de Aplicativos (API). Uma interface de software que
permite que aplicativos se comuniquem entre si. Uma API é o conjunto de sentenças
e construções de linguagem de programação que podem ser codificadas em um
programa de aplicativo a fim de obter as funções e os serviços específicos fornecidos
por um programa de serviços ou sistema operacional básico.
ASP
Active Server Pages (ASP), da Microsoft, é uma tecnologia que visa fornecer
comportamento dinâmico a aplicativos da Web.
Back-end
Back-end é um conjunto de operações executadas pelo sistema.
Blog
Um weblog ou blog é uma página da Web cujas atualizações (chamadas posts) são
organizadas cronologicamente (como um histórico ou diário). A maioria dos blogs
são miscelâneas onde os blogueiros escrevem com total liberdade.
95
CALCO
O projeto CALCO (Catalogação Legível por Computador) foi desenvolvido pela
professora Alice Príncipe Barbosa, diretora do Serviço de Intercâmbio de
Catalogação (SIC) em meados de 1970, e representou o marco inicial dos processos
automatizados de registros bibliográficos no Brasil. O formato CALCO foi
inteiramente baseado no formato MARC II da Library of Congress por ser
considerado o formato padrão para o intercâmbio de informação bibliográfica.
CDU
A Classificação Decimal Universal (CDU) é um esquema internacional de
classificação de documentos. Baseia-se no conceito de que todo o conhecimento
pode ser dividido em 10 classes principais, e estas podem ser infinitamente divididas
numa hierarquia decimal.
CMM
Capability Maturity Model (CMM), é uma metodologia de diagnóstico e avaliação
de maturidade do desenvolvimento de softwares em uma organização.
CSS
Cascading Style Sheets, ou simplesmente CSS, é uma linguagem de estilo utilizada
para definir a apresentação de documentos escritos em uma linguagem de marcação,
como HTML ou XML. Seu principal benefício é prover a separação entre o formato
e o conteúdo de um documento.
Cutter
Tabela de Cutter é a forma mais conhecida e utilizada para simbolizar, em números,
os sobrenomes dos autores de obras. Esse código é correspondente à autoria do livro,
formado por letras e números, aparece na segunda linha dos "endereços" dos livros
nas bibliotecas.
EJB
Um EJB (Enterprise JavaBean) é um objeto remoto e não visual, projetado para ser
executado em um servidor e para ser disparado pelos clientes. Um EJB pode ser
criado a partir de vários JavaBeans não visuais. Os EJBs foram desenvolvidos para
funcionar em uma máquina e para serem disparados remotamente a partir de outra
máquina. Eles são independentes de plataforma. Depois que um bean é escrito, ele
pode ser usado em qualquer plataforma de cliente ou servidor que suporte Java.
Getting Real
Getting Real é uma metodologia que define que, em poucas palavras, o
desenvolvimento de uma aplicação Web deve ser mais rápido e eficiente e, para isso,
96
defende que o deve-se preocupar apenas com as reais necessidades da aplicação,
retirando do escopo tudo que não é essencial para o funcionamento da mesma.
Hibernate
Framework para camada de persistência.
HTML
Linguagem de Marcação de Hipertexto (HTML). A linguagem básica usada para
criar documentos de hipertexto na World Wide Web. Ela é usada em documentos de
texto ASCII básicos e sem formatação, mas, quando esses documentos são
interpretados (o que chamamos de processamento) por um navegador da Web como o
Nestcape, o documento pode exibir texto formatado, cores, várias fontes, imagens
gráficas, efeitos especiais, saltos de hipertexto para outros locais na Internet e outras
formas de informação.
IBICT
IBICT (Instituto Brasileiro de Informação em Ciência e Tecnologia), criado em
1954, é um dos responsáveis pelo desenvolvimento de sistemas de catalogação
baseados no CALCO, introduzindo pequenas modificações para atender às
necessidades de cada instituição ou das Redes de catalogação que se formavam.
ISO 2709
ISO 2709 é um formato padrão de comunicação para registros bibliográficos,
utilizado para intercâmbio de registros em meio magnético de um sistema para outro.
O formato MARC ISO-2709 torna possível a transferência de um item bibliográfico
de um sistema ou banco de dados para outro, sem perda de informações, fazendo
com que os dados sejam independentes de software e hardware, tornando os registros
bibliográficos portáveis entre sistemas.
JDBC
Java Database Connectivity é uma API focada na comunicação e manipulação do
banco de dados.
JEE
Java Enterprise Edition (JEE) é uma plataforma de programação de computadores
que faz parte da plataforma Java. Ela é voltada para aplicações multicamadas,
baseadas em componentes que são executados em um servidor de aplicações.
JSP
Java Server Pages (JSP), é uma tecnologia utilizada no desenvolvimento de
aplicações para Web. JSP é uma especialização do servlet que permite que conteúdo
dinâmico seja facilmente desenvolvido.
97
MVC
Controlador de Visão de Modelo (MVC). Uma arquitetura de aplicativos que separa
os componentes do aplicativo: o modelo representa os dados ou a lógica de negócios;
a visão representa a interface do usuário; e o controlador gerencia entrada de usuário
ou, em alguns casos, o fluxo de aplicativos.
OPAC
Online Public Access Catalog (OPAC) é um catálogo on-line do acervo de uma
biblioteca, através do qual os funcionários e o público em geral da biblioteca podem
acessar informações referentes a tal acerto, seja dentro a própria biblioteca, seja em
casa, pela Internet.
Servlet
Servlets são objetos Java executados no servidor em resposta a uma solicitação do
navegador. Eles podem chamar um JSP para produzir a saída ou gerar HTML ou
XML diretamente.
Spring
Framework Modular, que contém a parte Web, AOP, IoC, dentre outras.
SQL
Structured Query Language é uma linguagem padrão de acesso e manipulação de
dados no banco de dados.
Tag Libraries
Biblioteca de Componentes.
Web
World Wide Web (WWW ou Web site) é um serviço de Internet de multimídia
hipertextual gráfica.
Web services
Web service é uma solução utilizada na integração de sistemas e na comunicação
entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações
possam interagir com aquelas que já existem e que sistemas desenvolvidos em
plataformas diferentes sejam compatíveis. Os Web services são componentes que
permitem às aplicações enviar e receber dados em formato XML. Cada aplicação
pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o
formato XML.
Web syndication
Web syndication é uma forma de organização na qual uma seção de um Web site é
disponibilizada para o uso de outros sites.
98
Wiki
Chamado "wiki" por consenso, o software colaborativo permite a edição coletiva dos
documentos usando apenas um navegador Web e sem que o conteúdo tenha que ser
revisto antes da sua publicação.
XML
Extensible Markup Language (XML) é uma recomendação da W3C para gerar
linguagens de marcação para necessidades especiais. Seu propósito principal é a
facilidade de compartilhamento de informações através da Internet.
99
ANEXO I
CAMPOS DE UM REGISTRO MARC
Líder - Compreende entre os caracteres (00-23) de cada registro.
Posições dos campos do Líder:
• (00-04) - Comprimento do Registro Lógico.
• (05) - Situação do Registro Bibliográfico.
• (06) - Tipo de Material.
• (07) - Nível Bibliográfico.
• (08) - Tipo de controle.
• (09) – Indefinido.
• (10) - Número de Indicadores.
• (11) - Números de Códigos de Sub -Campos.
• (12-16) - Endereço dos Campos de Dados.
• (17) - Nível de Codificação.
• (18) - Forma de Catalogação Descritiva.
• (19) - Ligação de Registro.
• (20-23) - Mapa do Diretório.
Campos Variáveis de Controle
• Campo (001) – Número de Controle (NR): Este campo, que geralmente é gerado pelo
sistema, é criado pela organização que está criando, usando ou distribuindo o registro.
• Campo (003) – Identificador do Número de Controle (NR): Este campo é usado para
especificar a organização que criou o número contido no campo (001).
• Campo (005) – Data e Hora da Ultima Operação (NR): Este campo possui dezesseis
caracteres que indicam a data e tempo da ultima transação de registro. O campo segue a
formatação segundo Representação de Datas e Tempos (ISO 8601). A data requer 8 caracteres
numéricos seguindo o modelo (yyyymmdd), e o tempo requer 8 caracteres numéricos no
modelo (hhmmss.f), onde a hora deverá variar entre (00-23).
100
• Campo (006) – Características do Material Adicional (NR): este campo é formado por 16
caracteres fixos, que contém características especiais do material catalogado.
• Campo (007) – Descrição Física (NR): este é um campo fixo com 23 caracteres, que
contém informações referentes às características físicas do item.
• Campo (008) – Informações Gerais (NR): Este campo possui 40 posições de caracteres que
fornecem informações codificadas do registro como um todo assim como os aspectos
bibliográficos do item que está sendo catalogado.
Posições dos caracteres:
o (00-05) – Data de Entrada do Registro no Arquivo.
o (06) – Tipo de Data da Publicação.
o (07-10) - Data Inicial.
o (11-14) - Data Final.
o (15-17) – Lugar de Publicação.
o (18-21) – Ilustrações.
o (22) – Nível Intelectual.
o (23) - Forma do item.
o (24-27) – Tipo de Obra de Referência.
o (28) – Publicação Oficial.
o (29) – Publicação de Conferência.
o (30) – Coletânea de Homenagens.
o (31) – Índice.
o (32) – Indefinido.
o (33) - Forma Literária.
o (34) – Biografia.
o (35-37) – Idioma do Texto do Documento.
o (38) – Modificação de Grafia.
o (39) – Fonte de Catalogação
Campos Variáveis de Dados – Variam de (01X) até (8XX). São eles:
• Campo (012) – Número de CPD (NR): Este campo esta disponível para que cada
instituição possa utilizar, de acordo com suas necessidades. Dentro da Rede Bibliodata
(Formato Calco), ele é utilizado para atribuir o número de CPD antecedido da sigla da
biblioteca que envia o registro.
101
• Campo (020) – Número do ISBN (R): Este campo indica o número de ISBN do item
designado por uma agência de controle nacional.
• Campo (040) - Fonte de catalogação (NR): Este código identifica o nome ou o código da
organização que criou o registro bibliográfico original.
• Campo (041) - Código da Língua (NR): Este código é usado para identificar as línguas
associadas ao item quando o código de língua no campo (008/35-37) do registro é
insuficiente, pois o item possui mais de uma língua. Neste caso, incluem registros para itens
de vários idiomas, itens que envolvem tradução, e itens onde o meio de comunicação é uma
língua de sinal. A fonte deste código é encontrada na lista: ‘MARC Code List for Languages’.
• Campo (043) – Código da Área Geográfica (NR): Indica o código da área geográfica
associada com os assuntos do item, descrito nos campos (6XX). O código possui sete
caracteres em comprimento. A fonte deste código esta na lista: ‘MARC Code List for
Geographic Areas’.
• Campo (045) – Código Cronológico (NR): Indica o código do período de tempo associado
com os assuntos descritos nos campos (6XX) do item. O conteúdo deste campo consiste em
quatro caracteres numéricos que são determinados de acordo com a tabela própria do período
de tempo.
• Campo (080) – Número de Classificação Decimal Universal (R): Este campo identifica o
número de classificação atribuído ao documento pela Classificação Decimal Universal.
• Campo (082) – Classificação Decimal de Dewey (R): Este campo identifica o número de
classificação atribuído ao documento pela Classificação Decimal Dewey, e a edição da tabela
utilizada.
• Campo (092) – Localização Fixa da Obra (R): Indica o número de chamada da localização
fixa.
Os campos (1XX) possuem um nome ou um título uniforme utilizado como uma
entrada principal nos registros bibliográficos.
Exceto às definições de indicadores posicionados e os códigos dos subcampos que
são campos específicos, o designador de conteúdo para cada tipo de nome e títulos uniformes
é consistente para: Entrada Principal (100-130), Declaração de Série (440-490), Entrada de
Assunto (600-630), Entradas Secundárias (700-730) e Entrada Secundária de Série (800-830).
• Campo (100) – Entrada Principal – Nome Pessoal (NR): Indica o nome do autor da obra,
quando este for uma entrada principal.
102
• Campo (110) – Entrada Principal – Entidade Coletiva (NR): Neste caso, o autor da obra é
uma entidade coletiva.
• Campo (111) – Entrada Principal – Nome de Evento (NR): Quando um evento é utilizado
como uma entrada principal em um registro bibliográfico.
• Campo (130) – Entrada Principal – Título Uniforme (NR): Neste caso, um título uniforme
é utilizado como uma entrada principal em um registro.
• Campo (240) – Título Uniforme (NR): Indica o título da obra catalogada, quando existe
uma entrada para o campo (100), (110) ou (111).
• Campo (243) – Título Convencionado para Arquivamento (NR): Indica um título genérico
utilizado para colecionar trabalhos, reunir edições, traduções de uma determinada obra, ou até
para reunir séries com títulos comuns.
• Campo (245) – Declaração de Título (NR): Indicação do título principal da obra.
• Campo (250) – Declaração de Edição (NR): Indica as informações relacionadas à edição
da obra catalogada.
• Campo (260) – Publicação, Distribuição, etc (R): Indica as informações relacionadas com a
publicação, impressão, distribuição, tiragem ou produção de uma obra.
• Campo (300) – Descrição Física (R): Indica a descrição física do item, como sua extensão,
dimensão, ou qualquer outro detalhe físico, incluindo informações físicas dos materiais
acompanhantes.
Os campos (440) e (490) contêm declarações de série. O campo (440) é usado para
como uma entrada de série, enquanto que o campo (490) é usado para uma declaração de série
quando uma ou outra informação não é um dado de entrada do registro ou o dado de entrada
difere da declaração de série que aparece no item. Os campos (800-830) são utilizados em
conjunção com campo (490) quando a série é tratada diferentemente. Os parêntesis que
costumeiramente cercam uma declaração de série em alguns displays no campo (440) não são
carregados no registro MARC, e podem ser gerados pelo sistema.
• Campo (440) – Título da Série: Transcrição do título principal da série, para gerar uma
entrada secundária.
• Campo (490) – Indicação de Série: Neste caso, o título da Série não irá gerar uma entrada
secundária.
103
Os campos (500-53X) contêm notas relacionadas aos aspectos dos itens
bibliográficos que não estão especificados em qualquer outra área de controle.
• Campo (500) – Notas Gerais (R): Indicas informações descritivas do item que não são
incluídos em suas respectivas áreas, onde para cada nota deve-se repetir o campo.
• Campo (501) – Notas Iniciadas com a Palavra “com” (R): Uma nota que é utilizada quando
mais que um trabalho bibliográfico é contido em um item físico área de publicação, liberação,
questão, ou execução. Os trabalhos usualmente têm títulos distintivos e carecem de um título
coletivo.
• Campo (502) – Notas de Dissertação ou Tese (R): Indicação específica de notas para Teses
ou Dissertações.
• Campo (504) – Notas de Bibliografia (R): Indicação da presença de informações referentes
à bibliografia, apêndices ou índices no item.
• Campo (505) – Notas de Conteúdo (R): Indica notas sobre o conteúdo do item.
• Campo (506) – Notas de Acesso Restrito (R): Informação nas restrições que governam
acesso para ou a distribuição limitada dos materiais descritos.
• Campo (520) – Notas de Resumo (R): Informação não formatada que descreve o escopo ou
o conteúdo geral dos materiais. Podendo ser um resumo, uma anotação, uma revisão, ou até
uma frase descrevendo o material. O nível de detalhamento em um resumo pode variar de
acordo com o público para qual o material é produzido.
• Campo (521) – Notas do Público Alvo (R): Indica as informações referentes ao público a
que se destina a obra.
• Campo (530) – Notas de Disponibilidade da Forma Física (R): Indica as informações
referentes às formas físicas disponíveis do item descrito.
• Campo (533) – Nota de Reprodução (R): Indicam as informações descritivas de uma
reprodução original de um item, mais a parte principal do registro bibliográfico, que descreve
o item original e as informações diferem.
• Campo (534) – Notas da Versão Original (R): Indica os dados descritivos para um item
original quando a parte principal do registro bibliográfica descreve uma reprodução daquele
item e os dados diferem.
• Campo (536) – Notas de Informação de Financiamento (R): Indica que o material descrito
é o resultado de um projeto financiado.
104
• Campo (538) – Notas Requeridas pelo Sistema (R): Indica informações técnicas sobre um
item, como a presença ou ausência de códigos; ou características físicas de um arquivo de
computador, como densidades de gravação, paridade, modo de acesso, língua programada,
periféricos, nome ou sistema de gravação comercializado, número de linhas de resolução,
freqüência de modulação, e etc. Para sons e videocassetes, informações sobre o nome
comercializado ou o sistema de gravação, freqüência de modulação ou o número de linhas de
resolução podem ser incluídos.
• Campo (546) – Nota do Idioma (R): Indica o idioma do texto dos materiais descritos.
• Campo (590) – Notas Locais (R): Indica as informações relativas à situação do item na
instituição.
• Campo (595) – Notas para Inclusão em Bibliografias (R): Refere-se às informações que
indicam que a bibliografia do documento deverá aparecer de acordo com tabelas de códigos já
incluídas nos respectivos subcampos.
Os campos (600-65X), com a exceção do campo (653) que é utilizado para termos de
índice descontrolados, contêm os assuntos ou possui termos que fornecem informações
adicionais do registro catalogado através do título que é construído segundo o assunto
catalogando. A lista padronizada ou autoridade utilizada é identificada pelo valor no segundo
indicador posicionado ou pelo código contido no subcampo ($2).
• Campo (600) – Assunto – Nome Pessoal (R): Gera uma entrada de assunto em que o item é
um nome pessoal.
• Campo (610) – Assunto – Entidade Coletiva (R): Neste caso, o elemento de entrada de
assunto é uma Entidade Coletiva.
• Campo (611) – Assunto – Nome de Evento (R): A entrada de assunto é o Nome do Evento.
• Campo (630) – Assunto – Título Uniforme (R): A entrada de assunto é um Título
Uniforme.
• Campo (650) – Assunto – Tópico (R): Neste caso, a entrada de assunto é um Tópico Geral.
• Campo (651) – Assunto – Nome Geográfico (R): A entrada de assunto é um Nome
Geográfico.
Os campos (7XX) contêm entradas de dados do registro bibliográfico que não são
fornecidas nas entradas dos campos: entrada principal (1XX), assunto (6XX), declaração de
série (4XX), entrada secundária de série (8XX), ou nos campos de título (20X-24X).
105
• Campo (700) – Entrada Secundária – Nome Pessoal (R): Indica a entrada secundária para
nomes pessoais que não tenham sido adotadas como entrada principal, como: coautores,
colaboradores, ilustradores, coordenadores, compiladores, pessoas relacionadas com a obra
em geral.
• Campo (710) – Entrada Secundária – Entidade Coletiva (R): Indica entrada secundária de
uma entidade coletiva.
• Campo (711) – Entrada Secundária – Evento (R): Indica entrada secundária de um evento.
• Campo (730) – Entrada Secundária – Título Uniforme (R): Indica neste campo o título
uniforme que não tenha sido adotado como entrada principal ou de assunto.
• Campo (740) – Entrada Secundária – Título Adicional ou Título Analítico (R): Neste
campo é indicado o título adicional diferente do que é registrado no campo (245).
• Campo (773) – Obra Principal (R): Indicação de Obra Principal.
• Campo (830) – Entrada Secundária de Série (R): Indica o título de série para qual deve ser
gerada uma entrada secundária com forma diferente daquela registrada na descrição
bibliográfica no campo (440). O preenchimento deste campo está relacionado com o campo
(490), onde o primeiro indicador será (1).
• Campo (852) – Sigla do Acervo (R): Identifica a organização na qual o item está
disponível. Este campo detalha informações sobre como localizar o item em uma coleção.
• Campo (856) – Localização de Recurso Eletrônico (R): Indica uma informação necessária
para localizar e acessar um recurso eletrônico.
Os campos (9XX) possuem a particularidade de não serem predefinidos pelo MARC,
podendo ser definidos por cada instituição. Apesar do MARC ser muito detalhista podendo
catalogar quase todo tipo de informação, esses campos são usados numa eventual necessidade
em que o MARC não atenda da melhor forma possível.
106
ANEXO II
EXEMPLO DE REGISTRO NO FORMATO MARC