Qualitative research: the choice of the method

O estudo de caso realizado foi reportado no trabalho de Sales Júnior e Coelho (2011). Neste estudo de caso foram utilizadas 4 versões da MobileMedia, tanto as versões orientadas a objetos (OO), quanto as versões orientadas a aspectos (AO). A utilização dessas múltiplas implementações foi importante para verificar os contratos de comportamento excepcional não somente entre diferentes verões do mesmo sistema, mas também entre diferentes implementações.

Após selecionar o sistema, o comportamento do tratamento de exceções da aplicação foi analisado manualmente na primeira versão orientada a objetos (OO 1.0). Com base na análise manual dessa nessa versão foram extraídos os contratos de tratamento de exceção que seriam verificados nas versões posteriores (tanto OO quanto AO). Como resultado foi obtido um conjunto de 16 regras de design excepcionais (essas regras de design são descritas no Apêndice B). A Tabela 2 apresenta alguns exemplos dos contratos encontrados.

ID Contratos de tratamento de exceções

1 <signaler signature="ubc.midp.mobilephoto.core. ui.datamodel.AlbumData.deleteImage(java.lang.String,j ava.lang.String)"> <exception type="lancs.midp.mobilephoto.lib. exceptions.ImageNotFoundException"> <handler signature="ubc.midp.mobile photo.core.ui.controller.BaseController.handleCommand (javax.microedition.lcdui.Command,javax.microedition. lcdui.Displayable)"/> </exception> </signaler> 2 <signaler signature="ubc.midp.mobilephoto.core.ui .datamodel.Im ageAccessor.loadAlbums()"> <exception type="lancs.midp.mobilephoto.lib .exceptions.InvalidImageDataException">

<handler signature="ubc.midp.mobilephoto .core.ui.datamodel.Al bumData.getAlbumNames()"/> </exception> </signaler> 3 <signaler signature="ubc.midp.mobilephoto.core.ui.dat amodel.AlbumData.getImageNames(java.lang.String)"> <exception type="lancs.midp.mobilephoto.lib .exceptions.UnavailablePhotoAlbumException"> <handler signature="ubc.midp.mobilephoto .core.ui.controller.BaseController.showImageList(java .lang.String)"/> </exception> </signaler>

Tabela 2: Exemplos de Contratos de Tratamento de Exceções da MobileMedia

A partir dos contratos definidos, passou-se para o passo seguinte da abordagem, com a geração semiautomática dos testes JUnit e dos Mock Aspects para cada teste. O trecho de código a seguir ilustra o teste gerado para o contrato 2 da Tabela 2.

1. imports …

2.

3. public class ImageAccessorloadAlbumsInvalidImage 4. DataExceptionTest extends TestCase {

5.

6. public void

7. testContractHandlergetAlbumNames0() { 8.

9. AlbumData handler = new AlbumData(); 10. handler.getAlbumNames();

11. } 12. 13.}

Com o objetivo de estimular o lançamento da exceção que deve ser verificada, foi gerado o mock aspect apresentado no trecho de código a seguir.

1.imports... 2.

3. @Aspect public class

4. ImageAccessorloadAlbumsInvalidImageData ExceptionTestMockTestAspect { 5. 6. @Around("execution (* ubc.midp.mobilephoto. 7. core.ui.datamodel.ImageAccessor.loadAlbums()) && 8. cflow(execution(* ImageAccessorloadAlbumsInvalid 9. ImageDataExceptionTest.*(..)))") 10. 11. public ObjectlaunchInvalidImageDataException 12. (ProceedingJoinPoint thisJoinPoint) 13. throws InvalidImageDataException { 14.

15. throw new lancs.midp.mobilephoto.lib. 16. exceptions.InvalidImageDataException(); 17. }

18. 19.}

Em alguns cenários não foi simples estimular o código do signaler e handler, visto que existiam algumas classes que exigiam muito código de inicialização. Em tais cenários foi necessário definir mock objects de suporte, utilizando frameworks como, por exemplo, o EasyMock [Freese and Tammo 2002]. O trecho de código abaixo ilustra o teste unitário criado para checar o contrato 3 da Tabela 2.

1. imports … 2.

3. public class AlbumDatadeleteImageImageNotFound 4. ExceptionTest extends TestCase {

5.

6. public void testContractHandlerhandleCommand0() 7. {

8.

9. Command comando =

10. EasyMock.createMock(Command.class); 11.

12. EasyMock.expect(comando.getLabel()). 13. andReturn("Delete").anyTimes(); 14.

15. EasyMock.replay(comando);

16. BaseController handler = new BaseController(new 17. MainUIMidlet(),new AlbumData());

18.

19. handler.handleCommand(comando, null); 20. }

No caso de teste acima, para instanciar o código do handler foi necessário criar objetos auxiliares (apresentados destacados nas linhas de 9-15) que devem ser passados como parâmetros mas que não interferem a maneira como a exceção é tratada.

O último passo foi executar a ferramenta VITTAE nas 4 versões OO e AO da MobileMedia. O resultado da execução dos testes pode ser observado na Tabela 3 da página 69.

Para um melhor entendimento, descrevemos a seguir o significado de cada um dos resultados apresentados na Tabela 3:

 Passed: O teste passou, ou seja, a regra de design excepcional foi obedecida o que significa que a exceção lançada pelo signaler especificado, foi tratada pelo handler descrito no contrato excepcional;  Passed-Esc: O teste passou, mas durante o tratamento da exceção

uma nova exceção foi lançada.

 Faled – Exc Han : O JUnit retornou uma falha no teste, não porque a exceção não foi capturada, mas sim porque havia ocorrido um refatoramento OO -> AO e a exceção não estava mais sendo tratada por uma classe, mas sim por um aspecto tratador de erro (como explicado na seção 3.1).

 Failed _{– Soft: O JUnit retornou uma falha porque a exceção foi} transformada em uma RuntimeException (também explicado na seção 3.1) e nenhuma outra entidade (objeto ou aspecto) tratou essa nova exceção lançada.

 n/a: O teste não é mais aplicável, devido a uma classe ou método que deixou de existir.

Como pode ser observado, nas versões OO a ferramenta detectou problemas no tratamento de exceções em oito casos. Nestes casos de teste, a exceção que estava especificada na regra de design era capturada corretamente através de um comando try. Porém, durante a execução do trecho de tratamento foi lançada uma nova exceção que não foi tratada por nenhum elemento do sistema.

Outros problemas surgiram ainda ao executar os testes nas versões AO. Sete casos de teste falharam porque a exceção não foi tratada pelo elemento descrito na regra de design, mas sim por um aspecto tratador de erro. Esses casos indicam que houve uma mudança na política de captura de exceções do sistema, o que exigiria uma atualização nos contrafiguratos excepcionais, e consequentemente nos testes. Em um caso, a exceção que era capturada na versão OO não foi capturada por ninguém e demonstra que no refatoramento OO -> AO o time de desenvolvimento descuidou-se deixando uma exceção sem tratamento. Igualmente perigosos foram os outros seis casos onde a exceção foi capturada e transformada numa exceção não checada do tipo RuntimeException. Como no Java as exceções não checadas não têm que obrigatoriamente ser tratadas, isso representa um perigo visto que durante o desenvolvimento o seu tratamento pode ser esquecido, por descuido do time de desenvolvimento.

5.3 Discussões

Este capítulo apresentou um estudo de caso preliminar que aplicou os passos da abordagem proposta neste trabalho sobre uma linha de produto de software, a Mobile Media. Foram apresentados detalhes sobre como este estudo foi realizado e os resultados obtidos. O estudo mostrou que com o passar das versões e na transformação do sistema na versão orientada a objetos para a versão orientada a aspectos houve mudanças na política de tratamento de exceção – o que exigiria uma mudanças nas regras de design excepcionais –, algumas exceções foram simplesmente transformadas em exceções não-checadas – representando um risco visto que essas exceções podem ser facilmente “esquecidas” durante o

desenvolvimento – e uma exceção simplesmente deixou de ser tratada e escapou para o usuário, o que se constitui num grave problema.

O próximo capítulo apresenta um estudo avaliativo que realizou a comparação entre a ferramenta que resultou deste trabalho, a VITTAE, com a JUnitE, ferramenta proposta no trabalho de DiBernardo et al [Di Bernardo et al. 2011] para especificação e verificação de fluxos de tratamento de exceções.

6 Estudo avaliativo

_{– Comparação entre VITTAE e}

JUnitE

Este capítulo apresenta uma avaliação empírica cujo objetivo é comparar duas ferramentas para teste de comportamento excepcional: a JUnitE [Di Bernardo et al 2011] e a VITTAE [Sales Júnior and Coelho 2011]. As duas ferramentas permitem a definição de regras que governam o comportamento excepcional da aplicação e estendem o JUnit [JUnit 2012] para a criação de testes que verificam essas regras. Devido à semelhança entre os objetivos dessas ferramentas, realizar um estudo avaliativo comparando-as é uma forma tanto de exercitar a utilização delas e analisar a sua usabilidade, quanto de verificar se na prática realmente elas são equivalentes. Tal avaliação foi realizada em duas etapas. Na primeira foi realizada uma análise quantitativa baseada na técnica GQM (Goal Question Metric) [Basili, Caldiera and Rombach 1994] e organizada de acordo com o Quadrado Latino [Box, Hunter and Hunter 2005] para avaliar a eficácia das duas ferramentas em descrever regras de comportamento excepcional e realizar os testes que verificam tais regras. Os resultados da execução da primeira etapa do experimento proveram dados que foram comparados com um conjunto de testes de hipóteses que permitiram chegarmos a determinadas conclusões. A segunda etapa foi uma análise qualitativa baseada em questionários para avaliar a satisfação dos indivíduos em utilizar as ferramentas para realização das atividades de teste de comportamento excepcional.

O capítulo está organizado como descrito a seguir. A seção 6.1 apresenta a JUnitE, a ferramenta gerada como resultado da abordagem proposta por Di Bernardo [Di Bernardo et al. 2011] e que está sendo comparada com a VITTAE. A seção 6.2 descreve a primeira etapa, a avaliação quantitativa, incluindo as hipóteses levantadas, como o experimento foi organizado, os dados obtidos durante a realização do experimento e o teste de hipótese realizado, levando assim a algumas conclusões que também são detalhadas nesta seção. A seção 6.3 descreve a segunda etapa do experimento, a avaliação qualitativa, quais os seus objetivos e os resultados obtidos. A seção 6.4 faz o fechamento do capítulo.