uma abordagem para verificação do comportamento excepcional a
If you can't read please download the document
TRANSCRIPT
-
Universidade Federal do Rio Grande do Norte
Centro de Cincias Exatas e da Terra
Departamento de Informtica e Matemtica Aplicada
Programa de Ps-Graduao em Sistemas e Computao
UMA ABORDAGEM PARA VERIFICAO DO
COMPORTAMENTO EXCEPCIONAL A PARTIR DE
REGRAS DE DESIGN E TESTES
RICARDO JOS SALES JNIOR
Dissertao apresentada ao Programa de Ps-Graduao em Sistemas e
Computao do Departamento de Informtica e Matemtica Aplicada da
Universidade Federal do Rio Grande do Norte como requisito parcial para a
obteno do grau de Mestre em Sistemas e Computao.
Natal/RN
FEVEREIRO - 2013
-
Universidade Federal do Rio Grande do Norte
Centro de Cincias Exatas e da Terra
Departamento de Informtica e Matemtica Aplicada
Programa de Ps-Graduao em Sistemas e Computao
UMA ABORDAGEM PARA VERIFICAO DO
COMPORTAMENTO EXCEPCIONAL A PARTIR DE
REGRAS DE DESIGN E TESTES
Ricardo Jos Sales Jnior
Dissertao apresentada ao Programa de
Ps-Graduao em Sistemas e
Computao do Departamento de
Informtica e Matemtica Aplicada da
Universidade Federal do Rio Grande do
Norte como requisito parcial para a
obteno do grau de Mestre em Sistemas
e Computao.
Prof. Dr. Roberta de Souza Coelho
Orientadora
Natal/RN
2013
-
Catalogao da Publicao na Fonte. UFRN / SISBI / Biblioteca Setorial
Especializada do Centro de Cincias Exatas e da Terra CCET.
Sales Jnior, Ricardo Jos.
Uma abordagem para verificao do comportamento excepcional a partir de
regras de design e testes / Ricardo Jos Sales Jnior. Natal, RN, 2013.
133 f. : il.
Orientadora: Profa. Dra. Roberta de Souza Coelho.
Dissertao (Mestrado) Universidade Federal do Rio Grande do Norte. Centro
de Cincias Exatas e da Terra. Departamento de Informtica e Matemtica Aplicada.
Programa de Ps-Graduao em Sistemas e Computao.
1. Software Teste - Dissertao. 2. Tratamento de excees Dissertao. 3.
Comportamento excepcional Dissertao. 4. Regras de design Dissertao. I.
Coelho, Roberta de Souza. II. Ttulo.
RN/UF/BSE-CCET CDU 004.4
-
Dedico essa dissertao a Jeov Deus, a
minha Esposa Raquel, meus pais e amigos que
me deram toda a ajuda que precisei.
-
Agradecimentos
Em primeiro lugar, agradeo a Jeov Deus por me dar a fora necessria para
conciliar as minhas atividades como trabalhador, marido, trabalhador e aluno de
mestrado. Agradeo a minha esposa pelo amor, bondade, pacincia e abnegao, as
horas que ela abdicou de estar comigo para que eu pudesse encerrar mais esta etapa.
Agradeo aos meus pais que estiveram comigo por toda a minha vida e cujo exemplo
e dedicao me educaram mais do que qualquer escola. minha orientadora mais
uma vez agradeo a pacincia, as horas de sono perdidas, o cuidado e a preocupao
na vida acadmica e pessoal. Aos meus irmos e amigos sou grato pelo apoio. Aos
meus chefes no Ministrio Pblico do Rio Grande do Norte e colegas de equipe,
agradeo o suporte para a realizao da minha pesquisa. Aos professores Eduardo
Aranha e Gibeon Soares as sugestes e apoio ao experimento. Tambm agradeo
aos colegas Israel Garcia, Rafael Di Bernardo e Luciano Carvalho pelas trocas de
figurinhas relacionadas com as nossas pesquisas.
-
Resumo
Verificar a conformidade entre a implementao de um sistema e suas regras de
design uma atividade importante para tentar garantir que no ocorra a degradao
entre os padres arquiteturais definidos para o sistema e o que realmente est
implementado no cdigo-fonte. Especialmente no caso de sistemas dos quais se
exige um alto nvel de confiabilidade importante definir regras de design (design
rules) especficas para o comportamento excepcional. Tais regras descrevem como
as excees devem fluir atravs do sistema, definindo quais so os elementos
responsveis por capturar as excees lanadas por outros elementos do sistema.
Entretanto, as abordagens atuais para verificar automaticamente regras de design
no proveem mecanismos adequados para definir e verificar regras de design
especficas para a poltica de tratamento de excees das aplicaes. Este trabalho
prope uma abordagem prtica para preservar o comportamento excepcional de uma
aplicao ou famlia de aplicaes, baseada na definio e verificao automtica em
tempo de execuo de regras de design de tratamento de exceo para sistemas
desenvolvidos em Java ou AspectJ. Para apoiar esta abordagem foi desenvolvida, no
contexto deste trabalho, uma ferramenta chamada VITTAE (Verification and
Information Tool to Analyze Exceptions) que estende o framework JUnit e permite
automatizar atividades do teste de regras de design excepcionais. Foi realizado um
estudo de caso preliminar com o objetivo de avaliar a eficcia da abordagem proposta
sobre uma linha de produto de software. Alm deste, foi realizado um experimento
cujo objetivo foi realizar uma anlise comparativa entre a abordagem proposta e uma
abordagem baseada na ferramenta JUnitE, que tambm prope testar o cdigo de
tratamento de excees utilizando testes JUnit. Os resultados mostraram que as
regras de design excepcionais evoluem ao longo de diferentes verses de um sistema
e que a VITTAE pode auxiliar na deteco de defeitos no cdigo de tratamento de
exceo.
Palavras-chave: Tratamento de Excees, Comportamento Excepcional, Testes de
Software, Regras de Design.
-
Abstract
Checking the conformity between implementation and design rules in a system is an
important activity to try to ensure that no degradation occurs between architectural
patterns defined for the system and what is actually implemented in the source code.
Especially in the case of systems which require a high level of reliability is important to
define specific design rules for exceptional behavior. Such rules describe how
exceptions should flow through the system by defining what elements are responsible
for catching exceptions thrown by other system elements. However, current
approaches to automatically check design rules do not provide suitable mechanisms
to define and verify design rules related to the exception handling policy of
applications. This paper proposes a practical approach to preserve the exceptional
behavior of an application or family of applications, based on the definition and runtime
automatic checking of design rules for exception handling of systems developed in
Java or AspectJ. To support this approach was developed, in the context of this work,
a tool called VITTAE (Verification and Information Tool to Analyze Exceptions) that
extends the JUnit framework and allows automating test activities to exceptional
design rules. We conducted a case study with the primary objective of evaluating the
effectiveness of the proposed approach on a software product line. Besides this, an
experiment was conducted that aimed to realize a comparative analysis between the
proposed approach and an approach based on a tool called JUnitE, which also
proposes to test the exception handling code using JUnit tests. The results showed
how the exception handling design rules evolve along different versions of a system
and that VITTAE can aid in the detection of defects in exception handling code.
Keywords: Exception Handling, Exceptional Behavior, Exception Policy, Software
Testing, Design Rules.
-
Sumrio
1 Introduo ........................................................................................................ 14
1.1 Exemplo Motivacional ...................................................................................... 17
1.2 Limitaes das abordagens atuais .................................................................. 21
1.3 Soluo proposta ............................................................................................. 22
1.4 Objetivos ......................................................................................................... 22
1.5 Contribuies escritas ao longo da pesquisa .................................................. 23
1.6 Organizao do texto ...................................................................................... 23
2 Fundamentao Terica .................................................................................. 25
2.1 Tolerncia a falhas .......................................................................................... 25
2.1.1 Tratamento de excees .............................................................................. 26
2.1.2 Tratamento de excees em Java ............................................................... 26
2.2 Verificao de Software ................................................................................... 27
2.2.1 Anlise esttica ............................................................................................ 28
2.2.2 Testes de Software ...................................................................................... 28
Testes funcionais (ou testes caixa-preta) .................................................................. 29
Testes estruturais (ou testes caixa-branca) .............................................................. 29
2.2.3 Nveis de teste ............................................................................................. 30
2.3 Automao de testes ....................................................................................... 31
2.3.1 JUnit ............................................................................................................. 32
2.4 Programao Orientada a Aspectos e AspectJ ............................................... 36
2.5 Regras de Design ............................................................................................ 37
2.6 Discusses ...................................................................................................... 38
3 Abordagem Proposta ....................................................................................... 39
3.1 Exemplo Motivador Refatorao de Sistemas Orientados a Objetos para
Aspectos.................................................................................................................... 39
3.2 Viso Geral da Abordagem Proposta .............................................................. 43
3.2.1 Passo1: Definio das Regras de Design Excepcionais da Aplicao ........ 44
3.2.2 Passo 2 : Projeto e Automao do Teste ..................................................... 47
3.2.3 Passo 3 : Execuo do teste ........................................................................ 49
3.2.4 Passo 4 : Avaliao do Teste ....................................................................... 49
-
3.3 Discusses ...................................................................................................... 52
4 A Ferramenta VITTAE ...................................................................................... 54
4.1 Viso Geral da Arquitetura da VITTAE ............................................................ 54
4.2 Pacote de aspectos ......................................................................................... 54
4.3 Pacote de controladores .................................................................................. 56
4.4 Pacote de excees ........................................................................................ 56
4.5 Pacote de classes utilitrias ............................................................................ 56
4.6 Pacote de geradores ....................................................................................... 57
4.7 Pacote de entidades ........................................................................................ 57
4.8 Verificao da regra de design ........................................................................ 58
4.9 Interface grfica ............................................................................................... 59
4.10 Discusses ................................................................................................... 59
5 Estudo de Caso ................................................................................................ 61
5.1 Mobile Media (MM) .......................................................................................... 61
5.2 Aplicando a Abordagem a uma Linha de Produto de Software ....................... 63
5.3 Discusses ...................................................................................................... 67
6 Estudo avaliativo Comparao entre VITTAE e JUnitE ............................. 70
6.1 JUnitE .............................................................................................................. 71
6.2 Avaliao quantitativa ...................................................................................... 73
6.2.1 Definio do experimento ............................................................................. 74
6.2.2 Hipteses ..................................................................................................... 75
6.2.3 Projeto do experimento ................................................................................ 76
6.2.3.1 Escolha dos sujeitos ................................................................................. 77
6.2.3.2 Escolha dos sistemas ............................................................................... 77
6.2.3.3 Organizao do experimento .................................................................... 80
6.2.3.4 Operao do experimento ......................................................................... 81
6.2.4 Anlise dos resultados ................................................................................. 86
6.2.5 Ameaas validade do estudo .................................................................. 102
6.3 Avaliao qualitativa ...................................................................................... 102
6.3.1 Ameaas validade do estudo .................................................................. 108
6.4 Discusses .................................................................................................... 109
-
7 Trabalhos relacionados ................................................................................. 110
7.1 Abordagens de verificao esttica ............................................................... 110
7.2 Abordagens de teste ..................................................................................... 111
7.3 Abordagens de regras de design para tratamento de exceo ..................... 113
7.4 Processos de Desenvolvimento .................................................................... 115
7.5 Discusses .................................................................................................... 116
8 Consideraes Finais .................................................................................... 117
8.1 Publicaes relacionadas .............................................................................. 118
8.2 Trabalhos futuros ........................................................................................... 119
Referncias ............................................................................................................ 121
Apndice A Artigos Publicados ........................................................................ 131
Apndice B Regras de Design excepcionais da Mobile Media ...................... 132
-
Lista de Figuras
Figura 1: Arquitetura de um sistema baseada em camadas ..................................... 18
Figura 2: Tcnica de Teste Funcional ....................................................................... 29
Figura 3:Tcnica de teste estrutural .......................................................................... 30
Figura 4: Modelo V que descreve a correspondncia entre as atividades de
desenvolvimento e os nveis de teste ........................................................................ 30
Figura 5: Arquitetura do JUnit (Fonte: http://www.devmedia.com.br/junit-
implementando-testes-unitarios-em-java-parte-i/1432) ............................................. 32
Figura 6: Resultados visuais do JUnit ....................................................................... 35
Figura 7: Arquitetura de um sistema refatorado para Aspectos ................................ 40
Figura 8: Viso esquemtica do "ladro de excees" ............................................. 42
Figura 9: Sequncia de Atividades da Abordagem Proposta .................................... 44
Figura 10: XML Schema para o arquivo que define as regras de design da aplicao
.................................................................................................................................. 46
Figura 11: Estrutura do projeto com a VITTAE e localizao do arquivo de contratos
.................................................................................................................................. 47
Figura 12: Tela do JUnit sem a extenso da VITTAE ............................................... 50
Figura 13: Exemplo de utilizao do framework JUnit em conjunto com a VITTAE
para execuo automatizada dos testes ................................................................... 50
Figura 14: Arquitetura da Vittae ................................................................................. 55
Figura 15: Inicializao do aspecto de checagem ..................................................... 58
Figura 16: Diagrama de sequncia para verificao da regra de design .................. 59
Figura 17: Interface grfica da VITTAE para configurao do projeto eclipse .......... 60
Figura 18: Janela da VITTAE para escolha do projeto eclipse a ser configurado ..... 60
Figura 19: Design OO da MobileMedia ..................................................................... 62
Figura 20: Design AO da MobileMedia ...................................................................... 62
Figura 21: Diagrama de classes e pacotes com a estrutura do Sistema Bancrio .... 78
Figura 22: Diagrama de classes e pacotes com a estrutura do Sistema de Fichas .. 79
Figura 23:Resultado do teste na VITTAE .................................................................. 85
Figura 24: Resultado do teste na JUnitE ................................................................... 85
Figura 25: Grfico Box-Plot para os dados da Q1 ..................................................... 89
Figura 26: Resultados individuais para cada ferramenta na Q1 ................................ 90
-
Figura 27: Comparao visual entre os dados obtidos na Q1 e o modelo predito no
grfico de envelope ................................................................................................... 91
Figura 28: Grfico Box-Plot para os dados da Q2 ..................................................... 93
Figura 29: Resultados individuais para os dados da Q2 ........................................... 94
Figura 30: Comparao visual entre os dados obtidos na Q2 aps a transformao e
o modelo predito no grfico de envelope. ................................................................. 95
Figura 31: Grfico em barras para a Q4 .................................................................... 98
Figura 32: Grfico Box-Plot para a Q5 ...................................................................... 99
Figura 33: Resultados individuais para os dados da Q5 ......................................... 100
Figura 34: Comparao visual entre os dados obtidos na Q5 aps a transformao e
o modelo predito no grfico de envelope. ............................................................... 101
Figura 35: Grfico em barras com o resultado da P5 .............................................. 104
Figura 36: Grfico em barras com o resultado da P6 .............................................. 104
Figura 37: Grfico em barras com o resultado da P7 .............................................. 104
Figura 38: Grfico em barras com o resultado da P8 .............................................. 105
Figura 39: Grfico em barras com o resultado da P9 .............................................. 105
Figura 40: Grfico Box-Plot referente ao tempo para a configurao do ambiente
para as duas ferramentas........................................................................................ 107
Figura 41: Desempenho individual dos sujeitos ao configurar o ambiente das
ferramentas. ............................................................................................................ 108
-
Lista de Tabelas
Tabela 1: Mtricas da MobileMedia ........................................................................... 61
Tabela 2: Exemplos de Contratos de Tratamento de Excees da MobileMedia ..... 64
Tabela 3:Resultados da execuo da abordagem da MobileMedia em diferentes
verses ...................................................................................................................... 69
Tabela 4: Comparao de caractersticas entre a VITTAE e JUnitE ......................... 73
Tabela 5: Questes relacionadas ao objetivo do experimento .................................. 75
Tabela 6: Mtricas relacionadas com as questes levantadas ................................. 75
Tabela 7: Hipteses baseadas nas questes ............................................................ 76
Tabela 8: Comparao de caractersticas entre os dois sistemas ............................ 79
Tabela 9: Organizao dos sujeitos no experimento utilizando o delineamento em
quadrado latino .......................................................................................................... 81
Tabela 10 Relao entre as fases do experimento e os dias em que elas foram
executadas ................................................................................................................ 81
Tabela 11: Regra de Design Excepcional de cada sistema ...................................... 82
Tabela 12: Resultado esperado das regras de design descritas nas ferramentas .... 83
Tabela 13: Lista de perguntas do questionrio e a relao delas com as questes
levantadas para o experimento ................................................................................. 86
Tabela 14: Dados obtidos para a Q1 ......................................................................... 88
Tabela 15: Mediana e Desvio padro dos dados da Q1 ........................................... 89
Tabela 16: Resultados do teste ANOVA para os dados da Q1 ................................. 92
Tabela 17: Dados obtidos para a Q2 ......................................................................... 92
Tabela 18: Mediana e Desvio padro dos dados da Q2: .......................................... 93
Tabela 19: Dados da Q2 aps transformao Box-Cox ............................................ 95
Tabela 20: Resultados do teste ANOVA para os dados da questo 2 ...................... 96
Tabela 21: Dados obtidos para a Q3 ......................................................................... 96
Tabela 22: Dados obtidos para a Q4 ......................................................................... 97
Tabela 23: Dados obtidos para a Q5 ......................................................................... 99
Tabela 24: Mediana e Desvio padro dos dados da Q5: .......................................... 99
Tabela 25: Dados da Q5 aps transformao Box-Cox .......................................... 101
Tabela 26: Resultados do teste ANOVA para os dados da questo 2 .................... 102
Tabela 27: Perguntas da avaliao qualitativa ........................................................ 103
-
Tabela 28: Tempo para preparao do ambiente (P11) .......................................... 106
Tabela 29: Expresses da LSD destinadas ao comportamento excepcional .......... 114
Tabela 30: Construes da DCL voltadas para o fluxo excepcional ....................... 114
-
14
1 Introduo
Na atualidade, os sistemas resultantes do desenvolvimento de software
geralmente so compostos por uma coleo de componentes distribudos que
precisam lidar com entradas provenientes de uma variedade de fontes, executar em
diversos tipos de ambientes e obedecer a requisitos rigorosos de confiabilidade. No
que diz respeito aos requisitos de confiabilidade, diversas tcnicas podem ser
utilizadas, mas uma das mais conhecidas e que est embutida na maior parte das
linguagens modernas de programao a utilizao de mecanismos de tratamento
de exceo [Cristian 1982]. Estes mecanismos auxiliam os desenvolvedores a
construir aplicaes mais robustas atravs da separao do fluxo de comportamento
excepcional do fluxo normal de controle [Parnas and Wurges 1976].
Estes mecanismos ajudam a garantir a modularidade do sistema na presena
de erros, visto que eles oferecem abstraes para: (i) representar situaes de erros
em mdulos do sistema como excees; (ii) encapsular atividades de tratamento de
exceo em entidades manipuladoras (handlers); (iii) definir partes dos mdulos do
sistema como regies protegidas para a ocorrncia do tratamento de excees; (iv)
associar essas regies com os handlers; (v) especificar explicitamente as interfaces
de tratamento de exceo dos mdulos.
Embora estudos como os de Castor et al. [Castor et al. 2006], Cabral e Marques
[Cabral and Marques 2007] e Cristian [Cristian 1994] mostrem que uma grande
quantidade de cdigo dedicada descoberta e tratamento de erros, outros trabalhos
como os de Rubira et al. [Rubira et al. 2005] e de Kienzle [Kienzle 2008] mostram que
lidar com as manifestaes de erros e excees em outros estgios do
desenvolvimento, como por exemplo requisitos, design e testes, um aspecto que
tem recebido pouca ateno nos processos de desenvolvimento. Os desenvolvedores
tendem a concentrar suas atividades de design no comportamento normal da
aplicao e esquecem o design do comportamento excepcional [Sha, Gerg and
Harrold 2008]. Eles geralmente lidam com a deteco e o tratamento de excees
somente em atividades de implementao [Cristian 1982]. O resultado disso o uso
inadequado dos mecanismos de tratamento de exceo, comprometendo a
confiabilidade do sistema [Kienzle 2008].
-
15
As construes para tratamento de excees geralmente so propensas a
falhas devido falta de ateno com o comportamento excepcional durante outras
disciplinas e atividades do desenvolvimento de software [Avizienis 1997]. Nesta
realidade, mesmo que a inteno inicial seja utilizar o tratamento de excees para
melhorar a robustez dos sistemas, o uso indevido pode ser uma fonte de falhas. Um
bom exemplo disso est na utilizao da orientao a aspectos para modularizar o
tratamento de excees. Os trabalhos de Castor et al. [Castor et al. 2006], Coelho et
al. [Coelho et al 2008a, Coelho et al 2008b] e Sales Jnior et al. [Sales Jnior et al.
2010] destacam que se determinados cuidados no forem tomados, a modularizao
do tratamento de excees atravs de aspectos pode ser uma fonte de erros.
Para lidar com este tipo de problema, abordagens baseadas em anlise
esttica foram propostas para descobrir falhas no cdigo de tratamento de exceo
[Coelho et al. 2008a, Fahndrich et al. 1998, Robiliard and Murphy 2003, Chang et al.
2001, Garcia et al. 2011]. Estas abordagens so baseadas em ferramentas que
descobrem os caminhos que as excees fazem a partir dos mtodos que as lanam
at os elementos responsveis por captur-las. Entretanto, devido s limitaes
inerentes s abordagens de anlise esttica e s caractersticas das linguagens de
programao modernas, tais como herana, polimorfismo e chamadas virtuais, estas
abordagens geralmente trazem um nmero muito grande de fluxos de exceo a
serem analisados, sem contar os muitos falsos positivos, que nada mais so do que
fluxos que na realidade no sero executados [Sinha and Harrold 2000].
Consequentemente, trabalho manual adicional deve ser realizado para verificar
quando um fluxo excepcional detectado pode realmente acontecer, e quando ele
realmente importante. Esse trabalho adicional manual pode tornar tais abordagens
to caras em termos de tempo e recursos a ponto de serem na realidade proibitivas.
Alm disso, uma vez que os fluxos de interesse so encontrados, tanto quanto
do nosso conhecimento, a nica forma de document-los atravs de um texto
informal em linguagem natural. Ainda outra limitao destas abordagens o fato de
que elas somente podem ser utilizadas aps pelo menos parte do sistema estar
implementada.
Por outro lado, outras abordagens como as de Rubira et al. [Rubira et al 2005]
e Kienzle [Kienzle 2008] focadas em metodologias de desenvolvimento, tem como
base a especificao do comportamento excepcional. Contudo, estas metodologias
no so atualmente passveis de automao e esto fortemente baseadas em
-
16
documentao, impondo uma sobrecarga indesejvel para ambientes em que se
exige uma maior agilidade. A experincia de trabalhos como os de Misra, Kumar e
Kumar [Misra, Kumar and Kumar 2009] tem mostrado que metodologias mais leves
esto sendo usadas com mais sucesso no desenvolvimento de aplicaes
atualmente. Tais metodologias incentivam fortemente a automao dos testes, e a
construo deles antecipadamente implementao baseando-se nas especificaes
de requisitos, prottipos [Beck and Andres 2004, Palmer and Felsing 2002] e modelos
arquiteturais.
Partindo do pressuposto que as regras de comportamento excepcional so
padres que devem ser obedecidos durante o desenvolvimento de um software, pode-
se considerar ento que elas so um tipo de regra de design [Baldwin and Clark 1999].
Uma das principais aplicaes para utilizao das regras de design definir padres
arquiteturais que devem ser obedecidos durante a implementao e manuteno de
um software. Tais padres precisam ser estritamente seguidos em todas as fases do
desenvolvimento de software. Atualmente estas regras de design, geralmente, so
definidas e checadas manualmente. Porm essa atividade se torna demasiadamente
custosa para sistemas de grande porte. Trabalhos como os de Brunet, Neto e
Figueredo [Brunet, Neto and Figueredo 2009] e Neto [Neto 2010] apresentam
abordagens para definir e automaticamente verificar as regras de design dos
sistemas. Uma limitao comum dessas abordagens que elas no proveem
maneiras apropriadas de definir regras de design relacionadas com fluxos de
exceo.
Pelas razes acima citadas verifica-se que so necessrias ferramentas que
(i) ajudem os desenvolvedores a entender o impacto das mudanas na poltica de
tratamento de excees e (ii) encontrem inconformidades entre as regras de design e
o cdigo que est sendo includo ou alterado.
Este trabalho prope uma abordagem baseada em contratos em uma
linguagem baseada em xml [Sales Jnior, Coelho and Lustosa Neto 2010] que
definem regras de design especficas para fluxos de exceo atravs da especificao
de que quando determinados elementos (sejam eles mtodos, classes, aspectos ou
pacotes) lanarem uma exceo (chamamos aqui esses elementos de signalers)
quais devero ser os outros elementos especficos por tratar essa exceo
(chamamos aqui esses elementos de handlers). Alm disso, a abordagem prov uma
ferramenta chamada VITTAE (Verification and Information Tool to Analyze
-
17
Exceptions) que permite (i) verificar automaticamente atravs de testes unitrios
(estendendo o framework JUnit [JUnit 2012]) se as regras de design esto sendo
obedecidas em sistemas Java [Java 2012] e AspectJ [AspectJ 2012], (ii) gerar parte
do cdigo dos testes de comportamento excepcional baseados nas regras de design,
(iii) gerar tambm os objetos mock dinmicos [Freese 2002] que simulam a
instanciao de objetos de teste de comportamento excepcional e (iv) montar o
ambiente no projeto Java para realizao dos testes utilizando a ferramenta.
Nossa abordagem pode ser utilizada tanto para escrever as regras de design e
os testes previamente s fases de desenvolvimento, usando o conceito de
desenvolvimento dirigido a testes [Beck 2003], quanto posteriormente ao
desenvolvimento, auxiliando nas atividades de manuteno.
Esta abordagem foi aplicada inicialmente em uma linha de produto de software
[Clements and Northrop 2002] escrita em Java e AspectJ, a MobileMedia [Figueiredo
et al. 2008], com o objetivo de avaliar sua eficcia em detectar a degradao das
regras de design de uma aplicao durante sua evoluo em diversas verses.
Adicionalmente foi realizado um experimento controlado, que comparou esta
abordagem com a JUnitE [Di Bernardo et al. 2011], proposta tambm para
especificao e verificao de fluxos de tratamento de excees utilizando testes
unitrios.
1.1 Exemplo Motivacional
Nesta subseo apresentado um exemplo ilustrativo simples para levantar
algumas limitaes da utilizao dos casos de teste JUnit puros para detectar bugs
de tratamento de exceo.
-
18
Figura 1: Arquitetura de um sistema baseada em camadas
Considere um sistema com arquitetura em camadas, como o exemplificado na
Figura 1. Ele composto pelas seguintes camadas:
Dados (Data Layer)
Negcio (Business Layer)
Interface Grfica (GUI Layer)
Uma regra de design de tratamento de excees que deve ser obedecida nesta
aplicao a seguinte: as excees lanadas por Objetos da camada de Dados (Data
Layer) representam problemas no acesso base de dados. Elas so subtipos da
exceo DAOException. Essas excees devem ser tratadas pela Servlet na
camada de interface grfica (GUI Layer). Com o objetivo de verificar se esta poltica
est sendo obedecida, o desenvolvedor pode tentar construir o seguinte caso de teste
JUnit:
1. public void testDAOEHPolicy (){
2. Servlet s1 = new Servlet();
3. s1.service();
4. }
-
19
Se nenhuma instncia de DAOException escapar deste mtodo, o
desenvolvedor pode presumir que a exceo foi adequadamente tratada pela
Servlet. Entretanto, dois problemas podem acontecer, e estes no sero
detectados por este teste:
A instncia de DAOException pode ter sido erroneamente tratada pelo
Facade que neste caso estaria atuando como um elemento
intermedirio entre o signaler e o handler definidos na regra de design.
Durante o teste, o DAO pode no lanar a exceo, o que tornaria o
teste sem efeito.
A construo do JUnit que permite verificar as excees a utilizao da
anotao @Test(expected=.class). Exemplificamos a
utilizao dessa construo no trecho de cdigo a seguir, supondo agora uma outra
situao onde o desenvolvedor deseja verificar se a Servlet lana uma exceo do
tipo DAOException quando ocorre um erro no acesso aos dados.
1. @Test(expected=DAOException.class)
2. public void testDAOEHPolicy(){
3. Servlet s1 = new Servlet();
4. s1.service();
5. }
Embora o teste detecte se a exceo foi realmente lanada, esta abordagem
ainda apresenta limitaes, visto que ela pode esconder um tipo sutil de erro. Por
exemplo, espera-se que a exceo DAOException seja lanada a partir da camada
de dados devido a um erro no acesso ao banco. Porm devido a um problema de
programao a camada de dados pode ter lanado uma exceo
NullPointerException, e essa exceo pode ter sido capturada por um tratador
genrico (generic handler), ou seja, uma clusula catch para o tipo genrico
Exception (ou tambm conhecido como catch-all). Se dentro dessa clusula a
exceo DAOException for lanada, o teste ir passar, mas um erro de programao
ter sido ocultado.
-
20
Outro cenrio comum no contexto da utilizao de orientao a aspectos, o
padro de bug chamado ladro de excees [Coelho et al. 2008c]. Esse cenrio
ocorre quando um aspecto responsvel por tratar uma exceo no consegue realizar
a tarefa visto que um elemento do cdigo base prematuramente capturou a exceo,
geralmente tambm pelo abuso na utilizao da clusula catch-all.
Uma maneira de prevenir esses dois ltimos problemas relatados seria a troca
das clusulas catch-all indevidamente utilizadas por clusulas de catch especficas.
No entanto, essa soluo ainda muito frgil, visto que depende de convenes de
cdigo. Alm disso, nada impede que uma clusula catch-all indevida possa ser
inserida posteriormente durante uma manuteno de cdigo.
O framework JUnit no prov uma maneira de verificar quando um elemento
intermedirio erroneamente trata uma exceo. A nica maneira de realizar isso seria
criar um teste para cada elemento intermedirio, uma atividade que consome um
tempo adicional muito grande e est sujeita a erros. Esta limitao compreensvel
visto que o objetivo do JUnit realizar testes unitrios e no testes de tratamento de
excees. No obstante, quando se trata de excees, situaes em que o tratamento
de excees realizado incorretamente, como por exemplo uma propagao global
de uma exceo inesperada, pode ser uma fonte significativa de bugs, como mostram
os trabalhos de Coelho et al. [Coelho et al. 2008a] e Robillard e Murphy [Robillard and
Murphy 2003]. Isso particularmente percebido em linguagens de programao como
Java e C#, onde excees so objetos que podem ser capturados atravs da
subsuno de tipos [Robillard and Murphy 2003], ou seja, um tratador para uma
exceo E captura tambm excees E, onde E um subtipo de E.
Por outro lado, JUnit considerado como um padro para automatizao de
testes, e tem sido estendida em alguns cenrios para ser utilizada em um escopo
maior do que o de testes unitrios, como mostra o artigo de Partington no caso dos
testes de integrao [Partington 2012]. Alm disso, esta dissertao parte do princpio
de que a preocupao com o tratamento de excees deve fazer parte de todas as
atividades de desenvolvimento de software [Rubira et al. 2005], e o teste
automatizado d um suporte melhor a essa ideia do que um processo de
desenvolvimento baseado fortemente em documentao. Como consequncia, este
trabalho considera que a abordagem baseada em JUnit para testes pode e deve ser
empregada em outros contextos, no somente para o teste unitrio comum.
-
21
A linha de base desta dissertao que existe a necessidade de uma
abordagem que facilite o desenvolvimento de casos de teste para comportamento
excepcional que permita que: (i) sejam definidas regras de design, especificando
quais elementos (handlers) so responsveis por tratar as excees (exceptions)
lanadas por outros elementos (signalers); (ii) essas regras sejam consideradas como
uma documentao do tratamento de excees do sistema; (iii) sejam construdos e
executados testes que verifiquem se essas regras de design foram obedecidas;
1.2 Limitaes das abordagens atuais
Como observado anteriormente, as abordagens baseadas em anlise esttica
como as de Coelho et al. [Coelho et al. 2008a] e Garcia et al. [Garcia et al. 2011]
descobrem todos os possveis fluxos de exceo. Essas abordagens de anlise
esttica possuem limitaes como, por exemplo, o fato de que elas incluem uma
massa de dados referentes aos fluxos de exceo muito grande a ser analisada, no
caso de sistemas de grande porte, e podem retornar muitos falsos positivos, o que
exige um trabalho manual adicional.
Outras abordagens, como por exemplo, as de Cacho et al. [Cacho et al. 2008]
e Silva e Castor [Silva and Castor 2013] estendem as linguagens de programao
Java e AspectJ para permitir que os desenvolvedores especifiquem os fluxos de
excees atravs da descrio de canais de exceo e verifiquem estaticamente
esses fluxos. Essas abordagens compartilham das mesmas limitaes das
abordagens de anlise esttica visto que as excees no so exercitadas em tempo
de execuo.
Tambm foi observado que os casos de teste JUnit puros no conseguem
detectar problemas como por exemplo o bug ladro de excees e o tratamento
indevido de excees durante o seu fluxo no sistema.
As abordagens baseadas em documentao pesada como as de Rubira et al.
[Rubira et al 2005] e Kienzle [Kienzle 2008] vo de encontro ideia de evitar uma
sobrecarga nas atividades de desenvolvimento e ainda no permitem a verificao
automtica dos fluxos de exceo.
J no que diz respeito s regras de design, abordagens como a Desig Wizard
[Brunet, Neto and Figueredo 2009], DCL [Terra and Valente 2008] e a LSD [Neto
2010] permitem a definio e verificao automtica de regras de design em sistemas
-
22
orientados a objetos e orientados a aspectos. Porm elas no possuem construes
especficas para tratamento de excees, ou as construes so por demais
limitadas, para detectar as inconformidades alistadas na seo anterior.
1.3 Soluo proposta
A soluo proposta neste trabalho oferece uma abordagem baseada na
definio de regras de design especficas para o comportamento excepcional em
conjunto com a verificao dessas regras atravs de testes automticos baseados no
framework JUnit. Para isso proposta uma sequncia de atividades para a realizao
da abordagem, que so suportadas por uma ferramenta que resultado desta
dissertao, a VITTAE (Verification and Information Tool to Analyze Exceptions).
1.4 Objetivos
A dissertao tem como objetivo principal propor uma abordagem sistemtica
para a definio e checagem de regras de design voltadas para fluxos excepcionais.
Alm disso, o trabalho apresenta os seguintes objetivos especficos:
Propor uma linguagem para definio das regras de design voltadas para
fluxos excepcionais;
Propor uma ferramenta que permita realizar a verificao automtica das
regras atravs de testes automatizados;
Aplicar e avaliar a abordagem proposta atravs da sua aplicao em um
sistema com vrias verses;
Comparar sistematicamente atravs de um experimento controlado a
abordagem proposta nesta dissertao com a JUnitE [Di Bernardo et al. 2011]
tambm voltada para teste de fluxo excepcional.
-
23
1.5 Contribuies escritas ao longo da pesquisa
Parte dos resultados obtidos neste trabalho foram publicados nos seguintes
artigos, que esto no Apndice A:
SALES JUNIOR, R. ; COELHO, R. S. Preserving the Exception Handling
Design Rules in Software Product Line Context: A Practical Approach.
In: I Workshop on Exception Handling in Contemporary Software
Systems (EHCOS 2011), 2011. Proceedings of I Workshop on Exception
Handling in Contemporary Software Systems (EHCOS 2011),, 2011
SALES JUNIOR, R.; COELHO, R. S. ; LUSTOSA NETO, V. .Exception-
Aware AO Refactoring. In: IV Latin American Workshop on Aspect
Oriented Programming, 2010, Salvador. Anais do CBSoft, 2010.
Di Bernardo, R., Sales Jnior, R., Castor, F. Coelho, R., Cacho, N.,
Soares S. Agile Testing of Exceptional Behavior . 25th Brazilian
Symposium on Software Engineering (SBES 2011). So Paulo,
September 28-30, 2011 DOI: 10.1109/SBES.2011.28.
1.6 Organizao do texto
Alm deste capitulo introdutrio, esta dissertao apresenta mais 7 captulos,
organizados como descrito a seguir: o captulo 2 apresenta a fundamentao terica,
apresentando os conceitos essenciais relacionados com o teste de comportamento
excepcional e as regras de design; o captulo 3 apresenta o ncleo da dissertao,
descrevendo a abordagem proposta; o captulo 4 detalha a ferramenta desenvolvida
neste trabalho para suportar as atividades da abordagem; o captulo 5 apresenta um
estudo de caso realizado atravs da aplicao da ferramenta em diversas verses de
uma linha de produto de software; o captulo 6 apresenta o experimento controlado
que foi realizado para comparar a abordagem apresentada neste trabalho com a
JUnitE [Di Bernarndo et al. 2011], outra abordagem voltada para teste de fluxo
excepcional; o captulo 7 apresenta os trabalhos relacionados com a pesquisa
realizada nesta dissertao; por fim o captulo 8 conclui a dissertao e sugere
trabalhos futuros; o Apndice A apresenta os artigos cujos resultados foram fruto da
pesquisa realizada durante a elaborao desta dissertao.
-
24
-
25
2 Fundamentao Terica
O objetivo deste captulo apresentar uma fundamentao dos principais
conceitos necessrios para o entendimento do restante da dissertao. Inicialmente
ser apresentado o conceito de tolerncia a falhas (seo 2.1). Outra parte
importante, a verificao de software, bem como suas vertentes testes e anlise
esttica recebero destaque na seo 2.2. Tambm ser feita uma introduo breve
a ideia de automao de testes (seo 2.3) e ser apresentada a ferramenta de testes
unitrios para a Linguagem Java, o JUnit. Na seo seo 2.4 o paradigma de
Programao Orientada a Aspectos ser apresentado. Por fim, o conceito de Regras
de Design ser abordado na seo 2.5.
2.1 Tolerncia a falhas
O termo tolerncia a falhas [Avizienis 1998] tem sido utilizado pela comunidade
acadmica para designar a propriedade que permite que os sistemas, em geral
computacionais, continuem a operar adequadamente mesmo com a presena de
falhas. Porm, para entender melhor este termo necessrio entender os conceitos
bsicos de falha, falta e erro. Os conceitos a seguir so baseados nos trabalhos de
Laprie [Laprie 1985] e Anderson e Lee [Anderson and Lee 1981].
Uma falha (do ingls failure) num sistema de hardware ou de software ocorre
quando o servio prestado pelo sistema desvia-se do comportamento especificado.
Por exemplo, quando num determinado estado do programa o resultado produzido
por uma determinada entrada no corresponde ao esperado, geralmente uma falha
manifestada para o usurio, seja ele um ser humano seja ele outro sistema. Uma
falha ocasionada por uma falta (do ingls fault). A falta um acontecimento que
altera o padro normal de funcionamento de um dado componente de sistema, por
exemplo, uma queda na rede ou um trecho de cdigo escrito de forma incorreta. O
erro, j o estado intermedirio de instabilidade proveniente da falta e que pode ou
no resultar em uma falha.
-
26
Assim, o objetivo das tcnicas de tolerncia a falhas evitar que erros
acarretem falhas. Nesse contexto, excees podem ser utilizadas para indicar um erro
ou uma condio anormal do sistema, e mecanismos de tratamento de excees
podem ser empregados para prover tolerncia a falhas.
2.1.1 Tratamento de excees
De acordo com o clssico The C++ Programming Language [Stroustrup et al
2001] uma exceo um mecanismo que permite a uma parte de um programa
informar a outra parte de um programa que uma situao fora do normal foi detectada.
Em linguagens modernas de programao uma exceo modela uma condio de
erro de tal forma que ela possa ser tratada. Desta forma, tratamento de excees a
capacidade que um software tem para reagir apropriadamente diante da ocorrncia
de uma exceo, continuando ou interrompendo sua execuo, a fim de preservar a
integridade do sistema [Cristian 1982]. Visto que este trabalho focado em sistemas
desenvolvidos utilizando-se as linguagens Java e AspectJ, a subseo a seguir
apresenta como funciona o tratamento de excees nestas linguagens.
2.1.2 Tratamento de excees em Java
Em Java as excees so objetos de tipos herdados de uma classe especial
chamada Throwable. Na hierarquia de Classes Java essa classe se divide em duas
Error e Exception. A classe Error representa os erros internos da linguagem
Java ou erros da mquina virtual. A classe Exception representa os erros de
programao. As excees podem ser de dois tipos: checadas e no checadas. As
checadas devem ser explicitamente tratadas ou propagadas no programa. As no
checadas no so obrigadas a serem lanadas ou tratadas. Alguns exemplos de
excees no checadas so as excees devido a acesso a objetos nulos
(NullPointerException), excees devido a diviso por zero
(ArithmeticException) dentre outros casos. O tratamento de excees em Java
apresentado no trecho de cdigo a seguir. Um conjunto de instrues colocado
dentro de um bloco protegido (circundado pela palavra reservada try e um conjunto
de abre e fecha chaves). Se dentro desse trecho de cdigo uma exceo for lanada,
o programa interrompido na linha de cdigo que gerou a exceo e tem o seu fluxo
-
27
transferido para o trecho de cdigo que fica circundado pela palavra reservada catch
e um conjunto de abre e fecha chaves associado. Blocos try-catch podem ser
aninhados sem restrio. Neste caso especfico no momento que o sistema tentar
realizar a diviso por zero o fluxo do sistema transferido para o bloco catch onde
ser exibida uma mensagem de erro.
Uma exceo pode ser lanada ou relanada atravs do comando throw. A
palavra reservada throws na assinatura do mtodo define quais as Excees
checadas que podem ser lanadas pelo mtodo. Caso uma exceo no seja
capturada em nenhum ponto da hierarquia de chamadas ela pode ser propagada at
o ponto de entrada do programa fazendo com que a execuo seja interrompida de
forma inesperada.
2.2 Verificao de Software
De acordo com o IEEE [IEEE 1983], a verificao de software permite constatar
se o produto est sendo construdo corretamente de acordo com sua especificao.
O processo de verificao de software deve ser aplicado em cada estgio do
desenvolvimento e tem basicamente o objetivo de descobrir problemas em um
sistema. A verificao de software no permite garantir que o software est
completamente livre de erros, mas sim que ele bom o suficiente para o uso
pretendido. A verificao de software pode ser esttica, como por exemplo, atravs
de anlise esttica de cdigo, inspeo e verificao formal, e dinmica, como o
caso dos testes de software. Os tipos de verificao tratados nesta dissertao so a
anlise esttica e os testes de software.
1. try{
2. divisao = divisao / 0; 3. }
4. catch (Exception e){
5. System.out.println(Erro! Diviso por Zero!) 6. }
-
28
2.2.1 Anlise esttica
A anlise esttica consiste na anlise de representaes estticas do sistema
com o objetivo de descobrir problemas sem execut-lo. Chess e West [Chess and
West 2007] afirmam que a anlise esttica pode ser utilizada com diferentes objetivos,
dentre eles a verificao de tipos, verificao de estilo de escrita e verificao do
programa, ou seja, a anlise verifica se o programa est de acordo com os requisitos.
Nesta dissertao estamos interessados principalmente em encontrar inadequaes
deste ltimo tipo.
A anlise esttica traz algumas vantagens, dentre elas: (i) para realizar a
anlise esttica no necessrio que o cdigo seja executado, o que permite que ela
possa ser realizada at nas fases mais iniciais de desenvolvimento; (ii) por examinar
o cdigo a anlise esttica geralmente permite identificar a causa dos problemas, e
no somente os sintomas; (iii) pode ser realizada tanto de forma manual como
automtica e sobre o cdigo-fonte ou sobre o cdigo-objeto. Pelos motivos acima
citados podemos dizer que a anlise esttica uma tima complementao ao teste
de software.
Porm, a anlise esttica tem algumas desvantagens. Por exemplo, a anlise
esttica automatizada um problema computacional indecidvel no pior caso, visto
que este um caso clssico de um programa que analisa outro [Sipser 2005], ou seja,
resolv-lo equivalente a resolver o problema da parada [Turing 1936]. Alm disso,
toda a anlise esttica produz algum falso positivo ou algum falso negativo, ou os dois
[Chess and West 2007]. Ambos so indesejveis, visto que os falsos positivos podem
induzir o desenvolvedor a gastar tempo na resoluo de um problema que no existe,
e os falsos negativos escondem problemas que realmente existem. Alm disso, em
sistemas de grande porte, a massa de dados gerada pela anlise esttica e que deve
ser analisada pode tornar invivel esse tipo de verificao.
2.2.2 Testes de Software
O Teste de Software um processo de verificao que consiste em executar
um sistema com o objetivo de encontrar defeitos [Myers 1979]. Nos testes so
selecionados dados de entrada, configurado o ambiente para execuo do
programa, ele executado e ento feita uma anlise dos resultados obtidos.
-
29
No que diz respeito s estratgias de teste elas podem ser classificadas de
acordo com a informao usada como base para o design dos testes. Segundo
Meyers [Meyers 1979] os testes podem ser divididos em testes funcionais ou testes
estruturais, que so apresentados a seguir:
Testes funcionais (ou testes caixa-preta)
De acordo com Meyers [Meyers 1979], nos testes funcionais o programa
visto como uma caixa-preta, ou seja, no considera-se o comportamento interno do
mesmo. Como ilustra a Figura 2 dados de entrada so fornecidos, o teste executado
e o resultado obtido comparado ao resultado esperado de acordo com os requisitos.
O teste passa caso o resultado obtido for igual ao esperado. Caso contrrio, o teste
falha. Entre alguns exemplos de critrios de teste para testes funcionais listados por
Meyers esto: particionamento em classes de equivalncia; anlise do valor limite e
grafo de causa-efeito. Os testes JUnit (apresentado na seo 2.3.1) so exemplos
tpicos de testes funcionais.
Figura 2: Tcnica de Teste Funcional
Testes estruturais (ou testes caixa-branca)
Tambm de acordo com Meyers [Meyers 1979], diferentemente dos testes
funcionais, os testes estruturais so baseados no comportamento interno do sistema.
Como ilustra a figura Figura 3, essa tcnica trabalha diretamente em cima do cdigo-
fonte do componente de software que est sendo testado. So exemplos de testes
estruturais os testes de condio, testes de fluxo de dados, testes de ciclo e testes de
caminhos lgicos.
-
30
Figura 3:Tcnica de teste estrutural
Visto que este trabalho foca na realizao de testes JUnit que envolvem o
fluxo excepcional, para projetar tais testes necessrio conhecer a estrutura do
programa, e esses testes portanto se caracterizam como caixa-branca. A seguir
apresentado o conceito de nveis de teste.
2.2.3 Nveis de teste
A atividade de testes realizada em diferentes nveis ou estgios do
desenvolvimento e pode envolver o sistema inteiro ou parte dele durante o andamento
de seu desenvolvimento. Como o modelo V [Craig and Jaskiel 2002] da Figura 4 esses
estgios dependem da fase de desenvolvimento em que os testes podem ser
aplicados.
Figura 4: Modelo V adaptado de Craig e Jaskiel [Craig and Jaskiel, 2002] que descreve a correspondncia entre as atividades de desenvolvimento e os nveis de teste
-
31
. Crespo et al. [Crespo et al. 2004] caracteriza tais nveis da seguinte forma:
Testes de Unidade: tambm conhecidos como testes unitrios, tem por objetivo
explorar a menor unidade do projeto, procurando provocar falhas ocasionadas
por defeitos de lgica e de implementao em cada componente de software,
separadamente. O universo alvo desse tipo de teste so os mtodos, classes
ou pequenos trechos de cdigo.
Testes de Integrao: visam provocar falhas associadas s interfaces entre os
mdulos quando esses so integrados para construir a estrutura do software
que foi estabelecida na fase de projeto.
Teste de Sistema: avalia o software em busca de falhas por meio da utilizao
do mesmo, simulando a utilizao por um usurio final. Dessa maneira, os
testes so executados nos mesmos ambientes, com as mesmas condies e
com os mesmos dados de entrada que um usurio utilizaria no seu dia-a-dia
de manipulao do software. Verifica se o produto satisfaz seus requisitos.
Teste de Aceitao: so realizados geralmente por um restrito grupo de
usurios finais do sistema. Esses simulam operaes de rotina do sistema de
modo a verificar se seu comportamento est de acordo com o solicitado.
Existem ainda os testes de regresso que no so considerados como um
nvel visto que podem ser executados durante todo o desenvolvimento. Eles so
executados quando um componente modificado e deseja-se verificar se outras
funcionalidades no foram quebradas pela modificao.
2.3 Automao de testes
Embora o objetivo do processo de testes seja encontrar falhas em uma
aplicao de software, a sua realizao de forma manual frequentemente consome
muito tempo, exige um trabalho intensivo, a comparao dos resultados de teste
tediosa e propensa a erros. A automao de testes pode reduzir de maneira
significativa o esforo necessrio para realizar este processo, ou aumentar a
quantidade de testes que podem ser realizados dentro de um tempo limitado [Fewster
and Graham 1999].
-
32
Com o objetivo de automatizar parte deste processo, algumas ferramentas de
software vem sendo propostas. O trabalho de Meudec [Meudec 2001] divide em trs
principais categorias os softwares de automao de testes: (i) softwares para tarefas
administrativas de testes espeficicao dos testes e gerao de relatrios de testes;
(ii) softwares para tarefas mecnicas de testse execuo e monitoramento de testes,
captura e execuo de testes automatizados; (iii) softwares para gerao de testes.
Dentre as ferramentas da segunda categoria, que so o foco desta dissertao,
podemos destacar a ferramenta JUnit.
2.3.1 JUnit
O JUnit [JUnit 2012] foi criado como um framework para escrever testes de
unidade automatizados em Java. Esse framework facilita a criao de cdigo para
automao de testes com apresentao de resultados. Com ele pode ser verificado
se cada mtodo de uma classe funciona da forma esperada, exibindo possveis erros
ou falhas.
Figura 5: Arquitetura do JUnit (Fonte: http://www.devmedia.com.br/junit-implementando-testes-unitarios-em-java-parte-i/1432)
-
33
Como pode ser observado na Figura 5, no JUnit um teste de unidade
corresponde a uma classe que estende a classe TestCase. Essa classe possui os
seguintes mtodos:
run(): Cria um contexto (mtodo setUp), em seguida executa o cdigo e
verifica o resultado (mtodo runTest), limpando o contexto ao final (mtodo
tearDown);
setUp(): Mtodo chamado antes de cada mtodo de teste;
runTest(): Mtodo responsvel por controlar a execuo do teste em si;
tearDown(): Mtodo chamado aps cada mtodo de teste, devendo ser
utilizado para desfazer as operaes realizadas no mtodo setUp;
Para entendermos melhor como funciona o JUnit apresentamos a seguir um
trecho de cdigo de uma classe de um sistema de gerenciamento de contas bancrias
chamada Conta.
1. package br.ufrn.banco;
2.
3. //imports
4.
5. public class Conta{
6.
7. private double saldo;
8.
9. //gets e sets
10.
11. public void creditar(double valor){
12. saldo += valor;
13. Logger.log(Movimentao na conta em +
14. dataAtual);
15. }
16.
17. ...
18.
19. public void debitar(double valor){}
20.
21. ...
23.
24. public void realizarEmprestimo(doubleValor valor){}
25.
26. }
-
34
O trecho de cdigo a seguir exemplifica um teste simples em JUnit (Classe
SomaTeste) para os mtodos da classe Conta. Os mtodos desta classe
correspondem aos mtodos de teste, sendo que na verso 3 do JUnit cada mtodo
de teste precisa ter seu nome iniciado com a palavra test. Neste exemplo, depois de
instanciar uma conta e definir o saldo com um determinado valor realizada a
operao que se deseja testar, neste caso a operao creditar. Aps a execuo
do mtodo, deseja-se verificar se ele foi executado corretamente. Ento feita uma
assero, ou uma verificao de condio, e para isso o JUnit disponibiliza mtodos
que realizam estas verificaes. Neste caso foi utilizada a assero assertEquals
que avisa ao framework que ocorreu uma falha caso os dois parmetros no sejam
os mesmos.
1. //Exemplo de teste no JUnit 3
2. package br.ufrn.testes;
3.
4. import br.ufrn.banco.Conta;
5. import junit.framework.TestCase;
6.
7. public class SomaTest extends TestCase{
8. public void testSoma(){
9. Conta conta = new Conta();
10. conta.setSaldo(100.0);
11. conta.creditar(50.0);
12. assertEquals(150.0,conta.getSaldo());
13. }
14.}
15. //Agora o mesmo teste no JUnit 4
16. package br.ufrn.testes;
17.
18. import br.ufrn.banco.Conta;
19.
20. public class SomaTest{
21. @Test
22. public void testSoma(){
-
35
23. Conta conta = new Conta();
24. conta.setSaldo(100.0);
25. conta.creditar(50.0);
26. assertEquals(150.0,conta.getSaldo());
27. }
28.}
Como pode ser observado no trecho cdigo acima, na verso 4 do framework
para criar um teste no mais necessrio estender a classe TestCase. Alm disso,
para identificar um mtodo como sendo de teste no necessrio mais que o mtodo
inicie com a palavra test, bastando incluir a anotao @Test para identific-lo.
Tambm podemos observar na Figura 5, que existe uma classe chamada
TestSuite. Essa classe permite que sejam executados vrios testes, adicionando-
os atravs do mtodo addTest().
Para exibir os resultados, o Junit apresenta visualmente barras que
identificam se o teste passou, conforme mostra a Figura 6. A barra verde identifica
que o teste passou. A barra vermelha identifica que houve um erro durante a
execuo do teste.
Figura 6: Resultados visuais do JUnit
Esta dissertao apresenta uma extenso do framework JUnit para testes de
fluxos excepcionais.
-
36
2.4 Programao Orientada a Aspectos e AspectJ
A Programao orientada a Aspectos uma metodologia utilizada em
conjunto com os paradigmas de programao orientado a objetos e procedural, que
visa increment-los com conceitos e construes que permitam modularizar conceitos
transversais do sistema [Laddad 2003].
A programao Orientada a Aspectos permite aos desenvolvedores e
projetistas de software separarem e organizarem o cdigo de interesse comum a
vrias partes de um sistema (como por exemplo, conexo com banco de dados,
logging, tratamento de excees) encapsuladas em unidades de programao
chamadas aspectos. A esses interesses comuns chamamos crosscutting concerns
(ou interesses transversais).
Tomemos como exemplo o caso de logging de uma aplicao, como
mostrado no cdigo abaixo na implementao de orientao a aspectos utilizando a
linguagem AspectJ [AspectJ 2012].
Em basicamente toda a operao que se deseja registrar seria necessrio
incluir manualmente cdigo para armazenamento do logging, cdigo este que no
teria nenhuma relao com o objetivo da classe em que ele estaria sendo inserido. A
este tipo de cdigo chamamos de cdigo entrelaado. Agora imaginemos o quanto
isso dificultaria a manuteno e evoluo do sistema se houvesse uma quantidade
grande de classes em que seria necessrio fazer logging. A orientao a aspectos
resolve esse problema e complementa a orientao a objetos com a criao de um
aspecto logging (exemplificado no cdigo AspectJ abaixo) que encapsula a operao
de logging e ativado de acordo com uma regra indicada no aspecto (neste caso,
todas as operaes na classe conta bancria).
1. package br.ufrn.aspects;
2.
3. imports
4.
5. public aspect Logging{
6.
7. pointcut operacaoBancaria(): execution(
8. *br.ufrn.banco.Conta.*(..));
9.
10. after() : operacaoBancaria(){
-
37
11. Logger.log(Movimentao na conta em + dataAtual);
12. }
13.}
Vamos analisar melhor este cdigo. O primeiro elemento que aparece o
pointcut. O pointcut uma regra que define onde o aspecto dever ser ativado. No
nosso exemplo criamos um pointcut chamado operacaoBancaria que ativado
toda vez que um mtodo com quaisquer tipos de parmetros da classe Conta
executado.
O segundo elemento do nosso aspecto o advice. O advice define que aps
a execuo do pointcut operacaoBancaria ser executado um trecho de cdigo,
neste caso o trecho de Logging. Dessa forma em apenas algumas linhas de cdigo
definimos um conceito transversal, evitando a replicao em diversas partes de
cdigo de logging.
Outro elemento importante do AspectJ a declarao declare soft. Esta
declarao da linguagem permite suavizar uma exceo, o seja, silenciar a exceo
e relan-la como uma exceo no-checada.
A ferramenta fruto deste trabalho utiliza AspectJ no seu core. Alm disso, ela
permite a verificao de regras de fluxo excepcional tambm em cdigo orientado a
aspectos usando AspectJ. A seguir apresentamos o conceito base para as regras de
fluxo excepcional que servem de dados de entrada para os testes executados
utilizando a ferramenta desta dissertao.
2.5 Regras de Design
Uma atividade comum a todo processo de software o design do software. O
design incorpora a descrio da estrutura do software, os dados que so manipulados
pelo sistema, a descrio das interfaces entre os componentes do sistema, e algumas
vezes o algoritmo utilizado [Belady 1981]. Ele implementa importantes decises sobre
a arquitetura do software e possui um papel crucial no desenvolvimento, implantao
e evoluo do sistema [Krutchen et al. 2006].
Contudo, nem sempre a implementao reflete o design proposto. Isso acontece
porque frequentemente a documentao que expressa o design imprecisa e/ou
obsoleta. Esta inconsistncia entre o design documentado e a implementao tem
-
38
sido apontada como uma das principais causas de baixa qualidade de software
[Parnas 1994, van Gurp and Bosh 2002].
Neste contexto, a verificao de conformidade entre o design e a implementao
uma prtica que promove a qualidade do software. Neste sentido as regras de
design (do ingls design rules) [Baldwin and Clark 1999] especificam como as
entidades de software devem ou no se relacionar com as demais. Essas regras
definem contratos que devem ser rigidamente obedecidos em todas as fases
posteriores do ciclo de vida do processo de construo do software. Essa abordagem,
alm de promover a modularidade do sistema, favorece o paralelismo de
desenvolvimento. Ela pode ser considerada como uma camada de abstrao acima
da camada de implementao.
Nosso trabalho prope uma forma de descrever regras de design especficas
para o comportamento excepcional da aplicao.
2.6 Discusses
Este captulo apresentou os conceitos fundamentais que norteiam este trabalho,
como Tolerncia a Falhas, Verificao de Software, JUnit, Programao Orientada a
Aspectos e Regras de Design. O prximo captulo apresentar a abordagem proposta
por este trabalho.
-
39
3 Abordagem Proposta
O objetivo deste captulo apresentar a abordagem de testes de fluxos
excepcionais proposta neste trabalho. Um exemplo motivador apresentado na
seo 3.1. Logo depois a abordagem descrita na seo 3.2 com a ajuda de um
exemplo. Por fim, na seo 3.3, feito um fechamento do captulo e algumas
discusses so realizadas.
3.1 Exemplo Motivador Refatorao de Sistemas Orientados a
Objetos para Aspectos
Na seo 1.1 apresentamos um exemplo motivacional que mostrou algumas
limitaes da utilizao de casos de teste JUnit puros para detectar problemas de
comportamento excepcional. Nesta seo, apresentamos um exemplo adicional que
demonstra ainda outros problemas no tratamento de excees que podem ocorrer
quando um sistema computacional refatorado para utilizar um mecanismo de
orientao a aspectos.
Quando um sistema orientado a objetos refatorado para utilizar orientao a
aspectos uma questo surge: o conceito transversal a ser encapsulado em um
aspecto pode lanar alguma exceo? Se a resposta for positiva, o time de
desenvolvimento precisa lidar com duas tarefas igualmente importantes: (i) permitir
que o aspecto criado lance a exceo; (ii) pr em prtica a regra de design voltada
para fluxos excepcionais descrita no trabalho de Coelho et al. como soluo para bug
pattern Handlerless Signaler Aspect [Coelho et al. 2008b] que consiste em criar um
aspecto tratador de erro que ser responsvel por tratar as excees lanadas pelo
aspecto que encapsula o conceito transversal. Se a exceo lanada pelo aspecto
criado checada, devido a uma limitao da linguagem AspectJ, necessrio
convert-la em uma outra exceo no checada, atravs da utilizao da construo
declare soft do AspectJ, para que ela possa ser lanada. Este tipo de exceo
tambm deve ser tratada pelo aspecto tratador de erro.
Entretanto, algumas caractersticas do tratamento de exceo que realizado
no cdigo base (ou seja, o cdigo orientado a objetos), podem impedir que os
-
40
aspectos de tratamento de erro realizem o tratamento de exceo adequadamente,
levando assim a quebra de uma regra de design da aplicao. Para ilustrar, na Figura
7 apresentada a arquitetura de um sistema de gerenciamento de contas bancrias
que foi refatorado para utilizar orientao a aspectos.
Figura 7: Arquitetura de um sistema refatorado para Aspectos
Como pode ser observado este sistema utiliza o padro de arquitetura em
camadas e implementa os seguintes interesses transversais:
PerformanceMonitoring: o responsvel por monitorar a
performance de cada requisio servlet.
NegativeValueOnOpCheck: Verifica quando a transferncia foi
realizada com um valor negativo.
NegativeValueOnOpHandler: Responsvel por tratar as instncias
da exceo no checada NegativeValueOnOpException. Lanadas
pelo aspecto NegativeValueOnOpCheck.
No sistema, nenhum aspecto tratador de erro foi definido para o aspecto
PerformanceMonitoring porque cada exceo lanada por este monitor pode ser
tratada dentro do prprio aspecto. Em outras palavras, as excees lanadas durante
o monitoramento no devem causar distrbios aos fluxos excepcionais do sistema
que est sendo monitorado.
O trecho de cdigo a seguir pertence ao aspecto NegativeValueOnOpCheck:
-
41
1. public aspect NegativeValueOnOpCheck {
2.
3. //intercepta retiradas, crditos e transferncias
4. pointcut valueReceiversOps = ...;
5.
6. before (double value) :
7. execution(valueReceiversOps) && args(value)
8. {
9. if (value < 0){
10. throw new NegativeValueOnOpException();
11. }
12. }
13.}
Percebemos que nesta aplicao, uma regra de design de fluxo excepcional
que todas as instncias da exceo no checada NegativeValueOnOpException
lanadas pelo aspecto NegativeValueOnOpCheck devem ser tratadas pelo
aspecto tratador de erro NegativeValueOnOpHandler, cujo cdigo exibido a
seguir.
1. public aspect NegativeValueOnOpHandler {
2. ...
3. pointcut valueReceiversOps=...;
4. void around () : call (valueReceiversOps){
5. try{
6. proceed();
7. }catch(NegativeValueOnOpException nvoe){
8. //treating exception
9. }
10. }
11.}
Uma quebra da regra de design de fluxo de tratamento de exceo que pode
surgir durante o refatoramento conhecida como exception stealer ou ladro de
excees [Coelho et al. 2008c], e foi abordado na seo 1.1. Ela ocorre quando o
aspecto de tratamento de erro no consegue tratar a exceo lanada por um aspecto
que encapsula um interesse transversal porque um elemento do cdigo base
-
42
prematuramente captura a exceo. No exemplo do sistema de gerenciamento de
contas bancrias o aspecto NegativeValueOnOpHandler foi criado para tratar
qualquer instncia de NegativeValueOnOpException lanada pelo aspecto
NegativeValueOnOpCheck. Entretanto, uma clusula catch-all definida no cdigo
base ir tratar qualquer instncia NegativeValueOnOpException antes de
NegativeValueOnOpHandler entrar em ao, como ilustra a Figura 8.
Figura 8: Viso esquemtica do "ladro de excees"
O trecho de cdigo a seguir ilustra a classe Bank que contm a clusua catch-
all (linha 6), impedindo o aspecto NegativeValueOnOpHandler de tratar as
instncias de NegativeValueOnOpException.
1. public class Bank{
2. ...
3. public void credit(Account c, double val){
4. try{
5. //method body
6. }catch (Exception e){
-
43
7. //handles the exception
8. }
9. }
10. public void debit (Account c, double val) throws
11. NegativeBalanceException{
12. double aux = c.getBalance();
13. aux = aux val;
14. if(aux
-
44
Figura 9: Sequncia de Atividades da Abordagem Proposta
Com o objetivo de auxiliar nas atividades dessa abordagem, foi elaborada a
ferramenta VITTAE [Sales Jnior and Coelho 2011] que estende o framework JUnit e
apoia as atividades de projeto e automao dos testes, execuo e avaliao.
A estrutura da ferramenta ser explanada no prximo captulo. Porm, seu
funcionamento ser explicado medida que os passos da abordagem forem
explicados a partir das prximas subsees.
3.2.1 Passo1: Definio das Regras de Design Excepcionais da Aplicao
A tarefa de definir as regras de design excepcionais essencial, visto que estas
regras que devero ser obedecidas durante o desenvolvimento e manuteno do
software. Alm disso, as regras de design so muito teis como uma forma de
documentao complementar do sistema. A descoberta das regras de design foge do
escopo desta dissertao. Entretanto, podemos indicar algumas fontes de
informaes podem ser utilizadas para realizar esta tarefa. Para tanto podemos
vislumbrar duas situaes possveis:
a) As regras de design so estabelecidas antes do incio do
desenvolvimento: Quando isso acontece as regras podem ser extradas de
documentos e modelos que definem a arquitetura, do conhecimento do
arquiteto de software sobre como o sistema ir funcionar, das prprias
especificaes de requisitos do sistema e tambm de anti-padres de
tratamento de excees [McCune 2006] e de padres de bugs [Allen 2001].
Um exemplo que ilustra como seria o estabelecimento dessas regras de
design previamente seria o caso de um sistema onde definido que ser
utilizado a orientao a Aspectos. Como explicado na seo 3.1, o padro
de bug Handlerless Signaler Aspect ocorre quando um aspecto lana uma
-
45
exceo, mas nenhum handler definido para trata-la. Para evitar este
problema, pode-se previamente definir uma regra de design excepcional que
exija que uma exceo lanada por um aspecto seja capturada por outro
determinado aspecto (Error Handling Aspect).
b) As regras de design so estabelecidas ou evoludas aps o incio
do desenvolvimento: Nestes casos a variedade de fontes maior. Alm
das fontes citadas anteriormente podemos nos valer de uma anlise do
cdigo-fonte e dos relatrios de bugs e logs de exceo do sistema.
Para entender melhor a estrutura do XML Schema a exibe o XML Schema do
arquivo de regras de design.
Figura 10: XML Schema para o arquivo que define as regras de design da aplicao
Em nossa abordagem as regras de design so definidas em um arquivo XML. Nossa
escolha por essa linguagem se deveu ao fato de que XML consegue expressar bem
os conceitos representados na ferramenta, bastante utilizada por programadores
-
46
Java em outras ferramentas e, alm disso, possui diversas bibliotecas estveis e
simples em diversas linguagens de programao.
Podemos observar que o XML inicia com um elemento raiz chamado contract.
A partir da podemos definir diversos elementos signaler. Este elemento representa
um mtodo (ou conjunto de mtodos atravs do uso de um wildcards com o uso do
caractere * semelhante aos utilizado nos pointcuts do AspectJ) responsvel por
lanar, atravs da criao ou propagao, um ou mais tipos de exceo, que
definido atravs do atributo signature. Para cada signaler podemos ter diversos
elementos do tipo exception que representam as excees lanadas por este
mtodo, descritas no atributo type. Para cada elemento exception podemos ter
um ou mais elementos handler. Esse elemento representa o mtodo (ou conjunto
de mtodos utilizando o mesmo wildcard descrito para o elemento signaler)
responsvel por capturar a exceo, definido atravs do atributo signature.
Para ilustrar como esse XML preenchido vamos tomar como base o cdigo do
mtodo debit da classe Bank exibida na seo 3.1. Este mtodo pode lanar uma
exceo se o saldo da conta ficar negativo com a operao de dbito. Para este
mtodo podemos formular a seguinte regra:
Neste exemplo analisado, a especificao que cada instncia da exceo
NegativeBalanceException lanada pela operao debit com valores do tipo
Account e double da camada Facade deve ser tratada pelo mtodo
handlerNegativeBalance() da classe ServletClient.
Em um projeto que utiliza nossa abordagem, os contratos ficam armazenados
em um arquivo chamado contract.xml que deve ficar dentro de uma pasta
chamada contracts na raiz do projeto, conforme mostra a Figura 11.
-
47
Figura 11: Estrutura do projeto com a VITTAE e localizao do arquivo de contratos
3.2.2 Passo 2 : Projeto e Automao do Teste
Aps a definio das regras de design excepcionais necessrio que estas
sejam verificadas. Para isso preciso estimular tanto o cdigo que lana a exceo
quanto o cdigo que trata a exceo. Para estimular o cdigo que trata a exceo e
automatizar este teste, deve ser criado um caso de teste JUnit que chama o mtodo
responsvel por tratar uma determinada exceo do contrato. Atravs da VITTAE
nossa abordagem prov um suporte ferramental para criao de um esqueleto do
teste, destacando a chamada do mtodo que trata a exceo. Para fazer isso
necessrio chamar o mtodo chamado generateTests() da classe
br.ufrn.gits.fear.generators.ExceptionContractTestGenerator. No
cdigo abaixo apresentado um exemplo de esqueleto de teste gerado pela
ferramenta, baseado no contrato apresentado na seo anterior para a o mtodo
debit da classe Bank.
1. //declare package
2.
3. //imports
4.
5. ...
6. public class NegativeBalanceExceptionBankOperationEHTest extends
7. TestCase{
8. public void test01 (){
9.
-
48
10. ServletClient handler = new ServerClient();
11.
12. handler.handlerNegativeBalance();
13. }
14.}
Como podemos observar somente o esqueleto gerado ainda no suficiente
para realizar o teste. A complementao do caso de teste e a garantia de que o
mtodo que trata a exceo seja chamado corretamente ficam a cargo do testador.
Alm disso, faz-se necessrio garantir que durante a realizao do teste,
existam condies para que a exceo esperada definida na regra de design seja
lanada. No caso do nosso exemplo acima, seria necessrio durante o teste instanciar
os objetos de tal forma que quando o mtodo handlerNegativeBalance seja
chamado, o fluxo alcance o mtodo debit da classe Bank. Alm disso, o mtodo
debit precisa ser chamado com parmetros que o levem a lanar a exceo
NegativeBalanceException (por exemplo com o parmetro value com valor
negativo). Com esse objetivo de auxiliar nessa tarefa aconselha-se o uso de objetos
mock [Freeman and Craig 2001]. Os objetos mock so um padro de design para
testes unitrios onde um objeto mock simula o propsito de um objeto real sem a
necessidade de instanciar o objeto real. Em nossa abordagem, a ferramenta VITTAE
gera juntamente com as classes de Teste, mocks para simular o lanamento da
exceo quando o mtodo signaler for chamado com qualquer parmetro. Em termos
simples, o mock gerado um aspecto que, independente da situao, quando o
mtodo signaler chamado dentro do teste JUnit lana automaticamente a exceo
definida na regra. O cdigo a seguir apresenta um exemplo de aspecto mock para
simular o lanamento da exceo pelo signaler.
1. package br.ufrn.gits.tests;
2.
3. //imports
4. @Aspect
5. public class
6. NegativeBalanceExceptionBankOperationEHMockTestAspect {
7.
8. @Around("execution (*Bank.debit(Account,double)) &&
-
49
9. cflow(execution(*
10. NegativeBalanceExceptionBankOperationEHTest.*(..)))")
11.
12. public Object
13. launchNegativeBalanceException(ProceedingJoinPoint
14. thisJoinPoint)
15. throws NegativeBalanceException
16. {
17. throw new NegativeBalanceException();
18. }
19. }
O aspecto acima, que utiliza a forma de anotaes do AspectJ, executado no
lugar do mtodo signaler, neste caso, Bank.debit, e lana automaticamente a
exceo NegativeBalanceException.
Caso no fosse utilizado este mock, seria necessrio garantir que durante a
execuo do mtodo para debitar, o mtodo handlerBankOperation chamasse o
mtodo Bank.debit com um valor para o parmetro value negativo.
3.2.3 Passo 3 : Execuo do teste
Aps a construo do teste, faz-se necessrio realizar a execuo automatizada
dos testes. Visto que a abordagem constri os casos de teste em cima do framework
JUnit e utiliza os mecanismos desse framework para reportar os sucessos e erros,
pode-se utilizar toda a sua estrutura para automatizar essa execuo. O JUnit permite
a criao de conjuntos, ou sutes, de testes, e a gerao de relatrios de execuo,
que so usados para avaliao dos testes. Como j explicado no captulo anterior o
JUnit reporta visualmente os casos de uso que passaram e que falharam.
3.2.4 Passo 4 : Avaliao do Teste
Aps a construo dos testes, o prximo passo avaliar os resultados da
execuo automatizada. O JUnit caracteriza uma falha em um teste atravs de uma
barra vermelha e um failure trace.
-
50
Quando ocorre uma quebra da regra de design a VITTAE lana uma exceo do
tipo ContractCheckingException, exibindo qual a regra que foi quebrada e quais
foram os signalers e handlers. Dessa forma possvel analisar os motivos pelos quais
ocorreu a quebra de design.
A Figura 12 a seguir exibe inicialmente como o JUnit puro no consegue fornecer
informaes relacionadas ao fluxo do tratamento de exceo, enquanto a Figura 13
exibe um exemplo da atuao da VITTAE para avaliao do resultado durante a
execuo de um teste.
Figura 12: Tela do JUnit sem a extenso da VITTAE
Figura 13: Exemplo de utilizao do framework JUnit em conjunto com a VITTAE para execuo automatizada dos testes
Para ilustrar como seria a anlise tomemos os mesmos contratos e testes que
j foram criados nos passos anteriores, mas agora injetaremos uma quebra da regra
de design com uma pequena modificao na classe Bank como ilustrada no cdigo
a seguir.
-
51
1. public class Bank{
2. ...
3. public void credit(Account c, double val){
4. try{
5. //method body
6. }catch (Exception e){
7. //handles the exception
8. }
9. }
10. public void debit (Account c, double val){
12. double aux = c.getBalance();
13. aux = aux val;
14. try{
15. ...
16. if(aux
-
52
Podemos verificar que a ferramenta VITTAE identificou que um elemento
intermedirio no declarado na regra de design interceptou a exceo, e a tratou
quando no deveria ter feito isso de acordo com a regra de design de fluxo
excepcional da aplicao. Se a mesma exceo for lanada a partir de vrios lugares
do sistema, basta incluir uma clusula signaler nova para a mesma exception no
arquivo contract.xml. Se a mesma exception do mesmo signaler for
capturada em mais de um ponto no sistema, basta incluir uma nova clusula handler
dentro da mesma clusula signaler e dentro da mesma clusula exception da
regra.
Aps a avaliao dos testes pode-se observar que determinadas regras no so
mais aplicveis, ou que sofreram atualizaes. Alm disso, pode ser que durante o
desenvolvimento novas regras sejam estabelecidas. Nestes casos necessrio