Tanto a orienta¸c˜ao a aspectos quanto os mecanismos de tratamento de exce¸c˜oes tˆem como objetivo apoiar o desenvolvimento de software robusto. No entanto, a utiliza¸c˜ao de ambos torna poss´ıvel a introdu¸c˜ao de novos tipos de erros. Os estudos abordados nesta subse¸c˜ao discutem os tipos de erros referentes `a utiliza¸c˜ao de OA, assim como os defeitos que podem levar a ocorrˆencia destes erros, pois na maioria dos casos esses defeitos podem gerar erros tanto no fluxo normal quanto no fluxo de exce¸c˜oes.
Zhang e Zhao (2007) apresentam padr˜oes de defeitos para programas AspectJ. Eles s˜ao divididos em trˆes categorias: visibilidade do ponto de jun¸c˜ao, impacto do adendo e modifica¸c˜ao do c´odigo base.
Baekken e Alexander (2006) apresentam um modelo de defeitos para programas As- pectJ voltado para defeitos relacionado aos pointcuts. Os defeitos descritos nesse tra- balho s˜ao dos seguintes tipos: padr˜oes incorretos, escolha incorreta do tipo de pointcut, casamento incorreto de circunstˆancias dinˆamicas, composi¸c˜ao incorreta do pointcut e combina¸c˜ao anˆomala de pointcuts.
Ferrari et al. (2010) apresentam uma taxonomia de defeitos OA revisada e refinada que identifica tipos de defeitos (faults). A taxonomia apresentada divide os defeitos em quatro grupos: o primeiro grupo ´e composto por defeitos relacionados `as express˜oes de pointcuts, o segundo grupo cont´em defeitos relacionados a declara¸c˜oes inter-tipo, o ter- ceiro grupo cont´em defeitos relacionados com a defini¸c˜ao e implementa¸c˜ao de adendos e,
por fim, o quarto grupo se refere a defeitos relacionados ao programa que podem ocorrer por causa da falta de conhecimento dos programadores sobre os aspectos do programa ou por causa do processo de evolu¸c˜ao do software.
Coelho et al. (2008) apresentam um estudo sistem´atico que avalia a propens˜ao de erros em algumas constru¸c˜oes do tratamento de exce¸c˜oes em programas OA. Os resultados desse estudo indicam que o c´odigo de tratamento de exce¸c˜oes em sistemas OA ´e propenso a erros. ´E apresentado um cat´alogo de padr˜oes de erros com nove padr˜oes: Inactive Aspect
handler, Late Binding Aspect Handler, Obsolete Handler in the Base Code, Solo Signaler Aspect, Unstable Exception Interfaces, Handler Mismatch, Solo Declare Soft Statement, Unchecked Exception Cause e The Precedence Dilemma.
Inactive Aspect handler. Esse tipo de erro ocorre quando um aspecto de tratamento
(handler ) n˜ao trata a exce¸c˜ao que ele pretendia tratar. A causa ´e um defeito no PCD.
Late Binding Aspect Handler. Ocorre quando o aspecto handler est´a com o PCD
aparentemente correto, porem uma exce¸c˜ao foi capturada anteriormente por um "catch all clause" do c´odigo-base. Este padr˜ao de erro ´e dif´ıcil de identificar porque algumas IDE indicam para o desenvolvedor que os JPs que definem onde a exce¸c˜oes devem ser capturadas est˜ao corretos.
Obsolete handler in the Base Code. Ocorre quando um aspecto handler lida com uma
exce¸c˜ao previamente lan¸cada por um m´etodo e o handler associado a essa exce¸c˜ao no c´odigo base se torna obsoleto.
Solo Signaler Aspect. Solo Signaler s˜ao aspectos que sinalizam uma exce¸c˜ao que n˜ao
tem nenhum handler definido para ela, podendo levar a falhas causadas tamb´em pelo padr˜ao de erro Inactive Aspect handler.
Unstable Exception Interface. Este padr˜ao de erro est´a relacionado `a capacidade dos
aspectos de desestabilizar a interface de exce¸c˜ao dos m´etodos interceptados. Quando um adendo sinaliza uma exce¸c˜ao no escopo est´atico ou dinˆamico, a interface de exce¸c˜ao ´e alterada de acordo com escopo onde o m´etodo ´e invocado. Como consequˆencia disso, o m´etodo pode lan¸car um conjunto diferente de exce¸c˜oes, o que pode acabar levando ocorrˆencia de um erro.
Solo Declare Soft Statement. No AspectJ, as exce¸c˜oes podem ser suavizadas (softened )
e, quando isso ocorre, cabe ao desenvolvedor implementar um outro aspecto que ser´a respons´avel por trat´a-la. Este recurso do AspectJ e fr´agil: quando o desenvolvedor n˜ao faz o tratamento da exce¸c˜ao suavizada, nenhuma mensagem ´e enviada pra ele na compila¸c˜ao do sistema.
Unchecked Exception Cause. No AspectJ, quando uma exce¸c˜ao ´e suavizada ela ´e
transformada em um objeto SoftException. Com isso, algumas informa¸c˜oes ´uteis sobre a exce¸c˜ao acabam sendo escondidas. Para lidar com esta limita¸c˜ao, ao tratar a SoftEx-
ceptiondeve-se acessar a informa¸c˜ao atrav´es do m´etodo getCause() e comparar´a-la com todas exce¸c˜oes que podem ser lan¸cadas no contexto dos handlers.
Handler Mismatch. Ocorre quando exce¸c˜oes s˜ao suavizadas, mas os handlers foram
definidos para capturar as exce¸c˜oes primitivas (tipos das exce¸c˜oes antes de serem transfor- mada em SoftException) e as exce¸c˜oes se tornem n˜ao capturadas (uncaught), ou sejam capturadas por handlers n˜ao pretendidos para elas.
The Precedence Dilemma. Este erro ocorre quando, ap´os lan¸car uma exce¸c˜ao, o adendo
´e utilizado tamb´em para fazer suaviza¸c˜ao em um pointcut espec´ıfico. Neste caso, ambas as constru¸c˜oes tentam converter uma exce¸c˜ao em outra. A consequˆencia disso ´e que o
weaver n˜ao consegue decidir qual delas deve ocorrer primeiro e ent˜ao inclui no bytecode
somente o c´odigo relativo `a declara¸c˜ao da SoftException. Este erro gera uma SoftEx- ception que n˜ao pode ser capturada da maneira adequada.
Os padr˜oes de erros nos mecanismos de tratamento de exce¸c˜oes apresentados neste trabalho podem ser relacionados com os outros padr˜oes de erros e defeitos apresentados nesta se¸c˜ao (Baekken e Alexander, 2006; Ferrari et al., 2010; Zhang e Zhao, 2007). Por exemplo, o padr˜ao de erro Obsolete (or Outdated) Handler in the Base Code, pode ser causado por algum defeito que pertence ao quarto grupo da taxonomia de Ferrari et al. (2010), erros referentes ao padr˜ao Inactive Aspect Handler podem ser equivalentes a erros de visibilidade do ponto de jun¸c˜ao (Zhang e Zhao, 2007) e podem ter como causas os defeitos apresentados por Baekken e Alexander (2006) ou pertecerem ao primeiro grupo da taxonomia de Ferrari et al. (2010).
3.7
Estudos emp´ıricos
Sinha e Harrold (2000) realizaram trˆes estudos emp´ıricos. O primeiro estudo visou iden- tificar a frequˆencia com a qual o tratamento de exce¸c˜oes ocorre em programas Java. O segundo estudo emp´ırico focou em avaliar a precis˜ao da representa¸c˜ao do fluxo de con- trole, para o tratamento de exce¸c˜oes proposta nesse trabalho. O terceiro estudo emp´ırico avaliou os efeitos das constru¸c˜oes de tratamento de exce¸c˜oes na an´alise das dependˆencias de controle do programa.
O trabalho de Romano et al. (2011) tamb´em relata um estudo emp´ırico com o objetivo de avaliar a eficiˆencia da abordagem que propuseram no artigo. Para o estudo foram utilizadas seis aplica¸c˜oes de open source que derivaram 27 vers˜oes. Os resultados desse estudo mostram a capacidade da abordagem proposta para identificar tanto problemas de NullPointerExceptionartificialmente introduzido e reais e al´em disso, o estudo emp´ırico indica que a abordagem supera significativamente a abordagens de gera¸c˜ao de dados de teste aleat´orios.
O trabalho Briand (2007) n˜ao apresenta um estudo emp´ırico mas sim uma an´alise cr´ıtica sobre os estudos emp´ıricos na ´area de teste de software. Essa an´alise fornece uma vis˜ao das quest˜oes de validade mais comumente encontradas durante a execu¸c˜ao de es- tudos emp´ıricos de t´ecnicas de teste de software. Ela aponta que, como para qualquer outro campo emp´ırico cient´ıfico, a defini¸c˜ao de procedimentos-padr˜ao para a engenharia de software experimental aplicada a teste de software vai levar tempo, mas para iniciar este processo iterativo, devemos primeiro reconhecer claramente os problemas e identifi- car solu¸c˜oes potenciais para explorar. Eles recomendam tamb´em que, embora n˜ao haja nenhuma solu¸c˜ao perfeita para as amea¸cas de validade identificados, pr´aticas simples e melhores relat´orios dos estudos pode ser um caminho na constru¸c˜ao do conhecimento sobre o custo-efic´acia das t´ecnicas de teste.
3.8
Considera¸c˜oes Finais
O tratamento de exce¸c˜oes ´e um mecanismo que separa o c´odigo de tratamento de exce¸c˜oes do c´odigo normal e ´e adotado por muitas linguagens de programa¸c˜ao, principalmente linguagens de programa¸c˜ao orientada a objetos como C++ e Java. No entanto, um grande n´umero de programadores n˜ao o utiliza corretamente e, al´em disso, muitos programadores podem utiliz´a-lo apenas para satisfazer os requisitos b´asicos de verifica¸c˜ao como o do Java. As falhas causadas pelo uso incorreto do tratamento exce¸c˜oes s˜ao muito dif´ıceis de serem detectadas. Portanto, para melhorar a robustez e a confiabilidade do software, especialmente para sistemas cr´ıticos de seguran¸ca, atividades de VV&T s˜ao absolutamente necess´arias.
Abordagens Linguagem OO/OA N´ıvel de teste Ferramenta
(Sinha e Harrold, 2000) Java OO Teste de integra¸c˜ao JABA
(Mao e Lu, 2005) C++ OO Teste de integra¸c˜ao CppTest
(Vincenzi et al., 2006) Java OO Teste de Unidade JaBUTi
(Lemos et al., 2007) AspectJ OA Teste de Unidade JaBUTi/AJ
(Lemos e Masiero, 2011) AspectJ OA Teste de integra¸c˜ao JaBUTi/AJ
(Cafeo e Masiero, 2011) AspectJ OA Teste de integra¸c˜ao JaBUTi/AJ
(Xavier et al., 2008) Java OO Verifica¸c˜ao JPathFinderE
(Coelho et al., 2011) AspectJ OA Verifica¸c˜ao SAFE
(Romano et al., 2011) Java OO Gera¸c˜ao de dados de teste
(Di Bernardo et al., 2011) Java OO Teste funcional JunitE
(Sales e Coelho, 2011) Java OO Teste funcional VITTAE
(Nunes et al., 2009) Java OO Gera¸c˜ao de dados de teste OConGraX
Tabela 3.3: Abordagens de teste e verifica¸c˜ao do fluxo de exce¸c˜ao.
Por isso, diferentes abordagens tˆem sido propostas para as atividades de verifica¸c˜ao, valida¸c˜ao e teste para tratamento de exce¸c˜oes. A tabela 3.3, apresenta as abordagens que foram encontradas na revis˜ao realizada e nela pode-se visualizar que para o paradigma
OO j´a foram propostas abordagens para teste de integra¸c˜ao para as linguagens C++ e Java. J´a para o paradigma OA existem duas abordagens, mas nenhuma delas ´e adequada para o teste do tratamento de exce¸c˜oes: a primeira tem como foco um ponto especifico do teste de integra¸c˜ao que ´e a integra¸c˜ao entre adendo e m´etodos, com o objetivo de encontrar erros relacionados aos pointcuts (Lemos e Masiero, 2011) e a segunda n˜ao representa o fluxo de exce¸c˜ao de maneira adequada (Cafeo e Masiero, 2011), no cap´ıtulo 4 s˜ao discutidas as limita¸c˜oes dessa abordagem para seu uso no teste do tratamento de exce¸c˜oes. Assim esta revis˜ao da literatura indica que ainda h´a lacunas de pesquisa a serem exploradas em rela¸c˜ao ao teste de integra¸c˜ao para tratamento de exce¸c˜oes em programas OO/OA.