Modelo de Estilo para Artigo Científico - NPDI

Disponibilizando e Preservando o Acervo sobre Conservação e
Restauração de Bens Culturais Móveis do CECOR
FLÁVIO HUMBERTO CABRAL NUNES1
LUIZ ANTÔNIO CRUZ SOUZA 2
ARNALDO ALBUQUERQUE ARAÚJO 1
MARCELO ALBUQUERQUE CORREA 2
1
UFMG – Universidade Federal de Minas Gerais
DCC – Departamento de Ciência da Computação
NPDI – Núcleo de Processamento Digital de Imagens
Cx. Postal 702 – CEP 30.161-970 Belo Horizonte (MG)
{fhcnunes,arnaldo}@dcc.ufmg.br
2
UFMG – Universidade Federal de Minas Gerais
EBA – Escola de Belas Artes
CECOR – Centro de Conservação e Restauração de Bens Culturais Móveis
CEP 31.270-901 Belo Horizonte (MG)
[email protected], [email protected]
Resumo: Este trabalho descreve o processo de modelagem e implementação de um sistema de
cadastro e recuperação de informação multimídia para o CECOR – Centro de Conservação e
Restauração de Bens Culturais Móveis. O sistema contém informações sobre obras restauradas, seus
materiais e técnicas, imagens geradas por métodos de análises, resultados de análises científicas, etc.
Este trabalho também discute a metodologia de digitalização do acervo adotada que visou resguardá-lo
de possíveis degradações causadas pela sua manipulação direta. O sistema também armazena
informações sobre clientes, pagamentos e o estado atual do processo de restauração da obra.
Palavras Chaves: Restauração, conservação, multimídia, banco, dados, Internet, digitalização,
acervo.
1 Introdução
O CECOR – Centro de Conservação e Restauração de Bens Culturais Móveis – é um órgão vinculado à Escola de
Belas Artes (EBA) da Universidade Federal de Minas Gerais (UFMG). A instituição desenvolve pesquisas, estudos e
trabalhos em pintura de cavalete, escultura policromada e obras sobre papel, além de atuar no ensino, na pesquisa, na
preservação do patrimônio e conseqüentemente na formação de especialistas em Conservação/Restauração. A
instituição restaura peças de instituições públicas e particulares, inclusive pessoas físicas. Muitas obras são
atribuídas a artistas famosos, como Cândido Portinari, Guignard, Aleijadinho, Di Cavalcanti, entre outros.
Paralelamente aos trabalhos de restauração das obras, ocorre o processo de documentação. Além do processo de
restauração, também são documentadas informações administrativas relativas aos custos do trabalho e informações
geradas pelo Laboratório de Ciência da Conservação (LACICOR), localizado no CECOR, como análises físicoquímicas. O processo de documentação gera documentos na forma de textos, fotografias, slides, etc. Desde 1978, a
instituição vem mantendo este acervo que se constitui em uma importantíssima fonte de pesquisa para profissionais
da área como historiadores da arte, conservadores, cientistas, etc.
O modelo de gerenciamento do acervo que era utilizado possuía vários problemas. Até recentemente, toda a
informação somente podia ser recuperada através de uma busca manual nos arquivos do CECOR. O registro das
obras também era feito manualmente. Além de ser um trabalho cansativo e monótono, o restaurador perdia muito
tempo com esse processo que poderia ser usado em outras tarefas mais importantes. Outro problema é a preservação
dos documentos originais. Como a busca era feita manualmente, muitos documentos acabavam sendo manipulados
sem necessidade. Com o tempo, começavam a aparecer nos documentos degradações originadas desta manipulação
excessiva e desnecessária. Também havia o desejo de tornar as informações deste acervo acessíveis a pesquisadores
externos ao CECOR e ao público em geral. No antigo modelo somente os funcionários e professores do CECOR
tinham acesso a essas informações. Qualquer pessoa que quisesse ter esse acesso, tinha que se dirigir até a instituição
e pedir às pessoas autorizadas pelas informações que ela necessitava.
O objetivo do sistema aqui apresentado é disponibilizar as informações do acervo existente no CECOR de forma
ampla, ágil e simples através do uso do computador. Em [Burnstock 2002] são citados mais quatro objetivos para o
projeto de um banco de dados para armazenar informações sobre conservação de bens culturais móveis:
•
Incorporar efetivamente dados históricos e técnicos.
•
Estabelecer uma abordagem balanceada para a entrada de dados.
•
Permitir que uma grande variedade de usuários com várias habilidades técnicas utilizem o banco de dados.
• Fornecer uma grande variedade de consultas para uma variedade de usuários.
Alguns trabalhos interessantes têm sido feitos, utilizando ferramentas da computação para produzir sistemas que
auxiliem no acesso e documentação de acervos. Alguns deles, como o Projeto Joaquim Nabuco
[www.ufpe.di.br/nabuco] e o Projeto Portinari [www.portinari.org.br], encontram-se disponíveis na Internet. Outro
exemplo é o sistema que está sendo implantado no Arquivo Público Mineiro (APM), em Belo Horizonte, para
disponibilizar o acervo da instituição para o público em geral. Há também projetos internacionais como o Sistema
Narcisse (Network of Art Research Computer Image SystemS in Europe), em Paris, que armazena informações sobre
pinturas de cavalete do laboratoire de Recherche et de Restauration des Musées de France. Estes exemplos mostram
a preocupação existente em documentar e disponibilizar o patrimônio público e foram um fator a mais de motivação
ao desenvolvimento deste trabalho.
2 A Organização e o Acesso à Base de Dados
Uma das metas deste trabalho foi automatizar todo o trabalho de consulta, manipulação e organização de toda a
informação contida no acervo do CECOR. Com essa meta alcançada, o restaurador passou a ter mais tempo para se
dedicar aos trabalhos de restauração, pois o todo processo de documentação e acesso passou a ser feito pelo
computador.
O uso de ferramentas de banco de dados permitiu se alcançar essa meta, pois possibilitou tornar a recuperação e
o armazenamento dos dados do acervo mais eficiente, sendo a finalidade de um sistema de banco de dados
simplificar e facilitar o acesso aos dados [Silberschatz 1999]. A utilização de um sistema gerenciador de banco de
dados (SGBD) possui várias vantagens. Ele faz o controle de redundância, impedindo que uma atualização simples
seja feita múltiplas vezes, evitando o desperdício de espaço e a inconsistência de dados. O SGBD também fornece
múltiplas interfaces de usuários, armazenamento permanente para objetos de programa e estruturas de dados e
suporte a múltiplas visões, onde o usuário tem acesso somente à parte do banco de dados de seu interesse [Elmasri
2000].
Esta abordagem também permitiu uma economia de papel e espaço nas instalações do CECOR. Inicialmente,
toda a informação gerada na instituição era armazenada em arquivos de aço que ocupavam muito espaço físico na
instituição. Com a implantação deste sistema, todos os dados ficam guardados dentro de um computador que ocupa
muito menos espaço físico do que os armários. E como eles estão guardados dentro de discos rígidos, há uma
drástica redução de uso de papel.
Para disponibilizar as informações existentes no CECOR para um público maior, é preciso utilizar um meio que
permita alcançar esse objetivo. Devido a sua grande difusão, a Internet é considerada um meio ideal para a
divulgação de conhecimento e para a democratização do acesso à informação [Andrade 2000]. A Internet, rede
mundial de computadores, trouxe a possibilidade de acessar e manipular informação situada em locais de todo o
mundo utilizando-se microcomputadores com poucos recursos adicionais de hardware e software [Filho 2000]. Com
todas essas características, a Web foi eleita como o melhor meio de disponibilizar o acervo do CECOR para o maior
número de pessoas possível.
Mas essa informação não pode ser disponibilizada sem nenhum controle. Aspectos como os direitos autorais e
de propriedade precisam ser considerados, pois as obras restauradas no CECOR pertencem a terceiros. Qualquer tipo
de uso da imagem das obras que for feito precisa do consentimento de seus proprietários. Para isso é necessário
implantar uma política de acesso que atenda a esse requisito. Ainda não se chegou a um consenso sobre essa política
de acesso. Por enquanto, a segurança de acesso ao sítio está a cargo do sistema operacional, no caso Windows 2000.
Uma possível solução seria a divisão das obras em dois grupos: obras com acesso externo e interno e obras com
apenas acesso interno do CECOR. Também se criariam os grupos de usuários, interno e externo, tendo a
preocupação de definir se o usuário poderá acessar o sistema como um todo ou se apenas uma parte dele. Usuários
externos poderiam somente visualizar as informações e os usuários internos, além da visualização, também poderiam
atualizar o banco de dados.
3 O Acervo do CECOR
O acervo do CECOR engloba, além das fichas com informação textual, slides, fotografias, radiografias, fitas cassete,
cadernos técnicos com dados de amostras e análises e VHS e negativos. A Figura 1 apresenta uma amostra do acervo
existente no CECOR. Nela pode ser visto o modelo externo das pastas onde estão armazenados os formulários com
as informações sobre o processo de restauração, fotografias que também são guardadas dentro das pastas, slides e
radiografias.
Figura 1: Uma pequena amostra dos tipos de documentos existentes no CECOR.
O manuseio direto e constante dos documentos, normalmente frágeis e únicos, seja por pesquisadores ou pelo
público em geral acelera seu processo de degradação [Andrade 2001]. A preservação de documentos é usualmente
uma tarefa difícil, porque a fragilidade dos artefatos impõe um trafe-off entre sua conservação e sua disponibilidade.
A solução proposta neste trabalho para este trade-off foi digitalizar o acervo. A Figura 2 ilustra um exemplo de
degradação que o acervo vem sofrendo. Neste exemplo é apresentada uma fotografia de uma pintura bastante
amarelada.
Figura 2: Exemplo de uma fotografia bastante deteriorada (amarelamento).
Este trabalho somente está digitalizando a documentação visual (fotografias) das obras restauradas e analisadas
durante todo o trabalho realizado a partir do ano de 1977. São ao todo 13644 fotografias divididas entre 1137 fichas,
o que dá uma média de 12 fotografias por pasta. Deste conjunto, estão sendo excluídas as fotografias repetidas que
por acaso apareçam. As fotos selecionadas são relevantes ao processo de estudo e restauro das obras em suas várias
etapas.
4 A Metodologia de Digitalização do Acervo
A tecnologia digital vem sendo apontada como uma alternativa de disponibilizar obras e documentos para o público
interessado, mantendo a integridade física e intelectual dos artefatos. A digitalização é uma poderosa aliada
principalmente para bibliotecas, instituições e museus onde existe o problema de se dispor obras e documentos
originais para consulta devido à degradação sofrida pelo seu manuseio. A digitalização do acervo possui muitas
vantagens. Os usuários passam a manipular as cópias digitais dos documentos, resguardando-os do manuseio
constante e desnecessário. Os dados digitais são imunes à deterioração causada pela manipulação do usuário.
Também podem ser apresentados documentos de melhor qualidade aos usuários ou realçar aspectos interessantes dos
mesmos com a utilização de técnicas de processamento digital de imagens (PDI), como controle de brilho, contraste
e realce de bordas, sem alterar o documento digitalizado original [Andrade 2000]. Outras vantagens do uso de
imagens digitais são apresentadas em [AcIS 1997], como:
•
Enquanto os originais podem se deteriorar, as imagens digitais não sofrem deterioração física e química com
o passar do tempo.
•
Permitem reprodução idêntica da qualidade de cópia para cópia e de geração para geração.
•
Podem ser manipuladas mais facilmente que imagens fotográficas.
• O acesso é melhorado enormemente, utilizando a Internet.
Entretanto, arquivos digitais são incrivelmente vulneráveis, não somente pela fragilidade da mídia, mas também
pela rápida evolução da tecnologia. Freqüentemente, arquivos antigos em poucos anos não podem ser lidos porque o
hardware e o software necessários para interpretar os dados se perderam [Valle Jr. 2000].
Devido a esses problemas, é imprescindível que se adote uma metodologia de digitalização que minimize os seus
efeitos. Além disso, o próprio processo de digitalização envolve manipulação dos documentos originais. Então, é
necessário que a metodologia também evite a manipulação dos documentos ao máximo.
A metodologia adotada se baseia na geração de cópias matrizes a partir dos documentos originais. Destas
matrizes originam todas as outras imagens para os mais diferentes usos, como impressão e visualização na Web.
Quando o material original é passivo de perigo de deterioração e perda, o original convertido adquire o status de
uma matriz, em um caso extremo, ela servirá como um substituto para o original perdido. Devido a isso, é necessário
que as matrizes possuam as melhores qualidade e resolução possível.
A seleção da resolução ótima começa com a determinação do que é o menor elemento significativo que deve ser
legível no produto final. É muito mais difícil determinar qual é o menor elemento significativo em uma fotografia ou
figura. Em parte, depende de quem usará a imagem digitalizada e de que maneira. Uma pessoa não especialista pode
olhar a fotografia de uma paisagem casualmente, enquanto uma especialista pode ser capaz de distinguir a
estratigrafia de amostras retiradas das obras. É importante notar que quanto maior a resolução, maior é o tamanho do
arquivo [AcIs 1997].
Neste trabalho, as imagens matrizes estão sendo digitalizadas com a resolução de 600 dpi (dot per inch) que já
gera imagens de boa qualidade. Outra característica das matrizes é que elas não podem possuir nenhum tipo de
tratamento digital de imagens ou compressão, sendo extremamente fiéis ao original. O formato rescolhido para os
arquivos matrizes foi o Tagged Image File Format (TIFF).
A aplicação desenvolvida disponibiliza todo o seu conteúdo pela Internet. Como os documentos são
digitalizados em uma resolução muita alta, as matrizes geradas possuem um tamanho muito grande, sendo da ordem
de dezenas de megabytes. Por isso, a visualização destas matrizes na Internet torna-se inviável. Então, a partir das
matrizes, são produzidas imagens menores para viabilizar o seu uso na Web. Para que isso seja possível, é necessário
que haja algum tipo de compressão para se alcançar esse resultado. Essas imagens, chamadas de imagens de acesso,
também podem sofrer algum tipo de tratamento digital de imagens para melhorar a qualidade dos documentos que
estarão disponíveis aos usuários. O formato escolhido para as imagens de acesso foi o Joint Photographic Experts
Group (JPEG). A sua compressão elimina dados imperceptíveis para o olho humano, reduzindo o tamanho do
arquivo; conseqüentemente não deve ser usado como o arquivo matriz do documento original. A Figura 3 ilustra o
uso mais comum das imagens neste sistema. Trata-se do formulário de Identificação da Obra onde são exibidos
todos os dados bibliográficos e gerais da obra com a visualização da respectiva obra.
Figura 3: Visualização das imagens no sistema.
5 As Tecnologias Utilizadas
Um dos pré-requisitos do sistema é que ele deve executar em uma plataforma Windows2000 e no servidor Web
Internet Information Service 5 (IIS 5). Como a plataforma alvo é Microsoft, foi interessante adotar tecnologia da
própria Microsoft. Seguindo esta linha, as tecnologias escolhidas foram Active Server Pages (ASP) e ActiveX Data
Objects (ADO). Os scripts ASP podem ser programados utilizando uma das seguintes linguagens: VBScript,
JavaScript, ou PerlScript [Jones 2001]. Definiu-se que VBScript seria a linguagem no servidor e JavaScript seria a
linguagem no cliente.
Na hora da escolha do SGBD, optou-se por um software livre. O custo foi fator decisivo na escolha e o SGBD
selecionado foi o MySQL. Mas o custo não é a única vantagem do MySQL. Segundo [Drummond 2001], a instalação
do produto é muito simples a partir dos pacotes binários, a administração é simples e fácil, existe um manual de
referência completo e atualizado disponível no sítio [www.mysql.com]. O MySQL aceita programação em C, Perl,
Java (via Java DataBase Connectivity – JDBC) e Phyton, assim como PHP e, principalmente, linguagens via Object
DataBase Connectivity (ODBC) que foram as linguagens utilizadas neste trabalho. A eficiência é outro ponto forte.
Entretanto, a eficiência do MySQL não é alcançada sem sacrifícios. Ele possui várias limitações para permitir a
sua rapidez de resposta. No entanto, tais limitações não representam um empecilho à utilização do produto, pois elas
podem ser eliminadas via programação. Por exemplo, o MySQL não possui suporte a transações. Isso não representa
um problema, pois ASP possui funções que permitem ao programador implementar tais funcionalidades. Outro
recurso que ainda não está disponível no MySQL é a subseleção. Esta permite basear uma consulta nos resultados de
outra consulta. Esse problema pode ser contornado através da inclusão de mais junções múltiplas dentro de uma
única consulta [Maslakowski, 2000]. Outra limitação é a não implementação da integridade referencial, mas o
programador pode construir um código que verifique se ela está sendo violada em algum lugar, solucionando este
problema.
6 A Construção do Sistema
6.1 Introdução
Inicialmente, foi necessário realizar pesquisas e entrevistas junto aos potenciais usuários do sistema para poder
entender e documentar os requisitos da aplicação. Esses usuários compreenderam restauradores, professores,
funcionários e o pessoal técnico do Laboratório de Ciência da Conservação (LACICOR). A forma utilizada para
identificar os requisitos do sistema foi entender as etapas do processo de restauração seguidas por uma peça, desde
sua chegada ao CECOR até a sua devolução ao proprietário. Através deste estudo pode-se identificar os dados que
seriam de armazenamento persistente e as principais funcionalidades que a aplicação deveria apresentar. O processo
de restauração ocorre basicamente em três ambientes que foram divididos da seguinte forma:
•
Restauração – É o processo de restauração propriamente dito e ocorre nos ateliês do CECOR.
•
Orçamento – Representa o trabalho feito na secretaria da instituição e compreende informações sobre os
custos dos trabalhos de restauração.
•
Laboratório – Compreende os processo de análise físicos e físico-químicos a que são submetidas as amostras
retiradas das obras em restauração realizados no LACICOR.
As próximas subseções descrevem os processos de modelagem e implementação da base de dados, do sítio e das
interfaces.
6.2 Modelagem e Implementação da Base de Dados
A modelagem da estrutura da base de dados utilizou o modelo de dados Entidade-Relacionamento (E-R). Este
modelo descreve os dados como um conjunto de entidades, relacionamentos e atributos [Elmasri 2000]. A notação
utilizada segue a notação descrita em [Elmasri 2000]. A Figura 4 ilustra o diagrama E-R simplificado da estrutura da
base de dados. Os retângulos representam as entidades e os losangos representam os relacionamentos. Note que o
diagrama apresenta a divisão em Orçamento, Restauração e Laboratório bem definida.
Figura 4: Diagrama E-R simplificado do banco de dados.
A próxima etapa foi implementar a estrutura do banco de dados utilizando um SGBD relacional. Para isso foi
necessário traduzir o modelo E-R para o modelo relacional. O modelo relacional representa o banco de dados como
uma coleção de tabelas ou relações, onde as linhas ou tuplas representam as entidades e relacionamentos e as colunas
ou atributos são do mesmo tipo de dados chamado domínio. Essa tradução seguiu mapeamento proposto em [Elmasri
2000]. Neste mapeamento, para cada entidade existente no diagrama E-R é criada uma tabela no modelo relacional
incluindo todos os atributos simples. Para relacionamentos com cardinalidade 1:N, inclui-se uma chave estrangeira
na entidade do lado-N do relacionamento que represente a outra entidade participante. Em relacionamentos com
cardinalidade M:N, cria-se uma tabela incluindo as chaves estrangeiras que representem as duas entidades
participantes no relacionamento. Os atributos compostos se transformam em um conjunto de atributos simples e para
os atributos multivalorados é criada uma tabela com a chave estrangeira da entidade pertencente.
O diagrama E-R da base de dados completo possui ao todo 15 entidades. Após a tradução, o modelo relacional
apresentou 19 tabelas. Esse número de tabelas pode ser explicado por quatro motivos. Primeiro, pelo próprio
processo de tradução onde uma entidade é transformada em tabela, gerando 15 tabelas.
Segundo, o diagrama E-R possui um relacionamento com cardinalidade N:M e, segundo o processo sugerido, o
relacionamento é convertido em uma tabela contendo as chaves estrangeiras de ambas as entidades participantes no
relacionamento. Neste caso, mais uma tabela foi criada.
Outro motivo foi economia de espaço. Quando as obras dão entrada no CECOR, nem todas são restauradas. A
entidade OBRA possuía muitos atributos que diziam respeito apenas a obras que passam pelo processo de
restauração. Com isso, a tabela OBRA possuía muitos atributos que não eram preenchidos, ocasionando um grande
desperdício de espaço. Devido a isso, se optou por dividir a tabela OBRA em duas: OBRA e RESTAURACAO.
Assim, a tabela RESTAURACAO somente é preenchida quando a obra entra em processo de restauração.
Finalmente, por questões de implementação, gerando mais duas tabelas. Essas tabelas não têm ligação direta
com o modelo E-R. Toda obra que entra no CECOR para ser restaurada recebe um número de entrada provisório.
Este número apresenta a característica de ser seqüencial, voltando a ter o valor 1 todo início de ano. Havia duas
possibilidades para solucionar este problema: utilizar uma variável global do sistema para armazenar o valor do
número provisório ou guardava-se o valor em arquivo. A primeira alternativa possuía o inconveniente de se perder
toda vez que o computador fosse desligado, enquanto a segunda alternativa se mantinha intacta. Então, optou-se por
armazenar o número provisório no próprio banco de dados, como uma tabela. Nesta tabela, também foi armazenado
o ano atual para que, em uma comparação, o sistema soubesse que o ano mudou e que o número provisório deveria
voltar a ter o valor 1 e não ser incrementado de um. A outra tabela armazenou todas etapas de restauração que uma
obra poderia sofrer. Existiam as alternativas de armazenar o as etapas no próprio código do sistema ou no banco de
dados. A primeira alternativa foi abandonada porque representava um fator de complexidade desnecessário muito
alto para o sistema e também porque a segunda alternativa era mais atraente para o caso de novas etapas serem
inseridas no sistema. A Figura 5 mostra o resultado final do processo de conversão do modelo E-R para o modelo
relacional implementado no Microsoft-Access para efeito de ilustração. Nela podem ser vistas as tabelas geradas no
processo de tradução.
Figura 5: Modelo relacional da base de dados.
Outro problema encontrado no processo de tradução foi definir uma chave primária para a tabela OBRA. No
CECOR, quando uma obra dá entrada, ela recebe um número provisório. Se a proposta de orçamento para a sua
restauração for aprovada, ela recebe um número de registro definitivo, que é diferente do número provisório. O uso
do número provisório como chave primária parece óbvio, mas existem casos excepcionais onde a obra recebe um
número de registro definitivo e não possui número provisório. A solução encontrada foi definir como chave primária
um atributo código, incrementado automaticamente pelo SGBD (chamado de AUTO_INCREMENT no MySQL),
transparente ao usuário.
Uma decisão de implementação importante foi o não armazenamento das imagens no banco de dados. Ao invés
disso, optou-se por armazenar somente o nome do arquivo correspondente à respectiva imagem. Esta decisão
simplificou a manipulação das imagens por parte do sistema.
6.3 O Processo de Desenvolvimento
O processo de Engenharia de Software adotado neste trabalho foi o PRAXIS que significa Processo para Aplicativos
eXtensíveis InterativoS, refletindo uma ênfase no desenvolvimento de aplicativos gráficos interativos, baseados na
tecnologia orientada a objetos. O PRAXIS é desenhado para suportar projetos de seis meses a um ano de duração,
realizado individualmente ou por pequenas equipes. A UML é a notação de modelagem utilizada no PRAXIS, em
todos os níveis em que for aplicável. O PRAXIS se baseia no modelo de Entrega Evolutiva. Este modelo permite
que, em pontos bem definidos, os usuários possam avaliar partes do produto e fornecer realimentação quanto às
decisões de cada projeto, tanto por parte de seus gerentes como dos clientes [Filho 2001].
O PRAXIS é dividido em quatro fases: Concepção, Elaboração, Construção e Transição. A fase de concepção
englobou o estudo e análise das necessidades do pessoal do CECOR e dos conceitos da aplicação o suficiente
justificando a necessidade da produção do software.
Na fase de elaboração, o produto é detalhado de forma a poder modelar conceitualmente o domínio do problema,
validando requisitos desse modelo conceitual e criando uma base para o planejamento acurado da fase de
construção. Inicialmente, foi feito um levantamento dos requisitos que visou capturar as necessidades dos usuários
em relação ao software a ser desenvolvido. Neste levantamento, foi feito um estudo de como é executado o processo
de restauração pela instituição. A definição dos requisitos consistiu da identificação das funcionalidades do sistema e
dos usuários que irão interagir com a aplicação. As principais funcionalidades identificadas foram o cadastro e
consulta de dados referentes a informações bibliográficas, estado de conservação e dados do processo de restauração
das obras, orçamentos e pagamentos, amostras, camadas e análises. A aplicação também geraria recibos de entrada e
devolução de obras, relatórios de análises e amostras e propostas de orçamento e a inclusão, armazenamento e
exibição de imagens geradas durante os trabalhos dentro da instituição.
Foram identificados quatro perfis de usuários: restaurador, secretário, técnico e pesquisador. O restaurador é o
usuário encarregado de incluir, modificar e consultar os dados relativos à bibliografia e informações sobre a
restauração das peças e emissão dos recibos de entrada e devolução das peças. O secretário é o usuário que inclui,
altera e pesquisa dados sobre orçamentos e pagamentos e gera o documento da proposta de orçamento. O técnico
possui a responsabilidade de inserir, modificar, pesquisar e gerar relatórios sobre todas os dados gerados pelo
LACICOR. O pesquisador é um usuário que tem permissão apenas de pesquisar informações sobre o processo de
restauração e amostras, camadas e análises feitas no laboratório. Este usuário não tem direito de acessar informações
de orçamentos feitos na instituição.
Na fase de construção, foi desenhada, implementada e testada uma versão completamente operacional do
produto, atendendo aos requisitos especificados. A arquitetura do sistema foi dividida em três pacotes lógicos.
Pacotes lógicos são grupos de classes e outros elementos de modelagem que apresentam fortes relacionamentos entre
si (alta coesão interna) e poucos relacionamentos com elementos de outros pacotes lógicos (baixo acoplamento
externo) [Filho 2001]. Os pacotes lógicos identificados foram: restauração, orçamento e laboratório, que representam
os três ambientes de trabalho do CECOR. Estes três pacotes lógicos serviram de referência para a construção das três
liberações que a abordagem de desenho permitiu. Liberações são versões operacionais parciais que servem como
pontos de controle, permitindo a avaliação por parte dos usuários. A restauração foi a primeira liberação e consistiu
no desenho e na implementação dos formulários de cadastro e consulta de obras e seus dados de restauração, recibos
de entrada e devolução de peças e inclusão de imagens do processo de restauração. A segunda liberação foi o
orçamento e englobou o desenho e a implementação dos formulários de cadastro e consulta de orçamentos e
pagamentos e da emissão da proposta de orçamento. O laboratório foi a última liberação e consistiu no desenho e na
implementação dos formulários de cadastro e consulta de amostras, camadas e análises, emissão de relatórios de
camadas e amostras e inclusão de imagens geradas pelo LACICOR.
Durante o desenho e a implementação do sítio Web, decidiu-se dividir sua estrutura nos três ambientes do
processo de trabalho. Procurou-se tornar a navegabilidade do sistema o mais semelhante possível do processo de
trabalho que era efetuado no CECOR. A navegação entre ambientes somente é permitida através da página inicial do
sítio. A Figura 6 ilustra a estrutura simplificada do sítio Web, mostrando que a navegação entre ambientes é indireta
sendo a página inicial a ponte desta ligação.
Figura 6: Estrutura simplificada do sítio.
Uma das funcionalidades incorporadas ao sistema foi a possibilidade dos usuários enviarem as imagens por um
formulário Web. Estes formulários permitiram que os usuários pudessem incluir no sistema as imagens geradas. Os
exemplos de código ASP para upload de arquivos encontrados se mostraram bastante complicados e não possuíam
documentação. A solução encontrada foi utilizar um componente gratuito que permitisse, com um código simples, a
implementação dos formulários. O componente utilizado, chamado Dundas Upload, está disponível na Internet, no
sítio {www.dundas.com]. Este sítio também possui uma boa documentação a respeito deste componente. Estes
formulários permitiram aos usuários incluir as imagens na base de dados a partir qualquer computador ligado à
Internet. A Figura 7 mostra um formulário com uma imagem que foi inserida pelo formulário implementado
utilizando o componente Dundas Upload. Esta imagem ao ser clicada leva o usuário a uma outra tela que mostra
todas imagens que foram inseridas para aquela obra e é ilustrada na Figura 8.
Figura 7: Formulário de Cadastro e Identificação da Peça com a exibição da imagem da obra.
Figura 8: Tela mostrando as imagens do processo de restauração de uma obra.
A linguagem JavaScript foi utilizada para realizar a validação dos dados dos formulários no próprio cliente. Essa
abordagem permitiu que parte do processamento fosse transferido para o cliente, liberando o servidor para receber
novas requisições de outros usuários.
Na fase de transição, o produto é colocado à disposição de uma comunidade de usuários para testes finais,
treinamento e uso inicial. A aplicação já se encontra na fase de uso inicial. Durante os testes com os usuários e o
treinamento, notou-se que os usuários iam aumentando a produtividade assim que eles iam ganhando mais
experiência com o produto. Isso se mostrou satisfatório, pois mostrou que o sistema se mostrou de fácil aprendizado.
6.4
Desenho de Interfaces e Usabilidade
A interface de usuário está se tornando uma parte crítica do sistema interativo inteiro e o desenvolvimento da
interface de usuário é uma parte integral do processo de Engenharia de Software global. A usabilidade é uma
combinação das seguintes características orientadas ao usuário: facilidade de uso, alta produtividade do usuário,
baixa taxa de erros, satisfação do usuário e retenção ao longo do tempo. A usabilidade está relacionada com
efetividade e eficiência da interface de usuário e com a reação dos usuários com aquela interface. A naturalidade da
interface para o usuário é também um importante aspecto de usabilidade [Hix 1993].
O desenho das interfaces tomou como base os formulários utilizados pelo pessoal do CECOR. Durante o
desenho das interfaces, definiu-se um formato padrão para as interfaces dos formulários. Essa padronização traz
vários benefícios aos usuários, como redução de erros, aumento da confiança e da eficiência, e redução da resistência
à nova tecnologia. A padronização da interface também trouxe benefícios para o desenvolvedor, como minimização
da reinvenção, diminuição do tempo de desenvolvimento, possibilidade de re-uso [Hix 1993]. Na Figura 9, a
estrutura deste formato para as interfaces da aplicação pode ser vista. A primeira parte, chamada INSTITUIÇÕES,
apresenta os logotipos do CECOR e da Universidade Federal de Minas Gerais (UFMG). Este era um padrão que
existia nos formulários em papel e foi desejo dos usuários de que esse padrão continuasse. A segunda parte,
chamada de LINKS DE NAVEGAÇÃO, exibe links de navegação que levam os usuários às páginas iniciais de cada
ambiente e à formulários de mesmo significado, isto é, manipulam os mesmos tipos de dados, mas que provocam
ações diferentes. A parte TÍTULO DO FORMULÁRIO indica ao usuário o tipo de formulário que ele está
trabalhando. Os LINKS DE AÇÃO servem para gerar recibos, relatórios e exibir informações mais específicas a
respeito dos dados que estão sendo informados na tela, como as análises e estratigrafias de uma amostra. Os
estrutura BOTÕES DE AÇÃO exibem os botões que desempenham ações sobre os dados do formulário, como
inclusões, atualizações e consultas. O campo FORMULÁRIO exibe o formulário com seus campos de acordo com
os tipos de dados que estão sendo trabalhados pelos usuários.
Figura 9: Estrutura padrão das interfaces do sistema.
A taxa de erros é um fator importante no uso de interfaces pelos usuários. Esses erros podem deixar a base de
dados inconsistente ou mesmo causar a perda de dados valiosos. É interessante que a interface trate esses erros
impedindo a ocorrência desses problemas. Entretanto, uma interface que evite que esses erros aconteçam é mais
atraente. Um dos problemas encontrados foi o formato do número provisório e registro. Durante o período de
levantamento, descobriram-se vários formatos para esses números. Alguns possuíam hífens separando o número de
entrada do ano. As letras colocadas no final para identificar a natureza da obra eram ou não separadas por hífen do
resto do número. Foram utilizadas duas soluções para estes problemas. A Figura 10 mostra a solução adotada para o
número provisório. Nela é mostrada a tela de entrada da obra que é utilizada quando uma obra dá entrada no
CECOR. O número provisório é formado pelo seu número de entrada de obras em um dado ano (na Figura 10 o
número é 51), pelo ano em questão (representado pelo número 02 na Figura 10) e por uma letra de identificação que
indica a natureza da obra (por exemplo, P significa particular). O número de entrada e o ano são separados por hífen.
Como este número é gerado automaticamente pelo sistema, ele é exibido de forma que o usuário não consiga alterálo, evitando a entrada de um formato incorreto pelo usuário. Somente o campo da letra de identificação pode ser
alterado pelo usuário por ser um campo opcional. Neste campo poderia ter sido utilizado um cardápio de opção com
as possíveis letras de identificação para minimizar a ocorrência de erros. Mas não se chegou a um consenso de um
padrão, então este campo foi deixado em aberto, mas com limite máximo de dois caracteres que é o utilizado neste
número.
Figura 10: Tela de entrada da obra.
A Figura 11 ilustra a solução para o número de registro. Esta solução é um pouco diferente. Nela, optou-se por
utilizar três campos de texto. O primeiro campo é o ano de início do processo de restauração da peça. Ele é
preenchido pelo sistema com o valor do ano atual, podendo ser modificado pelo usuário. Isso foi decidido porque
existem obras com números de registro de anos anteriores que ainda não foram incluídas na base de dados do
sistema. O segundo campo um número seqüencial que indica a ordem de início da restauração da obra no ano em
questão. Apesar de ser um número seqüencial, definiu-se, a pedido nos profissionais do CECOR, que esse número
não fosse preenchido pelo sistema, dando liberdade ao usuário. Esses dois primeiros campos são separados por
hífen. O último campo também é uma letra de identificação nos mesmos moldes do número provisório.
Figura 11: Tela de cadastro de obras em restauração exibindo os campos do número de registro.
Outro detalhe interessante de usabilidade é a indicação através de ‘*’ dos campos de preenchimento obrigatório
em todos os formulários. Este detalhe permite que o usuário possa visualizar os campos que devem ser preenchidos,
agilizando o seu trabalho de preenchimento dos formulários. Essa característica pode ser vista nas Figuras 8 e 9.
7 Conclusão
A versão em uso do sistema desenvolvido vem cumprindo bem sua finalidade principal que é automatizar o processo
de documentação das obras que são restauradas no CECOR, bem como fornecer suporte às atividades
administrativas e dos custos relacionados com o processo de restauração. O sistema diminuiu bastante o tempo que o
restaurador perdia com a consulta ou cadastro das obras, aumentando a produtividade deste em suas atividades
diárias.
A principal contribuição deste trabalho foi a informatização dos trabalhos de restauração desenvolvidos no
CECOR, antes feitos manualmente e de forma analógica, possibilitando a preservação do acervo existente na
instituição. Os restauradores e pesquisadores da área em geral contam agora com uma ferramenta útil que agilizou e
simplificou o processo de cadastro e pesquisa de informações sobre restauração e conservação de bens culturais
móveis.
O uso das cópias digitais diminuiu drasticamente o manuseio direto dos documentos originais. Somente em casos
extremos é que estes documentos são acessados, prolongando sua vida útil. Também possibilitou, através das
técnicas de processamento digital de imagens, disponibilizar imagens de boa qualidade ao usuário final da aplicação.
A metodologia de digitalização adotada permitirá estudos sobre a melhor forma de preservar este acervo digital que
foi montado. Futuramente, pretende-se iniciar a digitalização do acervo de slides.
O acesso ao acervo por parte de pessoas externas ao CECOR via Web ainda não está disponível. Está se
estudando uma política de acesso por parte destes usuários e, assim que essa política estiver definida e
implementada, o acesso será liberado ao público em geral. A aplicação também não possui um sistema de ajuda online ao usuário, mas que poderá ser desenvolvido com o prosseguimento do projeto.
A estrutura atual do sistema permite que novas funcionalidades sejam incluídas, como relatórios estatísticos
sobre tipos de obras e materiais utilizados. Na Figura 12 pode ser vista um dos documentos que são gerados pelo
produto desenvolvido. Trata-se do recibo de entrada de obras que é emitido em um formato para impressão e
entregue ao proprietário da obra, assim que este deixa sua peça para ser feito um orçamento do trabalho de
restauração.
Figura 12: Tela do recibo de entrada de peças.
8 Agradecimentos
Os autores agradecem ao CNPq, à FAPEMIG, à CAPES, ao CECOR e ao LACICOR pelo apoio e suporte financeiro
a este trabalho.
9 Referências Bibliográficas
[AcIS 1997] “Technical Recommendations for Digital Imaging Prepared by the Image Quality Working Group of
ArchivesCom, a Joint Libraries/AcIS Committee” (1997) http://www.columbia.edu/acis/dl/imagespec.html.
[Andrade 2000] Andrade, N. S. e Araújo, A. A. “Um Sistema de Informação Multimídia para Recuperação de
Documentos Históricos”. I Workshop em Tratamento de Imagens, Belo Horizonte, 2000.
[Andrade 2001] Andrade, N. S., Valle Jr., E. A., Amorim, E. D. e Araújo, A. A. “Um Sistema de Informação
Multimídia para o Arquivo Público Mineiro”. II Workshop em Tratamento de Imagens, Belo Horizonte, 2001.
[Burnstock 2002] Burnstock, A. , & Morgan, S., “A Database of Artistis’ Material from Paintings Examined at the
Courtauld Institute of Art”, ICOM 13th Triennal Meeting, Rio de Janeiro, 2002.
[Drummond 2001] Drummond, G. F. e Paula, V. C. “Avaliação Técnica do MySQL”. 2001.
[Elmasri 2000] Elmasri, R. & Navathe, S. B. “Fundamentals of Database Systems”. Addison Wesley, 2000.
[Filho 2000] Filho, W. P. P. “Multimídia: Conceitos e Aplicações”. LTC – Livros Técnicos e Científicos Editora S.
A., Rio de Janeiro, 2000.
[Filho 2001] Filho, W. P. P. “Engenharia de Software: Fundamentos, Métodos e Padrões”. LTC – Livros Técnicos e
Científicos Editora S. A., Rio de Janeiro, 2001.
[Hix 1993] Hix, D. & Hartson, H. R. “Developing User Interfaces: Ensuring Usability Through Product & Process”.
John Wiley & Sons, Inc., 1993.
[Jones 2001] Jones, A. R. “Dominando ASP 3 – Active Server Pages”. Makron Books, São Paulo, 2001.
[Maslakowski, 2000] Maslakowski, M., “Aprenda em 21 Dias MySQL”, Editora Campus, Rio de Janeiro, 2000.
[Silberschatz 1999] Silberschatz, A., Korth, H. F. & Sudarshan, S. “Sistemas de Banco de Dados”. Makron, São
Paulo 1999.
[Valle Jr. 2000] Valle Jr., E. A., Araujo, A. A., Amorim, E. D., e Andrade, N. S. “A Web Multimedia Information
System for Arquivo Público Mineiro”. I Workshop em Tratamento de Imagens, Belo Horizonte, 2000.