UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

INSTITUTO DE INFORMÁTICA

CURSO DE CIÊNCIA DA COMPUTAÇÃO

FELIPE DOS SANTOS GIACOMEL

XVersion - uma ferramenta gráfica para gerenciamento e consulta de versões de

documentos XML

Trabalho de Graduação. Profª. Drª. Renata de Matos Galante Orientadora Profª. M. Sc. Deise de Brum Saccol Co-orientadora

Porto Alegre, novembro de 2006.

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitor: Prof. José Carlos Ferraz Hennemann Vice-reitor: Prof. Pedro Cezar Dutra da Fonseca Pró-Reitora Adjunta de Pós-Graduação: Profa. Valquiria Link Bassani Diretor do Instituto de Informática: Prof. Flávio Rech Wagner Bibliotecária-Chefe do Instituto de Informática: Beatriz Regina Bastos Haro

AGRADECIMENTOS

Gostaria de agradecer primeiramente a Deus, por ter me dado saúde e inteligência para chegar até aqui.

Aos meus pais, que desde a época do vestibular sempre me apoiaram nos meus sonhos. Aos meus irmãos, meu primo e minha avó, por terem me agüentado nestes últimos meses, que foram os mais difíceis para mim. A todos os meus tios, tias, primos e primas, pelo carinho e amor que me deram.

A Juliane, meu grande amor, que me ajudou a relaxar durante os momentos de tensão.

A todos os meus amigos e colegas da faculdade, porque sem eles com certeza não teria chegado aqui. Graças a vocês, os últimos cinco anos foram os melhores da minha vida.

Às minhas orientadoras Renata e Deise, sempre dispostas a resolver minhas dúvidas a qualquer momento, e que acreditaram em mim às vezes mais do que eu mesmo. Também agradeço a Cecília, minha primeira orientadora.

A todas as empresas que passei e que me ajudaram a me tornar o profissional que sou hoje.

E a todos os outros, que de forma direta ou indireta, contribuíram nesta minha trajetória rumo à graduação.

A todos vocês, o meu muito obrigado!

SUMÁRIO

LISTA DE ABREVIATURAS E SIGLAS ...................................................................6

LISTA DE FIGURAS .....................................................................................................7

LISTA DE TABELAS ....................................................................................................8

RESUMO.........................................................................................................................9

ABSTRACT..................................................................................................................10

1 INTRODUÇÃO .....................................................................................................11

2 EVOLUÇÃO DE DOCUMENTOS XML ...........................................................14

2.1 Processo de evolução de documentos XML....................................................... 14 2.2 Versionamento de documentos XML................................................................. 15 2.3 Temporalidade em documentos XML............................................................... 17 2.4 Considerações Finais ........................................................................................... 19

3 DETECÇÃO DE DIFERENÇAS ENTRE DOCUMENTOS XML.................20

3.1 Representação de arquivos XML como árvores DOM .................................... 20 3.2 Detecção de diferenças em documentos XML................................................... 20 3.2.1 Operações de alterações sobre documentos XML.............................................. 21 3.3 Descrição dos principais algoritmos de detecção de diferenças em documentos XML............................................................................................................................... 23 3.3.1 Comparação entre os algoritmos de detecção de diferenças .............................. 24 3.4 XyDiff: O algoritmo escolhido ............................................................................ 27 3.4.1 Introdução ao XyDiff.......................................................................................... 28 3.4.2 Funcionamento do algoritmo .............................................................................. 28 3.4.3 Análise do desempenho do XyDiff..................................................................... 29 3.5 Considerações finais ............................................................................................ 30

4 XQUERY COMO LINGUAGEM DE CONSULTA..........................................31

4.1 XPath .................................................................................................................... 31 4.2 XQuery como linguagem de consulta ................................................................ 32 4.3 Consultas temporais em documentos XML ...................................................... 35 4.3.1 Tempo representado em 4 dimensões ................................................................. 35 4.3.2 Uma abordagem visando a aplicação em bancos de dados temporais................ 36 4.4 Considerações finais ............................................................................................ 38

5 XVERSION............................................................................................................40

5.1 Visão geral da ferramenta................................................................................... 40 5.1.1 Ferramentas utilizadas ........................................................................................ 40 5.2 Descrição da ferramenta ..................................................................................... 41 5.2.1 Colhendo as diferenças entre arquivos ............................................................... 43 5.2.2 O SCCS para juntar arquivos.............................................................................. 45 5.2.3 Criação do SCCS a partir de delta scripts........................................................... 45 5.2.4 União dos documentos gerados .......................................................................... 47 5.2.4.1 Equivalência de nodos pelo contexto ................................................................. 47 5.2.4.2 Equivalência de nodos pela posição ................................................................... 49 5.2.5 Executando consultas.......................................................................................... 51 5.2.5.1 Consultas temporais ............................................................................................ 51 5.2.5.2 Executando XQuery............................................................................................ 55 5.3 Considerações Finais ........................................................................................... 56

6 CONCLUSÃO.......................................................................................................58

6.1 Trabalhos futuros ................................................................................................ 58

7 REFERÊNCIAS....................................................................................................59

A.1 Diagrama de casos de uso.................................................................................... 62 A.2 Diagrama de classes............................................................................................. 63 A.2.1 Classe: Constantes .............................................................................................. 63 A.2.2 Classe: Main ....................................................................................................... 63 A.2.3 Classe: DOMManager ........................................................................................ 64 A.2.4 Classe: frmPrincipal............................................................................................ 64 A.2.5 Classe: dlgXQuery.............................................................................................. 64 A.2.6 Classe: XMLManager......................................................................................... 64 A.2.7 Classe: XQuery................................................................................................... 64 A.2.8 Classe: ExecutorXQuery .................................................................................... 64 A.3 Casos de uso e diagramas de seqüência ............................................................. 64 A.3.1 Gerar Delta Script entre dois documentos .......................................................... 64 A.3.1.1 Diagrama de seqüência do caso de uso Gerar Delta Script entre 2 Documentos65 A.3.2 Unir vários documentos (SCCS) ........................................................................ 65 A.3.2.1 Diagrama de seqüência do caso de uso Unir Vários Documentos ..................... 66 A.3.3 Executar consultas XQuery ................................................................................ 67 A.3.3.1 Diagrama de seqüência do caso de uso Executar Consultas XQuery................. 67

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface CVS Concurrent Versions System DOM Document Object Model DTD Document Type Definition FLWOR For, Let, Where, Order By e Return GNU (ou GPL) General Public License RCS Revision Control System RSS Really Simple Syndication, Rich Site Summary ou RDF Site Summary SCCS Source Control System SGBD Sistema Gerenciador de Banco de Dados SQL Structured Query Language UFRGS Universidade Federal do Rio Grande do Sul UML Unified Modeling Language W3C World Wide Web Consortium XML Extensible Markup Language XPath XML Path Language XSLT Extensible Stylesheet Language Transformations XQuery XML Query XVersion XML Versioner

LISTA DE FIGURAS

Figura 2.1 – Representação gráfica dos métodos RCS e SCCS ..................................... 17 Figura 3.1: Representação de um documento XML sob a forma de árvore ................... 21 Figura 3.2: Mudanças em um documento XML ao longo do tempo .............................. 22 Figura 4.1 – XML representando o estoque de uma livraria .......................................... 32 Figura 4.2 – Comparativo entre Xpath e XQuery........................................................... 33 Figura 4.3 – Criação de um HTML com XQuery .......................................................... 34 Figura 4.4 – Exemplo de consulta XML/SQL (GRANDI, 2005)................................... 36 Figura 4.5 – Exemplo de XQuery substituindo uma consulta SQL (WANG, 2003) ..... 37 Figura 4.6 – Consulta XQuery usando junções (WANG, 2003) .................................... 37 Figura 5.1 – Arquitetura do XVersion............................................................................ 41 Figura 5.2 – Tela inicial do XVersion............................................................................ 41 Figura 5.3 – Nomeação automática de diferentes versões de XMLs no XVersion. ....... 42 Figura 5.4 – Tela do XVersion mostrando a comparação entre dois arquivos. .............. 43 Figura 5.5 – Arquivo delta gerado para dois documentos XML fornecidos .................. 44 Figura 5.6 Arquivos envolvidos na criação do SCCS .................................................... 47 Figura 5.7 – 3 versões de um mesmo documento XML................................................. 47 Figura 5.8 – Construção do SCCS para mais de dois arquivos ...................................... 48 Figura 5.9 – 3 versões de um mesmo documento XML com metadados já inseridos. .. 49 Figura 5.10 – Construção do SCCS para mais de dois arquivos com metadados .......... 50 Figura 5.11 – SCCS de três arquivos formado com o XVersion.................................... 51 Figura 5.12 – XML com datas de início e fim................................................................ 52 Figura 5.13 – Consulta usando o valor do livro como filtro........................................... 53 Figura 5.14 – Consulta usando a validade do livro como filtro...................................... 53 Figura 5.15 – XML sobre o qual será aplicado o filtro de consulta temporal................ 54 Figura 5.16 – Execução do assistente para consultas temporais no XVersion............... 55 Figura A.1 – Diagrama de casos de uso do XVersion. ................................................... 62 Figura A.2 – Diagrama de classes do XVersion............................................................. 63 Figura A.3 – Diagrama de seqüência da geração de um delta script.............................. 65 Figura A.4 – Diagrama de seqüência para a união de vários documentos através do SCCS............................................................................................................................... 66 Figura A.5 – Diagrama de seqüência para a execução de consultas .............................. 67

LISTA DE TABELAS

Tabela 3.1: Principais algoritmos utilizados para a detecção de diferenças entre arquivos XML ............................................................................................................................... 25 Tabela 4.1: Exemplos de expressões XPath................................................................... 32 Tabela A.1 – Seqüência típica de eventos do caso de uso Gerar Delta Script entre dois Documentos .................................................................................................................... 65 Tabela A.2 – Seqüência típica de eventos do caso de uso Unir Vários Documentos..... 66 Tabela A.3 – Seqüência típica de eventos do caso de uso Executar Consultas XQuery 67

RESUMO

O XML vem provando ser a melhor forma de armazenamento de conteúdo, pois oferece um método simples e ao mesmo tempo restrito para a representação de documentos. Por estas razões, o XML vem sendo aplicado nos mais diversos campos da informática e, com seu uso cada vez mais difundido na comunidade, surgem alguns problemas relacionados a este modelo. Um dos maiores problemas percebidos é a detecção das alterações que os dados de um arquivo XML sofrem com o passar do tempo. Caso o tamanho do XML seja muito grande, também poderia se desejar que fosse executada alguma espécie de filtro sobre os dados, assim como as consultas SQL fazem em bases de dados.

O presente trabalho apresenta o XVersion (XML Versioner): uma ferramenta gráfica que permite a comparação entre diferentes arquivos XML, união de diferentes versões do mesmo documento, gerando assim um histórico de versões para posterior armazenamento, e por fim, consultas em arquivos XML, no mesmo molde que são feitas consultas em bancos de dados.

Palavras-Chave: XML, XQuery, Diferenças, Versionamento, Consultas, Evolução.

XVersion - a graphic tool for version management and querying of XML documents

ABSTRACT

XML has been proving to be the best way of content storage as it offers a simple and restrict method to the representation of documents. For these reasons XML is applied on various fields of Computer Science and, as its use on community grows, some problems related to this model arise. One of the biggest noticed is the detection of changes that XML data suffers as time goes by. If the XML’s size gets too big, it could be desirable the execution of some kind of filter over the data, such as SQL queries do on databases.

This manual presents XVersion (XML Versioner): a graphic tool that permits the comparison of different XML files, the union of different versions of the same document, generating then a historical of versions for later storage and, finally, querying of XML files, at the same mold that databases queries are made.

Keywords : XML, XQuery, Differences, Versioning, Queries, Evolution.

11

1 INTRODUÇÃO

O XML (W3C, 1997) é uma linguagem de marcação que foi definida pela W3C (World Wide Web Consortium) e permite a representação de informações estruturadas e, principalmente, semi-estruturadas. Um documento XML é formado por entidades (ou nodos), que representam os dados contidos no documento. Os dados em um documento XML podem ter várias formas de representação dentro do mesmo: o próprio conteúdo do documento, geralmente representado sob a forma de um texto legível, atributos (que definem as propriedades das entidades) e até mesmo outras entidades, permitindo assim a representação hierárquica, estruturada e correta da informação.

O XML vem se tornando cada vez mais comum em ambientes corporativos e acadêmicos. Qualquer organização que deseja ter suas informações bem organizadas decidirá pelo XML como forma de armazenamento ou transporte de seus dados. Este grande uso do XML criou novas necessidades de funcionalidades que não existem integradas nas linguagens de programação. O usuário intensivo de XML necessita de ferramentas que o ajude a melhor organizar o seu trabalho.

Uma das necessidades de funcionalidade que surgiram com a popularização do XML foi a possibilidade de se poder versionar documentos XML, como mostram (TICHY, 1985) e (ROCHKIND, 1975). O versionamento de documentos é importante para que se tenha um controle do histórico dos dados de determinado documento. De posse de tal histórico, é possível analisar a evolução dos dados ao longo do tempo e, a partir desta análise, chegar a conclusões que não seriam possíveis de se alcançar caso fosse considerada apenas a última versão. Uma aplicação que verifica alterações climáticas em uma região, por exemplo, precisa do histórico de muitos anos sobre o clima de determinada região para chegar a alguma conclusão. Saber o clima apenas do último ano não terá praticamente nenhuma utilidade para que se possa prever o clima dos anos seguintes.

Outra necessidade que surge é a da representação do tempo em arquivos XML (DA SILVA, 2001). Muitas vezes não é suficiente apenas dispor dos dados: é necessária também a presença de metadados que informem o período do tempo no qual estes dados foram válidos. Num sistema que armazene a constituição de um país, por exemplo, onde a legislação sofre alterações em suas leis com o passar dos anos, é interessante que se armazenem todas as leis que existiram e que se possa recuperar a data em que determinada lei era válida.

Também é importante que exista a possibilidade de verificar as diferenças entre dois arquivos XML, como mostrou (PETERS, 2004). O que existe hoje em dia integrado com as linguagens de programação são funções que dizem apenas se dois documentos XML são iguais ou não, mas que não são capazes de dizer o que estes documentos têm de diferente entre si. Saber estas alterações é importante nas diversas aplicações. Como

12

exemplo é considerada uma rede de supermercados que faz o balanço de todas as suas filiais e que gostaria de comparar as diferenças entra cada uma delas, para saber qual gasta menos e qual lucra mais.

Para auxiliar as pessoas que trabalham no cenário descrito acima, foi idealizada a criação de uma ferramenta, o XVersion (XML Versioner), que permitirá que sejam feitas as seguintes atividades: comparação entre diferentes arquivos XML, união de diferentes versões do mesmo documento - gerando assim um histórico de versões para posterior armazenamento, e por fim, consultas em arquivos XML, no mesmo molde que são feitas consultas em bancos de dados.

Para poder descrever melhor os conceitos da pesquisa feitos neste trabalho, e também para explicar a ferramenta desenvolvida, são usados com freqüência dois termos parecidos, mas que possuem significados diferentes: arquivo XML e documento XML. Por um documento XML entende-se a representação em XML de uma série de dados, enquanto que é considerado um arquivo XML a representação em disco de um documento XML. Esta nomenclatura torna-se necessária porque, como serão tratadas diversas versões de um mesmo XML, é possível que em certos cenários que serão apresentados se pense que estão sendo manipulados uma série de documentos, quando na verdade, são utilizados uma série de arquivos, todos representando o mesmo documento.

O objetivo deste trabalho é mostrar toda a pesquisa feita a fim de obter uma base intelectual para a confecção do XVersion e, após isto, mostrar a ferramenta desenvolvida. Para atingir estes objetivos, este trabalho está estruturado da seguinte forma:

• O capítulo 2, Evolução de documentos XML, mostra o processo de criação de novas versões do mesmo documento XML ao longo do tempo e o uso da representação da temporalidade como forma de poder controlar estas diversas versões que são criadas. Após a análise de diferentes representações da temporalidade existentes, é escolhida a representação que será implementada na ferramenta a ser desenvolvida;

• O capítulo 3, Detecção de diferenças entre documentos XML, mostra como os documentos XML são representados dentro do programa através de árvores DOM e pesquisa uma série de algoritmos existentes que detectam alterações entre arquivos XML. Ao fim do capítulo, o algoritmo que melhor se adapta às necessidades da ferramenta e que foi escolhido para ser usado na mesma é descrito;

• O capítulo 4, XQuery como linguagem de consulta, faz uma pesquisa sobre as formas de se realizar consultas em documentos XML e escolhe a mais eficiente, que será então inserida no XVersion;

• O capítulo 5, XVersion: A ferramenta desenvolvida, discorre sobre a implementação da ferramenta, linguagem utilizada e bibliotecas de terceiros importadas. Também são apresentados screenshots do programa como forma de exibir os resultados obtidos;

• O capítulo 6, Conclusão, mostra expectativas para a ferramenta e possibilidades de novas funcionalidades para a mesma, ou até mesmo de novas ferramentas a serem desenvolvidas através do conhecimento obtido;

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

21

que transforme um documento XML em outro, os algoritmos de diff calculam a distância entre as duas árvores que representam estes documentos, para que tenham um parâmetro que indique se o conjunto de operações encontrado realmente pode ser considerado mínimo.

Figura 3.1: Representação de um documento XML sob a forma de árvore

Nesta seção serão apresentados os principais algoritmos que calculam as diferenças entre dois arquivos XML. O próximo passo será analisar estes algoritmos e, baseado em suas características, escolher o que melhor se adapta às necessidades deste trabalho. As próximas subseções tratarão de conceitos que são utilizados na confecção dos algoritmos de diff.

3.2.1 Operações de alterações sobre documentos XML Antes de começar o estudo das alterações em documentos XML, é importante que se

defina os tipos de operações que podem ser aplicadas sobre um documento XML. Esta definição faz-se importante para que se possa analisar a evolução de um documento XML, além de permitir a identificação das operações que tornaram a versão original diferente da atualizada. As operações de edição possíveis em um documento XML segundo (PETERS, 2004) são descritas abaixo.

§ Insert (Inserir) - inserção de dados em um documento, o que implica numa inserção de um ou mais elementos no XML;

§ Delete (Excluir) - exclusão de dados em um documento, o que implica em uma exclusão de alguns ou de vários elementos no XML;

§ Update (Atualizar) - atualização de dados em um documento, o que implica na alteração de um ou mais elementos no XML;

22

§ Move (Mover) - transferência de dados de uma região para outra do documento, o que implica na troca de posição de um ou mais elementos dentro do XML;

§ Copy (Copiar) - cópia de dados de uma região para outra do documento, implicando na cópia de elementos dentro do XML sem perda da posição original destes elementos.

Figura 3.2: Mudanças em um documento XML ao longo do tempo

Estas operações estão definidas para edição em árvores, mas como foi dito neste capítulo e será destacado no capítulo 3, um arquivo XML pode ser representado como

23

uma árvore. Portanto, estas operações são realizadas sobre uma árvore, e não diretamente em um XML.

As três últimas operações mencionadas (Update, Move e Copy) não existem em todos os algoritmos de detecção de mudanças, pois elas podem ser substituídas por uma combinação de operações Insert e Delete. O motivo de elas serem utilizadas em alguns algoritmos apesar de serem dispensáveis é que o seu uso diminui o tamanho de suas saídas, que sempre consiste em uma lista das alterações necessárias para se chegar em um documento XML a partir de outro. Uma desvantagem da adoção de operações além das básicas (inserção e deleção de elementos) é que para um algoritmo calcular um delta script em um tempo aceitável ele dificilmente conseguirá chegar na resposta ótima (COBÉNA, 2002).

A figura 3.2 exemplifica uma possível mudança que pode ocorrer em um arquivo XML ao longo do tempo. O documento superior representa os empregados e equipamentos de uma empresa fictícia. Já o documento inferior mostra uma descrição da mesma empresa algum tempo depois, com uma secretária diferente inserida nas linhas 7 a 9 e um computador novo inserido nas linhas 13 a 15. É possível observar como as operações mostradas anteriormente aconteceram no documento. Uma operação do tipo update aconteceu na entidade “empregado” da linha 7, que possui a secretária como conteúdo e uma operação do tipo insert aconteceu na entidade “computadores” na linha 12, já que a empresa adquiriu um computador novo.

3.3 Descrição dos principais algoritmos de detecção de diferenças em documentos XML

Os algoritmos pesquisados possuem, em geral, a mesma estrutura. Primeiro eles recebem como entrada dois arquivos XML a serem comparados. Após serem inicializados com estes arquivos, os algoritmos criam duas representações de árvore, uma para cada arquivo fornecido. Depois é calculada a distância mínima entre as duas árvores criadas, através de algum algoritmo de Tree Edit Distance. Este algoritmo gera o conjunto mínimo de operações necessárias para transformar um arquivo XML em outro. Este conjunto de operações é chamado de Delta Script, e é a saída gerada por estes algoritmos. Existem vários algoritmos para tal função, mas serão descritos aqui apenas os mais relevantes para a ferramenta implementada. Por fim, será apresentada uma tabela com dados comparativos entre todos os algoritmos encontrados:

§ X-Diff - este algoritmo (WANG, 2003) transforma o XML em uma árvore, entretanto, ele assina cada nodo da árvore para fazer a equivalência entre as duas árvores (os dois arquivos XML) a serem comparadas. Outra particularidade deste algoritmo é que ele compara duas árvores considerando-as não ordenadas, ou seja, a ordem de aparição de dois nodos irmãos é irrelevante: se dois nodos estão no mesmo nível então o único aspecto comparado é o conteúdo deles e não o seu ordenamento. Esta abordagem, por calcular um isomorfismo entre árvores, tem um custo de processamento maior do que os outros algoritmos. O algoritmo, porém, é otimizado, pois leva em conta propriedades que os documentos XML possuem. Um exemplo destas propriedades é que, ao contrário do isomorfismo entre grafos, que leva em conta apenas as relações (ou seja, todos os nodos são considerados iguais), o isomorfismo entre duas árvores XML só pesquisará relações possíveis entre elementos do mesmo tipo. Por

24

exemplo, não deve ser feita uma relação de um nodo que representa o nome de uma pessoa com um nodo que representa o endereço. Além disso, um nodo que representa uma entidade não deve estar relacionado com um nodo que representa um atributo. Estas considerações ocasionam um desempenho muito próximo, e às vezes até superior, ao dos algoritmos que levam o ordenamento em consideração;

§ MHDiff (SUDARSHAN, 97) - é um algoritmo bastante simples e que tem como diferencial usar todas as 5 operações possíveis, gerando um Delta Script reduzido em relação aos demais - principalmente se as operações forem feitas sobre grandes subárvores. Embora este algoritmo gere Delta Scripts pequenos, o tempo necessário para gerar estes deltas é muito grande. A complexidade deste método no pior caso é O(n3), onde n é o número de nodos da árvore gerada a partir do arquivo XML, ou seja, sua baixa performance o torna inviável para uso em vários arquivos XML;

§ XyDiff - o XyDiff (CÓBENA, 2002) é um dos mais conhecidos. Ele atribui um código de hash e um peso para cada nodo das duas árvores e compara estes nodos individualmente. Sua principal idéia é, de posse dos hashs (assinaturas) para cada nodo, fazer antes a comparação das subárvores com mais diferenças entre si do que as que possuem poucas diferenças detectadas. Além disso, ele também vai agrupando subárvores cada vez maiores até realmente precisar comparar dois nodos. É um algoritmo muito rápido (possui complexidade O(n log n) e usa 4 das 5 operações básicas possíveis), porém não fornece sempre os resultados totalmente corretos. Estes dois fatores (alto desempenho, porém baixa corretude) devem ser levados em conta na hora de optar por este algoritmo;

§ DeltaXML - este algoritmo (DELTAXML, 2001) tem como vantagem aceitar tanto árvores ordenadas quanto desordenadas. Ele possui métodos para comparar dois documentos XML entre si e fazer a união entre dois ou três XMLs. Também é capaz de fazer a sincronização entre diferentes XMLs. Tantas funcionalidades talvez se expliquem pelo fato de ser uma ferramenta comercial. Este talvez seja o algoritmo com melhor relação custo de processamento/benefício, pois ele é muito rápido e o delta script gerado é muito próximo do mínimo.

3.3.1 Comparação entre os algoritmos de detecção de diferenças Essa seção apresenta um estudo comparativo sobre os principais algoritmos para

detecção de diferenças em árvores XML. A seguir, são descritos os itens utilizados para a comparação:

§ Complexidade - não só para os algoritmos de comparação, mas para qualquer tipo de problema, a complexidade de um algoritmo é sempre um fator a se preocupar. É preciso saber a ordem de um algoritmo, ou seja, qual função que determina o tempo gasto no seu processamento. As funções usadas para calcular a ordem destes algoritmos contêm apenas uma variável n, que representa o número de nodos da árvore dada como entrada. Também é interessante saber a velocidade que a ordem de um algoritmo cresce, ou seja, se o tempo de execução cresce linearmente ou quadraticamente (existem

25

ainda os crescimentos exponenciais e fatoriais, mas não foi encontrado este crescimento em nenhum dos algoritmos estudados);

§ Memória - nem só a velocidade e eficiência são importantes num algoritmo. Os programas de computador não são como os problemas matemáticos que não se preocupam com a memória disponível à medida que o tamanho das entradas aumenta. Eles executam em computadores reais e que possuem capacidade limitada de memória. Por isso é importante a preocupação com o crescimento da memória consumida pelo algoritmo de acordo com o crescimento da entrada, pois assim é possível saber se um algoritmo, apesar de eficiente, terá sua execução inviabilizada devido à grande quantidade de memória utilizada;

§ Operações suportadas - embora exista um total de cinco operações de edição possíveis em uma árvore, nem todos os algoritmos geram um delta script com estas cinco possibilidades. Isto acontece porque para alguns algoritmos continuarem eficientes, eles abrem mão de uma análise mais aprofundada das alterações em uma árvore e procuram por apenas um subconjunto das operações possíveis de serem feitas. Esta simplificação é possível pois três das cinco operações possíveis podem ser substituídas por uma seqüência de operações Insert e Delete. Usar poucas operações no delta script, embora torne o algoritmo mais eficiente, pode tornar o delta script muito extenso, o que tornará o mesmo mais trabalhoso de ser analisado;

§ Ordenação - um algoritmo de comparação entre arquivos XML pode ou não levar em conta o ordenamento dos elementos que pertencem ao mesmo nível. Por exemplo, se um nodo “autor” for pai de dois nodos do tipo “livro”, e estes dois nodos tiverem suas posições invertidas, se o algoritmo de detecção de diferenças levar em conta o ordenamento, ele detectará duas alterações no arquivo XML (as mudanças de posição dos dois nodos “livro”). Caso o algoritmo não leve em conta o ordenamento, ele considerará os dois arquivos iguais. Cabe ao programador escolher, de acordo com suas necessidades, qual o tipo de ordenamento que prefere utilizar. Em aplicações, no qual a ordem dos nodos importa, como, por exemplo, parágrafos de um livro, é preferível usar um algoritmo ordenado. Já em aplicações em que a ordem dos nodos não importa, como numa representação de uma base de dados em XML, talvez fosse interessante optar por um algoritmo desordenado.

Em (PETERS, 2004) é feita uma comparação entre os principais algoritmos que detectam alterações entre dois arquivos XML. O resultado desta comparação é exibido na tabela 3.1, considerando os critérios anteriormente descritos. Observe que nem todos os dados foram obtidos, pois nem todos os autores revelam todos os detalhes de suas implementações.

Tabela 3.1: Principais algoritmos utilizados para a detecção de diferenças entre arquivos XML

Algoritmo Complexidade Memória Operações suportadas

Ordenado/ Desordenado

Observações

LaDiff Linear O(n.e+e2)

Linear Insert, Delete, Update, Move

Ordenado Usável somente com documentos LATEX

26

MH-Diff Quadrádico O (n2log n)

? Insert, Delete, Update, Move, Copy

Desordenado

XMLTreeDiff Quadrádico O(n2) Quadrática Insert, Delete, Update

Ordenado

MMDiff Quadrádico O(n2)

Quadrática Insert, Delete, Update

Ordenado

XMDiff Quadrádico O(n2)

Linear Insert, Delete, Update

Ordenado Custo de I/O quadrático

IBM’s XML Diff and Merge Tool

? ?

? Insert, Delete, Update

? É uma ferramenta comercial

3DM’s matching algorithm

Linear O(n)

? Insert, Delete, Update, Move

Ordenado

XyDiff Linear O(n log n)

Linear Insert, Delete, Update, Move

Ordenado

VM Tools ? ?

? ? Desordenado

DiffXML Linear O(n.e+e2)

Linear Insert, Delete, Update, Move

Ordenado

KF-Diff+ Linear O(n)

? Insert, Delete, Update

Ambos

XML Diff and Patch

? ?

? ? Ambos É uma ferramenta comercial

X-Diff Quadrático O(n2)

Quadrática Insert, Delete, Update

Desordenado

DeltaXML Linear O(n2)

Linear Insert, Delete, Update

Ambos

TreePatch Linear O(n.e+e2),

Linear Insert, Delete, Update, Move

?

BioDIFF Quadrádico O(n2)

Quadrática Insert, Delete,

Desordenado Apenas para dados de

27

Update genoma ou proteínas

Fonte: PETERS, 2004

Analisando a tabela, logo se percebe que muitos algoritmos não podem ser utilizados neste trabalho, pois possuem características que inviabilizam seu uso. Imediatamente podem ser eliminados os que são ferramentas comerciais (IBM’s XML Diff e XML Diff and Patch). Também serão eliminados os que não tratam qualquer tipo de arquivo XML (LaDIFF e BioDIFF). Em seguida será feita a análise do desempenho dos algoritmos.

Alguns algoritmos, como o XMLTreeDiff e o MMDiff, possuem um altíssimo consumo não apenas de processamento, mas também de memória. Esta característica não é comum nos algoritmos ordenados, e como estes algoritmos não oferecem nenhum grande diferencial em relação aos outros, não são interessantes para uso neste trabalho. O XMDiff é um algoritmo que aparenta mostrar os resultados bastante corretos, já que usa poucas operações, mas paga um alto custo de processamento para chegar a um resultado. O X-Diff possui desempenho quadrático, mas apenas em casos muito extremos. Além disso, trabalha com árvores desordenadas, o que realmente é um problema que exige maior processamento. Tratar árvores desordenadas pode ser uma abordagem interessante, e para este problema o DeltaXML pode ser utilizado também, já que aparentemente é mais eficiente e trata não apenas árvores desordenadas como ordenadas também.

Enfim, se a preferência for pelos algoritmos mais eficientes, deve-se optar pelos algoritmos de ordem linear, como o 3DM (que além da eficiência, permite a comparação não apenas entre dois, mas também entre três arquivos XML diferentes), o XyDiff (que apresenta um ótimo rendimento), e o DiffXML.

Quanto à corretude dos resultados, são raros os algoritmos que não fornecem o resultado correto: o único que mostrou esta característica foi o IBM’s XML Diff and Merge Tool. Todos os outros algoritmos mostram resultados corretos, mas as suas saídas geradas se diferenciam na proximidade da resposta mínima, pois alguns algoritmos geram resultados mais otimizados do que outros. Como fazer uma comparação entre qual de vários algoritmos é mais eficiente para um conjunto de entradas XML seria desviar do foco deste trabalho, o algoritmo a ser utilizado será escolhido baseado na análise de seu funcionamento.

3.4 XyDiff: O algoritmo escolhido Para a necessidade deste trabalho, escolhemos usar o algoritmo XyDiff. Levando em

conta os fatores de desempenho e de corretude, foram considerados três principais candidatos: o X-Diff, o Delta Diff e o próprio XyDiff. O X-Diff não foi escolhido por não considerar o ordenamento e, para textos, por exemplo, é preciso um algoritmo que leve em consideração este fator. O Delta Diff era uma ótima opção, mas a falta de documentação deste algoritmo foi decisiva na sua eliminação. O XyDiff possui vasta documentação, implementação em Java, ótimo desempenho e, apesar de não mostrar os resultados ótimos, o autor prova em (COBÉNA, 2002) que o algoritmo gera resultados muito próximos do melhor possível. Como a pequena perda de qualidade no resultado ocorre para que o algoritmo seja muito mais eficiente, este fator não foi considerado grave, e por isso o XyDiff foi escolhido.

A seguir, será mostrada uma breve descrição do funcionamento do XyDiff. Mostrar como o XyDiff encontra as diferenças entre dois arquivos XML é importante para que o

28

seu uso na ferramenta a ser desenvolvida seja otimizado e também para que se tenha certeza de que esta foi a melhor escolha. Nas próximas subseções, os dois arquivos a serem comparados serão chamados de arquivo original (que é o arquivo que serve como base para a comparação) e arquivo alterado (que é o arquivo que queremos comparar com o original), mesmo que ele possa não ter sido efetivamente alterado.

3.4.1 Introdução ao XyDiff O XyDiff tem este nome porque foi criado para o projeto Xyleme (XYLEME,

2006), cujo objetivo é criar uma data warehouse capaz de armazenar um grande conteúdo de dados em XML. Para atingir este objetivo, é necessário que sejam comparados grandes volumes de arquivos XML diariamente. O XyDiff foi concebido originalmente em C++, mas foi encontrada em (TANI, 2006) uma implementação do XyDiff em Java, versão esta denominada JXyDiff. A preferência neste trabalho pelo Java deve-se ao fato de ser uma linguagem gratuita e com vasta documentação. Além disso, por ser bem difundida no mundo, existem vários componentes prontos em Java que reduzem o esforço gasto na confecção de novos programas.

Sucintamente, o XyDiff busca a maior subárvore sem modificações possível. A partir desta subárvore, são procurados nos nodos pais e filhos da mesma outros nodos que não sofreram modificações, filtrando, ao final de sua execução, os nodos modificados dos não modificados. O algoritmo usa também algumas heurísticas para otimizar o desempenho em relação à comparação entre duas árvores. Uma delas é diferenciar a comparação entre nodos que representam texto e nodos que representam atributos, já que, para nodos de atributos, o ordenamento não é considerado. Além disso, nodos representando atributos não possuem filhos. Outra heurística é comparar apenas os nodos que possuem nomes (ou nomes de pais e filhos) iguais, ao invés de comparar todos com todos, como no isomorfismo entre árvores, diminuindo assim o tempo de processamento.

O XyDiff gera um delta script com as operações Insert, Delete, Update e Move. Esta última é a mais custosa, pois o algoritmo gasta mais processamento para localizar a permutação de nodos. Além disso, um nodo movido de posição pode estar em um contexto totalmente diferente do anterior (pais, irmãos e filhos diferentes), dificultando sua localização. O autor prova que o algoritmo é correto e que executa em ordem O(n * log(n)). Esta ordem linear, apesar de já ser considerada baixa, só é atingida em raros casos, como quando existem muitas alterações no arquivo. Isto significa que o algoritmo, na maioria dos casos, executa num tempo muito abaixo do que o de sua ordem. O autor também mostra que os Delta Scripts gerados são em sua grande maioria bastante próximos da resposta ótima.

3.4.2 Funcionamento do algoritmo Segundo o autor mostra em (COBÉNA 2002), a execução do algoritmo se divide em 5 fases:

1) Usar informação dos atributos de ID - os elementos de um XML podem ter definidos na DTD do arquivo um atributo de ID. A primeira fase da execução consiste em encontrar todos os nodos do XML que possuem este atributo. O XyDiff usará este ID de cada nodo para encontrar um nodo correspondente no XML a ser comparado. Os nodos que não possuem atributo de ID serão localizados pelo seu contexto (informações sobre os pais e filhos destes nodos).

29

Observe que é muito mais simples para o algoritmo localizar um nodo tendo seu ID imutável do que usando heurísticas para encontrar este mesmo nodo em um contexto diferente. Assim, quanto mais nodos de ID o documento XML possuir, mais rápido o algoritmo executará;

2) Computar assinaturas e ordenar as subárvores pelo peso - nesta fase, é atribuída a cada nodo uma assinatura. Esta assinatura é um Hash gerado a partir do conteúdo do nodo e das assinaturas de seus filhos, e será usada para representar a subárvore cujo nodo raiz é o próprio nodo. Além da assinatura, é calculado também o peso de cada nodo. O peso é calculado a partir do tamanho do conteúdo do nodo e dos pesos dos nodos filhos. Após o cálculo de todos os pesos, é construída uma fila de prioridade. Esta fila contém todas as subárvores do documento (representadas pelo seu nodo raiz) e é classificada por ordem de peso. Isto significa que as primeiras posições da fila (e, portanto, com maior prioridade) serão ocupadas pelos nodos de maior peso. A primeira posição será ocupada pelo nodo raiz do arquivo. É esta fila de prioridades que decidirá quais subárvores o algoritmo vai verificar antes a equivalência de seus nodos;

3) Tentar encontrar equivalências iniciando pelos nodos com maior peso - neste passo é removida a primeira árvore da fila de prioridade (ou seja, o seu nodo raiz) do arquivo alterado e cria-se no documento original uma lista de candidatos, ou seja, nodos que têm a mesma assinatura. O algoritmo usa várias técnicas para escolher qual nodo dentre os candidatos equivale ao nodo original. Caso nenhum candidato seja aceito, o algoritmo irá procurar uma equivalência nos nodos pais dos candidatos;

4) Otimização - usar a estrutura criada para propagar a igualdade entre os nodos para evitar o processamento de tarefas complexas e dispensáveis, é feito um mapeamento de baixo para cima e depois de cima para baixo na árvore procurando nodos cujos pais são equivalentes e que tem o mesmo nome. Assim, o algoritmo evita a detecção de inserções e deleções desnecessárias, melhorando a qualidade do delta script gerado;

5) Calcular o delta script - esta fase é dividida em 3 passos. No primeiro, são procurados no documento alterado os nodos sem correspondência no documento original. Estes nodos são marcados como inseridos, deletados ou, caso seu conteúdo tenha sido alterado, como atualizados. A partir destas anotações serão calculadas as operações Insert, Delete e Update do Delta Script. No segundo passo, buscam-se os nodos idênticos nos dois documentos, porém com pais diferentes. Sabe-se que estes nodos sofreram uma operação move. Ainda assim, nodos com pais iguais nos dois documentos podem ter sido movidos junto com seus pais. Para isto o XyDiff busca diferenças nos filhos dos nodos. Este processo é muito custoso para o algoritmo e devido a este fato são usadas heurísticas que otimizam o processo e que o autor também prova em (CÓBENA, 2002) que produzem resultados muito próximos da solução mínima. No terceiro e último passo as operações são reorganizadas e o delta script é gerado. O autor não explica como este processo é realizado.

3.4.3 Análise do desempenho do XyDiff

O XyDiff é um algoritmo muito rápido, pois possui complexidade (n * log n), onde n é o número total de nodos dos dois documentos a serem comparados. Esta velocidade deve-se ao fato do processo de ler os dois documentos e de gerar um hash para cada

30

nodo ser linear. O autor prova em (COBÉNA, 2002) que tanto a execução do mapeamento de baixo para cima (descrito no passo 4 da seção anterior, executado para evitar que operações desnecessárias aconteçam), quanto as construções do delta script acontecem em tempo linear.

A inserção de nodos na fila de prioridades tem complexidade (log n). Logo, no pior caso, que é quando nenhum nodo do documento original é mapeado no documento alterado e todos os nodos são inseridos na fila de prioridades, a complexidade do algoritmo torna-se (n * log n). É interessante perceber que o pior caso dificilmente acontecerá. Então na maioria das vezes o algoritmo executará num tempo bem menor do que o delimitado pelo seu limite superior.

3.5 Considerações finais Este capítulo apresentou uma análise dos diversos algoritmos conhecidos cuja

função é encontrar as diferenças entre dois arquivos XML. Dentre estes algoritmos, o XyDiff foi o escolhido para a implementação da ferramenta proposta neste trabalho, pois é o que apresentou melhor relação entre desempenho, custo e documentação existente.

O algoritmo escolhido será de fundamental importância neste trabalho, pois ele será o núcleo da ferramenta a ser desenvolvida. Este algoritmo determinará o desempenho da ferramenta como um todo, independente de como ela foi projetada. Uma vez escolhido o melhor algoritmo para a implementação da ferramenta, é possível partir para outras questões de implementação sem a preocupação de que a sua principal funcionalidade não está pronta.

31

4 XQUERY COMO LINGUAGEM DE CONSULTA

O objetivo deste capítulo é especificar como podem ser feitas consultas sobre os documentos XML que representam versões de documentos em evolução. Primeiramente é feito um estudo sobre as linguagens XPath e XQuery e posteriormente são mostrados os trabalhos propostos para consultar documentos XML com características temporais.

4.1 XPath A linguagem XML define apenas a forma como os dados são estruturados, mas não

define nenhum meio de se obter informações específicas em um documento. Este processo deve ser feito manualmente pelo usuário, o que não é uma tarefa trivial quando o documento XML a ser pesquisado é muito grande ou quando se deseja uma grande quantidade de informações do mesmo documento. O XPath (CLARK, 99) é uma linguagem criada para definir estas partes de documentos XML, cuja sintaxe lembra a utilizada pelos programas gerenciadores de arquivos e pelos navegadores de Internet. Assim como um sistema de arquivos usa uma linha de comando para se chegar no arquivo desejado (dependendo da instrução utilizada, pode-se obter não apenas um, mas um conjunto de arquivos) e um navegador web utiliza uma URL para descrever a página desejada, a sintaxe do XPath usa uma instrução para que seja possível obter um nodo, um subconjunto de nodos ou até mesmo uma parte inteira do documento XML, desde que a informação capturada pertença a determinado caminho dentro da árvore que representa o XML, e que atendam aos critérios definidos na expressão. O XPath se tornou um padrão reconhecido pela da W3C em 16 de Novembro de 1999, e é utilizado por diversas linguagens que manipulam arquivos XML.

As expressões XPath podem ser usadas não apenas em documentos, mas também em nodos ou em conjuntos de nodos. Depois de executadas, estas expressões podem retornar o valor nulo, um tipo básico (string ou inteiro) um nodo ou um conjunto de nodos pertencentes ao documento XML sobre o qual foi feita a expressão. Por ter uma sintaxe validada e que cuja documentação é vasta, o XPath é utilizado por vários desenvolvedores quando se deseja obter um subconjunto das informações do documento.

Não é o objetivo deste trabalho oferecer um curso completo e aprofundado de XPath, mas foi percebida a necessidade de uma breve apresentação das suas principais funcionalidades. Assim, será mais fácil de entender os conceitos utilizados ao longo deste e dos próximos capítulos.

Para os exemplos de expressões XPath a serem utilizados a seguir, será considerado como documento de entrada o XML da figura 4.1. Ele representa o estoque de uma livraria, e grava as informações necessárias para cada livro à venda.

32

Figura 4.1 – XML representando o estoque de uma livraria

Neste documento, pode-se realizar uma série de consultas XPath. Na tabela 4.1 abaixo são exemplificadas algumas expressões possíveis e seus valores de retorno. É interessante perceber que, exceto por algumas variações como os filtros, o XPath é muito parecido com a sintaxe utilizada para navegar entre os arquivos do computador e através de URLs. Esta semelhança torna o XPath uma linguagem de fácil assimilação para um usuário iniciante:

Tabela 4.1: Exemplos de expressões XPath Expressão Retorno

/livros/item[2] O 2º livro da lista de livros (O Código da Vinci). As condições ficam delimitadas entre colchetes.

//item[@categoria=”ficção”] Todos os nodos que possuem o atributo “categoria” com o valor “ficção”. O símbolo “//” indica que a busca deve ser feita a partir da raiz do documento.

/livros/item[quantidade = 0]/autor Todos os autores que tiveram todos seus livros vendidos. Esta consulta retornaria vazio para o XML da figura 4.1

/livros/* Todos os livros da loja.

Existem milhares de outras possibilidades de expressões - o XPath possui cerca de 300 funções pré-definidas que auxiliam na construção destas expressões. Estas funções fornecem as mais diversas funcionalidades como, por exemplo, carregar um documento XML em disco, obter apenas o valor texto dentro de cada nodo ou obter somente o nome do nodo.

4.2 XQuery como linguagem de consulta O XQuery é uma linguagem criada a partir da necessidade de se realizar consultas

sobre arquivos XML. XQuery está para o XML assim como SQL está para os bancos de

33

dados relacionais, pois embora suas sintaxes sejam totalmente diferentes, a semântica é a mesma. O XQuery ainda não é um padrão reconhecido pela W3C, apesar de ser compatível com vários outros padrões da mesma como: Namespaces, XSLT, XPath, XML Schema e o próprio XML. Em 3 de Novembro de 2005, o XQuery ganhou o status de “working draft”, o que significa que ele é um candidato a recomendação e que deve se tornar um padrão da W3C nos próximos meses. Atualmente o XQuery está na versão 1.0.

As versões atuais do XQuery e do XPath (1.0 e 2.0 respectivamente) possuem o mesmo modelo de dados e o mesmo conjunto de funções e operadores. Esta grande semelhança com o XPath torna o XQuery uma linguagem de fácil aprendizado para o programador que já conhece XPath. Programadores SQL também não devem ter muita dificuldade em aprender XQuery, uma vez que a sua semântica é a mesma do SQL.

Nas suas instruções mais simples, o XQuery pode ser confundido com o XPath, tamanha a semelhança entre ambos. A diferença entre estas duas linguagens começa quando se deseja fazer mais do que uma consulta sobre o XML. Usando XQuery, é possível criar novos arquivos (em qualquer formato que possa ser representado como um texto plano, e não apenas XML) derivados da consulta realizada. É possível, por exemplo, embutir XQuery dentro de arquivos HTML formando assim páginas com conteúdo dinâmico.

A sintaxe do XQuery se baseia nas suas funções pré-definidas e em um conjunto de cinco operadores que lembram os do SQL. São eles: FOR, LET, WHERE, ORDER BY e RETURN. Por serem usados sempre juntos e nesta ordem (embora nem todos sejam obrigatórios), cada expressão XQuery é chamada de uma expressão FLWOR, uma abreviatura das instruções utilizadas. As expressões FLWOR possuem funcionalidade semelhante ao conjunto de instruções SELECT-FROM-WHERE do SQL, porém a sintaxe FLWOR permite a junção, algo que para ser feito no SQL necessitaria uma sintaxe diferente.

Os exemplos mostrados na figura 4.2 são baseados no conteúdo do site oficial da W3C (W3SCHOOLS, 2001) e se referem às consultas XQuery que podem ser feitas sobre um suposto arquivo “livros.xml”, que representa uma lista de livros de uma livraria. O primeiro deles mostra uma expressão XPath:

Xpath doc("livros.xml")/livraria/livro [preço > 30]/titulo XQuery for $x in doc("livros.xml")/livraria/livro where $x/preco > 30 order by $x/titulo return $x/titulo Resultado gerado <titulo lingua="en">Learning XML</titulo> <titulo lingua="en">XQuery Kick Start</titulo>

Figura 4.2 – Comparativo entre Xpath e XQuery

No exemplo apresentado, é possível compreender as várias vantagens que o XQuery possui para o Xpath mesmo quando o que se deseja fazer são consultas simples sobre um documento XML. São elas:

34

• A instrução XQuery é mais legível, pois pode ser decomposta em várias linhas;

• O XQuery permite que se trate cada nodo encontrado como uma variável (no caso do exemplo, $x – todas as variáveis em XQuery começam com ‘$’), tornando possível a execução de uma série de operações sobre a saída gerada;

• Graças à instrução “order by”, é possível ordenar a saída de acordo com algum critério especificado, algo impossível de se fazer utilizando apenas XPath.

Também se pode observar que a função utilizada para carregar o arquivo XML é a mesma nas duas linguagens (doc), além da representação de caminho como nas URLs, separando diferentes níveis por barras. O XQuery reuniu todas as boas características do XPath e melhorou aquelas deficientes, tornando-se assim a linguagem mais importante para executar consultas em documentos XML.

Consulta XQuery envolvendo elementos HTML <ul> { for $x in doc("livros.xml")/livraria/livro/titulo order by $x return <li>{$x}</li> } </ul> Resultado <ul> <li><titulo lingua ="en">Everyday Italian</titulo></li> <li><titulo lingua ="en">Harry Potter</titulo></li> <li><titulo lingua ="en">Learning XML</titulo></li> <li><titulo lingua ="en">XQuery Kick Start</titulo></li> </ul>

Figura 4.3 – Criação de um HTML com XQuery

Embora o XQuery já seja mais vantajoso do que o XPath para consultas simples, é no exemplo da figura 4.3 que se percebe o grande diferencial do XQuery: a possibilidade de gerar novos arquivos em outro formato. No exemplo citado, foi definida uma consulta XQuery que retorna todos os livros da livraria como uma lista de itens no formato html. Isto significa que é possível com XQuery construir páginas dinâmicas que variam de acordo com o conteúdo de um XML. No futuro, quando se tornar um padrão da W3C, o suporte ao XQuery provavelmente poderá vir integrado nos navegadores, possibilitando a interação das páginas com documentos XML e não apenas com bases de dados.

Por possibilitar a realização de pesquisas mais complexas e de leitura mais fácil, para a ferramenta a ser desenvolvida foi escolhido como linguagem de consulta o XQuery. Embora ainda não seja uma especificação oficial da W3C, acredita-se que num futuro próximo ela será oficializada. Portanto, as deficiências de documentação e de APIs que trabalhem com esta linguagem serão superadas com o passar do tempo.

35

4.3 Consultas temporais em documentos XML A partir do momento em que a linguagem de consulta foi escolhida, a próxima etapa

é montar um algoritmo que trate da tarefa de realizar consultas temporais em documentos XML. A necessidade de se realizar consultas temporais, e não apenas consultas convencionais surge porque os arquivos a serem utilizados são XMLs que evoluem ao longo do tempo e que possuem todos os passos desta evolução mapeados em metadados.

Foram pesquisadas duas abordagens para a realização de consultas temporais em documentos XML. Após a análise de ambas, foi montado um esquema próprio de representação temporal das informações em documentos XML. Como a metodologia criada utiliza as melhores características de cada método, para a melhor compreensão da mesma serão descritos brevemente os métodos consultados.

4.3.1 Tempo representado em 4 dimensões É apresentado em (GRANDI, 2005) um método para consultar documentos

temporais. Este modelo foi construído visando à representação do tempo em arquivos XML cujo conteúdo são as leis de um determinado país (no caso do autor, da Itália). A escolha do XML para representar as leis de um país se deu devido ao fato do mesmo possibilitar a representação hierárquica das informações, já que as leis aparecem na forma “conteúdo-seção-artigo-parágrafo”. O modelo apresentado usa quatro dimensões para representar o tempo. Estas quatro dimensões estão todas relacionadas ao ciclo de vida de uma lei, portanto, podem não ser adaptáveis para uso em outros cenários. As dimensões utilizadas são:

• Data de publicação - é a data em que a lei foi publicada no diário oficial ou equivalente do país em questão, isto é, a data em que a lei foi criada. Este atributo é definido na sua criação e permanece imutável ao longo do ciclo de vida do documento;

• Início da validade - é a data a partir da qual a lei ou uma parte da lei entra em vigor. Este atributo faz-se necessário, pois nem todas as leis passam a valer logo após a sua criação. Como exemplo é citada a criação da moeda única da União Européia, o Euro. As leis relativas ao uso do Euro já estavam definidas desde o ano 2000, mas entraram em vigor apenas em 2002;

• Data de eficácia - delimita o período em que alguma lei continua sendo usada em situações reais. Esta dimensão existe porque mesmo se alguma lei não estiver mais valendo, ela pode ainda ser utilizada para julgar casos que aconteceram enquanto ela ainda era válida;

• Tempo de transação - é o tempo que alguma lei ou parte de alguma lei ficou armazenada no sistema. Serve para uma espécie de controle sobre o sistema para que se saiba se o valor antigo de uma lei foi devolvido errado em uma consulta, quando na verdade deveria ter sido retornado o valor mais recente.

Como o primeiro atributo (data de publicação) é comum ao documento inteiro, os rótulos temporais são um produto cartesiano dos outros três atributos descritos. A pertinência temporal de cada versão é representada por um destes rótulos, que acabam sendo uma união disjunta destes intervalos de tempo tridimensionais. Para demarcar uma lei como válida até o período atual, é utilizado o símbolo “UC” (uma abreviatura

36

da expressão em inglês Until Changed – algo como “até ser alterado”) ou o símbolo de infinito - 8.

Por usar quatro dimensões para representar o tempo, esta abordagem não é muito econômica no espaço em disco ocupado. Numa tentativa de diminuir este espaço, adotou-se a convenção de que se determinado elemento tiver um rótulo temporal, todos os seus filhos herdarão este rótulo, a não ser que os mesmos tenham seus próprios rótulos. Esta metodologia, embora economize espaço em disco, faz com que as consultas tornem-se mais complexas e, portanto, menos eficientes no quesito tempo de execução. Um exemplo de rótulo temporal seria <nome_nodo vt_start=‘‘2000-01-01’’ vt_end=‘‘2003-12-31’’ et_start=‘‘2000-01-01’’ tt_start=‘‘1999-12-20’’/>. Este rótulo representa o intervalo tridimensional [01/01/2000, 31/12/2003) · [01/01/2000,UC) · [20/12/1999,UC). Aqui, os parênteses representam um intervalo aberto, onde o limite é um delimitador. Já os colchetes representam um intervalo fechado, ou seja, o extremo pertence ao intervalo.

Para tornar o método mais simples, o modelo foi equipado com dois operadores básicos: changeText, cuja função é alterar o conteúdo dos elementos do XML (permitindo assim a sua evolução) e changeTime, que permite ao programador alterar os rótulos temporais, mudando assim a pertinência dos elementos. Ambos os operadores, quando executados, gerenciam a criação de novos elementos representando as versões anteriores do elemento sendo alterado. A partir da composição destes operadores, pode-se fazer quaisquer operações desejadas, tornando de certa forma desnecessária a criação de um novo operador para cada tipo de operação. SELECT L.XML-DOC.extract(_//article_).getStringVal() FROM tnorms L WHERE (VT-START <= _01-JAN-1999_) AND (VT-END is null OR VT-END >= _01-JAN-1999_) AND (ET-START <= _01-JAN-1999_) AND (ET-END is null OR ET-END > _01-JAN-1999_) AND (TT-START <= $cur_date) AND (TT-END is null OR VT-END >= $cur_date) AND (PUBLICATION <= _01-JAN-2001_) AND CONTAINS (L.XML-DOC, _sailing WITHIN paragraph_) > 0

Figura 4.4 – Exemplo de consulta XML/SQL (GRANDI, 2005)

A figura 4.4 mostra um exemplo de consulta originalmente feita em Oracle adaptada para a sintaxe do XQuery, utilizando esta abordagem. A variável $cur_date representa a data atual do sistema, ou seja, a data em que a query foi submetida ao sistema.

4.3.2 Uma abordagem visando à aplicação em bancos de dados temporais

Em (WANG, 2003) é apresentado um método de representação temporal de arquivos XML visando a sua posterior utilização em bases de dados temporais. Entende-se por bases de dados temporais os sistemas de bancos de dados que não se preocupam apenas em armazenar a informação (como são os mais conhecidos atualmente), mas também visam guardar todas as informações que existiram na base de dados mesmo no caso delas terem sido excluídas. Estas bases possuem este comportamento para que seja possível realizar o que vem sendo estudado ao longo deste trabalho: a representação da informação ao longo do tempo, guardando suas diferentes versões para consulta posterior.

37

Como não existe um SGBD que ofereça suporte à temporalidade, os autores propuseram duas soluções para este problema. A primeira foi converter todo conteúdo da base de dados relacional para um único arquivo XML. A segunda é converter cada tabela em um XML separado e somente então neste formato é que serão executadas as operações de consulta. Utilizando esta segunda solução, é proposto um método de consulta utilizando XQuery que substitui o SQL, modelo este que é exemplificado na figura 4.5, que representa uma consulta pelo histórico salarial do empregado de nome “Bob”. Segundo o autor, também algumas consultas que seriam muito complexas se fossem feitas em SQL ficariam bem mais simples quando a linguagem utilizada é o XQuery.

Figura 4.5 – Exemplo de XQuery substituindo uma consulta SQL (WANG, 2003)

Os autores não entram a fundo no funcionamento do algoritmo. Muitas questões que surgiriam em cenários mais complexos são ignoradas como, por exemplo, a mudança em algum relacionamento entre tabelas ou a mudança de um campo de chave em um registro. Apesar disto, é possível extrair uma série de conceitos úteis para a realização deste trabalho.

Um destes conceitos é a forma como são utilizados os rótulos de tempo. Estes existem em cada nodo do documento e são representados pelos atributos tstart e tend. Caso um nodo tenha seu rótulo modificado, o rótulo do nodo é alterado e esta mudança é propagada para todos os filhos do mesmo. Quando acontece uma operação de deleção, o valor de tend é atualizado para o horário atual. Quando a operação é de inserção, um novo nodo é criado com o atributo tstart igual à hora local e tend igual a “now” (que significa que o valor que delimita que a validade da informação deste elemento ainda não acabou). Uma operação de atualização é representada por uma de deleção seguida por uma de inserção. element depts{ for $d in doc("depts.xml")/depts/dept return element dept { $d/@*, $d/*, element employees { for $e in doc("employees.xml")/ employees/employee for $ed in $e/deptno where $ed = $d/deptno and not(empty(overlapinterval($ed, $d/deptno))) return <employee> {$e/empno, overlapinterval($ed, $d/deptno)} </employee> } } }

Figura 4.6 – Consulta XQuery usando junções (WANG, 2003)

38

Nesta metodologia, os elementos dos documentos XML são agrupados pelo tempo. O autor acredita que modelos que usam agrupamento pelo tempo são mais naturais e poderosos do que os que não o fazem. Embora este tipo de agrupamento seja difícil de implementar em um banco de dados (além de estar sujeito a vários erros), é relativamente simples de implementá-lo usando XML, devido à possibilidade de rotular os elementos. Nesta abordagem, é possível criar consultas temporais complexas utilizando apenas o XQuery, sem a adição de novas funcionalidades na linguagem. Isto porque o XML e o XQuery já possuem uma vasta gama de tipos pré-definidos como datetime, date, time e duration, além de funções prontas para trabalhar com estes tipos. Caso seja necessária alguma nova funcionalidade, basta definir novas funções, como em qualquer outra linguagem de programação.

O autor mostra que, usando o SCCS, é possível realizar operações complexas do SQL (como junções) utilizando XQuery através de uma série de exemplos. Um destes exemplos é o da figura 4.5, que faz uma junção com os documentos XML contendo os empregados (“employees.xml”) e departamentos (“depts.xml”) de uma companhia, gerando um 3º documento XML hierárquico com o histórico dos empregados de cada departamento, agrupado por departamento. A função overlapinterval é uma função criada pelo usuário que retorna apenas os intervalos delimitados pelos parâmetros de data inicial e final.

Por último, é mostrada no artigo uma alternativa ao XQuery para a consulta em documentos XML, o XSLT. Com a estrutura XSLT pronta, basta passar alguns parâmetros que o processador XSLT retornará apenas os elementos desejados. Porém, como a sintaxe do XSLT é menos intuitiva e não tão flexível como a do XQuery, esta forma de realização de consultas não será adotada para este trabalho.

4.4 Considerações finais Ambos os métodos analisados são muito recentes e provavelmente serão

aperfeiçoados no futuro. Não é possível escolher o melhor, já que cada um atua em um escopo próprio. Mas como os dois possuem tanto vantagens quanto desvantagens, serviram como base para a representação do tempo na ferramenta a ser criada. No primeiro, existem várias idéias interessantes, mas que não podem ser aproveitadas, pois este método tem como objetivo representar as leis de um país. Se fosse desejado utilizar este método, por exemplo, para representar um estoque de uma loja de roupas, não haveria motivo para a existência de uma dimensão representando a data de eficácia, por exemplo, já que uma vez vendida e fora da loja, não há mais sentido em mapear a peça de roupa. A maior contribuição do artigo para este trabalho foi mostrar a forma como podem ser feitas consultas temporais em documentos XML.

A representação dos rótulos temporais mais interessante foi a utilizada na proposta de (WANG, 2003). Isto porque se deseja executar consultas temporais sobre o documento XML formado, e, portanto necessita-se que os rótulos estejam presentes em todos os elementos. O espaço em disco ocupado com esta escolha não é superior ao ocupado pela primeira proposta, pois o tamanho dos rótulos utilizados na primeira (mesmo que em menor quantidade), por representar três dimensões do tempo, acabaria ocupando mais espaço caso houvesse muitas alterações.

A metodologia utilizada pelos dois métodos para executar consultas utilizando XQuery é bastante interessante e aparentemente são eficientes. A primeira é bem tipada enquanto que a segunda oferece suporte à extensão. Porém, como neste trabalho foi

39

optado por oferecer ao usuário a possibilidade de personalizar o máximo possível suas consultas, como é feito nas ferramentas de banco de dados, não será utilizado nenhuma das formas de consultas apresentadas. O usuário será livre para escrever sua consulta utilizando apenas XQuery puro, sem nenhum acréscimo de funcionalidade, o que permitirá também que as consultas criadas na ferramenta a ser desenvolvida sejam utilizadas em outras ferramentas.

40

5 XVERSION

O objetivo deste capítulo é apresentar os resultados gerados neste trabalho, através do desenvolvimento da ferramenta XVersion. O capítulo inicia com uma apresentação das funcionalidades da ferramenta. Após, são mostrados os algoritmos desenvolvidos e printscreens da ferramenta, além das dificuldades encontradas durante o desenvolvimento de cada algoritmo. O capítulo termina com as considerações finais sobre a ferramenta desenvolvida.

Para explicar a implementação da ferramenta, será tratada a questão da união de vários documentos XML em um só, preservando a temporalidade graças ao uso em conjunto das metodologias estudadas (SCCS e XyDiff). Será proposta também a forma como os dados do arquivo gerado serão filtrados, gerando assim um documento contendo apenas o material necessário.

5.1 Visão geral da ferramenta A ferramenta desenvolvida recebeu o nome XVersion, uma abreviatura de XML

Versioner, pois se trata de uma ferramenta cujo principal objetivo é permitir o versionamento e o controle da validade dos dados de documentos XML. Ela possui uma série de funcionalidades que permitem ao usuário gerenciar melhor sua base de dados, caso esta esteja armazenada em documentos XML.

O XVersion é capaz de verificar as alterações que ocorreram entre duas versões de documentos XML. Em outras palavras, ele é capaz não apenas dizer se dois XMLs são iguais ou não, mas também pode descobrir quais são as diferenças entre os mesmos documentos. Além de verificar as alterações, o XVersion é capaz de agrupar uma coleção de dois ou mais documentos XML em um novo documento XML, com metadados de data indicando a validade de cada dado do mesmo. Por último, a ferramenta possibilita ao usuário a execução de consultas tanto sobre documentos XML gerados quanto sobre um documento XML de escolha do usuário. Na figura 5.1, onde é mostrada a arquitetura do XVersion, é possível visualizar todos os módulos que compõem a ferramenta.

A modelagem e o projeto da ferramenta, desenvolvidos de acordo com o padrão UML, estão documentados no apêndice A deste trabalho.

5.1.1 Ferramentas utilizadas Para a implementação da ferramenta XVersion, a linguagem de programação Java

foi escolhida. Isto porque, além de ser uma linguagem gratuita e independente de plataforma, a maioria das APIs pesquisadas para a implementação da ferramenta também estavam implementadas em Java. Uma última razão para justificar esta escolha é que se planeja no futuro tornar a ferramenta uma aplicação que rodará num ambiente

41

web. Esta transição de aplicação desktop para web é mais suave se a mesma linguagem for utilizada em ambas as abordagens, algo nos dias de hoje somente possível de se fazer (gratuitamente) com Java.

Figura 5.1 – Arquitetura do XVersion

5.2 Descrição da ferramenta

Figura 5.2 – Tela inicial do XVersion

Ao executar o XVersion, a tela inicial mostrada na figura 5.2 é exibida. Nela o usuário pode criar a primeira versão de um documento XML do início ou abrir documentos já existentes. O sistema fornece suporte para a criação de múltiplas versões do mesmo documento, já que, quando o usuário solicita o salvamento de um documento

42

XML, o sistema coloca um sufixo no nome do arquivo informando qual a versão do documento XML que o arquivo contém. Os três primeiros botões da barra (“Novo”, “Abrir” e “Salvar”) são responsáveis por fornecer este suporte ao usuário. A figura 5.3 mostra os passos que acontecem quando o usuário deseja salvar um arquivo. A primeira ação do sistema é perguntar ao usuário se o arquivo que ele está gravando é a primeira versão ou a nova versão de um documento XML. Caso a última hipótese seja verdadeira, o sistema automaticamente nomeia o arquivo salvo com o mesmo nome da versão anterior, alterando apenas o seu sufixo, indicando a versão do documento. Esta nomenclatura é útil para que se possa identificar quais arquivos representam versões do mesmo documento XML.

Figura 5.3 – Nomeação automática de diferentes versões de XMLs no XVersion.

A partir da tela inicial, o usuário também pode invocar as outras funções do sistema. Estas funções têm sua execução iniciada a partir do pressionamento do botão correspondente à função na barra de ferramentas do XVersion. O quarto botão (com o desenho de várias pessoas), chama a agregação de documentos XML. O quinto botão (com o ícone de uma engrenagem, simbolizando processamento), chama a função de comparação de documentos XML, e por último, o sexto botão (com o desenho de um

43

funil, representando um filtro) solicita a execução de consultas sobre o XML carregado. Todas estas funcionalidades são descritas nas subseções a seguir.

5.2.1 Colhendo as diferenças entre arquivos A primeira funcionalidade a ser utilizada pelo usuário da ferramenta é o comparador

de arquivos XML. Este comparador consiste numa função que recebe dois documentos XML como entrada e retorna como saída o Delta Script resultante da comparação entre eles. Para sua criação era necessário o uso na ferramenta de alguma biblioteca implementada em Java e que executasse o XyDiff, algoritmo escolhido no capítulo 3 para a comparação entre documentos XML. Esta biblioteca foi encontrada em (TANI, 2006) e chama-se JXyDiff (Java XyDiff). Para executar a comparação entre arquivos, o XVersion fornece ao JXyDiff os arquivos a comparar, executa-o e carrega o Delta Script gerado sob a forma de um terceiro arquivo, para poder retorná-lo ao usuário.

Figura 5.4 – Tela do XVersion mostrando a comparação entre dois arquivos.

Para poder usar esta biblioteca de funções, houveram dificuldades devidas à natureza “fechada” do JXyDiff. Isto porque o JXyDiff é um arquivo JAR, ou seja, pode ser tanto uma biblioteca de funções quanto um arquivo executável. As funções do JXyDiff foram escritas visando seu uso pelo programa fornecido pelo fabricante e que vem junto com o JAR. Uma das desvantagens desta característica é que a função que recebe os documentos XML como entrada e devolve como saída o arquivo delta representando as diferenças entre ambos precisa que os documentos XML fornecidos estejam gravados em disco. Para que fosse possível que as entradas do algoritmo fossem

44

estruturas representando documentos XML já carregadas na memória, infelizmente seria necessário reescrever o algoritmo, o que não é o objetivo deste trabalho. Ao invés de adaptar o JXyDiff ao XVersion, optou-se por adaptar o XVersion ao JXyDiff. Para isso, o XVersion só aceita que sejam solicitadas as comparações entre dois documentos XML se ambos estiverem gravados no disco.

Figura 5.5 – Arquivo delta gerado para dois documentos XML fornecidos

A figura 5.4 mostra a tela do programa solicitando que o usuário escolha quais arquivos quer comparar. O programa oferece também a possibilidade de criar os

45

arquivos XML e salvá-los em disco para posterior utilização com as funcionalidades do mesmo.

Depois de feita a comparação, o delta script com as diferenças entre os dois arquivos é retornado como uma string, que é copiada então para a tela principal do programa, onde pode ser editada ou gravada, de acordo com o desejo do usuário. A figura 5.5 mostra o arquivo delta gerado para dois arquivos XML fornecidos utilizando o XyDiff. Este arquivo mostra as operações de inserção e deleção feitas no arquivo original através de nodos Insert e Delete, respectivamente. Além disso, ele também mostra a posição original dos nodos, para que se possa localizá-los dentro dos arquivos XML analisados. Na figura, os dois arquivos superiores são o XML original e o modificado (com informações excluídas e atualizadas). É possível observar no arquivo delta todas as modificações feitas no primeiro arquivo, como a inserção das linhas 7 a 10, indicando a inclusão de um novo livro, transformando-o no segundo.

5.2.2 O SCCS para juntar arquivos O SCCS (Source Code Control System) foi o algoritmo escolhido para que fosse

feito o controle de versão (detalhes no capítulo 2). A partir de n documentos XML fornecidos como entrada, executa-se o XyDiff a cada dois documentos di e di+1 (onde i é o índice do documento XML dentro da lista de documentos fornecidos), obtendo assim n-1 documentos representando as diferenças entre cada dupla de arquivos.

O próximo passo é criar a representação do SCCS para a união de todos os n arquivos. É criado um documento XML representando a união (usando SCCS) de cada dupla de documentos fornecidos. Esta união é feita a partir dos dois documentos fornecidos di e di+1 e do arquivo delta gerado, representando as diferenças entre os documentos comparados. O último passo é juntar todas as uniões geradas em um único documento, gerando assim uma representação única de todos os XMLs fornecidos através do SCCS. As próximas subseções explicarão como funcionam os algoritmos que realizam este processo de união de documentos XML.

5.2.3 Criação do SCCS a partir de delta scripts Para construir um documento XML no modelo do SCCS, a ferramenta deve, em seu

algoritmo, executar uma série de ações. A seguir será exemplificada a união de dois arquivos XML em um só, com os rótulos temporais nos atributos de cada nodo.

Em um primeiro momento, de posse de dois arquivos XML x1 e x2 e através do algoritmo de Diff escolhido (o XyDiff), é obtido um terceiro arquivo XML x3 contendo as diferenças entre x1 e x2. Cada nodo deste arquivo descreve uma inclusão ou uma alteração que houve no processo de transição do arquivo x1 para o arquivo x2. O objetivo é criar um arquivo XML x4, que representará a união dos arquivos fornecidos como entrada. Este arquivo x4 é inicializado como uma cópia do arquivo x1, pois é ele que contém as informações inicias.

A primeira edição feita em x4 é a inserção, em cada elemento do tipo nodo, das propriedades data_inicio e data_fim, que representarão o período de validade de cada informação do documento. Para fins de otimização, ambos os atributos são preenchidos com valores pré-definidos, que possuem a menor chance de serem alterados. Como os dados iniciais pertencem todos a x1, pode-se considerar como data inicial de validade de todas as informações do documento x4 a data de criação do arquivo x1. O sistema obterá esta data e a usará para preencher cada ocorrência do atributo data_inicio em x4. Já as

46

propriedades data_fim são iniciadas com o valor “~NOW” (uma abreviação da frase “until now”). Quando a propriedade tem este valor, significa que o valor do nodo é válido até o momento atual. O sistema infere que todos os valores são válidos no momento atual, só os alterando para alguma outra data quando detectar que esta premissa é falsa, ou seja, quando for localizada alguma alteração no nodo em questão durante a transição de x1 para x2. A idéia original era iniciar todos os campos de data em branco, determinar as datas iniciais, determinar quais conteriam datas finais e só depois, nos nodos restantes, preencher a propriedade data_fim com o valor “~NOW”. Esta abordagem tornaria o algoritmo mais organizado, mas para evitar rastreamentos extras no XML (o que poderia gastar um tempo considerável dependendo do tamanho do XML), optou-se por já iniciar os atributos com os valores pré-definidos.

Na seqüência são percorridas todas as operações de alteração contidas em x3: primeiro busca-se as operações de remoção. A existência de uma operação deste tipo significa que o dado indicado existia em x1, mas deixou de existir em x2. Quando isto acontece, obtêm-se a data de criação de x2 (pois é a partir da criação deste arquivo que a informação de x1 deixou de ser válida), localiza-se o nodo excluído em x4, e à sua propriedade data_final é atribuída à data obtida. O processo se repete para cada operação de exclusão até que todos os nodos que não existam mais em x1 tenham em x4 os atributos “data_inicio” e “data_fim” preenchidos.

O último passo é continuar percorrendo x3, desta vez, porém, para buscar as operações de inserção que ocorreram em x2. Para cada operação de inserção localizada, o nodo indicado é inserido em x4 (na última posição), já com os atributos “data_inicio” e “data_fim” definidos: o primeiro é igual à data de criação do arquivo x2 com uma unidade de tempo adicionada a ela, para que no caso de uma atualização no valor de um nodo (que equivale a uma exclusão seguida de uma alteração), exista uma diferença entre a data final e inicial dos nodos. Já o segundo é feito como na inicialização de x4, ou seja, o atributo é preenchido com o valor “~NOW”, indicando que o valor é válido até o presente momento.

A figura 5.6 mostra todos os documentos envolvidos no processo descrito: Os arquivos originais x1 e x2 possuem os dados a serem analisados na criação do SCCS. O terceiro documento da figura mostra o arquivo com as diferenças x3 contendo o delta script, onde é possível ver nas linhas 2 a 6 que o carro “Gol” foi excluído da garagem e nas linhas 7 a 11 que o carro “Palio” foi inserido na mesma. Por fim, no documento final x4 estão contidas todas as informações de temporalidade de cada nodo. Tanto os nodos que não são mais válidos (como o da linha 2, representando o carro Gol) quanto os ainda válidos (como o da linha 5, representando o carro Celta) estão representados neste XML.

Para fins de simplicidade, foram utilizados documentos bem simples, mas que permitem entender corretamente a lógica do algoritmo.

47

Figura 5.6 Arquivos envolvidos na criação do SCCS

5.2.4 União dos documentos gerados Embora a criação de documentos SCCS recebendo como entrada dois arquivos

XML tenha sido bastante viável, o desenvolvimento do algoritmo que trata da união de mais de dois documentos XML a partir dos documentos SCCS gerados foi a etapa mais complexa deste trabalho. Esta dificuldade surgiu porque caso algum nodo tenha sofrido mais do que uma alteração, ele aparecerá duas vezes no documento SCCS gerado, e será necessário identificar qual das versões deste nodo é a válida. A seguir são mostradas duas propostas para a resolução deste problema. A primeira não foi adotada, porém é citada para ilustrar a dificuldade em criar tal algoritmo. A segunda abordagem foi a escolhida por tratar da maioria dos problemas que a primeira apresenta.

5.2.4.1 Equivalência de nodos pelo contexto

A primeira solução encontrada para o problema da equivalência de nodos na união de documentos XML foi a que, dados dois arquivos XML x1 e x2, para algum nodo n1 pertencente a x1, procura entre todos os nodos de x2 algum nodo n2 que seja equivalente a n1. Dois nodos são considerados equivalentes caso tenham o mesmo atributo de nome. Para ilustrar esta metodologia, considere os três arquivos XML da figura 5.7, representando três diferentes versões do mesmo documento.

Versão 1: Data: 05/10/2006 <autor> <nome>Deise</nome> <cidade>LA</cidade> </autor>

Versão 2: Data: 10/10/2006 <autor> <nome>Deise Saccol</nome> <idade>30</idade> </autor>

Versão 3: Data: 15/10/2006 <autor> <nome>Deise Brum</nome> <cidade>POA</cidade> </autor>

Figura 5.7 – 3 versões de um mesmo documento XML

48

Se fosse executado o algoritmo de criação do SCCS sobre os dois primeiros arquivos, e depois a cada par seguinte de arquivos fosse calculado o delta script entre ambos, seria possível ir adicionando seqüencialmente as informações necessárias ao arquivo SCCS gerado. Para exemplificar este processo, a figura 5.8 mostra o arquivo SCCS gerado a partir dos dois primeiros arquivos e as alterações que ele teria ao longo do processamento do Delta Script dos próximos arquivos (no caso deste exemplo, para simplificar, existe apenas um terceiro arquivo, mas poderiam perfeitamente existir quatro ou mais).

Arquivo SCCS.xml (SCCS entre versões 1 e 2): <autor TS=05/10/2006 TE=~now> <nome TS=05/10/2006 TE=09/10/2006>Deise</nome> <cidade TS=05/10/2006 TE=09/10/2006>LA</cidade> <nome TS=10/10/2006 TE=~now>Deise Saccol</nome> <idade TS=10/10/2006 TE=~now>30</cidade> </autor>

Alteração 1: nome foi alterado <autor TS=05/10/2006 TE=~now> <nome TS=05/10/2006 TE=09/10/2006>Deise</nome> <cidade TS=05/10/2006 TE=09/10/2006>LA</cidade> <nome TS=10/10/2006 TE=14/10/2006>Deise Saccol</nome> <nome TS=15/10/2006 TE=~now>Deise Brum</nome> <idade TS=10/10/2006 TE=~now>30</cidade> </autor>

Alteração 2: idade foi removida <autor TS=05/10/2006 TE=~now> <nome TS=05/10/2006 TE=09/10/2006>Deise</nome> <cidade TS=05/10/2006 TE=09/10/2006>LA</cidade> <nome TS=10/10/2006 TE=14/10/2006>Deise Saccol</nome> <nome TS=15/10/2006 TE=~now>Deise Brum</nome> <idade TS=10/10/2006 TE=14/10/2006>30</cidade> </autor>

Alteração 3: cidade foi inserida <autor TS=05/10/2006 TE=~now> <nome TS=05/10/2006 TE=09/10/2006>Deise</nome> <cidade TS=05/10/2006 TE=09/10/2006>LA</cidade> <nome TS=10/10/2006 TE=14/10/2006>Deise Saccol</nome> <nome TS=15/10/2006 TE=now>Deise Brum</nome> <idade TS=10/10/2006 TE=14/10/2006>30</cidade> <cidade TS=15/10/2006 TE=now>POA</cidade> </autor>

Figura 5.8 – Construção do SCCS para mais de dois arquivos

Num primeiro momento, esta forma de construir um documento SCCS parece correta. Porém ao se realizar uma análise mais aprofundada do mesmo, descobre-se uma falha neste modelo que compromete seu uso em larga escala. Esta falha é que, caso existam dois nodos com o mesmo nome no arquivo XML, o algoritmo não saberá identificar qual deles deixou de ser válido. Pensou-se em contornar este problema analisando não apenas o nome, mas os pais do nodo em diversos níveis de hierarquia (ou seja, o contexto em que ele se encontra), mas caso uma subárvore inteira tenha sido movida ou um nodo tenha sido retirado de sua subárvore este método cairá de novo no mesmo problema. Não é possível verificar a equivalência entre nodos pelos atributos, conteúdo ou filhos do nodo porque estas são justamente as informações sujeitas às alterações entre cada versão de um documento. Este problema ao achar nodos quando

49

existem mais de um nodo com o mesmo nome fez com que esta abordagem fosse deixada de lado. Solicitar ao usuário que informe esta equivalência não foi cogitado pois deseja-se que a ferramenta seja a mais automática e independente possível.

5.2.4.2 Equivalência de nodos pela posição

Para resolver o problema da solução anterior, decidiu-se que era necessária a inserção de metadados nos arquivos XML antes que seja executada qualquer operação sobre eles. Estes metadados indicam a posição de cada nodo dentro do XML, e a partir deles é possível descobrir qual nodo do documento x2 é equivalente ao nodo do documento x1. Para ilustrar este método, serão usados exemplos como os da seção anterior. A figura 5.9 mostra três versões do mesmo documento XML já com os metadados inseridos e indicando a posição de cada nodo inserido.

Versão 1: Data: 05/10/2006 <autor pos="0.0"> <nome pos="0.0.0"> Deise </nome> <cidade pos="0.0.1"> LA </cidade> <cidade pos="0.0.2"> NY </cidade> </autor>

Versão 2: Data: 10/10/2006 <autor pos="0.0"> <nome pos="0.0.0"> Deise Saccol </nome> <idade pos="0.0.1"> 30 </idade> <idade pos="0.0.2"> 30 </idade> </autor>

Versão 3: Data: 15/10/2006 <autor pos="0.0"> <nome pos="0.0.0"> Deise Brum </nome> <cidade pos="0.0.1"> POA </cidade> <cidade pos="0.0.2"> POA </cidade> </autor>

Figura 5.9 – 3 versões de um mesmo documento XML com metadados já inseridos.

Apesar de possuir a etapa extra para a inserção de metadados nos arquivos XML a serem processados, esta abordagem é bem parecida com a anterior. Para a união de mais de dois arquivos, por exemplo, é criado o SCCS da primeira com a segunda versão. Após, são gerados os Delta Scripts para cada novo arquivo que se deseja juntar ao SCCS gerado e a partir destes Delta Scripts são inseridos as novas informações no mesmo. Este processo de criação do SCCS para três arquivos é descrito na figura 5.10, que mostra a fase inicial (com o SCCS entre as duas primeiras versões geradas) e as posteriores, resultados da análise das alterações feitas nas versões descritas na figura 5.6.

Arquivo SCCS.xml (SCCS entre versões 1 e 2): <autor pos=0.0 TS=05/10/2006 TE=now> <nome pos=0.0.0 TS=05/10/2006 TE=09/10/2006>Deise</nome> <cidade pos=0.0.1 TS=05/10/2006 TE=09/10/2006>LA</cidade> <cidade pos=0.0.2 TS=05/10/2006 TE=09/10/2006>NY</cidade> <nome pos=0.0.0 TS=10/10/2006 TE=now>Deise Saccol</nome> <idade pos=0.0.1 TS=10/10/2006 TE=now>30</cidade>

<idade pos=0.0.2 TS=10/10/2006 TE=now>30</cidade> </autor>

Alterações 1 e 2: nome foi alterado e idade foi removida <autor pos=0.0 TS=05/10/2006 TE=now> <nome pos=0.0.0 TS=05/10/2006 TE=09/10/2006>Deise</nome> <cidade pos=0.0.1 TS=05/10/2006 TE=09/10/2006>LA</cidade> <cidade pos=0.0.2 TS=05/10/2006 TE=09/10/2006>NY</cidade> <nome pos=0.0.0 TS=10/10/2006 TE=14>Deise Saccol</nome> <nome pos=0.0.0 TS=15/10/2006 TE=now>Deise Brum Saccol</nome>

50

<idade pos=0.0.1 TS=10/10/2006 TE=now>30</idade> <idade pos=0.0.2 TS=10/10/2006 TE=14/10/2006>30</idade>

</autor> Alterações 3 e 4: a outra idade foi removida e uma cidade foi inserida

<autor pos=0.0 TS=05/10/2006 TE=now> <nome pos=0.0.0 TS=05/10/2006 TE=09/10/2006>Deise</nome> <cidade pos=0.0.1 TS=05/10/2006 TE=09/10/2006>LA</cidade> <cidade pos=0.0.2 TS=05/10/2006 TE=09/10/2006>NY</cidade> <nome pos=0.0.0 TS=10/10/2006 TE=14>Deise Saccol</nome> <nome pos=0.0.0 TS=15/10/2006 TE=now>Deise Brum Saccol</nome> <idade pos=0.0.1 TS=10/10/2006 TE=14/10/2006>30</idade>

<idade pos=0.0.2 TS=10/10/2006 TE=14/10/2006>30</idade> <cidade pos=0.0.1 TS=15/10/2006 TE=now>POA</cidade>

</autor> Alteração 5: outra cidade foi inserida

<autor pos=0.0 TS=05/10/2006 TE=now> <nome pos=0.0.0 TS=05/10/2006 TE=09/10/2006>Deise</nome> <cidade pos=0.0.1 TS=05/10/2006 TE=09/10/2006>LA</cidade> <cidade pos=0.0.2 TS=05/10/2006 TE=09/10/2006>NY</cidade> <nome pos=0.0.0 TS=10/10/2006 TE=14>Deise Saccol</nome> <nome pos=0.0.0 TS=15/10/2006 TE=now>Deise Brum Saccol</nome> <idade pos=0.0.1 TS=10/10/2006 TE=14/10/2006>30</idade>

<idade pos=0.0.2 TS=10/10/2006 TE=14/10/2006>30</idade> <cidade pos=0.0.1 TS=15/10/2006 TE=now>POA</cidade> <cidade pos=0.0.2 TS=15/10/2006 TE=now>POA</cidade>

</autor> Figura 5.10 – Construção do SCCS para mais de dois arquivos com metadados

Esta última abordagem, embora resolva muitos dos problemas encontrados, possui algumas limitações, pois não funciona para todos os tipos de alterações. Especificamente, em uma alteração que inverta a ordem de dois nodos no XML, o algoritmo não funcionará como esperado. Isto acontece porque o algoritmo de diff utilizado não considera a mudança de posição de um nodo x1, decorrente da exclusão ou inserção de outros nodos x2, x3, xi no mesmo nível de x1 como uma operação de alteração, e por isso não exibe esta operação no arquivo delta gerado. Como exemplo, são considerados dois nodos irmãos x1 e x2, ordenados de acordo com seu índice. Na fase de inserção dos metadados, serão atribuídas a x1 a posição 0 e a x2 a posição 1, conforme esperado. Porém, se suas ordens forem alteradas em uma nova versão (x2 e x1), as operações detectadas pelo XyDiff serão a exclusão de x1 da posição 0 e a inserção do mesmo na posição 1, já que agora quem está na posição 0 é x2. No primeiro arquivo SCCS gerado, o nodo x1 tinha a posição 0 e o nodo x2 a posição 1. Após a análise do delta script, o SCCS indicará que existiu um nodo x1 na posição 0 (mas que não é mais válido) e que ainda existem dois nodos válidos: x2, na posição 1 (porque a mudança de posição não foi detectada), e x1, também na posição 1. Ocorreu um erro no posicionamento dos nodos porque o XyDiff não detectou este movimento involuntário do nodo x2.

Este erro pode parecer de pequena importância se for considerado que não se deseja obter o posicionamento do nodo, mas sim seu conteúdo. Porém, este erro vai se propagar se ocorrerem alterações no XML envolvendo x2. O nodo x2, que está na posição 0, nunca será encontrado pelo algoritmo que atualiza o SCCS, pois seu metadado indica que ele está na posição 1. A conseqüência disto é que este nodo ficará para sempre marcado como válido, já que o algoritmo não o encontra para gravar sua data de expiração.

51

Mesmo com este erro, esta abordagem foi a escolhida para este trabalho. Isto porque ela funciona na grande maioria dos casos, permitindo a solução do problema de juntar três ou mais versões no mesmo arquivo. É planejado para o futuro aprimorar os algoritmos utilizados e, assim, fazer com que a ferramenta retorne melhores resultados. A figura 5.8 mostra o XVersion gerando o SCCS dos três arquivos mostrados na figura 5.11.

Figura 5.11 – SCCS de três arquivos formado com o XVersion

5.2.5 Executando consultas A última funcionalidade implementada no XVersion é a possibilidade de se executar

consultas sobre o documento XML desejado. O objetivo desta funcionalidade é permitir ao usuário abrir um documento criado utilizando o SCCS e filtrar a informação desejada através da execução de consultas sobre este arquivo.

5.2.5.1 Consultas temporais

O estudo de (WANG, 2005) mostra com clareza como é possível, após unir todas as versões de um documento XML numa só, escrever usando XQuery consultas para obter um subconjunto das informações desejadas. Se tomarmos como exemplo o documento da figura 5.12 (suponha que ele está num arquivo chamado “livraria.xml”), podemos executar algumas consultas. Uma delas é mostrada na figura 5.13, onde é feita uma consulta no XVersion por todos os livros da livraria que custam mais de cem reais. Outra consulta possível é mostrada na figura 5.14, onde é feita uma pesquisa que pede como retorno todos os livros que ainda estão disponíveis, ou seja, com o atributo “fim” igual a “~NOW”. Esta última consulta mostra ainda a possibilidade de se gerar a saída do XQuery na formatação desejada (HTML, neste caso).

52

Figura 5.12 – XML com datas de início e fim

53

Figura 5.13 – Consulta usando o valor do livro como filtro

Figura 5.14 – Consulta usando a validade do livro como filtro

54

Como a sintaxe do XQuery exige que se defina de qual arquivo XML se deseja carregar os dados, o XVersion oferece ao usuário tanto a opção de executar a sua consulta sobre um arquivo em disco quanto a de executar a mesma consulta sobre o arquivo carregado. Para tal, basta que ele substitua na instrução XQuery o nome do arquivo a ser carregado pela palavra chave LOADED, que o próprio XVersion se encarregará de substituir esta palavra chave pelo nome de um arquivo temporário a ser criado.

Existem inúmeras outras opções de consultas. Poderia-se, por exemplo, obter todos os livros que foram editados desde 2005 e que estão em estoque, ou ainda todos os livros que determinado autor escreveu a partir de determinada data. Enfim, com esta representação de XML podemos classificar as informações de acordo com o período no tempo a que elas pertencem. Esta classificação não seria possível usando o RCS, pois as informações das diferentes versões do mesmo documento estariam em arquivos diferentes, impossibilitando assim o uso do XQuery.

Caso o usuário do XVersion deseje fazer consultas temporais, mas não esteja familiarizado com XQuery, a ferramenta oferece uma opção mais acessível. Trata-se da janela do Assistente de Consultas Temporais. Nela, o usuário tem a possibilidade de escolher os filtros de data que deseja aplicar sobre o arquivo XML carregado sem especificar consulta alguma – a única tarefa do usuário é preencher os campos contendo os limites de data inicial e final, tanto para o atributo “data_inicio” quanto para o “data_fim”. A figura 5.16 mostra o resultado de uma consulta feita sobre o XML exibido na figura 5.15.

Figura 5.15 – XML sobre o qual será aplicado o filtro de consulta temporal

55

Para invocar o filtro de consultas temporais, o usuário clica no botão com a imagem de um calendário (também exibido na figura 5.16). No assistente ele determina os atributos que servirão de filtro e confirma a operação. O resultado do filtro executado é exibido na mesma tela que exibe o resultado das consultas XQuery, já que tanto a filtragem pelos rótulos de tempo quanto as consultas temporais possuem a mesma semântica, que é restringir a informação do documento carregado.

Figura 5.16 – Execução do assistente para consultas temporais no XVersion

5.2.5.2 Executando XQuery

O XVersion possui a funcionalidade de permitir ao usuário executar consultas utilizando XQuery. Para acessar esta funcionalidade, o usuário deve, após abrir um documento XML, clicar no botão XQuery, com o ícone de um funil (representando a filtragem da informação). Uma janela se abrirá e nela o usuário poderá realizar tanto consultas XQuery quanto XPath, já que o Xpath está incluso no XQuery.

56

Tornar possível a execução de consultas XQuery no XVersion não foi uma tarefa trivial. Isto porque, por ainda não ser uma linguagem reconhecida pela W3C, não foi incluída no Java uma API para o tratamento de consultas neste formato. O que existem são bibliotecas proprietárias que fazem o que uma API que viria integrada com o Java faria. Dentre estas bibliotecas, a mais conhecida é a XQJ (DATADIRECT, 2005), uma abreviação para XQuery API for Java. Esta API pode ser usada em várias plataformas Java, como a J2EE e a J2SE. Ela também permite que sejam realizadas tarefas que não são possíveis com o XQuery, como o uso de Webservices e o acesso a árvores DOM. Embora seja uma biblioteca que realize todas as funções desejadas e de fácil uso, seu uso na ferramenta desenvolvida foi inviabilizado devido ao fato de ser uma API paga.

Uma alternativa encontrada para o XQJ foi o Qizx/Open (AXYANA, 2005). Esta é uma biblioteca distribuída sob a licença GNU (e, portanto, gratuita) pela Axyana Software. Esta API é uma versão reduzida de uma outra API, desenvolvida pela mesma empresa, e que cujo objetivo também é executar XQuery. O Qizx/Open implementa a mesma interface do XQJ e segue os padrões da W3C, o que significa que caso uma API para XQuery seja inclusa ao Java no futuro, provavelmente não haverá incompatibilidade com o código gerado usando esta API desenvolvida por terceiros.

Além da falta de documentação, uma das dificuldades encontradas na integração desta API no XVersion é que o programa teve que se adaptar à forma como foi implementada a API, e não o contrário. Isto porque o Qizx/Open, para funcionar corretamente e sem a necessidade de alterações em seu código, deve receber como entrada um arquivo texto com o conteúdo da consulta, realizar o processamento e então retornar o resultado da mesma num outro arquivo de texto. Este processo de carregar e salvar em arquivos texto os dados, embora funcione perfeitamente, é pouco prático numa ferramenta que planeja fornecer um apoio visual ao usuário que deseja executar consultas.

A solução encontrada foi a seguinte: na janela que se abre para que o usuário digite a sua consulta (já demonstrada nas figuras 5.13 e 5.14), existe o botão “Executar Consulta”, representado por um funil - como no formulário principal. Quando este botão é clicado, o seguinte fluxo de processos é disparado: primeiro, é criado um arquivo texto temporário com a consulta digitada. Após isto, é chamada a biblioteca Qizx/Open, que abrirá o arquivo recém gerado e gravará outro com o resultado. Por último, o arquivo com o resultado gerado é carregado no editor da janela. Todas estas operações de carregamento e salvamento de arquivos temporários, executadas a cada consulta, são transparentes ao usuário, que tem a ilusão de que o processamento é todo feito pelo próprio programa. Esta abordagem não é a ideal para o uso em uma ferramenta que prima pelo desempenho, mas infelizmente, pela falta de APIs satisfatórias disponíveis, ela teve que ser utilizada. Planeja-se para o futuro, quando o XQuery for formalizado pela W3C, substituir esta API por alguma que venha integrada com o Java.

5.3 Considerações Finais XVersion, a ferramenta desenvolvida para a detecção de diferenças, união e

consultas em documentos XML, representa um importante passo na popularização do XML, pois cria formas de resolver problemas existentes e que antes não tinham solução. Para a detecção de alterações, o que existe no Java são métodos que apenas dizem se dois documentos XML são iguais um ao outro, e não entram na análise mais profunda de quais mudanças ocorreram. Para o problema da união de arquivos em SCCS, não

57

existe nem ao menos algoritmos prontos para realizar tal tarefa. Por último, para a execução de consultas, existem ferramentas pagas e as gratuitas não oferecem uma boa interface com o usuário.

Apesar de ainda possuir certas limitações, acredita-se que o XVersion será muito útil para acadêmicos e profissionais que trabalham com XML. A partir do XVersion, podem surgir interessantes idéias de ferramentas a se desenvolver voltadas ao XML, como por exemplo, uma ferramenta controladora de versão (como o ClearCase®) voltada exclusivamente para XML.

58

6 CONCLUSÃO

Este trabalho apresentou o XVersion, uma ferramenta que possibilita ao usuário de documentos XML comparar, agrupar e fazer pesquisas em documentos XML. Nela o usuário pode criar, carregar e editar seus XMLs como preferir, além de fornecer uma interface amigável para funcionalidades presentes em pouquíssimas (todas ao mesmo tempo, nenhuma) ferramentas disponíveis no mercado.

A ferramenta tem como objetivo contribuir para que seja possível realizar com XML tarefas hoje feitas apenas através de bancos de dados: controle de versões, consultas em bases e armazenamento de informações. Entende-se que a tendência é que no futuro o XML seja ainda mais utilizado e, ainda que esta tendência não se confirme, é sempre bom ao projetista de sistemas ter mais de uma opção de tecnologia para escolher qual atenderá suas necessidades.

As principais contribuições desta ferramenta foram, além de reunir funcionalidades que já existiam com funcionalidades novas todas em uma mesma aplicação, facilitar o acesso a estas que já existiam. Isto porque, as ferramentas prontas que comparam documentos XML e executam consultas são aplicações de linha de comando, às vezes difíceis de serem usadas por programadores acostumados com interfaces gráficas. O XVersion torna transparente todo o acesso a estas funcionalidades, tornando seu uso fácil para quem não está acostumado a digitar comandos em prompts. Espera-se que o XVersion seja uma alavanca que ajude a impulsionar o uso do XML em todos os meios, tanto o acadêmico quanto o empresarial.

6.1 Trabalhos futuros Para projetos futuros, os objetivos principais são três. O primeiro e talvez mais

viável seja migrar o XVersion para a web, talvez utilizando a linguagem JSP, pois os algoritmos implementados estão em Java. Esta migração deixaria o XVersion mais acessível para seus usuários, já que todos teriam acesso ao programa através de um ambiente web, independente da plataforma instalada na máquina do usuário . A segunda alteração se refere aos algoritmos de terceiros utilizados: o objetivo é criar algoritmos próprios que realizem as operações que atualmente são executadas utilizando bibliotecas de terceiros, permitindo assim a atualização do algoritmo e a independência da ferramenta perante outros autores, além de eliminar problemas relativos à comunicação com estas bibliotecas. O terceiro e último objetivo é melhorar o algoritmo de criação do SCCS para mais de dois arquivos. Um quarto objetivo, não tão principal quanto os anteriores, seria estender a ferramenta para que pudesse reconhecer comentários e outras estruturas relacionadas ao XML, como XSLT e DTDs.

59

7 REFERÊNCIAS

TICHY, W. F. RCS – A System for Version Control. Software-Practice & Experience, Nova York, p. 637-654, jul. 1985. ROCHKIND, M. J. The Source Code Control System. IEEE Transactions on Software Engineering, v.1, n. 4, p.364-370, dez. 1975. W3C. Extensible Markup Language (XML). World Wide Web Consortium, dez. 1997. Disponível em: <http://www.w3.org/XML/>. Acesso em: abr. 2006. W3C. XML Query (XQuery). World Wide Web Consortium, jan. 2003. Disponível em: <http://www.w3.org/XML/Query/>. Acesso em: jun. 2006. PETERS, Luuk. Change Detection in XML Trees: a Survey. University of Twente: Faculty of Electrical Engineering, Mathematics and Computer Science, Twente, Escócia, 2004. WANG, Yuan; DEWITT, David J.; CAI, Jin-Yi. X-Diff: An Effective Change Detection Algorithm for XML Documents. University of Wisconsin, Madison, WI, U.S.A., 2005. VALIENTE, Gabriel. Tree Edit Distance and Common Subtrees. Department of Software, Technical University of Catalonia. Barcelona. 2005. BILLE, Philip. Tree Edit Distance, Alignment Distance and Inclusion. IT University Technical Report Series. mar. 2003. DULUCQ, Serge; TOUZET, Hélene. Analysis of tree edit distance algorithms. LaBRI – University Bordeaux. Bordeaux, França, 2000. GAROFALAKIS, Minos; KUMAR, Amit. Correlating XML Data Streams Using Tree­Edit Distance Embeddings. Symposium on Principles of Database Systems, San Diego, CA, p. 143-154, 2003. COBÉNA, Grégory; ABITEBOUL, Serge; MARIAN, Amélien. Detecting Changes in XML Documents. Proceedings of the IEEE International Conference on Data Engineering, San Jose, EUA, p. 41-52, 2002.

60

SUDARSHAN S. Chawathe; MOLINA, Hector Garcia. Meaningful change detection in structured data, Proceedings of the 1997 ACM SIGMOD international conference on Management of data, p. 26-37. Tuncson, Arizona, EUA, mai. 1997. WANG, Yuan; DeWITT, David J.; CAI, Jin-yi. X-Diff: An Effective Change Detection Algorithm for XML Documents. Proceedings of the 19th International Confererence on Data Engineering, IEEE Computer Society Press, Bangalore, Índia, p. 519-530, mar 2003. DELTAXML. A Delta Format for XML: Identifying Changes in XML Files and Representing the Changes in XML. XML Europe , 2001, Berlin, mai. 2001. COBÉNA, G.; ABDESSALEM, T.; HINNACH, Y. A comparative study for XML Change detection. INRIA, França, 2000. CÓBENA, G.; ABITEBOUL, S.; MARIAN, A. Detecting Changes in XML Documents. Proceedings of the 18th International Conference on Data Engineering, San Jose, EUA, p. 41-52. fev. 2002. XYLEME. Xyleme project. Disponível em <http://www.xyleme.com/>. Acesso em: setembro 2006. TANI, R.; MOLLI, P.; JOUILLE, F. JXyDiff. LibreSource. Disponível em <http://potiron.loria.fr/projects/jxydiff/>; Acesso em: setembro 2006. WOOD, L. et. al. Document Object Model (DOM) Level 1 Specification (Second Edition). World Wide Web Consortium (W3C). Set. 2002 Disponível em <http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/>. Acesso em: Novembro 2006. CLARK, J. et. al. XML Path Language (XPath). World Wide Web Consortium (W3C). nov. 1999. Disponível em: <http://www.w3.org/TR/xpath>. Acesso em: Abril 2006. DA SILVA, R. G. Uma proposta de extensão temporal para XML e realização de consultas. CLEI - XXVII LATIN-AMERICAN CONFERENCE ON INFORMATICS. Ciudad de Merida, Venezuela, 2001. WANG, F., ZANIOLO, C. An XML-Based Approach to Publishing and Querying the History of Databases. World Wide Web n. 8, p. 233-259, 2005. W3Schools, XQuery Tutorial. W3Schools Online Web Tutorials. 2001. Disponível em <http://www.w3schools.com/xquery>. Acesso em Agosto 2006. GRANDI, F.; MANDREOLI, F.; TIBERIO, B. Temporal modelling and management of normative documents in XML format. Data & Knowledge Engineering, v. 54, n. 3, p. 327-354, 2005.

61

DATADIRECT, XQJ – XQuery API for Java. 2005. Disponível em <http://www.datadirect.com/developer/xquery/index.ssp>. Acesso em Outubro 2006. AXYANA SOFTWARE. Qizx/Open. 2005. Disponível em <http://www.axyana.com/qizxopen>. Acesso em Outubro 2006. DEITEL, H.M., DEITEL, P. J. Java – Como Programar. 4ª ed. Porto Alegre: Bookman, 2003. DEITEL, H.M. et. Al. XML – Como Programar. 1ª ed. Porto Alegre: Bookman, 2005. LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e ao projeto orientados a objetos e ao processo unificado. 2ª ed, Porto Alegre, Bookman, 2004. W3C WORKING GROUP. XML Query (XQuery) Draft. World Wide Web Consortium (W3C). Nov. 2005. Disponível em <http://www.w3.org/XML/Query/>. Acesso em: Novembro 2006.

62

APÊNDICE: ARQUITETURA DO XVERSION

Este apêndice apresenta, de maneira simplificada a arquitetura da ferramenta

desenvolvida, o XVersion. O objetivo é permitir que se obtenha um total entendimento das funcionalidades da ferramenta e de como cada uma destas funcionalidades foi desenvolvida.

Para descrever as ações que a ferramenta utiliza, serão mostradas as seguintes estruturas da UML (LARMAN, 2004): diagramas de caso de uso, descrição de casos de uso, diagramas de seqüência e diagramas de classe.

A.1 Diagrama de casos de uso A figura A.1 mostra o diagrama de casos de uso do XVersion. Embora possa parecer

bem simples devido ao baixo número de funcionalidades, a ferramenta desenvolvida é bastante complexa. Isto porque cada um dos requisitos desenvolvidos demandou grande esforço na programação e, principalmente, na pesquisa.

Figura A.1 – Diagrama de casos de uso do XVersion.

63

A.2 Diagrama de classes A figura A.2 mostra o diagrama de classes do XVersion. As funcionalidades

privadas a cada classe foram omitidas para fins de simplificação. No diagrama é possível visualizar os relacionamentos entre cada classe da ferramenta e as packages de terceiros que são utilizadas na mesma. A próximas subseções tratarão de relatar a função de cada classe dentro da ferramenta desenvolvida.

Figura A.2 – Diagrama de classes do XVersion

A.2.1 Classe: Constantes Esta classe é a mais simples do programa. Contém todas as constantes que são utilizadas pela aplicação. As strings utilizadas no XVersion também estão todas contidas nesta classe. Portanto, quando se deseja exibir uma mensagem, ao invés de se descrever o texto desejado, é feita uma chamada à constante equivalente a esta mensagem.

A.2.2 Classe: Main Esta é a classe que é chamada quando ocorre a execução do programa. Ela cria os arquivos temporários iniciais e faz com que o formulário principal seja exibido.

64

A.2.3 Classe: DOMManager É a maior classe do XVersion. Possui uma série de métodos que fazem a manipulação de árvores DOM que as bibliotecas do Java não fazem, como por exemplo, a busca de nodos a partir do seu atributo de posição. Estes métodos são necessários para a união de vários arquivos em um só, a partir do algoritmo do SCCS, que também é implementado nesta classe.

A.2.4 Classe: frmPrincipal Representa o formulário principal da aplicação. Todos os requisitos do sistema são invocados a partir desta classe. Também é responsável por exibir os XMLs carregados e por criar os arquivos temporários necessários, como por exemplo, os que servirão de entrada para o XyDiff.

A.2.5 Classe: dlgXQuery Representa o formulário que recebe uma consulta XQuery e a executa sobre o XML aberto no formulário criado pela classe frmPrincipal. Também oferece uma interface para abrir e salvar as consultas criadas.

A.2.6 Classe: XMLManager A biblioteca do XyDiff é utilizada diretamente por esta classe. O XVersion utiliza-a para fazer as comparações entre diversos arquivos XML. A classe possui um único método público (além de outros auxiliares) que torna o acesso à biblioteca JXyDiff transparente para o resto do sistema. A transferência de documentos XML entre o XVersion e o XyDiff é feita a partir de arquivos temporários.

A.2.7 Classe: XQuery Esta classe foi baseada na aplicação exemplo que vem junto com o Qizx/Open. Esta classe fornece uma interface de linha de comando para o processador XQuery, que usa Saxon. A sintaxe do XQuery desta biblioteca está em conformidade com o draft da W3C para o XQuery. Se comunica com a classe ExecutorXQuery, que é a porta de comunicação com o Qizx/Open.

A.2.8 Classe: ExecutorXQuery Também baseada na aplicação exemplo do Qizx/Open, esta classe chama diretamente os métodos desta biblioteca. Como na versão original do programa exemplo o resultado das consultas é impressa na linha de comando, a alteração mais substancial foi mudar a forma de retorno dos dados para um arquivo texto, que pode ser aberto pelo XVersion e que é utilizado pela classe XQuery.

A.3 Casos de uso e diagramas de seqüência

A.3.1 Gerar Delta Script entre dois documentos Ator: Usuário do sistema.

Finalidade : Recebe dois documentos XML e retorna o Delta Script que informa as alterações entre ambos.

Visão Geral: Com a ferramenta aberta, o usuário solicita a comparação entre dois documentos XML já gravados anteriormente em disco. Os dois documentos

65

representam versões diferentes do mesmo XML e o sistema retorna o Delta Script entre as duas versões.

Tipo: Secundário.

Tabela A.1 – Seqüência típica de eventos do caso de uso Gerar Delta Script entre dois Documentos

Ação dos Atores Resposta do Sistema 1. O usuário clica no botão “XyDiff it!”. 2. Exibe a tela que solicita que o usuário

escolha quais os dois arquivos que deseja comparar.

3. O usuário escolhe os dois arquivos a comparar.

4. Mostra no formulário principal o delta script entre os arquivos XML selecionados. O usuário ainda tem a opção de salvar o XML gerado para posterior uso.

A.3.1.1 Diagrama de seqüência do caso de uso Gerar Delta Script entre 2 Documentos

Figura A.3 – Diagrama de seqüência da geração de um delta script

A.3.2 Unir vários documentos (SCCS) Ator: Usuário do sistema.

Finalidade : Recebe uma série de documentos XML e retorna um novo documento XML com a união de todos os documentos passados.

66

Visão Geral: Com a ferramenta aberta, o usuário solicita a união de dois ou mais arquivos XML já gravados anteriormente em disco. Os arquivos representam versões diferentes do mesmo documento XML e o sistema retorna a representação do SCCS para todos estes documentos.

Tipo: Primário.

Tabela A.2 – Seqüência típica de eventos do caso de uso Unir Vários Documentos Ação dos Atores Resposta do Sistema 1. O usuário clica no botão “Juntar”. 2. Exibe a tela que solicita que o usuário

escolha quais os arquivos que deseja utilizar na formação do SCCS.

3. O usuário escolhe os arquivos a unir. 4. Mostra no formulário principal a representação SCCS para todos os arquivos XML selecionados. O usuário ainda tem a opção de salvar o XML gerado para posterior uso.

A.3.2.1 Diagrama de seqüência do caso de uso Unir Vários Documentos

Figura A.4 – Diagrama de seqüência para a união de vários documentos através do

SCCS

67

A.3.3 Executar consultas XQuery Ator: Usuário do sistema.

Finalidade : Recebe uma consulta XQuery e a executa sobre o arquivo XML já aberto anteriormente.

Visão Geral: Após ter carregado algum XML ou ter executado algum caso de uso na ferramenta aberta, o usuário solicita a execução de uma consulta sobre o XML que já está carregado no formulário principal. O resultado da consulta é exibido num novo formulário.

Tipo: Primário.

Tabela A.3 – Seqüência típica de eventos do caso de uso Executar Consultas XQuery Ação dos Atores Resposta do Sistema 1. Após ter carregado de alguma forma um documento XML na tela principal, o usuário clica no botão “Executar Consulta”.

2. Exibe a tela que solicita que o usuário escreva a consulta que deseja fazer sobre o XML carregado.

3. O usuário especifica a consulta. 4. Mostra na mesma tela o resultado da consulta, ou seja, o XML original com informações filtradas. O usuário ainda tem a opção de salvar a consulta para posterior uso.

A.3.3.1 Diagrama de seqüência do caso de uso Executar Consultas XQuery

Figura A.5 – Diagrama de seqüência para a execução de consultas