Müdafinin Yardımından Faydalanma Hakkı

Subquestões de investigação Todos os formatos de dados selecionados para esta expe-

riência têm a capacidade de poder ser utilizados na troca de informação georreferenciada. Como o NVG é o formato dados desenvolvido pela NATO para o domínio especifico da troca de informação georreferenciada entre C2, é nossa convicção que o NVG é mais efi- ciente (quer no tamanho de ficheiros produzidos, quer no tempo de envio desses fichei- ros) que os formatos alternativos selecionados para esta comparação. Para analisar mais facilmente os objetivos Obj1 e Obj2 definidos em5.2.1, decidimos formular cinco sub- questões de investigação para servirem de base a esta comparação, e que se relacionam com os objetivos da seguinte forma:

Obj1: q1 O formato de dados NVG produz ficheiros de dados mais pequenos que os formatos alternativos?

Obj2: q2 O formato de dados NVG tem tempos de processamento de operações de transformação XSLT dos documentos XML mais pequenos que os formatos alternativos?

q3 O formato de dados NVG tem tempos de compressão dos ficheiros de dados

mais pequenos que os formatos alternativos?

q4 O formato de dados NVG tem tempos de descompressão dos ficheiros de da-

dos mais pequenos que os formatos alternativos?

q5 O formato de dados NVG tem tempos de validação dos documentos XML

mais pequenos que os formatos alternativos?

Métricas aplicadas No seguimento da abordagem Objetivo, Questões e Métricas definida

em [Sha03], apresentamos as métricas que se impõem no contexto das questões levanta- das. Para respondermos à primeira subquestão, q1, avaliamos os formatos de dados em termos de métricas de tamanho[KSH02], sendo usadas as seguintes métricas:

• FileSize, número de bytes que o ficheiro ocupa após ter sido gerado;

• FileSizeSS, número de bytes que o ficheiro ocupa após ter sido realizada a operação

de transformação XSL de Strip-space;

• ZipFileSize, número de bytes que o ficheiro ocupa após ter sido comprimido;

5. AVALIAÇÃOQUANTITATIVA 5.2. Planeamento da experiência

Medimos o FileSize, porque este representa o tamanho da informação após ter sido gerada nos seu estado natural. Para medirmos o tamanho do ficheiro após a operação de Strip-spaceutilizamos a métrica FileSizeSS. Dado que operação de compressão afecta de forma muito diferente cada formato de dados, usamos a métrica ZipFileSize para medir o tamanho final do ficheiro após ter sido comprimido. Finalmente, também medimos o número de XML nodes do documento XML, XMLSize. Esta métrica é importante porque o número de XML nodes tem influência nas operações a realizar sobre o documento XML, nomeadamente: transformação XSL e a validação. Com estas quatro diferentes métricas, esperamos mitigar ameaças à validade que resultaria de usar apenas uma métrica para medir o tamanho do formato de dados.

No que diz respeito às restantes (q2, q3, q4 e q5), todas elas estão relacionadas com tempo gasto no processo de transferência do ficheiro, procedemos à utilização das se- guintes métricas de performance:

1. Strip-space Time, o tempo, em milissegundos, que a operação de transformação XSLT Strip-space leva a processar o documento XML;

2. Compression Time[Sak09], o tempo, em milissegundos, que a operação de com- pressão leva a processar o ficheiro;

3. Decompression Time[Sak09], o tempo, em milissegundos, que a operação de des- compressão leva a processar o ficheiro;

4. Validation Time, o tempo, milissegundos, que a operação de validação leva a pro- cessar o ficheiro;

A aplicação das métricas de tamanho e de performance foi conseguido mediante o de- senvolvimento das operações Strip-space, Compression, Decompression e Validation, aplica- das ao ficheiro durante o seu processo de transferência do Produtor para o Consumidor. Vamos de seguida fazer uma breve análise sobre cada uma das operações e explicar o modo de como é realizada a aplicação das respetivas métricas:

• Strip-space, esta operação remove os espaços em branco existentes no documento

XML. Os ficheiros XML quando são gerados, são sujeitos a regras de indentação (que permitem uma mais fácil leitura dos documentos XML, por seres humanos) que introduzem muitos "espaços em branco"nos ficheiros. Dado que, este "espaço em branco"não altera em nada a informação a transmitir e tem taxas de ocupa- ção muito consideráveis, optamos por introduzir uma operação de transformação XSL, Strip-space[MK07], para a remoção dos "espaço em branco"dos respetivos do- cumentos XML. Aplicação das métricas: o elemento Metrics Register carrega o fi- cheiro XML do FileSystem, carrega a folha de estilos XSL cuja a única instrução é aplicação da operação Strip-space, e aplicada a transformação XSL um novo ficheiro é guardado no FileSystem e as métricas do tamanho do novo ficheiro e do tempo gasto na operação de Strip-space são guardadas na base de dados ScenarioDB (ver figura5.4).

5. AVALIAÇÃOQUANTITATIVA 5.2. Planeamento da experiência

Figura 5.4: Diagrama de aplicação da transformação XSL Strip-space.

• Compression, esta operação comprime o ficheiro XML. Para diminuir o tamanho

do ficheiro a ser transmitido durante a troca de informação, resolvemos aplicar uma operação de compressão ao ficheiro antes de o transmitir. Existem vários compres- sores para ficheiros XML, que podem ser divididos em: General Text compressor ou XML Conscious Compressors[Sak09]. Utilizamos um do tipo General Text compres- sor, disponibilizado nas bibliotecas do Java, que utiliza o algoritmo de compressão DEFLATE3 _{e grava a informação binária no bem conhecido format de dados ZIP.}

Este algoritmo de compressão DEFLATE obteve excelentes resultados nos testes re- alizados em [Sak09]. Aplicação das métricas: o elemento Metrics Register carrega o ficheiro XML do FileSystem, e aplicada a operação de compressão Zip um novo ficheiro comprimido no formato ZIP é guardado no FileSystem e as métricas do tamanho do novo ficheiro e do tempo gasto na operação de Zip Compression são guardadas na base de dados ScenarioDB (ver figura5.5).

Figura 5.5: Diagrama da aplicação da operação de compressão Zip Compression.

• Decompression, esta operação descomprime o ficheiro comprimido, ZIP, para o

estado original do ficheiro. O cliente recebe o ficheiro enviado pelo servidor, em formato binário ZIP, e aplica a operação descompressão (inversa à compressão), para obter o ficheiro XML no seu estado original. Aplicação das métricas: o ele- mento Metrics Register carrega o ficheiro ZIP do FileSystem, e aplicada a operação de descompressão UnZip Decompression um novo ficheiro XML é guardado no Fi- leSysteme as métricas do tamanho do novo ficheiro e do tempo gasto na operação de UnZip são guardadas na base de dados ScenarioDB (ver figura5.6).

• Validation, esta operação valida o documento XML recebido de acordo com o

schema. Quando uma aplicação recebe um ficheiro XML, por norma, esta aplica- ção verifica se o documento XML que vem no ficheiro está de acordo com o schema

5. AVALIAÇÃOQUANTITATIVA 5.2. Planeamento da experiência

Figura 5.6: Diagrama da aplicação da operação de descompressão UnZip Decompression. definido para esse documento. Esta operação permite antecipar problemas com er- ros no documento XML que prejudiquem o normal funcionamento da aplicação. Aplicação da métrica: o elemento Metrics Register carrega o ficheiro XML do Fi- leSystem, e aplicada a operação Validation de validação do ficheiro XML carregado, depois de fazer a validação a métrica do tempo gasto na operação de Validation é guardada na base de dados ScenarioDB (ver figura5.7).

Figura 5.7: Diagrama da aplicação da operação de validação XML Validation.

Quadro Resumo A figura5.8, apresenta um quadro com a aplicação das métricas de

tamanho e de performance antes identificadas, ao longo das diversas operações realizadas na transferência de um ficheiro do Produtor para o Consumidor. No quadro observamos também qual a tecnologia em causa em cada operação.

5. AVALIAÇÃOQUANTITATIVA 5.2. Planeamento da experiência