Modelo de Estilo para Artigo Científico - NPDI
Transcrição
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.
Documentos relacionados
Restaure - Universidade Federal de Minas Gerais
As ferramentas de banco de dados se mostraram como uma alternativa para uma forma mais eficiente de recuperar e armazenar os dados deste acervo. A finalidade de um sistema de banco de dados é simpl...
Leia mais