13
• A seção final, Anexo A, apresenta a modelagem e o projeto da ferramenta XVersion, desenvolvidos de acordo com o padrão UML, como forma de possibilitar o melhor entendimento da construção e funcionamento da ferramenta.
14
2 EVOLUÇÃO DE DOCUMENTOS XML
O objetivo deste capítulo é apresentar uma base conceitual sobre as diversas formas de se garantir o versionamento de documentos XML. Primeiramente será descrito o processo de evolução de documentos XML. Em seguida, o processo de versionamento de documentos XML é apresentado. Por fim, serão descritas as formas de representar o conceito de tempo em documentos XML.
2.1 Processo de evolução de documentos XML
Com o uso do XML difundido tanto no meio acadêmico quanto no meio comercial, é natural que apareçam alguns problemas relacionados ao seu uso. Um destes é a necessidade de se detectar se um arquivo XML sofreu alterações, ou seja, se ele evoluiu ao longo do tempo. Quando um arquivo é criado, é pouco provável que seu conteúdo seja o mesmo durante toda sua existência. Após a criação deste arquivo, provavelmente nele serão inseridos, excluídos ou modificados uma série de dados. Este cenário parece ser mais provável ainda de acontecer ao considerarmos como formato do arquivo discutido o XML, que tem entre suas utilidades reconhecidas armazenar dados que podem mudar com freqüência, devido à facilidade de acesso à informação que este formato permite.
É possível citar várias situações que causam alterações em arquivos XML. Por exemplo, um site de notícias que usa RSS. Este site poderia estar disponibilizando periodicamente um XML com uma série de notícias no mesmo arquivo. Os navegadores ou programas de RSS que acessam este site precisariam baixar periodicamente as notícias do servidor para estarem sempre com as mais atualizadas. Porém, um servidor recebendo requisições constantes de arquivos XML inteiros poderia ficar sobrecarregado, causando um tempo maior de espera dos seus usuários pela obtenção das informações. Uma possível solução seria o programa no cliente, antes de solicitar novas notícias, verificar se o conteúdo no servidor é diferente do seu. Apenas se o conteúdo do servidor fosse diferente do conteúdo do cliente é que seria feita uma requisição. A remoção de várias requisições ao servidor reduziria o tráfego na rede e aumentaria o tempo de resposta do site.
Outro exemplo de aplicação de evolução de documentos seria no uso de arquivos de configuração. A plataforma .NET® da Microsoft, por exemplo, usa para a configuração de seus programas arquivos XML com a extensão “config”. Estes arquivos podem ficar muito grandes dependendo da aplicação, podendo chegar a milhares de linhas. Caso um programador altere um arquivo de configuração e o programa pare de funcionar, outro programador pode verificar o que foi alterado do documento original sem ter que mapear todo o arquivo XML para encontrar o que foi alterado e tentar consertar aquele erro.
15
¹ http://www.nongnu.org/cvs/
² http://www-306.ibm.com/software/sw-bycategory/
Como último exemplo, pode ser considerado um professor de faculdade que passa um exercício qualquer para seus alunos e solicita a resposta como um documento XML. Ao receber cerca de 30 trabalhos, seria muito mais fácil para este professor corrigi-los se ele dispusesse de uma ferramenta que recebesse como entrada uma porção de arquivos XML, os comparasse com a resposta do exercício e que fornecesse como saída um percentual indicando o nível de semelhança do trabalho de cada aluno com a resposta para o problema.
2.2 Versionamento de documentos XML
Os documentos XML possuem aplicabilidade em vários cenários, como o armazenamento de informações e a representação de arquivos de configuração. Este tipo de uso faz com que um mesmo arquivo possua várias versões ao longo do tempo. Para tornar possível o gerenciamento de várias versões de arquivos, existem as ferramentas de controle de versão, cujo objetivo principal é manter o histórico de todas as versões que um arquivo possui, e não apenas armazenar a atual. As ferramentas de controle de versão mais conhecidas são o CVS¹ e o Rational ClearCase². Ambas preenchem satisfatoriamente as necessidades que o versionamento de arquivos impõe, mas, além de serem programas comerciais, não existe no mercado uma ferramenta de controle de versão específica para arquivos XML. Para este objetivo, existem diversas abordagens que visam o armazenamento e a recuperação de várias versões de um arquivo XML.
Em muitas situações, nem sempre apenas o armazenamento e a recuperação de versões são suficientes. Muitas vezes deseja-se também que seja oferecida a possibilidade de visualizar determinada versão anterior de um arquivo ou de executar consultas sobre todas as versões do mesmo, como se fosse uma consulta SQL sobre uma base com várias tabelas. Como exemplo é citado um sistema de busca de sites na web que possui milhões de páginas em sua base de dados. Levando em conta a natureza dinâmica da web, os endereços dos links de um site podem ter sofrido alterações. Mudar a página que está na base para uma nova com os endereços dos links atualizados não é recomendado, pois as palavras-chave podem mudar entre as diferentes versões da mesma página, prejudicando assim o resultado da busca. O cenário desejado é aquele no qual a busca é feita tanto sobre a versão nova quanto sobre a versão antiga da mesma página.
Outra aplicação da necessidade de manter todas as versões de um mesmo documento é a de um ramo relativamente novo na informática: as warehouses (computadores com o objetivo de armazenar uma grande quantidade de arquivos de uma determinada organização e que possibilitam a recuperação de dados específicos contidos entre todos estes arquivos). As warehouses mantêm um volume muito grande de arquivos, e parte destes arquivos são diferentes versões para um mesmo documento – surge assim a necessidade da existência de métodos viáveis para o tratamento destes arquivos. Uma última aplicação a ser citada é uma alternativa aos bancos de dados temporais usando XML: uma base de dados pode ser representada por um arquivo XML, e diferentes versões da base poderiam ser obtidas para consulta.
As duas principais abordagens adotadas para o problema do versionamento de arquivos XML são a RCS (Revision Control System), proposta por (TICHY, 1985) e a SCCS (Source Code Control System), proposta por (ROCHKIND, 1975). O RCS é
16
considerado um método baseado na edição: esta abordagem consiste em armazenar apenas a versão mais recente do documento original enquanto que cada versão anterior deste documento é armazenada como um delta script, um arquivo (geralmente também no formato XML) contendo as diferenças da versão em questão para a atual. A vantagem desta abordagem é economizar o espaço em disco que o armazenamento de várias versões de um mesmo documento pode consumir, visto que o tamanho de um arquivo delta contendo apenas as alterações de um documento para outro em vários casos é menor do que o tamanho do arquivo a ser comparado. Esta economia em espaço, porém, implica em um maior tempo gasto em processamento para a recuperação de versões antigas de um documento, já que para obter estas versões anteriores é necessário, a partir do documento atual e do delta script, realizar um processamento para gerar a versão do arquivo em questão. O esforço gasto neste processamento tende a crescer à medida que a versão que se deseja obter se afasta temporalmente da versão mais atual (parte-se do princípio que versões mais antigas possuem mais diferenças para as mais atuais do que as mais recentes). Pode-se diminuir este custo de processamento através da adoção do RCS inverso: ao invés de armazenar a versão atual, é armazenada na base a versão original do documento e a cada nova atualização é gerado um delta script novo com as diferenças da versão nova para a anterior. A escolha entre o RCS e o RCS inverso deve ser feita levando-se em consideração as necessidades do sistema, ou seja, se a maior parte das requisições for pelas versões mais atuais de arquivos, deve-se escolher o RCS. Caso o oposto ocorra, a maioria das requisições será pelas versões iniciais (um cenário menos comum), a escolha deverá ser o RCS inverso.
Outra forma de se gerenciar diferentes versões de um mesmo arquivo XML é através do SCCS. Este método consiste em armazenar todas as versões do arquivo em um grande e único arquivo XML. A diferenciação entre os conteúdos das várias versões é feita através de um par de atributos, inseridos nos nodos elementos que formam o XML, que indicam o período de validade daquele conteúdo (existe uma alternativa a esta forma de identificação de versões: pode-se usar, ao invés da data de validade, uma propriedade com o identificador da versão). A abordagem SCCS permite que sejam feitas consultas (usando XQuery (W3C, 2003), por exemplo) para que seja filtrado o conteúdo desejado do original. A existência desta possibilidade de realizar consultas é uma grande vantagem do SCCS sobre o RCS. Esta vantagem é obtida, porém, ao custo de um maior espaço em disco e da necessidade de se ter maior capacidade de processamento para que seja possível gerenciar os grandes arquivos que são gerados por este método.
Ao ser feita a escolha entre o SCCS e o RCS é necessário levar em conta que o RCS nem sempre é tão econômico no quesito “espaço em disco ocupado” como pode parecer em uma primeira análise. Isto porque, caso as alterações entre uma versão e outras forem muitas, o arquivo de diferenças (delta) gerado pode ter um tamanho próximo do tamanho do arquivo com o conteúdo. No cenário em que um documento XML for totalmente alterado de uma versão para outra, o tamanho do arquivo com as diferenças será maior do que o do arquivo original, pois o delta guarda as informações excluídas e as inseridas na versão original. Isto implicaria num espaço ocupado semelhante, e talvez maior, ao que seria gasto caso fossem armazenadas todas as versões, e com a agravante do sistema necessitar de um maior custo para recuperar as informações antigas. O RCS só será econômico se as alterações entre cada versão forem pequenas.
Uma solução alternativa para este problema é usar o RCS entre cada versão quando as alterações forem poucas e copiar o arquivo inteiro quando houver muitas alterações.
17
A figura 2.1 mostra graficamente a diferença principal entre os dois métodos: enquanto que no RCS a informação é fragmentada em vários documentos pequenos (com exceção do último que contém a versão final), o SCCS guarda num único e grande arquivo todas as informações que pertencem ou pertenceram ao documento XML sendo analisado.
Figura 2.1 – Representação gráfica dos métodos RCS e SCCS
Para este trabalho, chegou-se à conclusão de que a melhor abordagem a ser seguida é a SCCS. Isto porque, tendo a união de todas as informações que já existiram em todas as versões de um documento num arquivo só, é possível executar consultas com XQuery (W3C, 2005) sobre este arquivo, tornando possível desta forma filtrar os resultados desejados, exatamente como é feito em consultas SQL. Como o SCCS insere as datas inicial e final de cada informação do XML, as consultas podem usar como filtro tanto o tipo de conteúdo quanto a data de validade da informação desejada. Além disso, como não se sabe que tipo de alterações os documentos XML irão sofrer ao longo do tempo, não é possível ter certeza de que o RCS seria mais eficiente do que o SCCS, o que acabou confirmando a escolha pelo último.
2.3 Temporalidade em documentos XML
Dada a importância de se saber o período no tempo em que cada informação contida no documento XML foi válida, faz-se necessária a criação de rótulos temporais que indicarão este período. Isto porque, se existirem rótulos que indiquem a temporalidade, é possível dividir o documento obtido em vários outros usando como critério a data de validade de suas informações.
Existe a opção de se realizar a temporalidade de acordo com a granularidade desejada. Pode-se, por exemplo, detectar as alterações apenas levando-se em conta a raiz do documento. Também é possível detectar as alterações considerando como nível de granularidade os elementos ou até mesmo os atributos do arquivo. O nível de granularidade escolhido afetará na precisão do versionamento obtido. A granularidade não precisa ser apenas no nível de nodo, mas também no nível de tempo. Pode-se
18
armazenar nas datas de validade o dia, apenas o ano ou o tempo em segundos. Este critério dependerá das necessidades de precisão do sistema. Para este trabalho, serão tratadas as datas com ano, mês, dia, hora do dia, minutos e segundos. Os rótulos de data serão inseridos em todos os nodos elemento do XML. Optando por estes níveis de granularidade acredita-se que a ferramenta a ser desenvolvida será a mais genérica possível.
Pelos métodos existentes, é possível versionar uma série de documentos XML de duas formas: ou gravar cada versão criada em arquivos separados ou juntar todas estas versões em um único documento. A questão da temporalidade possui solução para ambas as abordagens. Se fosse escolhida a adoção de um modelo com vários documentos (o RCS), seria possível obter o aspecto temporal pelas datas de criação de cada arquivo. Usando a abordagem do SCCS, que insere todas as informações no mesmo arquivo, a temporalidade será representada com rótulos em cada nodo elemento do XML, indicando a data de início e fim da validade de cada um destes elementos, criando assim a possibilidade de se realizar no arquivo gerado consultas temporais. Por consultas temporais, entende-se que sejam aquelas cujos principais parâmetros utilizados são os que indicam a data na qual os dados desejados foram válidos.
O uso de consultas temporais para filtrar o conteúdo de documentos XML é de essencial importância para sistemas de controle de versão, pois apenas diferenciando os arquivos pelo período desejado será possível recuperar o conteúdo que estava válido durante determinado período de tempo. Desta forma, será possível obter também o histórico da evolução do documento.
São apresentados em (DA SILVA, 2001) uma série de conceitos sobre a modelagem temporal de documentos XML. Estes conceitos, que ajudam a entender e classificar melhor o aspecto da temporalidade, estão listados abaixo:
• Prazo de validade - é o período no qual o valor especificado é válido dentro do contexto. É delimitado pelas datas inicial e final, ambas fornecidas pelo usuário;
• Ordem no tempo - para se ordenar os itens do histórico de valores cronologicamente, existem duas alternativas. Na primeira, usa-se uma seqüência de valores crescentes que indicam a posição no tempo de cada valor do documento. Na segunda, que foi a escolhida para este trabalho, é adotado o tempo do mundo real (dia, mês, hora, etc.). Esta escolha foi feita pois, as vezes é desejado saber não apenas a ordem cronológica, mas também em que data alguma informação foi válida;
• Tempo absoluto - é a união da informação temporal com a informação propriamente dita. Esta união forma a informação completa e situada no tempo, ou seja, uma informação temporal específica, com determinada granularidade, associada a um fato. A descrição apenas do tempo, independente da granularidade, é denominada tempo relativo;
• Variação temporal - mede como o tempo varia conforme o desenvolvimento das novas versões. Apesar da variação do tempo no mundo real ser contínua, não é possível expressá-lo desta forma, visto que as informações guardadas são os instantes de tempo. Assim, a abordagem escolhida é usar uma representação discreta do tempo. Com esta representação, o tempo é representado como uma seqüência de intervalos, e, quando necessário, um dos itens desta seqüência é
19
capturado, representando corretamente qual o instante de tempo no qual dada informação ocorreu;
• Granularidade temporal - por granularidade entende-se como sendo a precisão usada para medir o tempo. É possível escolher uma granularidade alta (neste caso, o tempo seria representado no nível do dia, mês ou em casos mais extremos do ano) ou uma granularidade baixa (por exemplo, pode-se representar o tempo no nível das horas, dos segundos ou até mesmo dos milissegundos). Como as alterações podem ser muito freqüentes, a granularidade adotada neste trabalho foi segundos;
• Elemento primitivo de representação temporal - significa o intervalo de tempo entre dois instantes de tempo discreto. Para este trabalho, como elemento primitivo de representação temporal, será usada a unidade de tempo “segundo”;
2.4 Considerações Finais
Neste capítulo foram vistas as formas mais conhecidas de versionamento de documentos XML. Seus pontos fortes e fracos foram discutidos, levando à conclusão de que o método que melhor se adapta às necessidades deste trabalho é o SCCS. Isto porque ele permitirá ao usuário fazer consultas utilizando XQuery abrangendo todas as versões existentes no documento.
Este capítulo também mostrou o processo de evolução de um documento XML, ou seja, como um documento XML vai sendo alterado ao longo do tempo, e a importância de possuir um algoritmo que seja capaz de encontrar diferenças entre diferentes versões do mesmo documento XML, além de ilustrar alguns conceitos sobre a temporalidade em documentos XML.
Na ferramenta a ser desenvolvida, já está definida a forma de armazenamento de várias versões de arquivos XML. Definir quais os componentes e técnicas a serem utilizados antes de começar a implementação da ferramenta é importante porque poupará o esforço gasto durante a implementação da mesma. O próximo passo no projeto desta ferramenta será a escolha do algoritmo que calculará as diferenças entre dois arquivos XML, conforme apresentado no capítulo seguinte.
20
3 DETECÇÃO DE DIFERENÇAS ENTRE DOCUMENTOS
XML
Neste capítulo serão mostrados os principais algoritmos para detectar as alterações entre arquivos XML, sendo discutidas suas características relevantes. Por fim, será detalhadamente apresentado o algoritmo XyDiff, escolhido para implementação da ferramenta implementada neste trabalho.
3.1 Representação de arquivos XML como árvores DOM
Antes do estudo dos algoritmos de detecção de mudanças em documentos XML, é necessário mostrar que qualquer documento XML pode ser representado na forma de uma árvore (COBÉNA, 2001). Isto porque os algoritmos utilizados trabalham sobre uma estrutura de árvore e não sobre um texto plano, que é a forma original de um documento XML. A especificação DOM (Document Object Model) (WOOD, 2000) será usada neste trabalho para representar documentos XML como uma árvore, pois atende perfeitamente às suas necessidades.
Na representação DOM, todos os componentes do XML são transformados em nodos de uma árvore: elementos, nodos texto, atributos, comentários, etc. Mas o DOM não oferece apenas a representação da árvore – ele possui também métodos para inserção, remoção e manipulação destes nodos dentro da árvore, e sempre atualizando o documento XML correspondente conforme as operações vão sendo feitas.
A figura 3.1 mostra como pode ser representado um documento XML simples em uma árvore DOM. Usando esta especificação, as operações de alteração em arquivos XML agora podem ser representadas como operações de alteração sobre uma árvore. Já existem algoritmos prontos na teoria dos grafos que fazem estas operações em árvores, o que facilita o desenvolvimento de soluções para a finalidade desejada. O problema original de se detectar alterações em arquivos XML agora se transforma num problema de detecção de alterações em árvores.
3.2 Detecção de diferenças em documentos XML
Os algoritmos utilizados para a detecção de diferenças (que podem ser chamados também de algoritmos de diff) são aqueles cujo objetivo é obter uma seqüência de operações que transformam a versão original de um documento (uma árvore XML a1) na sua versão modificada (uma outra árvore XML a2). Estes algoritmos, em geral, possuem mais ou menos a mesma estrutura interna. Nesta estrutura lógica interna, estes algoritmos são formados por outros algoritmos já existentes que resolvem subproblemas relacionados à menor distância entre duas árvores. Como qualquer arquivo XML pode ser representado como uma árvore DOM, é natural que sejam utilizados algoritmos conhecidos, usados em árvores. Para encontrar o menor número de alterações possível