Universidade Federal de Pernambuco

CENTRO DE INFORMÁTICA

PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

RELATÓRIO DE DISSERTAÇÃO DO MESTRADO

Specification of Exceptional Behavior: A Test-Based Approach

MESTRANDO

RAFAEL TAVARES DANTAS

ORIENTADOR

FERNANDO JOSÉ CASTOR DE LIMA FILHO

Recife, Março de 2012

SUMÁRIO

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

1.1 ESTRUTURA DO DOCUMENTO .................................................................................. 2

2. REVISÃO BIBLIOGRÁFICA ......................................................................................... 3

2.1 ANÁLISE ESTÁTICA DO COMPORTAMENTO EXCEPCIONAL ............................ 3

2.2 TESTE DO COMPORTAMENTO EXCEPCIONAL ...................................................... 3

3. OBJETIVOS ...................................................................................................................... 6

4. METODOLOGIA ............................................................................................................. 7

5. ESTADO ATUAL DA PESQUISA .................................................................................. 8

5.1 CONCLUSÃO DOS CRÉDITOS .................................................................................... 8

5.2 LEVANTAMENTO BIBLIOGRÁFICO ......................................................................... 8

5.3 FERRAMENTA JUNITE ................................................................................................ 8

6. CRONOGRAMA ............................................................................................................ 10

7. REFERÊNCIAS BIBLIOGRAFICAS .......................................................................... 11

1. INTRODUÇÃO

Sistemas de software, ao longo do tempo, passaram a atuar cada vez mais em ambientes que

exigem a satisfação de requisitos de qualidade, como: desempenho, confiabilidade,

disponibilidade, tolerância a erros, entre outros. Dependendo do contexto do sistema,

determinados atributos devem ser tratados de forma crítica. Uma técnica amplamente

utilizada nas linguagens de programação atuais para atender algumas dessas características é o

tratamento de exceções [2].

Os mecanismos de tratamento de exceções auxiliam desenvolvedores a construírem

aplicações mais robustas, onde o comportamento excepcional é separado do fluxo normal do

sistema. Se por um lado, na etapa de implementação de um software, grande parte do código é

dedicado à tratamento de exceções, por outro, nas demais etapas de desenvolvimento, como

definição dos requisitos e projeto arquitetural, pouca esforço é dado a esse aspecto [5]. Como

o comportamento excepcional acaba não sendo pensado adequadamente em todas as etapas de

desenvolvimento, o código gerado com esta finalidade possui grande probabilidade a erros,

tornando-se uma possível fonte de falhas [6].

Ciente deste problema, diversas são as abordagens que ajudam a lidar com os

possíveis problemas causados pelo mau uso do tratamento de exceções. Elas podem variar

desde a análise estática do código [8] ou através de documentações produzidas durante demais

etapas de desenvolvimento [7].

A abordagem proposta em [1] possibilita projetar testes desde as atividades iniciais do

desenvolvimento e verificar, em tempo de execução, como as exceções trafegam ao longo de

um sistema. Inicialmente é especificado o caminho esperado e, em seguida, é possível

verificar se um fluxo excepcional ocorreu como esperado. Através dessa especificação é

possível verificar a consistência do comportamento excepcional a cada nova versão e a

própria especificação serve como documentação atualizada do sistema. O maior problema

para esta abordagem está no alto custo e tempo dedicado a identificação e criação dos casos

de teste de formal manual, tanto para sistemas já desenvolvidos, como àqueles ainda em fase

inicial. O custo e tempo se tornam ainda maior quando novas versões do sistema são

desenvolvidas e faz-se necessário comparar os testes para cada uma.

Este trabalho visa desenvolver mecanismos que ajudem a automatizar a criação de

casos de teste para o comportamento excepcional, tendo como foco sistemas que já tenham

sido implementados.

1.1 ESTRUTURA DO DOCUMENTO

Este documento está estruturado da seguinte forma: o capitulo 2 conterá uma revisão

bibliográfica para o trabalho atual, analisando alguns trabalhos relacionados. O capítulo 3 diz

respeito aos objetivos iniciais do projeto. O capítulo 4 apresenta a metodologia que se espera

utilizar. No capítulo 5, será informado a situação atual do projeto. O capítulo 6 apresenta o

cronograma estimado para os próximos meses. Por fim, no capítulo 7, são apresentadas as

referências bibliográficas utilizadas no decorrer do projeto.

2. REVISÃO BIBLIOGRÁFICA

A revisão bibliográfica para este trabalho contempla dois tópicos principais: análise estática

do comportamento excepcional e teste do comportamento excepcional.

2.1 ANÁLISE ESTÁTICA DO COMPORTAMENTO EXCEPCIONAL

Ferramentas de análise estática de fluxo de exceções percorrem o grafo de chamadas com o

objetivo de estimar os caminhos pelos quais exceções deverão passar em tempo de execução.

Muitos trabalhos atuais referentes ao comportamento excepcional se baseiam em análise

estática de código. O trabalho proposto em [19] afirma que o compilador Java realiza uma

análise de exceções se baseando na especificação do programador para checar se as entradas

do programa não produzirão exceções não capturadas em tempo de execução. Dessa forma é

utilizada a análise estática para estimar os fluxos de exceção em programas Java,

independentemente das especificações do programador. Em [20], um modelo simplificado

para determinar o fluxo excepcional em sistemas Java é proposto. Atrelado a este modelo, foi

desenvolvida a ferramenta de análise estática chamada Jex. Esta ferramenta extrai

informações sobre o fluxo de exceções através da propagação de informação sobre tipos de

exceções lançadas pelo grafo de chamada de métodos, fornecendo uma visão dos tipos de

exceção que possam surgir em pontos diferentes do programa. A ferramenta JexVis [18] foi

desenvolvida baseada no Jex com o intuito de utilizar informações textuais para gerar uma

visualização interativa da estrutura da exceção.

A grande limitação das técnicas de análise estática e suas ferramentas associadas está

no apoio somente a descoberta de caminhos excepcionais, e não na execução destes. Outro

ponto negativo é que, devido a diversos fatores, como por exemplo herança, muitos falsos

positivos são levantados por essas ferramentas.

2.2 TESTE DO COMPORTAMENTO EXCEPCIONAL

Na abordagem proposta em [1], o comportamento excepcional é especificado, monitorado e

testado através da ferramenta desenvolvida: o JUnitE [9]. O JUnitE funciona como uma

extensão do JUnit [10], que é um framework padrão para o desenvolvimento de testes de

unidade em Java. Essa extensão se baseia em três pontos:

1. Permitir ao desenvolvedor definir os caminhos percorridos por uma exceção em

um determinado fluxo. Esse caminho pode ser especificado através de todos os nós

propagados ou de forma parcial;

2. Os testes são especificados semelhante ao modo convencional do JUnit;

3. A especificação dos testes, pelo fato de estar sempre atualizada (pois caso

contrário os testes não passariam), pode ser utilizada como a própria

documentação dos fluxos excepcionais do sistema.

O estudo feito na proposição dessa abordagem sugere alguns aspectos que podem ser

relevantes na hora de priorizar quais casos de teste devem ser selecionados. Eles são:

• Blocos try-catch que não lançam mais uma exceção;

• Tratadores com tipo de exceção mais genérica;

• Tratadores que remapeiam uma exceção em outro tipo;

• Blocos que levantam tipos diferentes de exceções em um mesmo fluxo

excepcional;

• Blocos que capturam um grande número de tipos de exceção em um mesmo fluxo

excepcional.

Após selecionar os caminhos mais importantes a serem testados, uma suíte de testes é

criada e posteriormente executada. Os caminhos das exceções disparados em tempo de

execução são comparados com aqueles que foram especificados. As divergências podem tanto

indicar apenas manutenções evolutivas do sistema que alteraram o caminho percorrido, como

bugs não identificados. As correções são feitas e a suíte de testes é executada novamente.

A abordagem proposta foi avaliada em três sistemas desenvolvidos em Java e

conseguiu identificar diversos possíveis bugs no tratamento do comportamento excepcional

que surgiram com a evolução do sistema. Mesmo com o resultado satisfatório das avaliações

realizadas pela ferramenta, o custo de se identificar, especificar os casos de teste manualmente

e comparar o resultado da execução mostrou ser bastante alto. Outro aspecto negativo, foi

que, por mais que se houvesse uma direção sobre quais casos deveriam ser selecionados, a

forma de seleção ainda é bastante subjetiva.

Em [21] é desenvolvida uma abordagem automática para dar suporte na detecção de

falhas no código do tratamento excepcional que lida com recursos externos. Primeiramente, o

programa alvo é ajustado para que chamadas a recursos externos de interesse sejam forçadas a

lançar exceções. Em seguida, os casos de teste são sistematicamente amplificados para

simularem padrões de exploração o espaço do comportamento excepcional. Quando uma

falha é descoberta pelo teste amplificado, o padrão aplicado serve como explicação do erro

induzido pelo recurso externo.

O trabalho proposto por Brito et al. [12] apresenta uma abordagem de

desenvolvimento baseado em métodos formais, que permite sistematizar a verificação do

comportamento anormal no nível da arquitetura do sistema. O processo sugerido é dividido

em 4 partes:

1. A partir cenários de caso de uso, especificar a arquitetura do software e seus

cenários anormais em diagramas UML (componentes e sequência);

2. Especificar formalmente os elementos e cenários da arquitetura utilizando as

notações B-Method e CSP;

3. Verificar integridade, cenários de violação e propriedades pré-definidas para o

fluxo e os tratadores do controle de exceção;

4. Gerar e executar os casos de teste.

Em trabalho posterior [11], Brito et al. focam em extrair casos de teste diretamente da

representação formal da arquitetura do sistema, mesma utilizada em [12], permitindo a análise

da propagação de erros no nível da implementação.

3. OBJETIVOS

Este projeto tem como objetivo dar continuidade a abordagem proposta em [1], focando em

auxiliar a automatização da criação dos casos de teste do comportamento excepcional de

sistemas de software desenvolvidos em Java. Atualmente, utilizando a ferramenta JUnitE

especifica-se o comportamento excepcional, gerando uma suíte de testes de uma versão

estável de um determinado sistema. Em seguida esta mesma suíte é aplicada a versões

posteriores. A comparação entre os resultados da execução dos testes indica as divergências

que, em alguns casos, poderão ser bugs. Esta comparação feita de forma manual acaba sendo

muito demorada, trabalhosa e sujeita a falha humana.

O objetivo será automatizar essa comparação e, de posse dos resultados, combiná-los

com heurísticas extraídas a partir de dados sobre caminhos de propagação de exceções em

sistemas reais. Essa combinação funcionará como indicador dos locais que devem ser

testados, auxiliando, assim, na automatização da criação dos casos de teste do comportamento

excepcional de um sistema real.

4. METODOLOGIA

Serão realizadas diversas atividades durante os próximos meses com o objetivo de concluir o

trabalho de pesquisa apresentado nesta proposta de dissertação de mestrado. Essas atividades

são descritas abaixo:

Atividade 1 (Revisão bibliográfica): Estudo crítico das publicações atuais

relacionadas ao tema com o intuito de produzir conhecimento para desenvolvimento

do projeto.

Atividade 2 (Relatório de dissertação para o SAAP): Elaboração do relatório

obrigatório de Acompanhamento dos Alunos da Pós-Graduação.

Atividade 3 (Definição das implementações): Com base nos estudos realizados até o

momento, nessa atividade serão definidas e especificadas as implementações que serão

necessárias para a conclusão do projeto.

Atividade 4 (Realização das implementações): Com base no que foi definido e

validado na etapa anterior, nesta fase será realizada a codificação da(s) ferramenta(s)

especificada(s) na etapa 3.

Atividade 5 (Avaliação, testes e validação das implementações): Com a(s)

ferramenta(s) produzida(s), nessa etapa serão feitos os testes e possíveis ajustes para

validar se o que foi implementado está correto.

Atividade 6 (Estudo de caso): Com a ferramenta desenvolvida, será realizado o

estudo de caso, avaliando os cenários possíveis.

Atividade 7 (Escrita da Dissertação): A escrita da dissertação iniciará ainda durante

a fase de implementação, abordando sessões mais conceituais. De posse da

implementação concluída e do estudo de caso realizado, serão tratadas as sessões da

dissertação referentes a documentação dos resultados obtidos.

Atividade 8 (Ajustes finais e Defesa da dissertação): Esta etapa é destinada aos

ajustes gerais que poderão ocorrer no período final do projeto e conseqüentemente a

apresentação final.

5. ESTADO ATUAL DA PESQUISA

A pesquisa pode ser divida em três etapas até o momento atual: conclusão dos créditos

necessários, levantamento bilbiográfico e utilização da ferramenta JUnitE.

5.1 CONCLUSÃO DOS CRÉDITOS

Disciplina Conceito

IN1007 - Paradigmas de Linguagens de Programação A

IN0980 - Tópicos Avançados em Engenharia de Software 3 (Linhas de

Produto)

A

IN1002 – Administração e Integração de Sistemas C

IN0979 - Tópicos Avançados em Engenharia de Software 3 (Arquitetura

de Software)

B

IN1884 – Trabalho Individual em Engenharia de Software 1 -

IN1030 - Seminários -

5.2 LEVANTAMENTO BIBLIOGRÁFICO

Seguem listados abaixo os tópicos que foram estudados até o momento e que foram

abordados na elaboração desse documento:

Tratamento de Exceções

Análise Estática do Comportamento Excepcional

Teste do Comportamento Excepcional

5.3 FERRAMENTA JUNITE

Foi adquirido familiaridade e conhecimento sobre a ferramenta JUnitE [1, 9]. Foram feitos

testes, tendo como alvo a ferramenta Target – Test and Requirements Generation Tool, que é

utilizada para gerar casos de testes baseado nas combinações e reuso de passos de um

documento formal de casos de uso [16]. Os testes foram realizados de forma trivial com o

intuito de explorar os conceitos da ferramenta JUnitE.

6. CRONOGRAMA

Segue abaixo o cronograma proposto para as atividades descritas anteriormente na seção de

Metodologia.

Período

2012 2013

Atividades Jan/Fev Mar/Abr Mai/Jun Jul/Ago Set/Out Nov/Dez Jan/Fev/Mar

1

2

3

4

5

6

7

8

7. REFERÊNCIAS BIBLIOGRAFICAS

[1] Rafael Di Bernardo, Fernando Castor, and Sérgio Soares. Towards agile testing of

exceptional behavior. In EHCoS 2011, São José dos Campos, São Paulo, Brazil, jan 2011.

[2] F. Cristian. Exception handling and software fault tolerance. IEEE Trans. Comput.,

31(6):531–540, 1982.

[3] P. Brito, R. de Lemos, and C.M.F. Rubira. Verification of exception control flows and

handlers based on architectural scenarios. In High Assurance Systems Engineering

Symposium, 2008. HASE 2008. 11th IEEE, pages 177 –186, dec. 2008

[4] Fernando Castor Filho, Patrick H. S. Brito, and Cecília M. F. Rubira. A framework for

analyzing exception flow in software architectures. ACM SIGSOFT Software Engineering

Notes, 30(4):1–7, 2005.

[5] Jörg Kienzle. On exceptions and the software development life cycle. In WEH ’08:

Proceedings of the 4th international workshop on Exception handling, pages 32–38, New

York, NY, USA, 2008. ACM.

[6] Algirdas Avizienis. Toward systematic design of fault-tolerant systems. IEEE Computer,

30(4):51–58, 1997.

[7] C. M. F. Rubira, R. de Lemos, G. R. M. Ferreira, and F. Castor Filho. Exception handling

in the development of dependable component-based systems. Softw. Pract. Exper.,

35(3):195–236, 2005.

[8] Martin P. Robillard and Gail C. Murphy. Static analysis to support the evolution of

exception structure in object-oriented systems. ACM Trans. Softw. Eng. Methodol., 12:191–

221, April 2003.

[9] JUnitE. https://sites.google.com/a/cin.ufpe.br/castor/jUnitE. Visitado em 08/02/2012.

[10] Eric Gamma e Kent Beck. Junit. Acessado em Novembro de 2010 http://www.junit.org/.

[11] Patrick H. S. Brito, Rogério de Lemos, Eliane Martins, Regina Lúcia de Oliveira Moraes,

and Cecília M. F. Rubira. Architectural-based validation of fault tolerant software. In LADC,

pages 103–110, 2009.

[12] P. Brito, R. de Lemos, and C.M.F. Rubira. Verification of exception control flows and

handlers based on architectural scenarios. In High Assurance Systems Engineering

Symposium, 2008. HASE 2008. 11th IEEE, pages 177 –186, dec. 2008.

[13] Bruno Cabral and Paulo Marques. Exception Handling: A Field Study in Java and .NET.

pages 151–175. 2007.

[14] F. Cristian. Exception handling and tolerance of software faults. Software Fault

Tolerance, 31(6):81–108, 1994.

[15] FERREIRA. et al. TaRGeT: a Model Based Product Line Testing Tool. In:

CONGRESSO BRASILEIRO DE SOFTWARE, 2010. Anais... Salvador: CBSoft, 2010

[16] D. L. Parnas and H. Würges. Response to undesired events in software systems. In ICSE

’76: Proceedings of the 2nd international conference on Software engineering, pages 437–

446, Los Alamitos, CA, USA, 1976. IEEE Computer Society Press.

[17] Hina Shah, Carsten Görg, and Mary Jean Harrold. Visualization of exception handling

constructs to support program understanding. In Proceedings of the 4th ACM symposium on

Software visualization, SoftVis ’08, pages 19–28, New York, NY, USA, 2008. ACM.

[18] A. Sinha. JexVis: An interactive visualization tool for exception call graphs in Java.

Unpublished report, http://cs.ubc.ca/˜tmm/courses/cpsc533c-05-

fall/projects/anirbans/report.pdf

[19] Byeong-Mo Chang, Jang-Wu Jo, Kwangkeun Yi, and Kwang-Moo Choe. Interprocedural

exception analysis for java. In Proceedings of the 2001 ACM symposium on Applied

computing, pages 620–625, New York, NY, USA, 2001. ACM.

[20] Martin P. Robillard and Gail C. Murphy. Static analysis to support the evolution of

exception structure in object-oriented systems. ACM Trans. Softw. Eng. Methodol., 12:191–

221, April 2003.

[21] Pingyu Zhang and Sebastian Elbaum. Amplifying Tests to Validate Exception Handling

Code. ICSE 2012.