| Summary: | Made available in DSpace on 2014-06-12T15:58:08Z (GMT). No. of bitstreams: 2
arquivo3259_1.pdf: 5762420 bytes, checksum: 0af73887e3af768529c1569155447ba5 (MD5)
license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5)
Previous issue date: 2011 === FUNDAÇÃO DE APOIO AO DESENVOLVIMENTO DA UFPE === Linhas de Produtos de Software (LPS) são definidas como conjuntos de sistemas de software
que atendem a um mercado especifico, que compartilham caracteristicas em comum,
porem sendo suficientemente distintos entre si, e que são desenvolvidos a partir de um
conjunto de artefatos reusaveis. Entre os beneficios possiveis com a implantação de LPS
podemos citar o reuso em larga escala e o aumento de produtividade. Um fator-chave no
desenvolvimento de uma LPS e o mecanismo utilizado para a estruturação fonte. Uma das tecnicas mais comumente utilizadas para a estruturação de
variações de código e a compilação condicional, tambem chamada de pre-processamento.
Apesar de ser amplamente utilizada, o uso de compilação condicional incorre em problemas
de legibilidade, modularidade, manutenibilidade e qualidade.
Programação Orientada a Aspectos (POA) e uma alternativa a compilação condicional
para a estruturação de variações de codigo em LPS, podendo apresentar melhor
legibilidade, modularidade, manutenibilidade, qualidade, entre outros fatores, do que a
compilação condicional. Entretanto, o uso de AspectJ, implementação mais popular de
POA sobre a linguagem Java, como mecanismo de estruturação de variações gera um
overhead (aumento) sobre o tamanho final do codigo compilado. No contexto de LPS
de sistemas para plataformas em dispositivos moveis, em plataformas como Java ME,
que possuem restrições de memoria, esse overhead pode tornar inviavel o uso do produto
final.
Neste trabalho, analisamos o impacto do uso de AspectJ como mecanismo de estruturação de variações sobre o tamanho do codigo compilado e investigamos os motivos por
tras deste aumento. Para tal, utilizamos o BestLap e o Juggling, duas LPS de jogos para
dispositivos Java ME que possuem uma versão puramente pre-processada e uma versão
hibrida, que utiliza pre-processamento e AspectJ. Utilizamos o BestLap na analise de
tamanho para quanticar o overhead com dois compiladores AspectJ, o ajc e o abc.
Em seguida, analisamos o codigo compilado de um subconjunto das construções As pectJ, a fim de identificar quais construções geram overhead no tamanho do codigo compilado
e os motivos por tras deste overhead. Esse subconjunto consistiu de todas as
construções AspectJ utilizadas na versão híbrida do BestLap e do Juggling, o ultimo
utilizado apenas para a elicitação das construções analisadas.
Com base nessa investigação, desenvolvemos quatro otimizações para o compilador abc
que modificam o codigo compilado de certas construções visando a eliminar o overhead.
Apresentamos detalhes da implementação e discutimos as pre-condições e a corretude das
otimizações desenvolvidas. Em seguida, apresentamos o resultado da aplicação destas
otimizações em duas LPS e discutimos como implementações diferentes, porem equivalentes,
da mesma variação em AspectJ podem inviabilizar a aplicação das otimizações
Por fim, para garantir que as modificações realizadas pelas otimizações não prejudiquem o
desempenho, apresentamos o resultado de testes de desempenho realizados em programas
AspectJ usados em benchmarks apos a aplicação das nossas otimizações
|
|---|
