ExceptionPolicyExpert: Uma Ferramenta para Auxiliar no Desenvolvimento do Tratamento ... · 2017-11-04 · Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática

Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da Terra

Departamento de Informática e Matemática AplicadaPrograma de Pós-Graduação em Sistemas e Computação

Mestrado Acadêmico em Sistemas e Computação

ExceptionPolicyExpert: Uma Ferramentapara Auxiliar no Desenvolvimento do

Tratamento de Exceções

Taiza Rabello Montenegro

Natal-RNFevereiro de 2017

Taiza Rabello Montenegro

ExceptionPolicyExpert: Uma Ferramenta paraAuxiliar no Desenvolvimento do Tratamento de

Exceções

Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas e Com-putação do Departamento de Informática eMatemática Aplicada da Universidade Fede-ral do Rio Grande do Norte como requisitoparcial para a obtenção do grau de Mestreem Sistemas e Computação.

Linha de pesquisa:Engenharia de Software

Orientadora

Profa. Dra. Roberta de Souza Coelho

Co-orientador

Prof. Dr. Eiji Adachi Medeiros Barbosa

PPgSC – Programa de Pós-Graduação em Sistemas e ComputaçãoDIMAp – Departamento de Informática e Matemática Aplicada

CCET – Centro de Ciências Exatas e da TerraUFRN – Universidade Federal do Rio Grande do Norte

Natal-RN

Fevereiro de 2017

Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial

Especializada do Centro de Ciências Exatas e da Terra – CCET.

Montenegro, Taiza Rabello.

ExceptionPolicyExpert: uma ferramenta para auxiliar no desenvolvimento do

tratamento de exceções / Taiza Rabello Montenegro. – Natal, RN, 2017.

92f. : il.

Orientadora: Profa. Dra. Roberta de Souza Coelho.

Coorientador: Prof. Dr. Eiji Adachi Medeiros Barbosa.

Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte.

Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática

Aplicada. Programa de Pós-Graduação em Sistemas e Computação.

1. Engenharia de software – Dissertação. 2. Tratamento de exceções –

Dissertação. 3. Política de tratamento de exceções – Dissertação. 4. Estudo

exploratório – Dissertação. 5. Plug-in eclipse – Dissertação. I. Coelho, Roberta de

Souza. II. Barbosa, Eiji Adachi Medeiros. III.Título.

RN/UF/BSE-CCET CDU 004.41

Dissertação de Mestrado sob o título ExceptionPolicyExpert: Uma Ferramenta para Auxiliarno Desenvolvimento do Tratamento de Exceções apresentada por Taiza Rabello Montenegroe aceita pelo Programa de Pós-Graduação em Sistemas e Computação do Departamentode Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte,sendo aprovada por todos os membros da banca examinadora abaixo especificada:

Profa. Dra. Roberta de Souza CoelhoPresidente

DIMAp – Departamento de Informática e Matemática AplicadaUFRN – Universidade Federal do Rio Grande do Norte

Prof. Dr. Eiji Adachi Medeiros BarbosaExaminador

Instituto Metrópole DigitalUFRN – Universidade Federal do Rio Grande do Norte

Prof. Dr. Fernando Marques Figueira FilhoExaminador

DIMAp – Departamento de Informática e Matemática AplicadaUFRN – Universidade Federal do Rio Grande do Norte

Prof. Dr. Fernando José Castor de Lima FilhoExaminador

Centro de InformáticaUniversidade Federal de Pernambuco

Natal-RN, 20 de fevereiro de 2017.

Agradecimentos

Agradeço à Universidade Federal do Rio Grande do Norte e a todos que fazem partedela pela oportunidade, mais uma vez, de ter acesso à qualificação gratuita e de qualidade.

Agradeço à Superintêndencia de Informática da UFRN pelo apoio recebido, sejaenquanto servidora, seja enquanto aluna, durante o estudo de caso lá realizado.

Agradeço à professora Roberta pela dedicação, pelo profissionalismo, pelo comprome-timento e pelos conhecimentos passados.

Agradeço ao professor Eiji por todas as muitas e valiosas contribuições a este trabalho.

Agradeço a Hugo Melo pela produtiva parceria, por todas as contribuições dadas etodas as discussões e análise de dados, que só fizeram acrescentar a este trabalho.

Agradeço ao pessoal do LETS (Laboratório de Especificação e Testes de Software). Deforma muito especial a Teresa e Joilson, pelos muitos conhecimentos compartilhados e porestarem sempre disponíveis a colaborar.

Agradeço a todas as pessoas que participaram dos estudos realizados, seja nas entre-vistas, no survey de validação ou na avaliação da ferramenta. Sem vocês este trabalho nãoexistiria.

Agradeço a todos da equipe do SIGRH pela grande colaboração e disponibilidade,principalmente aos que participaram da avaliação.

Agradeço aos meus pais por toda dedicação e amor de sempre e por me orientar aseguir o melhor caminho.

Por fim, agradeço a todos os amigos que me ajudaram com incentivos e apoio.

ExceptionPolicyExpert: Uma Ferramenta paraAuxiliar no Desenvolvimento do Tratamento de

Exceções

Autora: Taiza Rabello MontenegroOrientadora: Profa. Dra. Roberta de Souza Coelho

Co-orientador: Prof. Dr. Eiji Adachi Medeiros Barbosa

Resumo

Na medida em que aumenta a dependência da sociedade com os sistemas de software,aumenta também a demanda pela robustez destes sistemas. O tratamento de exceções éuma das técnicas mais utilizadas para a construção de sistemas de software robustos. Apolítica de tratamento de exceções é o conjunto de regras que define como as exceções devemser manuseadas. Porém, na maioria dos casos, essa política não está definida de formaexplícita, sendo um desafio para o desenvolvedor criar o código de tratamento de exceções.Este trabalho propõe uma ferramenta em formato de plug-in do Eclipse, denominadaExceptionPolicyExpert, que tem o objetivo de orientar o desenvolvedor na implementaçãodesse tipo de código de forma a atender uma política previamente definida. Esta ferramentaanalisa o código fonte e verifica se há alguma violação à política de tratamento de exceções,alertando o desenvolvedor para não conformidade, caso exista. Para auxiliar o levantamentodos requisitos da ferramenta, foi realizado um estudo exploratório com desenvolvedores,utilizando técnicas de Grounded Theory, que buscou entender quais eram os principaisdesafios deles no momento da implementação do código de tratamento de exceções. Oestudo mostrou que a maioria deles não recebem orientações a respeito da política detratamento de exceções e nem tem acesso à política de tratamento de exceções a ser seguida.Consequentemente, muitas vezes lidam com esse código de forma indevida. Dessa forma,foi proposta uma ferramenta que visa trazer informações sobre a política de tratamento deexceções para a IDE, de forma que auxilie o desenvolvedor na implementação do códigoexcepcional sem violar a política. A avaliação da ferramenta mostrou que ela auxilia odesenvolvedor a tomar decisões no momento da implementação do código de tratamentode exceções.

Palavras-chave: Tratamento de exceções; política de tratamento de exceções; estudoexploratório; plug-in Eclipse.

ExceptionPolicyExpert: a tool to assist exceptionhandling development

Author: Taiza Rabello MontenegroSupervisor: Profa. Dra. Roberta de Souza Coelho

Co-supervisor: Prof. Dr. Eiji Adachi Medeiros Barbosa

Abstract

As our society becomes more and more dependent of software systems the demandrobustness requirements increases. The exception handling mechanism is one of the mostused techniques to enable the development of robust software systems develop. Theexception handling policy comprises the set of rules that specify how exceptions should bethrown and handled inside a system. But usually the policy is not explicitly defined. As aconsequence, it becomes a challenge for developers to create the exception handling codeaccording to it. This work proposes an Eclipse plug-in, called ExceptionPolicyExpert, toguide the developer on how to implement this kind of code by checking policy violationsand providing recommendations to developers concerning how to exceptions should behandled and signaled. In order to support the creation of such tool, we performed anexploratory study, using Grounded Theory techniques, to understand which are the mainchallenges that the developers have during the implementation of the exception handlingcode. This study showed that most of the developers did not receive any instructionsregarding the exception handling policy and they often handle exceptions in a wrongway. Therefore, the proposed tool aims to provide information to developer regarding theexception handling policy integrated to the IDE - helping him/her to develop exceptionhandling code and preventing policy violations. The tool evaluation showed that the toolhelps the developer to make decisions when implementing the exception handling code.

Keywords: Exception handling; exception handling policy; exploratory study; Eclipseplug-in.

Lista de figuras

1 Hierarquia de algumas classes Java que representam exceções . . . . . . . p. 20

2 Passos utilizados para a coleta e análise das entrevistas semiestruturadas p. 28

3 Tempo de experiência profissional dos participantes do survey de validação p. 39

4 Resultados do survey de validação para a QP1 . . . . . . . . . . . . . . . p. 40



7 Funcionamento da ferramenta ECL/DAEH. Fonte: (ABRANTES, 2016) . . p. 52

8 Exemplo de contrato especificado na linguagem ECL. Fonte: (ABRANTES,2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53

9 Exemplo da construção cannotHandle . . . . . . . . . . . . . . . . . . . . p. 54

10 Visão geral da ferramenta ExceptionPolicyExpert . . . . . . . . . . . . . p. 54

11 Diagrama de sequência das operações do módulo de verificações . . . . . p. 55

12 Exemplo de política de tratamento de exceções especificada em ECL . . . p. 57

13 Verificação de sinalização indevida . . . . . . . . . . . . . . . . . . . . . . p. 58

14 Verificação de tratamento indevido . . . . . . . . . . . . . . . . . . . . . p. 60

15 Verificação de possíveis tratadores . . . . . . . . . . . . . . . . . . . . . . p. 61

16 Exemplo de escala Likert usada no survey de validação . . . . . . . . . . p. 88

Lista de tabelas

1 Quantificação do código fonte dos SIGS . . . . . . . . . . . . . . . . . . . p. 26

2 Resumo dos participantes do estudo. . . . . . . . . . . . . . . . . . . . . p. 30

3 Distribuição dos sinalizadores e tratadores nos SIGS . . . . . . . . . . . . p. 46

4 Resumo das verificações realizadas pela ExceptionPolicyExpert. . . . . . p. 56

5 Quantidade de warnings exibidos durante a avaliação da ferramenta . . . p. 64

6 Quantidade de sinalizações indevidas encontradas . . . . . . . . . . . . . p. 65

7 Quantidade de tratamentos indevidos encontrados . . . . . . . . . . . . . p. 66

8 Quantidade de possíveis tratadores identificados . . . . . . . . . . . . . . p. 66

Sumário

1 Introdução p. 14

1.1 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14

1.2 Limitações das abordagens atuais . . . . . . . . . . . . . . . . . . . . . . p. 15

1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

1.4 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

1.5 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

2 Fundamentação Teórica p. 18

2.1 Tratamento de exceções . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

2.2 Tratamento de exceções em Java . . . . . . . . . . . . . . . . . . . . . . p. 19

2.3 Grounded Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

2.3.1 Versões da Grounded Theory . . . . . . . . . . . . . . . . . . . . . p. 22

2.3.2 Coleta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

2.3.3 Codificacão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

3 Estudo Exploratório p. 25

3.1 Contexto do estudo exploratório . . . . . . . . . . . . . . . . . . . . . . . p. 25

3.2 Definição das questões de pesquisa . . . . . . . . . . . . . . . . . . . . . p. 26

3.3 Entrevistas semiestruturadas . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

3.3.1 Coleta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28

3.3.2 Perfil dos participantes das entrevistas semiestruturadas . . . . . p. 30

3.3.3 Codificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31

3.3.4 QP1: Na opinião dos desenvolvedores, quais as vantagens e des-vantagens do mecanismo de tratamento de exceções? . . . . . . . p. 32

3.3.5 QP2: Quais são os obstáculos enfrentados pelos programadores nomomento da implementação do código de tratamento de exceções? p. 34

3.3.6 QP3: Quais são as práticas utilizadas pelo desenvolvedor para aimplementação do código de tratamento de exceções na indústriade software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

3.4 Survey de validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38

3.4.1 Vantagens e desvantagens em utilizar mecanismos de tratamentode exceções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39

3.4.2 Obstáculos durante a implementação do código de tratamento deexceções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41

3.4.3 Práticas de desenvolvimento durante a implementação do códigode tratamento de exceções . . . . . . . . . . . . . . . . . . . . . . p. 43

3.5 Análise do código fonte e logs do sistema . . . . . . . . . . . . . . . . . . p. 45

3.5.1 Análise estática do código fonte . . . . . . . . . . . . . . . . . . . p. 45

3.5.2 Inspeção manual do código . . . . . . . . . . . . . . . . . . . . . . p. 47

3.5.3 Análise dos logs de exceções não capturadas . . . . . . . . . . . . p. 47

3.6 Ameaças à validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48

3.7 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49

4 Ferramenta Proposta: ExceptionPolicyExpert p. 51

4.1 Ferramenta ECL/DAEH . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51

4.1.1 Linguagem ECL . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52

4.2 Desenvolvimento da ExceptionPolicyExpert . . . . . . . . . . . . . . . . p. 53

4.3 Visão geral da ExceptionPolicyExpert . . . . . . . . . . . . . . . . . . . . p. 54

4.4 Módulo de verificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55

4.4.1 Exemplo de política de tratamento de exceções especificada em ECL p. 56

4.4.2 Sinalização indevida . . . . . . . . . . . . . . . . . . . . . . . . . p. 57

4.4.3 Tratamento indevido . . . . . . . . . . . . . . . . . . . . . . . . . p. 58

4.4.4 Possíveis tratadores . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59

4.5 Limitação da ferramenta proposta . . . . . . . . . . . . . . . . . . . . . . p. 61


5 Avaliação da Ferramenta ExceptionPolicyExpert p. 63

5.1 Participantes e definição da política . . . . . . . . . . . . . . . . . . . . . p. 63

5.2 Coleta de dados do log . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63

5.2.1 Sinalização Indevida . . . . . . . . . . . . . . . . . . . . . . . . . p. 64

5.2.2 Tratamento Indevido . . . . . . . . . . . . . . . . . . . . . . . . . p. 65

5.2.3 Possíveis tratadores . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66

5.3 Opinião dos usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67


6 Trabalhos relacionados p. 69

6.1 Estudos qualitativos envolvendo desenvolvedores . . . . . . . . . . . . . . p. 69

6.2 Ferramentas para definição e checagem de políticas de tratamento deexceções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 71

6.3 Ferramentas de recomendação . . . . . . . . . . . . . . . . . . . . . . . . p. 73

7 Considerações Finais p. 75

7.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76

Referências p. 78

Apêndice A -- Roteiro base das entrevistas p. 81

Apêndice B -- Códigos mantidos após a codificação seletiva p. 83

Apêndice C -- Survey de validação p. 86

Apêndice D -- Definição da política utilizada na avaliação da ferra-menta p. 89

Apêndice E -- Avaliação da ferramenta ExcpetionPolicyExpert p. 92

14

1 Introdução

Na medida em que aumenta a dependência da sociedade com os sistemas de software,aumenta também a demanda pela robustez destes sistemas. A robustez é um aspectochave da qualidade de software, que, de acordo com o IEEE, indica o grau de corretofuncionamento de um sistema ou componente na presença de entradas inválidas ou condiçõesambientais de estresse (RADATZ; GERACI; KATKI, 1990). O tratamento de exceções é umadas formas mais utilizadas para a construção de sistemas de software robustos (GARCIA

et al., 2001), pois determina como o sistema deve reagir na presença de uma situação defalha.

A política de tratamento de exceções consiste no conjunto das regras de design queespecificam como as exceções devem ser manuseadas e em geral elas são mal definidasou não estão explicitamente documentadas (EBERT; CASTOR, 2013). A forma como osdesenvolvedores lidam com o código de tratamento de exceções e a aderência à políticade tratamento de exceções dos sistemas é um indicativo importante da qualidade finaldo software, pois problemas no código de tratamento de exceções e em sua políticapodem tornar o código, inicialmente projetado para tornar os sistemas mais robustos, umapotencial fonte de falhas. De fato, estudos empíricos realizados ao longo dos últimos anoscoletaram evidências sobre a recorrência de falhas provindas do código de tratamentode exceções (EBERT; CASTOR; SEREBRENIK, 2015) (BARBOSA; GARCIA; BARBOSA, 2014)(COELHO, 2008) (SAWADPONG; ALLEN; WILLIAMS, 2012) (MARINESCU, 2011) (MARINESCU,2013).

1.1 Problema

O estudo de Shah, Gorg e Harrold (2010) mostra que é comum que o programadornegligencie os trechos de código que realizam o tratamento de exceções, assumindo que acorreta implementação será feita em um momento posterior. Todavia, são raros os casosem que os desenvolvedores realizam melhorias nos trechos de código de tratamento de

15

exceções (BARBOSA; GARCIA; MEZINI, 2012).

Além disso, as boas práticas e a política de tratamento de exceções não são deconhecimento geral dos desenvolvedores (LEMOS; ROMANOVSKY, 2001) (KIENZLE, 2008),seja por falta de documentação ou treinamento adequado. Muitas vezes a política detratamento de exceções nem sequer está documentada, sendo definida implicitamente peloarquiteto do software (EBERT; CASTOR; SEREBRENIK, 2015). A falta de atenção ao códigode tratamento de exceções pode comprometer a robustez do sistema, pois o restante docódigo fonte da aplicação pode não estar preparado para lidar com as diversas situaçõesque podem ocorrer, decorrente da falta de alinhamento com a política.

1.2 Limitações das abordagens atuais

Alguns trabalhos propõem a especificação e a verificação de políticas de tratamentode exceções (ABRANTES; COELHO, 2015) (BARBOSA et al., 2016) ou ferramentas de reco-mendação que apoiam a implementação de tratadores de exceção (BARBOSA; GARCIA;

MEZINI, 2012) (RAHMAN; ROY, 2014). Porém, essas ferramentas e abordagens propostasnão auxiliam o programador a manter a aderência à política de tratamento de exceções ounão são integradas ao ambiente de desenvolvimento. Assim, o código de tratamento deexceção vai se mantendo cada vez mais distante da política de tratamento de exceções.

Algumas ferramentas de recomendação foram propostas para apoiar o desenvolvimentodo código de tratamento de exceções (BARBOSA; GARCIA; MEZINI, 2012) (RAHMAN; ROY,2014), porém estas ferramentas não incluem o conceito de política de tratamento, tendocomo foco a recomendação de tipos de tratamento com base nos tratadores já existentes.

Nenhuma das soluções propostas até o momento orienta o desenvolvedor a criar códigoexcepcional em conformidade com a política de tratamento de exceções. Dessa forma, aetapa de implementação não é totalmente beneficiada, podendo levar ao negligenciamentoda política durante o desenvolvimento do código de tratamento de exceções.

Sendo assim, com este trabalho, pretendemos cobrir essa lacuna, através de umaferramenta integrada ao ambiente de trabalho do desenvolvedor, que o auxilie a implementaro código de tratamento de exceções, a partir da definição da política de tratamento. Dadoisso, o principal problema endereçado neste trabalho é a falta de apoio ao desenvolvedor nomomento da implementação do código de tratamento de exceções, de forma que a políticade tratamento de exceções não seja violada.

16

1.3 Objetivos

O objetivo geral deste trabalho consiste em investigar como os desenvolvedores Javalidam com o código de tratamento de exceções e com a política de tratamento de exceções.Para isto, foi realizado um estudo exploratório, em que entrevistas foram aplicadas comdesenvolvedores, seguido de um survey de validação para avaliar se e até que ponto osresultados encontrados se estendem a outros desenvolvedores. Em adição, foi realizadauma análise estática e inspeção manual do código fonte e dos logs de execução do sistema.

A partir dos resultados levantados nesta pesquisa exploratória, este trabalho tem oobjetivo de identificar os requisitos para a implementação de uma ferramenta que auxilieo desenvolvedor a entender e seguir a política de tratamento de exceções da instituição.Diante disso, este trabalho propõe uma ferramenta para auxiliar os desenvolvedores aimplementar esse código de forma que a política previamente definida seja seguida. Aferramenta proposta, chamada ExceptionPolicyExpert, foi construída na forma de um plug-in para a IDE Eclipse.1 Esta ferramenta estende a ferramenta ECL/DAEH apresentadano trabalho de Abrantes (2016) e foi avaliada num ambiente real de desenvolvimento.

Este trabalho está voltado para a linguagem de programação Java, devido ao fato daferramenta proposta ser integrada ao ambiente Eclipse, próprio para aplicações Java. Ainda,estamos considerando o termo “programador” como sinônimo do termo “desenvolvedor”.

1.4 Contribuições

As principais contribuições desse trabalho são:

i. Identificação de práticas comuns adotadas e obstáculos enfrentados por programado-res ao lidarem com a política de tratamento de exceções de seus sistemas;

ii. Identificação de uma abordagem que permite que o desenvolvedor crie códigos maispadronizados e aderentes à política de tratamento de exceções;

iii. Implementação de uma ferramenta que torna as informações sobre a política detratamento de exceções explicita para o usuário no momento do desenvolvimento,auxiliando-o a escrever o código de tratamento de exceções aderente à políticaespecificada;

iv. Avaliação da ferramenta proposta num ambiente de desenvolvimento real.1https://eclipse.org/

17

1.5 Organização do Documento

Este texto possui mais 6 Capítulos, além deste introdutório. O Capítulo 2 apresenta afundamentação teórica com os principais conceitos envolvidos na solução proposta por estetrabalho. O Capítulo 3 trata do estudo exploratório realizado, incluindo seus resultados.Já o Capítulo 4 traz detalhes da ferramenta proposta. O Capítulo 5 aborda a avaliação daferramenta. O Capítulo 6 fala dos trabalhos relacionados e, por fim, o Capítulo 7 traz asconsiderações finais e trabalhos futuros.

18

2 Fundamentação Teórica

Neste Capítulo serão apresentados os principais conceitos envolvidos neste trabalho,com o objetivo de fundamentar o entendimento do mesmo. Inicialmente, será apresentadoo conceito de tratamento de exceções (Seção 2.1), em seguida os conceitos de exceçõesespecíficos para Java (Seção 2.2) e por fim, o método de pesquisa Grounded Theory (GT)(Seção 2.3), o qual fundamentou a realização do estudo exploratório com os programadores.

2.1 Tratamento de exceções

O tratamento de exceções é uma das forma de se implementar tolerância a faltas.Uma falta (do inglês fault), no contexto de software, é um acontecimento que altera ocomportamento considerado normal do sistema. Um exemplo de falta é uma instruçãono código incorreta ou ausente. A ocorrência de uma falta cria um erro latente, que seráobservado apenas se a falta for exercitada. O erro representa um estado do sistema que épassível de resultar numa falha, ou seja, é um estado de instabilidade que se concretiza sea falta for exercitada e irá resultar numa falha. Uma falha (do inglês failure), por sua vez,é caracterizada quando o sistema não entrega um serviço da forma como deveria, ou seja,não está seguindo a especificação da forma correta (LAPRIE, 1985).

Exceções representam condições de erros no software, de forma que ele possa ser tratadoe volte ao seu estado de normalidade. De acordo com Goodenough (1975), tratamento deexceções tem o objetivo de apoiar o desenvolvimento de programas robustos com detecçãoconfiável de erros e rápido tratamento. A separação do código dedicado ao tratamentode erros e do código do fluxo normal da execução dos sistemas, aumenta a robustez emodularidade dos mesmos (GOODENOUGH, 1975).

Um mecanismo de tratamento de exceções é composto por quatro conceitos principais,detalhados a seguir:

1. Exceção: caracteriza um defeito no sistema. Em linguagens orientadas a objetos, é

19

representada através de uma classe;

2. Sinalizador: é o método que identifica o estado anormal do sistema e lança uma novaexceção. Em muitas linguagens, esse elemento é representado através da palavra-chavethrow;

3. Tratador: é o código que captura uma exceção e faz algum tratamento sobre ela. Aresponsabilidade do tratador é de recuperar o sistema do estado anormal em queele se encontra para um estado em que ele possa continuar sua execução normal. Apalavra-chave catch é usada em muitas linguagens de programação para identificar otratador;

4. Modelo de exceção: é a relação entre os sinalizadores e os tratadores. Em muitaslinguagens, uma exceção, após ser sinalizada, é repassada por uma série de invocaçõesdinâmicas até chegar no método que será responsável por seu tratamento.

Nove dentre as dez linguagens mais populares (Java, C++ e C#, por exemplo)implementam mecanismos de tratamento de exceções, comprovando que este mecanismofaz parte dos principais sistemas desenvolvidos na atualidade (JAKOBUS et al., 2015). ASeção seguinte mostra detalhes de como essa técnica é representada na linguagem Java,em específico.

2.2 Tratamento de exceções em Java

A linguagem Java oferece muitas facilidades para o desenvolvimento de aplicaçõesrobustas, sendo que uma delas é a flexibilidade ao se trabalhar com exceções.1 As exceçõesem Java são classificadas em dois tipos: checadas e não checadas. As checadas (do inglêschecked exceptions) são aquelas em que um sistema bem projetado se antecipa para tratar evoltar ao seu estado normal. Já as não checadas (do inglês unchecked exceptions) englobamas runtime exception e os erros, cujas classes são heranças das classes RuntimeExceptione Error, respectivamente. As runtime exception representam estados em que a aplicaçãogeralmente não pode se antecipar ou se recuperar delas. Elas geralmente representam bugscomo falhas na lógica de programação que violam regras semânticas da linguagem (e.g.,acessar um ponteiro nulo) ou uso impróprio da API. Os erros representam problemas sériosque uma aplicação comum não deve tentar capturar por serem, geralmente, associados a

1https://docs.oracle.com/javase/tutorial/essential/exceptions/index.html

20

alguma condição de erro externa à aplicação. As exceções runtime e os erros são chamadasde exceções não checadas.

A Figura 1 mostra a hierarquia de algumas das classes que representam exceções emJava. A classe Throwable engloba todos os erros e exceções e apenas instâncias dessa classe(ou subclasses) podem ser referenciadas nas instruções throw e catch. Suas duas subclasses,Error e Exception, são convencionalmente usadas para indicar que situações excepcionaisocorreram. A classe Error representa os erros que não devem ser capturados no nível deuma aplicação, como por exemplo um erro na máquina virtual Java (VirtualMachineError).Já a classe Exception indica condições de erros que uma aplicação deve capturar para fazeros tratamentos adequados.

Figura 1: Hierarquia de algumas classes Java que representam exceções

Todo código Java, para compilar sem erros, deve cumprir o requisito "Catch or Specify".2

Tal requisitos determina que um trecho de código que deseja lançar uma exceção deve (i)ser envolvido com uma declaração try-catch, que captura e trata essa exceção ou (ii) estarno contexto de um método que indica o lançamento dessa exceção, por meio da cláusulathrows. Todas as exceções checadas, ou seja, todas que não são do tipo ou subtipo da classeError ou RuntimeException, estão sujeitas a esse requisito.

2.3 Grounded Theory

Grounded Theory (GT) é um método de pesquisa qualitativa proposto por Glaser eStrauss (1967), cujo objetivo é gerar uma teoria a partir da análise de situações reais,

2https://docs.oracle.com/javase/tutorial/essential/exceptions/catchOrDeclare.html

21

não sendo recomendada para validar ou testar uma teoria já existente (STOL; RALPH;

FITZGERALD, 2016). Esse método de pesquisa é adequado para ser aplicado em situaçõesonde se deseja entender como determinado processo é executado ou para responderperguntas do tipo "O que está acontecendo aqui?". Como a área de engenharia de softwareé relativamente nova, o método Grounded Theory se adequa bem a essa realidade, jáque existem muitas lacunas de teoria para serem criadas e formalizadas (STOL; RALPH;

FITZGERALD, 2016). Essa tendência pode ser confirmada através do crescente número deutilização de Grounded Theory na última década para a área de Engenharia de Software,como apontado por Stol, Ralph e Fitzgerald (2016).

O método GT consiste de orientações sistemáticas, porém flexíveis, para coleta eanálise de dados qualitativos com o objetivo de construir teorias a partir desses própriosdados (CHARMAZ, 2014). De acordo com Stol, Ralph e Fitzgerald (2016), as principaiscaracterísticas de uma GT são:

∙ Limitação de acesso à literatura: ao iniciar um estudo utilizando esse método, opesquisador deve evitar se expor à literatura já existente sobre o tema de interesse.De acordo com os criadores da GT, essa recomendação serve para que haja umpensamento amplo, sem se deter aos conhecimentos atuais, para evitar análisestendenciosas, como também para evitar que o pesquisador passe a testar teorias jáexistentes e pensar em termos de conceitos estabelecidos;

∙ Tudo é considerado dado: o pesquisador deve considerar todas as fontes de informaçãoque estiver disponível para ele (dados qualitativos, quantitativos, diagramas, vídeos,etc);

∙ Análise contínua e imediata: a análise dos dados inicia o mais breve possível e duraaté mesmo durante etapas posteriores do método;

∙ Amostragem teórica: o pesquisador deve identificar fontes de dados, para explorarconceitos insaturados, ou seja, a coleta e análise de dados devem ser realizados deforma contínua, até que os dados coletados não tragam mais nenhuma informaçãonova;

∙ Sensibilidade teórica: o pesquisador deve ser capaz de conceituar os dados e estabelecerrelações entre os conceitos. Os autores da metodologia destacam que a criatividade éfundamental nesse processo; Codificação: é um processo analítico (MONTONI, 2010),onde os dados são segmentados e rotulados através de uma etiqueta. Ao mesmotempo, são categorizados e resumidos (CHARMAZ, 2014);

22

∙ Anotação: nessa etapa indispensável para o método Grounded Theory, o pesquisadordeve fazer anotações (notas, diagramas, esboços, etc.) descrevendo propriedadesiniciais da teoria, bem como categorias e suas relações, a medida que emergem.As lacunas também devem ser anotadas e relações entre categorias (STOL; RALPH;

FITZGERALD, 2016). De acordo com Charmaz (2014), colocar as ideias no papeltornam o processo mais concreto e gerenciável, além de que durante essa atividade,novas ideias surgem;

∙ Comparação constante: a comparação dos dados, anotações, códigos e categoriasdeve ser iniciada o mais brevemente possível e ser feita de forma contínua, até que ograu de saturação seja alcançado;

∙ Classificação das anotações (ou classificação teórica): é o ato de dispor diversasanotações em uma teoria integrada, pois esta etapa permite que as comparaçõessejam feitas num nível mais abstrato (CHARMAZ, 2014). É um passo fundamentalpara que a teoria seja coesa e não apenas um conjunto de informações soltas. Asanotações são arranjadas por similaridade, conexão e ordenação conceitual (NG;

HASE, 2008);

∙ Teoria coesa: é a criação de uma teoria coesa, a partir de categorias superficiais;

∙ Saturação teórica: a saturação ocorre quando os novos dados não implicam em umarevisão ou reinterpretação da teoria. Quando esse ponto é alcançado, o pesquisadordeve parar de coletar e analisar novos dados.

2.3.1 Versões da Grounded Theory

Atualmente, existem pelo menos três principais linhas de GT: de Glaser, tambémdenominada de GT Clássica; de Strauss e Corbin; e de Charmaz, também chamada de GTConstrutivista.

Em 1967, os pesquisadores Glaser e Strauss, da área de ciências sociais, criaram ométodo Grounded Theory (GLASER et al., 1967) para suprir uma necessidade do momento:gerar, elaborar e validar teorias sobre fenômenos essencialmente sociais, no contexto deum determinado grupo de pessoas ou situações (MONTONI, 2010).

Porém esses autores passaram a divergir sobre alguns pontos e o método passou ater duas linhas principais: a versão de Glaser (denominada de clássica), que enfatiza oprincípio da emergência (a teoria deve emergir dos dados levantados, sem a utilização de

23

conceitos pré-concebidos); e a versão de Strauss, que consolidou sua linha em conjuntocom Corbin, propondo uma sistematização do método de coleta e análise de dados.

Enquanto essas duas linhas estavam consolidadas, a pesquisadora Charmaz considerouque uma nova linha poderia ser criada, gerando o método construtivista (CHARMAZ, 2014).Charmaz enfatiza o papel do pesquisador na construção da teoria. De acordo com ela, dadose teorias não são descobertos, mas sim construídos, a partir das experiências de passado epresente dos pesquisadores e das pessoas envolvidas na pesquisa, bem como das interaçõesentre pessoas, perspectivas e práticas de investigação. Este trabalho utiliza técnicas dalinha Grounded Theory Construtivista como metodologia para análise qualitativa.

2.3.2 Coleta de dados

Uma das etapas fundamentais de uma GT é a etapa de coleta de dados. Glaser (2001)afirma que todas as informações que estão disponíveis no contexto da pesquisa podem serconsideradas como dados relevantes, incluindo observações, diagramas, entrevistas, etc. JáCharmaz (2014) complementa que os dados variam em qualidade, relevância e utilidadepara a pesquisa, além disso, cada pesquisador possui sua própria habilidade em diferenciarquais desses dados são úteis ou não.

2.3.3 Codificacão

A etapa de codificação é uma das que mais caracterizam o método GT. É nela queos dados são analisados, funcionando como uma rotulação de trechos dos dados, quesimultaneamente, categoriza e sumariza cada pedaço dos dados. Codificar é o primeiropasso para se fazer interpretações analíticas, pois a medida que o pesquisador codifica eledeve questionar qual classificação teórica aquela declaração indica (CHARMAZ, 2014).

Uma das características do método Grounded Theory é a análise contínua, permitindoque a a etapa de codificação seja iniciada e prossiga de forma simultânea com a etapa decoleta de dados. Isso pode ser justificado pelo fato de que, na codificação, o pesquisadorinterage diversas vezes com os mesmos dados e os questiona de várias formas, abrindo,assim, oportunidades para enxergar questões ainda nao observadas, podendo criar aténovas questões de pesquisa (CHARMAZ, 2014). Portanto a codificação reflete na coleta dosdados e vice-versa. As atividades seguem em paralelo até que o pesquisador considere quenão há mais questões a serem respondidas.

A teoria construtivista (CHARMAZ, 2014) indica que a fase de codificação possui duas

24

etapas. Na fase inicial o pesquisador observa e nomeia cada trecho do dado (cada palavra,cada linha, ou cada segmento da informação), de forma ampla, para abranger todas aspossibilidades que a informação traz. A fase que segue é mais focada e seletiva, pois opesquisador seleciona os códigos mais significantes e frequentes para ordenar, sintetizar,integrar e organizar um grande conjunto de informação.

25

3 Estudo Exploratório

Este Capítulo apresenta o estudo exploratório realizado, que teve como propósitoentender como os programadores de software profissionais lidam com o tratamento deexceções na prática. Este estudo teve como objetivo inicial identificar o estado da prática dotratamento de exceções no contexto de uma empresa. Com os dados que foram emergindono estudo, um objetivo secundário foi levantado: identificar problemas e dificuldades quepoderiam ser minimizados com suporte ferramental. O estudo foi realizado no contextode um ambiente real de desenvolvimento de software, com a participação voluntária dedesenvolvedores, e foi dividido em duas etapas: entrevistas semiestruturadas, seguido deum survey de validação.

O Capítulo está organizado da seguinte forma: a Seção 3.1 contextualiza o ambienteem que o estudo exploratório foi realizado, a Seção 3.2 enumera as questões de pesquisaque guiaram este estudo. Já a Seção 3.3 e suas subseções trazem detalhes e resultados dasentrevistas semiestruturadas e a Seção 3.4, juntamente com suas subseções, exibem osresultados encontrados na etapa do survey de validação. A Seção 3.5 detalha a análiseestática do código fonte, a Seção 3.6 discute as ameaças à validade do estudo e, por fim, aSeção 3.7 traz as conclusões do estudo exploratório.

3.1 Contexto do estudo exploratório

O estudo exploratório foi realizado no contexto da Superintendência de Informáticada Universidade Federal do Rio Grande do Norte (SINFO/UFRN), setor responsável pelaárea de Tecnologia da Informação da instituição. Existem em torno de 40 desenvolvedoresalocados na SINFO trabalhando no desenvolvimento dos Sistemas Integrados de Gestão(SIGs), que são responsáveis pela automação dos processos de negócio da universidade.1

Esses sistemas são compostos por basicamente três subsistemas - SIGAA, SIPAC eSIGRH, responsáveis pela automação dos processos acadêmicos, processos administrativos

1http://www.info.ufrn.br

26

e processos de recursos humanos, respectivamente. Além disso, os três subsistemas utilizamos serviços disponibilizados por um sistema compartilhado, nesse texto denominada deCamada Núcleo, que é responsável pela automação de processos utilizados por todos ossistemas, como por exemplo log, controle de transação e controle de permissão. A CamadaNúcleo, que é mantida pela equipe de arquitetura da SINFO, também é responsável portratar as exceções que são lançadas nos subsistemas mas não são capturadas por eles.

Os Sistemas Integrados de Gestão são utilizados pela UFRN e também por mais de 40instituições em todo Brasil, através de projetos de cooperação técnica. Para ilustrar ossistemas em termos de tamanho de código, a Tabela 1 sumariza as informações quantita-tivas do código fonte dos sistemas. Para o número de linhas de código (KLOC), se estáconsiderando apenas linhas lógicas, ou seja, ignorando linhas em branco, comentários, etc.,em unidade de milhar.

Tabela 1: Quantificação do código fonte dos SIGS

Sistema KLOC #classes Java #catch #throwCamada Nú-cleo

58 955 705 388

SIGAA 717 6554 6080 3592SIPAC 855 5332 6533 5184SIGRH 442 6458 2940 1928

A Tabela 1 mostra que os Sistemas Integrados de Gestão são grandes sistemas emtermos de tamanho de código. Eles possuem um número considerável de elementos detratamento de exceções (blocos catch e throw), dessa forma os desenvolvedores destessistemas estão expostos a diversos e, possivelmente, não triviais cenários em que exceçõessão usadas.

3.2 Definição das questões de pesquisa

Essa Seção apresenta as questões de pesquisa que guiaram este estudo exploratório.As questões, listadas abaixo, serviram como guia de execução das entrevistas, bem comoreferência para a fase de análise de dados e para a definição do survey de validação.

27

∙ QP1: Na opinião dos desenvolvedores, quais as vantagens e desvantagens do meca-nismo de tratamento de exceções?

∙ QP2: Quais são os obstáculos enfrentados pelos programadores no momento daimplementação do código de tratamento de exceções?

∙ QP3: Quais são as práticas utilizadas pelo desenvolvedor para a implementação docódigo de tratamento de exceções na indústria de software?

A primeira questão de pesquisa procura identificar quais são as vantagens e as desvan-tagens que o desenvolvedor considera ao utilizar o mecanismo de tratamento de exceçõesdisponibilizado pela linguagem de programação. A segunda questão tem objetivo de iden-tificar quais são as principais dificuldades que o programador tem ao implementar códigode tratamento de exceções. E a terceira questão procura levantar quais são as práticasmais utilizadas pelos desenvolvedores, no que diz respeito a tratamento de exceções.

3.3 Entrevistas semiestruturadas

A primeira etapa do estudo exploratório foi a realização de entrevistas com desen-volvedores de software. De forma geral, esta etapa foi composto pelas fases de coletade dados, análise dos dados e interpretação dos resultados. Durante a análise dos dadoscoletados, foram utilizadas as técnicas codificações inicial e seletiva, bem como a utilizaçãodo conceito de saturação, do método Grounded Theory.

A Figura 2 mostra os detalhes da metodologia utilizada para a condução das entrevistassemiestruturadas. O primeiro passo foi a definição das questões de pesquisa, seguida dacoleta de dados. A partir do momento que os primeiros dados foram coletados, foi iniciada afase de codificação dos mesmos, através das duas etapas indicadas pela teoria construtivista:codificação inicial e seletiva (CHARMAZ, 2014). Os dados continuaram a ser coletados e emseguida codificados até que o ponto de saturação foi encontrado. Nesse momento, os códigosforam compilados para se obter os resultados da fase de entrevistas semiestruturadas.

As Subseções seguintes detalham a coleta de dados (Subseção 3.3.1), o perfil dosparticipantes (Seção 3.3.2), a codificação dos dados (Subseção 3.3.3) e, por fim, as Sub-seções 3.3.4 , 3.3.5 e 3.3.6 exibem os resultados encontrados na etapa das entrevistassemiestruturadas.

28

Figura 2: Passos utilizados para a coleta e análise das entrevistas semiestruturadas

3.3.1 Coleta de dados

A principal fonte de informação utilizada na coleta de dados foram as entrevistas em si.Porém, diante da necessidade de contextualizar melhor os pesquisadores nos sistemas SIGsdesenvolvidos pelos participantes das entrevistas, fez-se necessária a coleta de outros dados.Essas fontes de dados complementares permitiram uma melhor preparação e compreensãodos pesquisadores para a análise das informações oriundas das entrevistas. Dessa forma,as seguintes fontes de informações foram utilizadas nesta etapa pesquisa: (i) código fonte,(ii) documentação do sistema, (iii) e entrevistas semiestruturadas. Elas foram coletadasde forma simultânea, sem uma ordem estipulada, de acordo com a necessidade observadapelos pesquisadores.

Para minimizar problemas de viés na coleta de dados, ela foi toda feita em conjunto comoutro pesquisador da área de tratamento de exceções. Todas as informações coletadas foramdiscutidas em par, para que o conhecimento prévio de um dos pesquisadores interferisse omínimo possível na interpretação dos fatos.

Em relação ao código fonte, foram analisados algumas classes que continham palavras-chaves associadas ao tratamento de exceções (try, catch, throw), para observação da

29

maneira como a sinalização e tratamento de exceções são feitos. Além disso, também foramanalisadas as classes responsáveis por fazer o tratamento de exceções na Camada Núcleo,a partir das informações dadas pelo responsável pela equipe de arquitetura de software daSINFO. A Camada Núcleo contém algumas classes responsáveis pelo tratamento genérico deexceções, ou seja, classes que tratam as exceções que foram lançadas pelos subsistemas masnão foram tratadas por nenhuma classe desse próprio sistema. Essas exceções percorremum fluxo e chegam até o tratador genérico implementado pela Camada Núcleo. Como osSIGs não documentam explicitamente uma política formal de tratamento de exceções, aanálise do código fonte é bastante relevante, pois a política está dispersa e implícita aolongo do código.

Além disso, a documentação de desenvolvimento do sistema também é outra fontede informação importante, pois ela orienta os desenvolvedores e determina um padrãode implementação. A documentação oficial do sistema utilizado no estudo de caso, queconsiste em páginas wiki com orientações ao desenvolvedor, foi analisada com foco notratamento de exceções. Foi encontrada uma página que continha uma seção específicasobre tratamento de exceções. Porém essa seção apenas mostra um diagrama de classescom uma parte da hierarquia dos sistemas, citando superficialmente em que situações elasdevem ser usadas e também faz uma recomendação aos desenvolvedores para que exceçõesnão sejam silenciadas.

Por fim, a principal fonte de dados utilizada foram as entrevistas semiestruturadas.Goulding (1999) afirma que as entrevistas devem ser conduzidas de forma que haja um meiotermo entre o rigor e a maleabilidade. Entrevistas muito estruturadas, com um planejamentorigoroso de questões, tira o foco do método Grounded Theory, pois não deixa o entrevistadolivre para mostrar o seu ponto de vista, além de correr o risco de se tornar meramenteuma extensão da perspectiva do pesquisador. Porém entrevistas sem estruturação causamconfusão no entrevistado, incoerência de respostas e resultados insignificantes. Dessa forma,a metodologia deste trabalho usou entrevistas semiestruturadas, onde um conjunto dequestões-chaves abertas foram definidas inicialmente. Porém ao longo de cada entrevista,outras questões puderam ser levantadas, bem como outras foram consideradas irrelevantes,a depender das informações que o entrevistado trazia. Além disso, a cada nova entrevista,um novo roteiro era planejado, considerando as palavras-chaves iniciais, mas também ocontexto da entrevista, incluindo a experiência do entrevistado, dúvidas que surgiramem entrevistas anteriores, etc. Dessa forma, foi possível ter a flexibilidade para mudar oroteiro de cada entrevista, mas todas as entrevistas seguiram uma mesma base, assim,pode-se extrair da melhor maneira o que cada participante poderia colaborar. O Apêndice

30

A traz o roteiro base utilizado para as entrevistas, que foi sendo adaptado de acordo como respondente.

3.3.2 Perfil dos participantes das entrevistas semiestruturadas

Todos os participantes das entrevistas semiestruturadas são desenvolvedores de softwareprofissionais que fazem (ou fizeram - pois um dos participantes havia saído da instituiçãohá algumas semanas) parte da equipe técnica dos SIGs.

Eles foram selecionados por conveniência e tiveram live arbítrio para aceitar a par-ticipação - voluntária - na pesquisa, bem como cancelar a sua participação a qualquermomento. Dez profissionais, de diferentes perfis, foram selecionados, porém 8 aceitaramparticipar do estudo. O perfil do participante foi traçado a partir do seu tempo de experi-ência profissional e do papel que exerce na instituição. A maioria dos participantes sãoprogramadores, mas dois deles estavam alocados na equipe de arquitetura da instituição.Esta equipe é responsável por prover soluções e resolver problemas que se aplicam a váriossistemas desenvolvidos pela instituição, incluindo a Camada Núcleo, que provê uma soluçãogenérica para o tratamento de exceções, a ser utilizado pelos sistemas.

As entrevistas, sigilosas, tiveram seu áudio gravado - após autorização dos participantes- para facilitar a transcrição e análise dos dados. Segundo Charmaz (2014), essa é umaprática recomendada para que o entrevistador possa dar total atenção ao participante,focando no contato visual com o mesmo, sem se distrair para fazer anotações.

Tabela 2: Resumo dos participantes do estudo.

Identificador Tempo de experiência PapelP1 6 anos ProgramadorP2 5 anos ProgramadorP3 9 anos ProgramadorP4 7 anos ArquitetoP5 6 meses ProgramadorP6 1 ano e 3 meses ProgramadorP7 12 anos ProgramadorP8 7 anos Arquiteto

31

Sobre o perfil dos entrevistados, 25% trabalha ou trabalhou na equipe de arquiteturade software da instituição e o restante (75%) estão alocados em equipes de desenvolvimentode um dos subsistemas (SIGAA, SIPAC ou SIGRH). Como a equipe de arquitetura provêuma solução para o tratamento de exceções do sistema, é esperado que seus integrantestenham uma visão mais abrangente dos conceitos e uso de exceções.

O tempo de experiência profissional dos entrevistados varia de 6 meses a 12 anos, commédia de 5.98 anos e mediana de 6.5. A Tabela 2 lista os entrevistados e suas respectivasinformações.

3.3.3 Codificação

Nesta etapa do estudo exploratório, duas fases de codificação foram aplicadas, comomostra a Figura 2. Na primeira fase de codificação, em torno de 150 códigos foramlevantados, a partir dos dados obtidos nas entrevistas e nas outras fontes de dados. Na fasede codificação seletiva, em torno de 50 códigos foram mantidos, do total de 150. A coletae análise de dados foi realizada até o alcance do ponto de saturação, ou seja, o momentoem que os dados de entrada não estavam mais trazendo informações relevantes.

A codificação seletiva foi realizada com base nas questões de pesquisa. Apenas os códigosque traziam algum tipo de resposta para as questões foram mantidos. Cada código foiassociado a uma das palavras-chave - “Obstáculos”, “Prática” ou“Vantagens/Desvantagens”- referente à questão de pesquisa que ele está associado. Além disso, os códigos tambémforam agrupados por categoria, de forma que na análise dos dados, os códigos similarespuderam estar próximos. O Apêndice B lista os códigos que foram mantidos após acodificação seletiva, agrupados por suas respectivas palavras-chaves e categorias.

Para evitar viés na codificação, a cada entrevista realizada, os códigos foram gerados ediscutidos com outro pesquisador da área de tratamento de exceções presente na entrevista.Para gerenciar a quantidade de informação, a ferramenta de mapa mental XMind foiutilizada.2

As próximas Subseções trazem os principais resultados encontrados durante a análisedos códigos, referentes a cada questão de pesquisa. Para ilustrar os resultados, citações dasentrevistas serão fornecidas, acompanhadas do identificador de cada participante (P#).

2http://www.xmind.net/

32

3.3.4 QP1: Na opinião dos desenvolvedores, quais as vantagense desvantagens do mecanismo de tratamento de exceções?

O objetivo dessa questão é entender como os desenvolvedores consideram que aimplementação do tratamento de exceções influencia em seu trabalho, seja positiva ounegativamente. Os principais pontos positivos levantados pelos participantes foram arelação do tratamento de exceções com a robustez do sistema e a melhoria na usabilidadedo usuário. Como pontos negativos, estão o custo de implementação e de manutenção.

∙ Robustez: vários participantes relacionaram o uso de tratamento de exceções como aumento de robustez do sistema e, consequentemente, com a qualidade final domesmo. Os participantes P5 e P7 focaram na importância da recuperação automáticado sistema, enquanto que P4 destacou a importância da robustez para o usuário.Isso mostra que os participantes compreendem a relação do tratamento de exceçõescom a robustez.

“O mais importante quando você vai tratar uma exceção é não deixar ousuário na mão. O sistema deve ser inteligente o suficiente para voltar parauma tela em que o usuário possa continuar usando o mesmo.” [P5]

“Acredito que as exceções são importantes por possibilitar a recuperação dosistema que se encontra numa situação não esperada, para que ele possa voltarao seu estado normal automaticamente.” [P7]

“O mecanismo de exceção é usado para garantir que caso algo não previstono seu código aconteça, você tem como dar um comportamento padrão paraaquilo ali.” [P4]

∙ Estruturação do código: Vários participantes comentaram que o uso dos meca-nismos de tratamento de exceções tem impacto diretamente no código fonte. P5considera que o impacto é positivo, pois organiza melhor o código, devido a separaçãode funcionalidades. Em relação a exceções checadas, P7 considera que o uso dessetipo de exceção serve como documentação do sistema e vários consideram que dácontrole ao desenvolvedor.

“Deixa o código mais organizado, mais estruturado, até para manutenção.Outro desenvolvedor, novo ou antigo, pode ver o código e já sabe o que esperar.”[P5]

33

“Eu acho que se você já tem na assinatura [do método] o que é que podeacontecer de inesperado, então é positivo. Porque você está passando maisinformação, até mesmo para os usuários, pensando em termo de interface.Então, é algo que já é documentado na própria linguagem.” [P7]

Porém nem todos veem de forma positiva. O mesmo P7 que viu vantagens no usode exceções, diz que também tem a desvantagem de poluir um pouco o código, mas“nada significativo, podendo ser considerado um mal necessário”. Já o participante P4critica o uso indiscriminado de exceções checadas, pois elas aumentam a dificuldade demanutenção do código e deixam o código verboso, devendo ser usadas apenas quandorealmente necessárias.

“Vamos supor uma cadeia de chamadas de método que possui cinco níveis.Se você usar uma exceção checada o primeiro nível, que só será tratada nonível mais alto, precisará alterar o código em cinco pontos diferentes, de formadesnecessária. Acaba sendo difícil de manter e uma coisa verbosa.” [P4]

∙ Custo de desenvolvimento: Alguns participantes comentaram que implementarcódigo de tratamento de exceções traz um custo a mais para a etapa de implementação,porém eles consideram que esse custo é irrisório em comparação às vantagensadquiridas. Grande parte dos participantes afirmaram que usar o tratamento deexceções ajuda o trabalho do desenvolvedor. Os participantes P1 e P3 reforçam queo desenvolvedor é mais beneficiado se a Camada Núcleo for responsável por grandeparte da política de tratamento, pois fica menos custoso para o desenvolvedor. Deforma geral, os participantes reconhecem a necessidade de implementar código detratamento de exceções, mas demonstram não querer gastar muito esforço com essatarefa.

“O tratamento de exceções me ajuda muito, como desenvolvedor. Só pelofato de saber o que tá acontecendo numa determinada situação de erro, ou aomenos ter um norte para saber o que aconteceu.” [P5]

“Se não fosse o tratamento de exceções, o programador teria grandes pro-blemas. Mas se a arquitetura [Camada Núcleo] for responsável por cuidar degrande parte das situações excepcionais, não tem muito impacto no o dia adia programador. Ele só irá precisar analisar algum caso específico, de formaesporádica.” [P1]

34

“Nós usamos muito os mecanismos de tratamento de exceções. Existe umcusto para a gente detectar que precisa de algum tratamento específico, mas éirrelevante. Porém se não for uma coisa bem estruturada e abstraída para odesenvolvedor, a produtividade cai muito.” [P3]

∙ Preocupação com o usuário: A maioria dos participantes considera que o trata-mento de exceções traz vantagens para o usuário, pois o auxilia nas situações deerros e permitindo que ele continue a usar o sistema. Além disso, P3 afirmou queoutra vantagem é descobrir e corrigir erros, através dos logs, antes mesmo do usuárioreportar o mesmo. Dessa forma, o usuário, ao tentar a mesma operação um tempodepois, irá conseguir realizar com sucesso.

“A gente dispara a exceção de negócio e já faz o tratamento na camadasuperior para exibir melhor para o usuário. Outra vantagem é, antes mesmo dousuário reportar o bug, descobrir que ocorreu um erro no sistema e a gente podercorrigir isso, pois somos notificados por e-mail sobre os erros que ocorrem.”[P3]

“Uma das principais vantagens, que eu vejo, é a prevenção de erros, prin-cipalmente na frente do usuário.” [P6]

“O tratamento da exceção deve colocar alguma mensagem coerente prousuário. Seja direcionando para uma tela onde ele possa continuar, seja direci-onando para uma tela onde ele possa entrar em contato com a administraçãodo sistema ou com o suporte e, enfim, reportar aquele problema de maneiramais adequada.” [P7]

3.3.5 QP2: Quais são os obstáculos enfrentados pelos programa-dores no momento da implementação do código de trata-mento de exceções?

Essa questão tem o objetivo de fazer o levantamento das principais dificuldades que osprogramadores tem ao lidar com a implementação do código de tratamento de exceções. Agrande maioria dos participantes relatam que a falta de treinamento é um dos principaisobstáculos, agravado pela falta de documentação. Os desenvolvedores também se queixaramda pouca evolução da política de tratamento de exceções e da falta de comunicação entreas equipes de desenvolvimento e de arquitetura.

35

∙ Falta de treinamento: No que se refere a treinamento acadêmico, apenas umparticipante relata ter tido aula na graduação a respeito do tema tratamento deexceções. Todos os outros afirmaram que aprenderam na prática, quanto entraramno mercado de trabalho, muitas vezes observando o código dos colegas. Isso foirefletido no estudo, pois alguns participantes demonstraram não ter muito domínionos conceitos envolvidos com exceção.

“Eu não tive nenhuma disciplina específica de desenvolvimento de software,de tratamento de exceções. A gente vai aprendendo mesmo com a prática, coma experiência, com o que a gente lê, no dia a dia.” [P7]

“Não existe nenhum treinamento para a gente... Quem entra aqui [naempresa] vai descobrindo aos poucos.” [P3]

“Existe uma prática de observar o que o código dos seus colegas faz.” [P4]

“Quando que eu preciso capturar uma exceção, eu me baseio no [código]dos outros. Observo como eles lançaram e procuro fazer similar, para não ficartão diferente do que o pessoal está acostumado a fazer.” [P5]

∙ Falta de documentação: O participante P8 afirmou que, além da falta de trei-namento, também há o problema da falta de documentação, com instruções aodesenvolvedor. Isso já havia sido percebido na fase de coleta de dados, pois foi verifi-cado que documentação oficial era muito superficial, com instruções muito básicas emrelação ao tratamento de exceções. Esse item explicitou que os desenvolvedores nemsequer sabem se existe uma documentação da política de tratamento de exceções e, seexistir, não tem acesso fácil a ela. Dessa forma, o código de tratamento é construídode forma não padronizada.

“Deveria haver um documento, explicando quais as políticas que os desen-volvedores devem adotar, como eles devem fazer, o que deve ser feito casoaconteça uma exceção.” [P8]

∙ Falta de evolução da política de tratamento de exceções: Alguns participan-tes consideram que é necessário que ocorra uma atualização da política de tratamentode exceções, pois o sistema foi sendo alterado constantemente nos últimos anos, mas

36

a política ou a implementação do tratamento de exceções na Camada Núcleo quasenão foi alterada ao longo dos anos. Essa falta de sintonia entre a alta velocidade decriação de código fonte para atender novas demandas do sistema e a baixa frequênciade atualização do mecanismo genérico de tratamento de exceção, dificulta aindamais a utilização de boas práticas por parte do desenvolvedor.

“É muito raro ocorrer uma alteração no mecanismo de tratamento deexceções da arquitetura [Camada Núcleo].” [P4]

“A iniciativa em se aprimorar o tratamento é de extrema importância. Agente quer continuar usando as coisas da mesma forma que a gente fazia havários anos ou a gente vai evoluir e passar a tratar de maneira mais adequada.”[P7]

3.3.6 QP3: Quais são as práticas utilizadas pelo desenvolvedorpara a implementação do código de tratamento de exce-ções na indústria de software?

O objetivo dessa questão é levantar as principais práticas que os programadorespossuem ao implementar o código de tratamento de exceções.

Mesmo sem ter treinamento - seja acadêmico ou profissional -, como mostrado naSeção anterior, a maioria dos entrevistados consideram que utilizam esse tipo de códigocom frequência. Alguns deles afirmam que só costumam lançar nova exceção (ou seja,instanciar um novo objeto representando uma exceção) quando precisam validar regra denegócio.

“Toda vez que [o desenvolvedor] for programar, tem que se preocupar com otratamento de exceções em si, porque em geral as classes lançam exceções.” [P4]

“Diariamente eu estou lidando com esse tipo de código. Porque eu acho queé uma preocupação que a gente deve ter, principalmente nas operações críticasou em situações que a gente imagina que possa ter algum comportamentodiferente do esperado.” [P7]

“É bastante comum lançar nova exceção para validação de [regra de] negócio.”[P3]

37

Em relação às práticas, alguns deles relataram costumes relacionadas ao negligencia-mento - como uma abordagem reativa -, citaram que muitas vezes realiza o remapeamentode exceções e delegam o tratamento de exceções para a Camada Núcleo com frequência.

∙ Delegar tratamento para a Camada Núcleo: Alguns participantes relataramque tem o costume de apenas relançar as exceções para que a Camada Núcleo dosistema dê o devido tratamento a elas, ignorando a boa prática de tratar assim quepossível (WIRFS-BROCK, 2006). Isso pode ser um reflexo da má utilização de exceçõeschecadas, ou seja, essas exceções que os desenvolvedores apenas repassam para acamada superior provavelmente poderiam ser do tipo unchecked.

“Praticamente todo dia eu me deparo com código de tratamento de exceções,mas geralmente eu relanço para a arquitetura [Camada Núcleo] tratar.” [P1]

“Na maioria dos casos a gente deixa para que a arquitetura [CamadaNúcleo] trate, pois ela possui um ponto central de tratamento, que notifica osadministradores e realiza o log do erro.” [P7]

∙ Negligenciamento: Em alguns momentos os participantes citaram práticas quepodem ser consideradas como negligenciamento do tratamento de exceções. É umaconsequência da prática citada anteriormente, de demandar a complexidade dotratamento de exceções para a Camada Núcleo. Dessa forma, muitos deles só sepreocupam com o “caminho feliz” do caso de uso que está implementando, isto é, coma execução normal do caso de uso. Um dos participantes justifica que os prazos sãosempre apertados, não permitindo que o desenvolvedor demore muito para finalizarsua tarefa. Esse item reforça os resultados encontrados no trabalho relacionado deShah et al. (2008), que conclui que os desenvolvedores não implementam o código deexceções de forma cuidadosa por não priorizarem essa atividade.

“Eu não me preocupo com o tratamento de exceções, apenas jogo para aCamada Núcleo tratar. Creio que seja até um ponto falho.” [P1]

“A gente acaba se preocupando em entregar o produto e só pensa no caminhofeliz. Se der algum problema a gente registra aqui e vê o que faz depois.” [P7]

“Na academia é tudo muito bonito, mas na prática é outra realidade. Étudo para ontem, querem ver resultado.” [P8]

38

∙ Remapeamento: Alguns participantes citaram que tem o costume de remapear osobjetos que representam exceção para outros tipos, de forma que cada camada dosistema lide apenas com um subconjunto de tipos.

“Existem várias exceções que poderiam ocorrer ali, mas eu trato todas comoum conjunto de exceções da mesma camada, através do remapeamento.” [P7]

∙ Exceções vindas de serviços externos: Apenas um dos entrevistados cita que sepreocupa em prevenir a aplicação de erros vindos de bibliotecas externas ou serviços.Os outros comentaram que, em geral, não se preocupam com isso.

“[Ao usar serviços de outros sistemas] a gente não tem a preocupação dever quais exceções ele vai estourar. A gente faz a chamada e se há a necessidadede tratar exceção, adiciona o throws.” [P7]

“Dificilmente preciso consultar serviços de terceiros. Mas quanto utilizo,descubro as exceções na tentativa e erro, de forma geral. Não leio a documen-tação pra descobrir o que aquele serviço pode retornar de erro, pra tratar deantemão.” [P3]

“Eu já cheguei a olhar a documentação de serviços externos para ver aspossíveis exceções. Em outros casos, não precisei olhar porque elas eram todaschecadas. (...) Mas ao lidar com serviços externos, o tratamento de exceções émais importante ainda. Porque se você não fizer o tratamento pode ser que tireo seu sistema do ar.” [P4]

3.4 Survey de validação

Após a etapa de condução e análise das entrevistas semiestruturadas, foi realizado umsurvey de validação para avaliar se e até que ponto os resultados observados durante asentrevistas se estendem aos outros desenvolvedores da mesma instituição.

Para isso, os principais resultados encontrados durante as entrevistas semiestruturadasforam compilados e incluídos no survey de validação, formando um questionário que foidisponibilizado durante 1 semana na plataforma Google Forms. Este questionário, queestá reproduzido no Apêndice C, consiste de afirmações que o respondente deve indicar,

39

Figura 3: Tempo de experiência profissional dos participantes do survey de validação

para cada uma delas, seu grau de concordância a partir de uma escala Likert de 5 níveis(variando de “Discordo fortemente” até “Concordo fortemente”). Nenhuma pergunta eraobrigatória, porém o questionário obteve uma taxa de resposta de 99,54%.

Diferentemente da etapa de entrevistas, em que alguns desenvolvedores foram selecio-nados para participar, o survey de validação foi enviado para todos os desenvolvedores dainstituição, em torno de 40. Ao todo, 19 desenvolvedores responderam voluntariamenteao survey (taxa de resposta de 49%). Dentre os respondentes, 57,9% indicaram estarinteressados no estudo e disponibilizaram seus e-mails para receber os resultados do mesmo.A Figura 3 detalha o nível de experiência profissional dos respondentes. Assim comonas entrevistas, os participantes são, em sua maioria, profissionais com vários anos deexperiência com desenvolvimento de software.

As subseções a seguir detalham os resultados encontrados no survey de validação,agrupados pelos temas das questões de pesquisa.

3.4.1 Vantagens e desvantagens em utilizar mecanismos de tra-tamento de exceções

Os respondentes foram questionados sobre as vantagens e desvantagens do uso dosmecanismos de tratamento de exceções. A Figura 4 apresenta as afirmações e as respostassobre este tema. De forma geral, os desenvolvedores concordam que esses mecanismos sãoum aspecto positivo do desenvolvimento de software.

1. 85% dos respondentes concordam ou concordam fortemente que o mecanismo detratamento de exceções é uma ferramenta útil para correção de bugs.

40

Figura 4: Resultados do survey de validação para a QP1

2. 63% dos respondentes concordam ou concordam fortemente que o tratamento deexceções está diretamente relacionado com a robustez do software.

3. 64% dos respondentes discordam ou discordam fortemente que o código de tratamentode exceções é de difícil manutenção.

4. 74% dos respondentes discordam ou discordam fortemente que a implementaçãodesse tipo de código é uma tarefa cara, em termos de tempo.

Esses resultados revelam que os desenvolvedores reconhecem a importância do me-canismo de tratamento de exceções. A maioria deles (85%) usa esse mecanismo comoferramenta de debug, auxiliando a correção de bugs - esse resultado está alinhado com oestudo de Shah, Gorg e Harrold (SHAH; GÖRG; HARROLD, 2008b), que encontrou que osdesenvolvedores costumam usar a informação contida nas exceções para rastrear a origemdo erro. Ainda, a maioria dos desenvolvedores confia no mecanismo de tratamento deexceção para prover robustez ao software.

Em adição, os desenvolvedores pensam que o código de tratamento de exceções é de fácilmanutenção e seu desenvolvimento não é uma tarefa que consome muito tempo. Na etapadas entrevistas, foi percebido que os desenvolvedores não apresentaram ter dificuldade emlidar com o código de tratamento de exceções no sistema que eles trabalham. O resultadoobservado no survey está alinhado com essa impressão obtida nas entrevistas, dando aentender que o código de tratamento de exceções demanda algum tempo do desenvolvedoraté que a política de tratamento de exceções seja aprendida por ele. Apesar disso fica oquestionamento se eles de fato tem total domínio do código ou se ele tendem a focar nocódigo do “caminho feliz”, negligenciando o código de tratamento de exceções, ou aindase esse código é simples o suficiente e recebe poucas manutenções a ponto de não ser

41

uma tarefa custosa de fato. Esse questionamento é reforçado com a análise das respostasreferentes aos obstáculos, mostrados na Seção 3.4.2

3.4.2 Obstáculos durante a implementação do código de trata-mento de exceções

O survey de validação incluiu sete afirmações relativas às dificuldades que os desenvol-vedores demonstraram ter durante as entrevistas. A Figura 5 mostra as afirmações e asrespostas sobre este tema, destacando que a falta de treinamento e documentação são umdos maiores obstáculos.


5. 58% dos respondentes concordam ou concordam fortemente que eles conhecem boase más práticas para implementação do código de tratamento de exceções.

6. 69% dos respondentes concordam ou concordam fortemente que eles reconhecem esabem usar as exceções do sistema.

7. 69% dos respondentes discordam ou discordam fortemente que receberam treinamentoadequado na empresa.

8. 69% dos respondentes discordam ou discordam fortemente que a documentação dosistema auxilia o desenvolvimento do código de tratamento de exceções.

9. 47% dos respondentes discordam ou discordam fortemente que se baseiam no códigojá existente quando está desenvolvendo o código de tratamento de exceções.

42

10. 58% dos respondentes concordam ou concordam fortemente que existe uma formapadrão de lidar com as exceções no sistema que eles desenvolvem.

11. 61% dos respondentes discordam ou discordam fortemente que essa forma padrão foiatualizada recentemente.

A maioria dos respondentes afirmam que a empresa não ofereceu um treinamentoadequado para lidar com as exceções do sistema e também discordam que a documentaçãoos auxilia nesta tarefa. Apesar disso, os desenvolvedores afirmam conhecer as boas emás práticas para implementação do código de tratamento de exceções. Ainda, a maioriaafirma que conhece e sabe lidar com a maioria das exceções existentes no sistema quedesenvolve. Esses resultados formam uma possível contradição pois os desenvolvedoresnão recebem o suporte necessário para realizar suas atividades adequadamente - por faltade treinamento e documentação-, mas ao mesmo tempo não possuem dificuldades, poisconhecem as boas práticas e sabem usar as exceções adequadamente. Em complemento,durante o estudo exploratório, foi percebido que não existe uma documentação oficialexplicitando a política de tratamento de exceções e isso deve justificar o fato de 69%dos respondentes discordaram que a documentação os auxilia - talvez grande parte delesconsidere que não existe documentação.

Com esses resultados encontrados, fica o questionamento de como os desenvolvedoresaprendem a lidar com o código de tratamento de exceções, já que eles não possuem treina-mento e documentação para se apoiarem, aliado a falta de treinamento teórico (mostradonos resultados do estudo exploratório). Uma possível resposta é que os desenvolvedoresaprendem na prática, ou seja, observando o código já existente, feito por colegas, comomencionado por alguns nas entrevistas e reforçado no estudo feito Shah, Gorg e Harrold(2010), que reportou que essa é uma prática comum. Porém, quando questionados sobre issono survey de validação, 47% dos respondentes discordam da afirmação. Essa contradiçãopode ser justificada pelo perfil dos respondentes, onde a maioria tem mais de 4 anos deexperiência. Talvez em algum momento de sua experiência profissional o desenvolvedorprecisou aprender com o código de sistemas existentes, mas hoje em dia a forma de lidarcom o tratamento de exceções se tornou um conhecimento implícito. Isso pode ser reforçadocom a afirmação a respeito da existência de uma forma padrão de lidar com exceçõesno sistema, ou seja, quando lançar e capturar exceções. Para esta afirmação, 58% dosrespondentes concordam que existe uma forma padrão de lidar com exceções, apesar dessepadrão não estar documentado formalmente. Então pode-se chegar a conclusão de queexiste uma forma padrão, ou seja um política de tratamento de exceções, mas que não está

43

explicitada por uma documentação, sendo um conhecimento intrínseco dos desenvolvedoresexperientes. Ainda sobre essa forma padrão, 61% dos desenvolveres concordam que elanão foi atualizada recentemente, confirmando o que foi encontrado nas entrevistas. Issopode mostrar que a forma padrão de lidar com exceções foi estabelecida há muito tempo,facilitando o aprendizado dos desenvolvedores experientes.

3.4.3 Práticas de desenvolvimento durante a implementação docódigo de tratamento de exceções

Para finalizar o survey de validação, foram incluídas 5 afirmações relativas às práticasobservadas durante o estudo exploratório, como mostrado na Figura 6. Foi observado queos desenvolvedores se preocupam com o código de tratamento de exceções, porém algumascontradições também foram encontradas.


12. 75% dos respondentes concordam ou concordam fortemente que escrever código detratamento de exceções é uma tarefa confortável.

13. 68% dos respondentes concordam ou concordam fortemente que eles se preocupamem como as exceções são manuseadas.

14. 74% dos respondentes discordam ou discordam fortemente que eles reservam partedo tempo somente para pensar em como lidar com exceções.

15. 78% dos respondentes concordam ou concordam fortemente que há preocupação como código normal antes da preocupação com o código de tratamento de exceções.

44

16. 52% dos respondentes discordam ou discordam fortemente que procuram saber queexceções um sistema externo pode lançar, antes do seu uso.

Apesar da falta de treinamento e documentação, os desenvolvedores acreditam que aimplementação de código de tratamento de exceções não é uma tarefa difícil. Ainda, apesarde na fase das entrevistas do estudo exploratório termos percebido a prática da negligênciaem vários participantes, adiando a decisão sobre o tratamento de exceções (Seção 3.3.6),os respondentes do survey de validação indicaram se preocupar em como as exceções sãotratadas. Esse resultado está em contradição com o fato da maioria dos respondentesafirmarem não reservar uma parte do tempo para pensar em como lidam com exceções.Era esperado que as respostas das afirmações 13 (“Eu me preocupo com o tratamentoque é dado às exceções”) e 14 (“Parte do meu tempo programando é voltado somentepara pensar em como lidar com exceções”) fossem proporcionais, porém foi encontrado umresultado inversamente proporcional. Uma possível explicação é que os desenvolvedoresse preocupam com o tratamento dado às exceções, mas que devido à experiência ou àsimplicidade com que esse tratamento é dado, essa é uma atividade que não demandamuito tempo deles.

Em adição, foi encontrado que a grande maioria dos respondentes se preocupam como código normal antes do código de tratamento de exceções, também podendo caracterizaruma contradição com os resultados anteriores. Em estudo feito em 2010 por Shah, Gorge Harrold (SHAH; GORG; HARROLD, 2010), esse resultado já foi observado. Estes autoresobservaram que os desenvolvedores geralmente tem a prática de postergar o devidotratamento das exceções para uma futura versão do software, apesar de raramente essafutura melhoria ocorrer na prática (BARBOSA; GARCIA; MEZINI, 2012). Esse resultado foiencontrado por Shah, Gorg e Harrold para os desenvolvedores novatos, ou seja, com poucosanos de experiência (média de 2 anos de experiência). Para os programadores experientes(mais de 5 anos de experiência), os autores concluíram que existe a prática de nãodistinguir a importância do código de tratamento de exceções do código da funcionalidadeprincipal, pois estes programadores pensam sobre as exceções já no momento que estãoimplementando a funcionalidade principal. Os resultados encontrados neste survey estãomais similares ao resultados encontrados por Shah, Gorg e Harrold para os novatos. Porémo perfil dos respondentes survey está mais similar ao perfil dos experientes na pesquisadestes autores, já que 84% dos participantes possuem mais de 4 anos de experiência (Figura3). Uma possível explicação para isso é o fato de grande parte do tratamento de exceçõesdado nos SIGs serem delegados para a Camada Núcleo, então mesmo os desenvolvedoresmais experientes não precisam tomar muitas decisões a respeito do tratamento.

45

Por fim, 52% dos desenvolvedores assumem não procuram se precaver de exceçõesexternas antes de usar uma biblioteca ou serviço de terceiros. Apesar dos respondentesterem afirmados que se preocupam com o tratamento que é dados às exceções, eles corremo risco de ficar expostos a exceções desconhecidas.

3.5 Análise do código fonte e logs do sistema

Alguns resultados encontrados nas etapas das entrevistas e do survey de validação semostraram conflitantes, como o fato dos desenvolvedores não receberem treinamento e nãopossuírem uma documentação que formaliza a política de tratamento de exceções, de modoa apoiar as decisões a serem tomadas. Apesar disso, eles afirmam que o desenvolvimentodesse tipo de código não é uma atividade custosa. Uma possível explicação para essacontradição se baseia na simplicidade que pode ser dada ao tratamento de exceções nossistemas, repassando todas a responsabilidade para a Camada Núcleo.

A extração de características do código pode explicar essas contradições. Dessa forma,foi realizada uma análise estática e inspeção manual do código fonte, juntamente coma mineração de logs de exceções não capturadas, que estão detalhadas nas Subseçõesseguintes. Esses dados foram levantados levando em consideração os sistemas SIG (SIGAA,SIPAC e SIGRH) e também a Camada Núcleo.

3.5.1 Análise estática do código fonte

Esta seção traz detalhes da análise estática realizada no código dos sistemas. Estaanálise levantou dados sobre os elementos que lidam com as exceções no sistema (classesde exceção, tratadores e sinalizadores) e foi estritamente estática, sem levantar dados sobreo fluxo das exceções ou se os trechos de código analisados são executados ou não. Porémcomo o objetivo é verificar como esse código é estruturado, essas limitações não interferemdiretamente no nosso objetivo.

Em relação às classes de exceções, foram encontrados 152 tipos de exceções utilizadasno sistema, que são instanciadas, sinalizadas ou capturadas. Destas, 25% são definidas nopróprio sistema, 41% são exceções próprias do Java e 34% são exceções de bibliotecas deterceiros, como Hibernate e Spring. Do total das exceções, 51% são exceções checadas e49% não checadas.

A respeito dos sinalizadores, 11092 instruções throw foram encontradas. Foram identi-

46

ficadas três estratégias de sinalização: 52% dos sinalizadores são simples, ou seja, lançamuma nova instância da exceção; 44% captura uma exceção, a encapsula, ou seja, muda seutipo (wrapping) e a relança; e 4% dos sinalizadores realizam um rethrow de uma exceçãoque acabou de ser capturada. Dentre todos os blocos de sinalização, 70 tipos de exceçõesdiferentes são sinalizados, onde 44% desses são exceções do próprio sistema. Em relação aosistema onde a sinalização, a Tabela 3 resume a distribuição dos sinalizadores nos sistemas:47% dos blocos throw estão no sistema SIPAC, 32% estão no SIGAA, 17% estão no SIGRHe apenas 4% estão na Camada Núcleo.

Tabela 3: Distribuição dos sinalizadores e tratadores nos SIGS

Sistema Blocos throw Blocos catchCamada Núcleo 4% 4%SIGAA 32% 38%SIPAC 47% 40%SIGRH 17% 18%

Já em relação aos tratadores, ou seja, blocos catch, existem 16258 blocos de tratamentode exceções nos sistemas. Metade das capturas é feita pela exceção genérica do Java(java.lang.Exception), considerada uma má prática por Bloch e Joshua (2008), seguida deexceções definidas no próprio sistema. Do total das 152 classes de exceções encontradosno sistema, 76% delas são utilizadas em ao menos um bloco catch. Em relação ao localonde a captura é realizada, a Tabela 3 traz os dados da distribuição dos tratadores nossistemas SIGs: 40% dos blocos catch estão no sistema SIPAC, 38% estão no SIGAA, 18%estão no SIGRH e apenas 4% estão na Camada Núcleo. Apesar deste sistema ter umaparte do código responsável pelo tratamento genérico de exceções, o baixo número detratadores nesta camada pode ser apenas uma questão de proporção, já que o tamanhototal do código fonte dela é cerca de 9% do tamanho médio dos outros sistemas, comomostrado na Tabela 1.

O alto número de tipos de exceções, sinalizadores e tratadores indicam que o códigode tratamento de exceções forma uma parte considerável do código fonte dos sistemasanalisados. Apesar disso, ele parece não ter a devida atenção dos desenvolvedores, comomostrado nos resultados encontrados.

47

3.5.2 Inspeção manual do código

Para a inspeção manual, 81 blocos de tratamento (0,5%) foram aleatoriamente es-colhidos e analisados, com o objetivo de identificar padrões de tratamento usados pelosdesenvolvedores para realização do tratamento das exceções. Do total de blocos anali-sados, foram detectados 13 ações de tratamento distintas, onde três delas são soluçõespadronizadas do sistema, que exibem uma mensagem de erro para o usuário, notifica osadministrados do sistema em relação ao erro e adiciona o erro numa fila de pendênciaspara posterior avaliação. Porém o tratamento mais utilizado é o trecho de código padrãogerado pela IDE, em que a exceção é simplesmente impressa no output de execução. Osegundo tratamento mais usado é o encapsulamento de exceção e em seguida a adição demensagem para o usuário.

Durante a análise, foram encontrados 26% dos tratadores que silenciam as exceções.Ao dividir os tratamentos dados de acordo com a estratégia usada, foi encontrado que 29%dos tratamentos são simples logs do erro, 19% são feedback ao usuário, 14% são ações derecuperação do sistema (entram numa lista de pendências para serem re-executadas umperíodo de tempo depois) e 12% dos tratamentos dados notificam os administrados dosistema. Todos os dados levantados na inspeção que podem ser possíveis fontes de errosnos sistemas, serão repassados para o setor responsável.

3.5.3 Análise dos logs de exceções não capturadas

Além da análise estática e inspeção manual do código, também foi realizada a inspeçãodas exceções que não foram capturadas pelo sistema. Sempre que uma exceção é lançadae não é capturada por nenhuma camada do sistema, inclusive nem pelo tratador padrãoda Camada Núcleo, tem como consequência a interrupção do uso do sistema, através daexibição de uma tela de erro para o usuário. Nesses casos, a Camada Núcleo registra aocorrência no banco de dados.

Os dados registrados no banco de dados foram analisados, para um período de 1 mês,e foram registrados 1224 exceções não capturadas, dando uma média de 40 por dia. Dessas,56% foram exceções próprias do Java, 25% foram exceções de serviços de terceiros ou APIse 18% foram exceções específicas do sistema.

O alto índice de exceções de terceiros não capturadas está alinhado com os resultadosencontrados nas etapas anteriores do estudo exploratório, onde a maioria dos desenvol-vedores disse não procurar saber quais exceções são lançadas por um serviço externo

48

antes de usá-lo (Seção 3.4.3). Porém nessa mesma Seção, os desenvolvedores afirmam sepreocupar com o tratamento que é dado às exceções, apesar do alto número de exceçõesnão capturadas. Uma das possíveis causas desse alto número é o desconhecimento dapolítica por parte dos programadores. Quando o desenvolvedor cria um bloco de sinalizaçãode exceção sem verificar quem vai capturar esta exceção, pode ocorrer de nenhuma camadasuperior fazer o devido tratamento, gerando as ocorrências de não capturas. Quando ocódigo fonte está em conformidade com a política, o desenvolvedor tem como identificarquem deve fazer o devido tratamento e verificar se o código está refletindo essa situação.

3.6 Ameaças à validade

A primeira amaça à validade tem relação com a credibilidade dos resultados, pois oestudo se fundamentou basicamente nas percepções e opiniões dos participantes que sevoluntariaram a participar da etapa inicial do mesmo. Para minimizar essa limitação eaumentar a credibilidade e abragência dos resultados da pesquisa, foi realizada a etapa dosurvey de validação, pois os dados observados na etapa da entrevista puderam ser avaliadospor uma quantidade maior de participantes.

Outra ameaça à validade deste trabalho é em relação à generalização, pois os resultadosobtidos não podem ser diretamente generalizados para outros cenários. Essa limitação sedeve ao fato do estudo exploratório ter sido realizado no contexto de um único setor deTI, com uma quantidade não grande de participantes, que tiveram tempo e motivaçãopara participar das etapas do estudo. Dessa forma, os resultados encontrados não podemser generalizados para todos os desenvolvedores Java, já que outras populações podemadicionar novos conhecimentos, e consequentemente, possibilidade de outros resultados.Porém a metodologia utilizado no estudo foi descrita em detalhes, incluindo condições docontexto em que o estudo foi aplicado, facilitando a análise e avaliação da transferibilidadedeste estudo para outros contextos.

A última ameaça à validade levantada é em relação à confirmabilidade dos resultados,devido a um possível viés na análise e interpretação dos dados das entrevistas e survey devalidação. Essa limitação, característica de pesquisas qualitativas e do método GroundedTheory, foi acentuada pelo fato que já havia um conhecimento prévio a respeito do códigofonte do sistema utilizado no estudo, bem como do funcionamento da organização ondeo estudo foi realizado. Para minimizar essa ameaça, as entrevistas e a análise de dadosforam feitas em conjunto com outro pesquisador que não possuía nenhum conhecimento

49

prévio sobre o código fonte ou sobre o funcionamento da organização. Dessa forma, osdados foram analisados sob uma perspectiva mais alheia ao contexto, minimizando aimparcialidade dos resultados.

3.7 Considerações finais

Este Capítulo mostrou o estudo exploratório realizado com desenvolvedores de softwaredentro de um ambiente real de desenvolvimento. O estudo exploratório foi composto por trêsetapas: entrevistas semiestruturadas, em que alguns desenvolvedores foram questionados arespeito de como lidam com o tratamento de exceções, um survey de validação, em queos desenvolvedores responderam o quanto concordam com os resultados encontrados naetapa anterior, seguida de uma análise estática do código fonte e dos logs da aplicação.

Em relação às vantagens e desvantagens do uso de exceções, de forma geral, os resultadosdas entrevistas foram reforçados pelos resultados do survey. Os desenvolvedores acreditamna importância do mecanismo de tratamento de exceções para prover robustez ao sistemae resolução de bugs. Além disso, eles também acreditam que, apesar de demandar algumesforço, a relação custo-benefício do uso de tratamento de exceções é vantajosa.

Porém algumas contradições foram encontradas: os resultados, tanto das entrevistascomo do survey, deixaram explícitos que os desenvolvedores não possuem treinamento arespeito de tratamento de exceções, nem no ambiente acadêmico, nem no ambiente detrabalho. Aliado a isso, está a falta de documentação específica sobre exceções. Apesardisso, eles confirmam, no survey de validação, se sentir confiantes e confortáveis ao realizaras atividades de implementação e manutenção no código de tratamento de exceções, comotambém afirmaram conhecem a política adotada pela empresa e boas e más práticas nautilização de exceções. Um trabalho futuro pode abordar essa contradição, para entenderse existe uma forma padrão dos desenvolvedores aprenderem os conceitos e práticas dotratamento de exceções.

Os resultados sugerem que o conhecimento dos desenvolvedores acerca de tratamentode exceções é transferido entre seus pares, através dos padrões de código, reforçando,assim, a importância da existência de uma forma padronizada para lidar com as exceçõesno sistema. Esse padrão, que representa a política de tratamento de exceções, não évisível ao programador num artefato de software formal, sendo um conhecimento que eletem que absorver através da experiência com o código. A falta de padrão e treinamentolevam o desenvolvedor a lidar com o código de tratamento de exceções da forma mais

50

conveniente, por exemplo, utilizando o recurso de auto-complemente que a IDE oferece.Esse comportamento é susceptível a gerar erros no código e pode ser a causa das máspráticas encontradas no mesmo. Em contrapartida, os resultados das entrevistas e dosurvey indicam que os desenvolvedores se sentem a vontade ao implementar o código detratamento de exceções. A medida que a instituição negligencia a definição da políticade tratamento de exceções e um treinamento adequado, os desenvolvedores tendem anegligenciar a importância do código de tratamento de exceções e a pensar que este é umcódigo não essencial, gerando uma falta impressão de domínio desse código.

Diante dessas observações, este trabalho propõe uma ferramenta que explicita a políticade tratamento de exceções para o desenvolvedor, auxiliando-o a implementar o códigode tratamento de exceções em conformidade com a política definida. Estas informaçõespodem auxiliar o desenvolvedor na tomada de decisões de como tratar e lançar as exceções,evitando o adiamento dessas decisões. O Capítulo 4 aborda os detalhes desta ferramentaproposta.

51

4 Ferramenta Proposta:ExceptionPolicyExpert

Um dos objetivos da pesquisa exploratória realizado neste trabalho foi identificarquais são os principais obstáculos enfrentados pelos programadores no momento daimplementação do código do tratamento de exceções. Uma das maiores dificuldadesenfrentadas pelos desenvolvedores identificada foi a falta de informação a respeito dapolítica de tratamento de exceções dos sistemas desenvolvidos por eles. Este resultadomotivou o desenvolvimento da ferramenta ExceptionPolicyExpert (na forma de um plug-in inserido na IDE Eclipse) para auxiliar o desenvolvedor a implementar o código detratamento de exceções aderente à política. Observamos que essa política geralmente não édocumentada, sendo um conhecimento que é adquirido entre os desenvolvedores conformeganham experiência com o código dos sistemas. Por esta razão, a política implementadatende a não ser cumprida ao longo das sucessivas evoluções sofridas pelo sistema, sedegradando conforme o sistema evolui. Para que seja possível a documentação da políticade tratamento de exceções, a ferramenta ExceptionPolicyExpert utiliza a linguagemfornecida pela ferramenta ECL/DAEH, proposta por Abrantes (2016).

Este capítulo detalha a ferramenta proposta e seus conceitos envolvidos. A Seção4.1 traz mais informações sobre a ferramenta ECL/DAEH, a Seção 4.2 aborda comoa ferramenta ExceptionPolicyExpert foi desenvolvida, a Seção 4.3 traz a visão geralda ferramenta e a Seção 4.4 fala do módulo de verificações da ferramenta. Por fim, asSeções 4.5 e 4.6 trazem as limitações da ferramenta e as considerações finais do Capítulo,respectivamente.

4.1 Ferramenta ECL/DAEH

O design de software implementa decisões importante sobre a arquitetura de umaaplicação e as regras de design especificam como as entidades de software devem se

52

Figura 7: Funcionamento da ferramenta ECL/DAEH. Fonte: (ABRANTES, 2016)

relacionar com as demais, definindo contratos que devem ser rigidamente seguidos emtodas as fases do ciclo de vida do software (ABRANTES, 2016).

A ferramenta DAEH - Dynamic Analysis of Exception Handling (ABRANTES, 2016)permite que regras de design específicas para o tratamento de exceções sejam criadas everificadas de forma dinâmica. Para seu correto funcionamento, ela deve ser incorporada àaplicação Java que se deseja monitorar e utiliza o byte code da máquina virtual, atravésdo processo de dynamic weaving do AspectJ.

A ferramenta se utiliza de aspectos para verificar, a cada captura de exceção, se seufluxo excepcional obedece às regras de design definidas. Caso negativo, a informação éenviada para o servidor DAEH, que analisa e armazena a violação. As informações deviolação podem ser utilizadas por outras ferramentas de mineração de dados. A Figura 7mostra a visão geral do funcionamento da ECL/DAEH, que pode ser utilizada de formaconjunta com a ferramenta proposta neste trabalho, por serem consideradas ferramentascomplementares, já que uma delas funciona de forma estática (ExceptionPolicyExpert) e aoutra funciona de forma dinâmica (ECL/DAEH).

4.1.1 Linguagem ECL

A linguagem ECL (Exception Contract Language) é uma linguagem específica dedomínio que possibilita a definição das regras de design que são consumidas pela ferramentaECL/DAEH. A linguagem possui palavras chaves que identificam os elementos do contratode exceção. A Figura 3 mostra um exemplo de contrato definido com esta linguagem. Apalava-chave ehrule indica o início de uma regra, que pode ser de dois tipos: partial ou full.O modo parcial representa que o contrato define um subconjunto de regras que podem sersinalizadas pelo módulo, assim a sinalização de uma exceção não especificada não seráconsiderada violação. O tipo full, por sua vez, indica que todas as exceções que podemser lançadas por um módulo estão especificadas no contrato. A palavra-chave signaler

53

Figura 8: Exemplo de contrato especificado na linguagem ECL. Fonte: (ABRANTES, 2016)

representa um método ou pacote que lança uma ou mais exceção. Já a palavra-chaveexcpetionAndHandlers define um sinalizador, ou seja, uma tupla composta por uma exceçãoe um handler. O handler representa um conjunto de métodos ou pacotes que realizam otratamento da exceção indicada no elemento exception.

No exemplo da Figura 8, está representado um contrato que informa que a exceção dotipo DAOException, lançada por qualquer método da classe DAO (o wildcard “ * ” indicaqualquer método de uma classe) pode ser tratada por qualquer classe ou subtipo de Servlet(o wildcard “ + ” indica herança). Este contrato ainda indica que os métodos da classeDAO só pode lançar exceções do tipo DAOException, já que seu tipo é full. A ferramentaproposta ExceptionPolicyExpert utiliza a linguagem ECL como meio de documentar apolítica de tratamento de exceções.

4.2 Desenvolvimento da ExceptionPolicyExpert

O desenvolvimento da ferramenta foi composto por dois passos. O primeiro passo foia avaliação da linguagem ECL para verificar se os elementos dela eram suficientes paraconstruir as regras de política de exceções observadas na análise dos dados de entrada.Foi então percebido que a linguagem ficaria mais robusta se uma nova construção queindicasse elementos que não podem tratar determinadas exceções fosse adicionada.

Dessa forma, a construção cannotHandle foi incluída à linguagem. Essa construção fazparte do par exceptionAndHandlers e, ao contrário da construção original, informa quaisclasses não devem tratar determinada exceção.

A Figura 9 mostra um exemplo da construção cannotHandle. Esse exemplo indica queas exceções do tipo “DaoException”, lançadas por qualquer método/classe, não devem sertratadas pela classe “ViewFilter”.

O segundo passo constituiu na implementação de um plug-in do Eclipse para auxiliar

54

Figura 9: Exemplo da construção cannotHandle

Figura 10: Visão geral da ferramenta ExceptionPolicyExpert

o programador a seguir a política de tratamento de exceções definida, bem como a lidarmelhor com o código de tratamento de exceções. Essa ferramenta, cujo código fonte estádisponível1, foi implementada na linguagem Java, em formato de plug-in para a IDEEclipse e funciona por meio de alertas para o desenvolvedor. Seu objetivo é servir como umapoio ao desenvolvedor, auxiliando-o a escrever códigos mais robustos. As seções seguintestrazem mais detalhes da implementação.

4.3 Visão geral da ExceptionPolicyExpert

Como mostra a Figura 10, a ferramenta ExceptionPolicyExpert utiliza como entrada dedados dois artefatos: o código fonte Java que está sendo editado na IDE e o documento querepresenta a política do tratamento de exceções do sistema, escrito em ECL e compiladopara o formato XML.

O primeiro passo de execução da ferramenta é transformar o arquivo Java numa árvoreAST (Abstract Syntax Tree), que é a representação em objetos de todos os elementosdo código. Em seguida a ferramenta lê o arquivo onde está documentada a política

1https://bitbucket.org/taizarm/exceptionexpert

55

Figura 11: Diagrama de sequência das operações do módulo de verificações

de tratamento de exceções. Para que a ferramenta encontre o arquivo, foi criada umapadronização para o nome do arquivo (contract.xml) e para a localização do mesmo dentrodo projeto. O terceiro passo, o módulo de verificação, utiliza como entrada estes arquivose constitui o processamento principal da ferramenta. A ExceptionPolicyExpert verifica ocódigo em edição, analisa todos os métodos que sinalizam ou tratam exceções e verifica seexiste alguma violação à política e ainda averigua se há alguma recomendação a ser dadaao desenvolvedor. A Seção 4.4 detalha todas as análises feitas no módulo de verificação ea Figura 11 ilustra o diagrama de sequência das operações realizadas nesse módulo.

A ferramenta é acionada automaticamente cada vez que o código em edição é compiladoe tem como saída uma lista de violações e uma lista de informações ao desenvolvedor,mostradas na própria IDE de forma que o desenvolvedor não precisa chamar a ferramentaexplicitamente, através de um botão, por exemplo. Assim, o plug-in retorna as informaçõesde forma transparente para o usuário. A ferramenta exibe as informações em formatode warnings e também através de sublinhado na respectiva linha. Além disso, todas asanálises feitas são registradas no log da IDE.

4.4 Módulo de verificação

O módulo de verificação é o responsável por analisar o código fonte em edição ecomparar com a política de tratamento de exceções previamente informada. O módulo deverificação analisa se há alguma violação da política e em alguns casos, dá informaçõesao desenvolvedor, o auxiliando a implementar a funcionalidade em conformidade com apolítica definida.

56

A ferramenta implementa três verificações, listadas na Tabela 4. A coluna tipo informao tipo de verificação: violação ou informação. A violação se caracteriza por uma situaçãoque não satisfaz a política definida, enquanto que o tipo informação retorna dados quedevem auxiliar o desenvolvedor na implementação do método. Já a coluna “Aplicado a”indica em quais métodos a verificação será aplicada: sinalizadores (métodos que lançamexceção) ou tratadores.

As seções a seguir trazem detalhes de cada verificação, seguidas de um exemplo doretorno mostrado pela ferramenta. Para melhor entendimento dos exemplos, a Seção 4.4.1detalha a política utilizada para exemplificação.

Tabela 4: Resumo das verificações realizadas pela ExceptionPolicyExpert.

Verificação Tipo Aplicado a ObjetivoSinalização Indevida Violação Sinalizadores Informar se o método lança uma

exceção que não deveTratamento indevido Violação Tratadores Informar se o método trata uma

exceção que não devePossíveis tratadores Informação Sinalizadores Informar os possíveis tratadores

de uma exceção lançada

4.4.1 Exemplo de política de tratamento de exceções especifi-cada em ECL

Esta seção exemplifica uma especificação de política de tratamento de exceções nalinguagem ECL, após compilação para XML. Esta definição de política, ilustrada na Figura12 será utilizado nas seções seguintes para exemplificar o funcionamento da ferramenta.

A regra R1 especifica que quando qualquer método da classe “StudentDao” lançaruma exceção do tipo “DAOException”, o responsável por tratar ela é qualquer métododa classe “arq.ViewFilter”. Além disso, devido à regra ser do tipo full, ela indica que“DAOException” é a única exceção que pode ser lançada a partir da classe “StudentDao”.Já a regra R2 indica que a exceção “Exception” não pode ser capturada e tratada porqualquer método da classe “StudentMBean”, independente de quem a sinalizou. Por fim,a regra R3 documenta que quando a exceção “StudentBusinessException” for lançada por

57

Figura 12: Exemplo de política de tratamento de exceções especificada em ECL

qualquer método da classe “StudentBusiness”, quem deve ser responsável por tratá-la équalquer método da classe “StudentMBean” ou o método “processException” da classe“arq.ViewFilter”. Como a regra R3 é do tipo partial, pode ser que a classe “StudentBusiness”lance outras exceções que não estão listadas nessa documentação.

4.4.2 Sinalização indevida

Esta verificação, do tipo violação, é executada para todos os métodos que são sina-lizadores de exceção. Seu objetivo é informar se o método lança uma exceção que nãodeve. Como detalha o Algoritmo 1, as condições para que essa violação seja disparada, éque deve existir uma regra do tipo full, cujo signaler corresponde ao elemento (classe oumétodo) em edição. Além disso, o método verificado deve lançar uma exceção que nãoestá listada no elemento exceptionAndHandlers da regra.

A Figura 13 exemplifica a utilização desta verificação. A classe “StudentDao” estálançando a exceção “Exception”, porém a regra R1 delimita que a única exceção que estaclasse pode lançar é “DAOException”, já que a regra R1 é do tipo full. Assim sendo, aferramenta mostra uma mensagem indicando a violação e mostrando qual é a regra dapolítica está sendo violada.

58

Algorithm 1 Sinalização IndevidaRequire: Source Code of class under edition (𝑆𝐶)

1: 𝑆 ← ∅2: for method 𝑀 : Program Methods from 𝑆𝐶 do3: for statement 𝑆𝑖 : Statements from 𝑀𝑖 do4: if 𝑆𝑖 is a 𝑡ℎ𝑟𝑜𝑤 statement then5: 𝐸 ← GetThrownException(𝑆𝑖)6: 𝐹𝑅← GetFullRulesFromSignaler(𝑀𝑖)7: for rule 𝐹𝑅𝑖 : FR do8: if 𝐸 ̸∈ GetExceptionsFromRule(𝐹𝑅𝑖) then9: 𝑆 ← 𝑆 ∪ {𝑆𝑖}

10: end if11: end for12: end if13: end for14: end for15: return 𝑆

Figura 13: Verificação de sinalização indevida

4.4.3 Tratamento indevido

Esta verificação também é do tipo violação. Ela é executada para todos os métodosque são tratadores de exceção, ou seja, aqueles que possuem um catch. O objetivo destaviolação é informar ao desenvolvedor que o método está tratando uma exceção que nãodeve, ou seja, existe uma regra na política que explicita que o método em edição não devetratar aquela exceção, através do elemento cannotHandle. O Algoritmo 2 traz detalhes de

59

como a verificação é implementada.

A Figura 14 mostra a utilização desta verificação. A classe “StudentMBean” estátratando a exceção “java.lang.Exception”, apesar da regra R2 indicar que esta exceção nãopode ser capturada e tratada por qualquer método desta classe. Esta situação caracterizauma violação à política e é explicitado ao desenvolvedor.

Algorithm 2 Tratamento IndevidoRequire: Source Code of class under edition (𝑆𝐶)

1: 𝑆 ← ∅2: for method 𝑀 : Program Methods from 𝑆𝐶 do3: for statement 𝑆𝑖 : Statements from 𝑀𝑖 do4: if 𝑆𝑖 is a 𝑐𝑎𝑡𝑐ℎ statement then5: 𝐸 ← GetCaughtException(𝑆𝑖)6: 𝐹𝑅← GetRulesFromSignaler(𝑀𝑖)7: for rule 𝐹𝑅𝑖 : FR do8: for exception 𝐶𝐻 : GetCannotHandleExceptionsFromRule(𝐹𝑅𝑖)

do9: if 𝐸 matches 𝐶𝐻 then

10: 𝑆 ← 𝑆 ∪ {𝑆𝑖}11: end if12: end for13: end for14: end if15: end for16: end for17: return 𝑆

4.4.4 Possíveis tratadores

Diferentemente das verificações anteriores, esta verificação é informativa, ou seja, nãoacusa violação da política e é executada para todos os métodos que lançam uma ou maisexceções.

O objetivo da verificação é, dada uma exceção lançada, informar quais são os possíveistratadores dessa exceção. Para isso, a ferramenta verifica se existe, na política, algumaregra (de qualquer tipo - full ou partial) cujo elemento signaler seja o método/classe

60

Figura 14: Verificação de tratamento indevido

em edição e que um dos pares exceptionAndHandler contenha a exceção sendo lançada.Com essa informação, ele exibe ao desenvolvedor todos os elementos handlers do parexceptionAndHandler. O Algoritmo 3 mostra os passos que são realizados para a execuçãoda verificação.

Algorithm 3 Possíveis tratadoresRequire: Source Code of class under edition (𝑆𝐶)

1: 𝑆 ← ∅2: for method 𝑀 : Program Methods from 𝑆𝐶 do3: for statement 𝑆𝑖 : Statements from 𝑀𝑖 do4: if 𝑆𝑖 is a 𝑡ℎ𝑟𝑜𝑤 statement then5: 𝐸 ← GetThrownException(𝑆𝑖)6: 𝐹𝑅← GetRulesFromSignaler(𝑀𝑖)7: for rule 𝐹𝑅𝑖 : FR do8: 𝐻 ← GetHandlersFromRule(𝐹𝑅𝑖)9: if 𝐸 ∈ GetExceptionsFromRule(𝐹𝑅𝑖) then

10: 𝑆 ← 𝑆 ∪ {𝐻}11: end if12: end for13: end if14: end for15: end for16: return 𝑆

61

A Figura 15 ilustra um exemplo desta verificação. Como existe uma regra (R3) queinforma quais são os handlers das exceção “StudentBusinessException” , quando lançadapela classe “StudentBusiness”, a ferramenta é capaz de informar ao desenvolvedor quaissão os métodos/classes responsáveis por tratar aquela exceção. Essa informação podetornar o desenvolvedor mais atento a quem está capturando a exceção lançada.

Figura 15: Verificação de possíveis tratadores

4.5 Limitação da ferramenta proposta

Uma limitação da ferramenta ExcpetionPolicyExpert é a possibilidade de gerar falsospositivos. Como a ferramenta não analisa os fluxos de exceções dinamicamente, não existea informação de que classe um determinado objeto é instanciado, exceto por seu tipodeclarado. Assim, a ferramenta considera apenas os tipos declarados no código fonte, semconsiderar comportamentos de herança (sub-classes), podendo gerar falsos positivos.

Outra limitação da ferramenta é em relação à linguagem de definição de política detratamento de exceções utilizada. A linguagem ECL tem a limitação de definir apenasos pontos de captura e lançamento de exceções, não permitindo adicionar mais detalhesdo fluxo de exceções. Dessa forma, a ferramenta ExcpetionPolicyExpert herdou essacaracterística, que deve ser melhorada em versões futuras da linguagem ECL.


Neste Capítulo apresentamos a ferramenta proposta neste trabalho, a ExcpetionPo-licyExpert. Esta ferramenta tem o objetivo de explicitar a política de tratamento deexceções para o desenvolvedor no momento exato em que ele está implementando o código.

62

Após a instalação da ferramenta e configuração do arquivo contendo a definição da política,seu funcionamento ocorre de forma transparente para o usuário, já que ela roda em modobackground cada vez que o código é compilado. Para avaliar o funcionamento da ferramenta,elaboramos um estudo de caso com alguns desenvolvedores e analisamos os logs gerados ea opinião dos usuários. O Capítulo 5 detalha a avaliação da ferramenta.

63

5 Avaliação da FerramentaExceptionPolicyExpert

Para avaliar a ferramenta ExceptionPolicyExpert, foi realizado um estudo de caso emtrês etapas: na primeira, a ferramenta foi instalada no ambiente de desenvolvimento realdos participantes e um breve treinamento foi dado; em seguida, após o uso da ferramentapor alguns dias, o log gerado foi analisado; e por fim, os participantes responderam umquestionário, onde puderam informar suas impressões quanto ao uso da ferramenta.

As seções a seguir abordam os detalhes da avaliação.

5.1 Participantes e definição da política

A primeira fase do estudo consistiu da seleção dos participantes. Por conveniência,o projeto SIGRH, da SINFO/UFRN, foi selecionado para ambientar a avaliação e 3desenvolvedores da equipe foram convidados a participar, de forma voluntária. O plug-infoi instalado no ambiente de desenvolvimento utilizado pelos participantes e a política detratamento de exceções foi escrita em ECL. Como foi identificado no estudo exploratórioe no survey de validação, não existe uma documentação da política. Portanto, para suaformalização em ECL, foram necessárias a inspeção do código fonte e conversas com oarquiteto de software e com um membro experiente da equipe de desenvolvimento. Feitoisso, foram identificadas 8 regras ECL, que foram documentadas no arquivo XML. Detalhesdas regras podem ser vistos no Apêndice D.

5.2 Coleta de dados do log

Os voluntários utilizaram a ferramenta durante 32 dias ao todo, se considerar a somados dias utilizados pelos três desenvolvedores. Durante esse período, a ferramenta registrou5618 logs de verificação, o que dá uma média de 175,56 violações por dia de trabalho de

64

cada desenvolvedor.

Como pode ser observado na Tabela 5, do total de verificações, a maioria é do Tra-tamento Indevido (3169), seguida de Possíveis Tratadores (2334) e Sinalização Indevida(115). Esses números refletem a quantidade de vezes que o alerta foi mostrado ao de-senvolvedor, sendo que o mesmo alerta pode ser mostrado mais de uma vez, bastandoo desenvolvedor compilar o arquivo que possui a violação mais de uma vez, o que deveocorrer frequentemente. Levando em consideração apenas a quantidade de ocorrênciasúnicas, ou seja, a quantidade de pontos no código que o warning foi disparado, os númerosão Tratamento Indevido (181), Sinalização Indevida (13) e Possíveis Tratadores (120). AsSeções a seguir detalham cada verificação.

Tabela 5: Quantidade de warnings exibidos durante a avaliação da ferramenta

Verificação Quantidade total Quantidade de ocorrênciasSinalização Indevida 115 13Tratamento indevido 3169 181Possíveis tratadores 2334 120

5.2.1 Sinalização Indevida

Como mostrado na Seção 4.4.2, para que a ferramenta detecte essa violação, é necessárioter uma regra ECL do tipo full que vai enumerar todas as exceções que um determinadométodo pode lançar. Se o método estiver lançando uma exceção que não esteja listada naregra, a ferramenta detecta a violação e informa ao desenvolvedor. Levando em consideraçãoa política definida no início da avaliação (ver Apêncide D), essa verificação vai observarse há violação às regras R8 e R9. A Tabela 6 resume o quantitativo de violações a essasregras: a regra R8 foi violada 98 vezes, em 9 pontos distintos do código, enquanto que aregra R9, foi violada 17 vezes, em 4 pontos distintos.

Pode-se então concluir que, no código utilizado pelos desenvolvedores durante o períododa avaliação, existem 13 locais que podem ser melhorados para aumentar a aderênciacom a política, onde 9 são métodos na camada DAO que está lançando alguma exceçãodiferente de DAOException (R8) e 4 são métodos de qualquer classe da camada JSF queestá lançando alguma exceção diferente das enumeradas pela política (R9). Essas violações

65

podem ocasionar um comportamento inesperado no sistema, pois as camadas que estãolocalizadas acima do nível onde as exceções são sinalizadas podem não estar preparadaspara tratar essas exceções.

Tabela 6: Quantidade de sinalizações indevidas encontradas

Regra Quantidade total Quantidade de ocorrênciasR8 98 9R9 17 4

5.2.2 Tratamento Indevido

As violações de tratamento indevido, como explicado na Seção 4.4.3 ocorrem quandoexiste uma regra que define o elemento “cannot-handle” e o método lança essa mesmaexceção. A política define duas regras nesse formato, a R6 e a R7 e para ambas foramdetectadas violações, como mostrado na Tabela 7. Sendo assim, existem 181 locais nocódigo onde essas regras estão sendo violadas, em que 33 são violações à regra R6 e 148, àregra R7. Contabilizando a quantidade de repetições, o alerta da regra R6 foi exibido 476vezes e o da R7 foi exibido 2693 vezes. As regras R6 e R7 indicam que nenhum método doSIGRH pode tratar as exceções DAOException e Exception, respectivamente, deixandopara a Camada Núcleo tratar as mesmas. A regra R6 evita que classes da camada devisão ou negócio do SIGRH trate erros ocasionados na camada de banco de dados, poisse um erro ocorreu no banco, não há como reparar o dano, deixando para a CamadaNúcleo registrar o log e avisar aos administradores. Provavelmente esse é um caso demal uso de exceções checadas, pois a exception DAOException é uma forte candidata aser do tipo unchecked. Já a regra R7 foi criada para evitar que exceções genéricas sejamcapturadas, já que isso é considerado uma má-prática. Nesse caso o desenvolvedor deveanalisar a fonte do problema: se o método que lançou a exceção encapsulou em uma“java.lang.Exception” (nesse caso deve ser corrigido na fonte) ou se o elemento “catch” queestá fazendo a conversão (nesse caso, o “catch” deve ser alterada para capturar a exceçãoprópria da abstração).

Essas violações ferem algumas boas práticas de uso de exceções em Java, elencadaspor Bloch (BLOCH, 2008) como o uso de exceções checadas para representar condiçõesrecuperáveis, o lançamento de exceções que sejam próprias à abstração e evitar o uso

66

desnecessário de exceções checadas.

Tabela 7: Quantidade de tratamentos indevidos encontrados

Regra Quantidade total Quantidade de ocorrênciasR6 476 33R7 2693 148

5.2.3 Possíveis tratadores

A terceira validação feita pela ferramenta não indica violação da política, mas dá aodesenvolvedor informações que podem ser úteis para ele garantir que o código está deacordo com a política definida. Para todos os métodos que lançam exceções, a ferramentaprocura se há alguma regra que define quem é o elemento handler dessa exceção, ouseja, quem deve ser responsável por seu tratamento. Durante o período de avaliação daferramenta, foram dadas informações em relação às regras R1, R2, R4, R5 e R9, comolistado na Tabela 8. Considerando os pontos de ocorrência, foram detectados 120 locais nocódigo que há o lançamento de exceção e a ferramenta informou ao desenvolvedor quemdeve tratá-la. Dessa forma, é esperado que o desenvolvedor não apenas lance a exceção,mas também verifique quem está recebendo e tratando ela, evitando que exceções fiquemsendo relançadas indefinidamente pelas camadas do sistema.

Tabela 8: Quantidade de possíveis tratadores identificados

Regra Quantidade total Quantidade de ocorrênciasR1 298 26R2 1 1R4 1895 84R5 64 5R9 76 4

67

5.3 Opinião dos usuários

Os desenvolvedores voluntários usaram a ferramenta até uma data pré estabelecida.Durante esse tempo, foi solicitado que eles observassem como foi o uso da ferramenta,seja em termos de sua utilidade, elementos de interface gráfica e desempenho. Após otempo estabelecido para o uso, eles foram solicitados a preencher um questionário, que estáreproduzido no Apêndice E. Essa seção traz uma compilação das opiniões dos usuários.

Uma sugestão feita por um dos desenvolvedores já foi implementada na ferramenta. Naprimeira versão os warnings não estavam sendo mostrados em conjunto com o sublinhadoda linha, então o desenvolvedor comentou que não estava conseguindo identificar o outputda ferramenta e sugeriu o sublinhado, que tornava explícito a linha que estava ocorrendo averificação. Dessa forma a sugestão foi implementa e uma versão atualizada da ferramenta,com essa melhoria, foi disponibilizada para os desenvolvedores.

De acordo com as respostas dadas no questionário de avaliação, os desenvolvedoresaprovaram a ferramenta, indicando que ela auxilia na implementação de exceções. Elesconsideraram que eram pontos positivos da ferramenta:

∙ Ajuda os desenvolvedores novatos a entender melhor o tratamento de exceções dainstituição, de forma a mantê-los dentro do padrão;

∙ Deixou o desenvolvedor mais alerta para o uso correto das exceções e em tentarentender os motivos das decisões tomadas, sem simplesmente apenas fazer o que aIDE sugere;

∙ Fez refletir em como usar as exceções corretamente dentro de cada camada;

∙ Promove a rastreabilidade de utilização das exceções;

∙ Promove a padronização na implementação das exceções;

∙ Melhora a qualidade no processo de desenvolvimento de software, principalmente emrelação ao tratamento de erros.

Quando questionados se a ferramenta atrapalhou de alguma forma o processo dedesenvolvimento, os três desenvolvedores responderam que não. Porém todos eles falaramque os warnings mostrados pela ferramenta não estão claros, prejudicando a perfeitautilização da ferramenta. Um dos usuários falou que confundiu as mensagens geradas peloplug-in, precisando tirar essa dúvida diretamente com o autor da ferramenta. A criação

68

de um manual também foi sugerida, para que o usuário pudesse ter uma referência doswarnings exibidos. Além disso, um dos participantes comentou não ter achado necessárioa ferramenta quando ele vai alterar um pequeno trecho de código numa classe, comopor exemplo para uma correção pontual de bugs, indicando que a ferramenta tem maisutilidade quando um caso de uso é escrito do início ou quando grandes refatorações nocódigo são feitas. Por fim, eles também sugeriram melhorar o processo de instalação, paratornar mais fácil o acesso à ferramenta.


Este Capítulo abordou a avaliação da ferramenta ExceptionPolicyExpert, propostanesse trabalho, através de um estudo de caso. A análise dos logs mostrou que a ferramentadetectou um volume grande de verificações, em média de 175 por dia, indicando que ocódigo do sistema usado na avaliação tem muitos pontos de possíveis melhorias. A avaliaçãofeita pelos usuários voluntários mostrou que a ferramenta auxilia o desenvolvedor em váriospontos, como padronização do código, auxílio para os novatos, leva a reflexão da utilizaçãodos mecanismos de tratamento de exceções, em vez de usar o que a IDE sugere, etc. Porémexistem alguns pontos que podem ser melhorados, especialmente em relação a como aferramenta exibe as informações. Esses pontos de melhoria podem ser implementados emforma de trabalho futuro para a próxima versão da ferramenta.

69

6 Trabalhos relacionados

Existem três linhas principais de trabalhos relacionados: aqueles que realizam estudosqualitativos a partir das experiências profissionais de desenvolvedores que lidam com trata-mento de exceções, os que propõe linguagens para especificar comportamento excepcionale os trabalhos que propõem ferramentas de recomendação. As seções seguintes abordamas respectivas linhas.

6.1 Estudos qualitativos envolvendo desenvolvedores

Greiler, Deursen e Storey (2012) realizaram uma pesquisa qualitativa, utilizando técni-cas de Grounded Theory, com o objetivo de entender como programadores e testadoresatuam quando precisam testar sistemas baseados em plug-in. Os autores iniciaram apesquisa com um estudo exploratório e em seguida conduziram uma série de entrevistassemiestruturadas. As informações levantadas nas entrevistas foram organizadas em códigos,conceitos e categorias, através da técnica de coding, do método GT. 25 integrantes dacomunidade Eclipse foram entrevistados, incluindo desenvolvedores (64%), testadores(6%) e gerentes ou líderes. Assim como este trabalho, Greiler, Deursen e Storey preten-diam entender como os profissionais da área de desenvolvimento de software agiam numdeterminado contexto: no caso deles testes de sistemas baseados em plug-in e no casodeste trabalho, tratamento de exceções. Dessa forma, a mesma abordagem de estudoqualitativo foi utilizada neste trabalho: entrevistas semi-estruturadas, técnicas de GT esurvey de validação. Porém enquanto os autores selecionaram participantes com diversosperfis (desenvolvedores, testadores, gerentes de projeto, etc.) e diferentes empresas, estetrabalho focou numa única instituição e apenas em profissionais exercendo a função dedesenvolvedor. A expansão deste trabalho para diversas organizações está como objetivode trabalhos futuros.

Em se tratando de pesquisas qualitativas que abordam o tema tratamento de exce-ções, existem poucos estudos qualitativos conduzidos com desenvolvedores, tendo como

70

precursores Shah, Gorg e Harrold que realizaram dois estudos que focam a perspectiva dodesenvolvedor (2008 e 2010).

O primeiro trabalho (SHAH; GÖRG; HARROLD, 2008b) conduziu um estudo com 9programadores para avaliar como eles lidam com o tratamento de exceções. O trabalho foidividido em duas partes: na parte 1, os participantes responderam perguntas que explicamcomo eles lidam com exceções e quais abordagens utilizam ao implementar código detratamento de exceções e na segunda parte do estudo, os participantes foram encorajadosa usar a ferramenta proposta pelos autores, EnHanCe - Exception HANdling CEntricVisualization, que tem o objetivo de prover a visualização de fluxos de tratamento deexceções.

Os estudos mostraram que os desenvolvedores não consideram a implementação dotratamento de exceções como uma atividade de alta prioridade, muitos consideram queconsome muito tempo e utilizam esse recurso em primeiro lugar para fins de debug nocódigo. Os participantes da pesquisa também acreditam que uma implementação do códigoexcepcional bem planejada pode ser adiada até que erros ocorram naquele código. Arespeito da ferramenta de visualização, a maioria dos participantes consideraram a visãoquantitativa difícil de compreender, porém avaliaram as outras duas visões como sendode bastante utilidade, pois permitem enxergar construções não vistas antes (por exemploblocos não alcançados) e o número de níveis que o fluxo de exceção percorre (distânciaentre o throw e o catch). Porém os participantes não se mostraram motivados a mudarseu modo de trabalho em relação ao tratamento de exceções. A partir desses resultados, oartigo propõe a criação de um novo papel no processo de desenvolvimento de software - oengenheiro de exceção - cuja função é fazer o design, implementar e integrar o código detratamento de exceções.

Para aumentar o entendimento do ponto de vista dos programadores com respeitoao tratamento de exceções, Shah, Gorg e Harrold se manteram no tema e geraram outroestudo (SHAH; GORG; HARROLD, 2010) que foca na comparação entre o entendimentodos programadores com pouca experiência profissional e daqueles experientes. O trabalhoanterior (SHAH; GÖRG; HARROLD, 2008b) serviu como fonte de informação para os desen-volvedores novatos (média de 2 anos de experiência profissional) e novas entrevistas foramfeitas com programadores experientes. O guia de entrevista utilizado no primeiro estudoserviu de base para o estudo dos experientes, que foi realizado com 6 desenvolvedoresque tinham entre 5 e 16 anos de experiência profissional. As entrevistas semiestruturadasforam gravadas, transcritas e codificadas. Os pesquisadores perceberam que os experientes

71

consideram que a implementação do tratamento de exceções é uma atividade indistinguívele inseparável da implementação das funcionalidades principais do sistema (happy-path).Além disso, utilizam as exceções para exibir erros de maneira satisfatória, de forma que ousuário entenda qual o motivo do erro. Em relação ao comportamento dos desenvolvedoresnovatos, os experientes acreditam que os inexperientes não entendem a importância deum tratamento de exceções adequado e reconheceram comportamentos que eles mesmosreproduziam antes de ganhar experiência profissional. O trabalho conclui que, em geral,novatos negligenciam o tratamento de exceções, enquanto que os profissionais experientesconsideram essa como sendo uma parte crucial do processo de desenvolvimento.

Os artigos de Shah, Gorg e Harrold (2008 e 2010) são os mais similares a estapesquisa, pois visam entender como os programadores lidam com o código de tratamentode exceções, se utilizando também de entrevistas semiestruturadas como meio de coletade dados. Foram encontrados, inclusive, alguns resultados semelhantes, como o uso domecanismo de tratamento de exceção para fins de debug e o adiamento de decisões sobre otratamento de exceções. Porém neste trabalho não chegamos a diferenciar as abordagensutilizadas por novatos e experientes, já que os respondentes possuem um perfil uniformeem relação a experiência profissional, podendo a maioria ser considerada como experiente.Neste trabalho, além de buscar entender como os programadores lidam com o tratamentode exceções, também focamos nas dificuldades que eles enfrentam ao lidar com esse código.Com isso, a ferramenta proposta por nós está alinhada a uma das maiores dificuldadesrelatadas, que é a falta de documentação da política. Como consequência, o objetivo daferramenta proposta também difere da ferramenta proposta por Shah, Gorg e Harrold,podendo ser usadas de forma complementar.

6.2 Ferramentas para definição e checagem de políti-cas de tratamento de exceções

Abrantes e Coelho (2015) propõe uma linguagem específica de domínio para documentara política de tratamento de exceções, como também uma ferramenta de monitoramentopara verificação dinâmica da política de tratamento de exceções. O trabalho apresenta alinguagem ECL - Exception Contract Language (mais detalhes podem ser vistos na Seção4.1), que possibilita a definição da política de tratamento de exceções, considerando quecomponentes (métodos, classes ou pacotes) podem tratar determinado conjunto de exceçõesou quais componentes podem lançar determinadas exceções. Um plug-in para Eclipsefoi criado para facilitar a implementação das regras, com recurso de auto complemento

72

da linguagem. A pesquisa também contribuiu com uma ferramenta de monitoramento,denominada DAEH - Dynamic Analysis of Exception Handling, que é acoplada ao servidorda aplicação e observa, através do uso de aspectos, se alguma exceção é lançada e seela viola a política definida. As violações são enviadas para um servidor e esses dadospodem ser consumidos, para fins de log e análise, por outras aplicações. A abordagemde monitoramento proposta por Abrantes e Coelho, por utilizar verificação dinâmica,dá suporte apenas aos casos de uso exercitados pelo usuário, não sendo adequado paraambiente de desenvolvimento.

Barbosa et al. (2016) também propõe uma linguagem específica de domínio paradocumentar a política de tratamento de exceções, denominada de EPL - Exception HandlingPolicies Language, que é formada pelos conceitos de compartimentos, regras e alias.Um compartimento é um conjunto de elementos que estão relacionados a exceções, nocódigo fonte. O conceito de regra, na EPL, estabelece uma relação de dependência eresponsabilidade entre um compartimento e um ou mais tipos específicos de exceção. Estasrelações de dependência definem permissões (Only-may e May-only), proibições (Cannot) eobrigações (Must) que os compartimentos devem seguir, através das dependências do tipohandle, raises, propagates, re-maps e re-throws. Para facilitar a utilização da linguagem,ela também apresenta o conceito de pseudônimos (alias), que permite nomear um conjuntode exceções e utilizá-lo em várias regras diferentes, simplificando a especificação. Para averificação de uma dada política definida com a EPL, Barbosa também apresenta o EPLVerifier, que consiste em dois módulos: Rule Checker e Facts Extractor. O módulo FactsExtractor recebe o código fonte, gera a Abstract Syntax Tree (AST) - utilizando o EclipseJava Development Tools (JDT) - e analisa o código estaticamente extraindo as declaraçõesrelacionadas com tratamento de exceções. Já o módulo Rule Checker analisa cada regraespecificada e verifica se o código está violando as regras. Se sim, ele apresenta uma listade fatos de violação.

Os trabalhos citados nessa Seção também fazem a verificação da conformidade docódigo fonte com a política de tratamento de exceções. Porém eles não dão suporte paraa fase de desenvolvimento, que é uma das etapas mais críticas, em que o código fonteé implementado, deixando a verificação da conformidade da política de tratamento deexceções para um momento posterior. Além disso, a ExceptionPolicyExpert está integradaao ambiente de desenvolvimento, não sendo necessária nenhuma interação do desenvolvedorcom outra ferramenta, facilitando o acesso à informação. Dessa forma, as abordagenscitadas podem ser usadas de forma complementar à proposta por este trabalho.

73

6.3 Ferramentas de recomendação

O trabalho de Barbosa, Garcia e Mezini (2012) propõe e avalia um conjunto detrês heurísticas cujo objetivo é, a partir de um método específico, recomendar umalista de trechos de códigos que implementam tratamento de exceções, ordenados porrelevância, de acordo com a tarefa do desenvolvedor. Dessa forma, o programador visualizaações de tratamento de exceções que sejam relevantes no contexto do método que estáimplementando no momento. Para a representação do contexto do código, três informaçõessão usadas: os tipos das exceções lançadas, os métodos chamados e os tipos de variáveisusadas. Para cada umas dessas informações, uma heurística é proposta, resultando numtrecho de código recomendado para o tratamento da exceção. Entretanto, essa solução nãofaz referência à política de tratamento de exceção, tendo um foco diferente da propostapor este trabalho, já que as recomendações não estão alinhadas à política.

Com o objetivo de resolver o problema da falta de suporte para a especificação eimplementação da política para as exceções globais, ou seja, aquelas que passam por váriosmétodos desde o ponto que é lançada até o ponto que é tratada, Barbosa (2015) propõeuma solução que envolve a linguagem EPL (ver Seção 6.2) (BARBOSA et al., 2016), umconjunto de heurísticas de recomendações e um sistema que implementa as recomendaçõesdas heurísticas. As heurísticas são implementadas em dois níveis. As heurísticas de primeironível verificam o código fonte e, a partir da especificação da política, observam se há algumaviolação no código. Para cada método que viola, as heurísticas verificam a política paradescobrir quais tipos de exceção esse método pode estabelecer uma relação de dependênciasem que viole as regras especificadas. Essas relações de dependência (recomendações)são enviadas para as heurísticas de segundo nível, que tentam propor uma solução paraa violação. Uma solução é um conjunto de relações de dependências de tratamento deexceções que cada método da pilha de chamadas deve ter de forma que nenhuma regraseja violada. A solução dada por Barbosa e a proposta por este trabalho estão alinhadascom a política de tratamento de exceções e podem ser usadas de forma complementar. AExceptionPolicyExpert preenche a lacuna de informar as violações à política em “tempo-real” ao desenvolvedor, já que é desenvolvida na forma de plug-in integrada ao ambientede desenvolvimento.

Rahman e Roy (2014) propõe uma ferramenta de recomendação que considera arelevância estrutural e a similaridade léxica do código em desenvolvimento e tem comreferência os repositórios de código aberto populares. A solução proposta possui doismódulos, denominados cliente e computacional. O módulo cliente é um plug-in Eclipse

74

que coleta os trechos de código sob desenvolvimento que possuem tratamento de exceçõesgenérico ou mal programado e, a partir deles, prepara uma string de pesquisa com palavraschaves do código. Essas informações são enviadas para o web service do segundo módulo,que é responsável por coletar exemplos de código no repositório do GitHub. Ao finaldo processamento, que inclui filtros e classificações, 15 códigos de recomendação sãoselecionados dos repositórios remotos e são enviados para o módulo cliente. Este módulo,por sua vez, exibe as recomendações para o que o desenvolvedor opte por usar um dostrechos de código sugeridos como referência. Esta solução preenche a lacuna da interfacegráfica ser em formato de plug-in, apoiando o desenvolvedor no exato momento que eleimplementa o código. Porém ele usa como referência o código de aplicações popularesdo GitHub e considerando que devido tratamento de um comportamento excepcionaldepende de informações específicas da aplicação, tais como causa e local do erro, política detratamento de exceções, regras arquiteturais, entre outros, a solução proposta por Rahmane Roy deixa em aberto a lacuna de alinhamento à política.

75

7 Considerações Finais

O tratamento de exceções é uma das formas mais utilizadas para a construção desistemas de software robustos - atributo cada vez mais necessário aos sistemas compu-tacionais atuais. Porém estudos mostram que o código de tratamento de exceções nãotem recebido a devida atenção dos desenvolvedores (SHAH; GORG; HARROLD, 2010). Alémdisso, os desenvolvedores, muitas vezes, não aplicam as boas práticas de tratamento e nemseguem a política de tratamento de exceções da organização, essa, por sua vez, que nemsempre está explícita e documentada.

Este trabalho propõe uma ferramenta integrada ao ambiente de desenvolvimentoEclipse, que tem o objetivo de orientar o desenvolvedor na implementação do código detratamento de exceções em conformidade com uma política previamente definida. Para guiaro desenvolvimento da ferramenta, um estudo exploratório foi realizado com desenvolvedores,com o objetivo de identificar como eles lidam com a política de tratamento de exceçõese quais são suas maiores dificuldades. Este estudo foi aplicado num ambiente real dedesenvolvimento de software e foi composto de três partes: entrevistas semiestruturadas,survey e análise estática do código fonte e logs do sistema.

O estudo mostrou que os profissionais confiam nos mecanismos do tratamento deexceções para promover a robustez do sistema e utilizam esses mecanismos sem um custoadicional na etapa de desenvolvimento. Os resultados do estudo também mostraramque os desenvolvedores tem muitos desafios no momento de implementar o código detratamento de exceções, pois eles não possuem treinamento adequado e não existe umadocumentação que define e/ou orienta o desenvolvedor em relação a como as exceçõesdevem ser tratadas dentro do sistema. Apesar disso, os desenvolvedores afirmaram sesentir confiantes e confortáveis no momento da implementação do código de tratamento deexceções. Esses resultados sugerem que o conhecimento relacionado a como lidar com asexceções é transferido entre os desenvolvedores, através dos padrões de código, reforçandoa importância de uma forma padronizada de lidar com as exceções no sistema. Essaforma padrão, que caracteriza a política de tratamento de exceções não está documentada,

76

de acordo com os achados do estudo, sendo de conhecimento dos desenvolvedores maisexperientes que vai sendo passando para os novatos a medida que eles lidam com o códigode tratamento de exceções.

Com o objetivo de tornar a política de tratamento de exceções mais explícita e facilitarsua absorção pelos desenvolvedores, propomos a ferramenta chamada ExceptionPolicyEx-pert, que fornece informações sobre a política de tratamento de exceções diretamenteno ambiente de desenvolvimento. Essa ferramenta tem como entrada o código fonte e adefinição da política de tratamento de exceções e verifica o código que está sob edição,a fim de dar informações para o desenvolvedor tomar mais decisões baseado na política.A ExceptionPolicyExpert realiza três verificações: (i) sinalização indevida, que informaquando um método lança uma exceção que não deve; (ii) tratamento indevido, que indicase um método trata uma exceção que não deve; e (iii) possíveis tratadores, que lista ospossíveis tratadores de uma exceção lançada.

Como forma de avaliação da ferramenta, ela foi utilizada por desenvolvedores numambiente de desenvolvimento real. Os resultados mostraram que a ferramenta traz váriospontos positivos para a etapa de desenvolvimento do software, pois auxilia na padronizaçãodo uso de exceções, através da conformidade com a política de tratamento de exceções,leva o desenvolvedor a pensar melhor antes de tomar decisões em relacão ao tratamento deexceções, auxilia os novatos a terem conhecimento da política de tratamento de exceções,promove a rastreabilidade de exceções e a melhoria da qualidade de código. O estudoapontou algumas melhorias para a ferramenta, principalmente na sua interface gráfica,que estão listadas como trabalho futuro.

7.1 Trabalhos futuros

Alguns desdobramentos do presente trabalho são os seguintes:

∙ Novos Estudos Exploratórios. Os resultados encontrados no nosso estudo ex-ploratório se limitam a uma única empresa. Apesar de ter sido útil no contextodo nosso trabalho, seria interessante realizar um estudo qualitativo exploratóriomais amplo para incluir empresas com outros perfis e desenvolvedores com outrosníveis e tipos de experiência. Diversificando o tempo de experiência, pode-se fazeruma avaliação de como a experiência afeta a forma de lidar com o tratamentode exceções. Como a ferramenta proposta está direcionada ao desenvolvimento nalinguagem Java o nosso estudo exploratório focou nessa linguagem. Todavia pode

77

ser interessante aplicar o estudo exploratório com desenvolvedores que trabalhamcom outras linguagens de programação. Assim, pode se fazer um comparativo decomo os desenvolvedores Java e os desenvolvedores de outras linguagens lidam comtratamento de exceções. Além disso, um a extensão do estudo exploratório pode serfeita focando na investigação de como os como os desenvolvedores aprendem a lidare as boas/más práticas relacionadas ao código de tratamento de exceções.

∙ Realização de novos estudos de caso. Em relação à ferramenta proposta Excep-tionPolicyExpert, apesar dela ter sido avaliada em um ambiente de desenvolvimentoreal, é interessante fazer um estudo mais abrangente, com desenvolvedores de váriasequipes e com vários níveis de experiência.

∙ Melhorias na Ferramenta. Algumas possíveis melhorias na ferramenta seriam: (1)inclusão de uma visão de configuração, onde o usuário pode personalizar a ferramenta,escolhendo que verificações ele deseja no momento ou qual o diretório que se encontrao arquivo com a especificação da política; (2) possibilidade de buscar o arquivo coma especificação num servidor remoto, já que não é necessário que esse arquivo estejareplicado no computador de cada desenvolvedor; (3) geração de relatórios, onde odesenvolvedor possa visualizar quais as regras da política que são mais violadas,qual pacote possui mais violações, entre outras análises; (4) melhoria das mensagensexibidas pela ferramenta, a fim de deixar mais claro o conteúdo das mesmas; (5)criação de um manual, ou ainda a inclusão de uma visão dentro da própria IDE quepossibilite que o desenvolvedor tenha acesso a informações mais detalhadas de cadaverificação feita; (6) e melhoria no processo de instalação.

78

Referências

ABRANTES, J.; COELHO, R. Specifying and dynamically monitoring the exceptionhandling policy. In: Proceedings of the 27th International Conference on SoftwareEngineering and Knowledge Engineering. [S.l.: s.n.], 2015. p. 370–374.

ABRANTES, J. V. Especificação e Monitoramento Dinâmico da Política de Tratamentode Exceções. Dissertação (Mestrado) — Universidade Federal do Rio Grande do Norte,2016.

BARBOSA, E. A. Mastering global exceptions with policy-aware recommendations.In: IEEE PRESS. Proceedings of the 37th International Conference on SoftwareEngineering-Volume 2. [S.l.], 2015. p. 778–780.

BARBOSA, E. A.; GARCIA, A.; BARBOSA, S. D. J. Categorizing faults in exceptionhandling: A study of open source projects. In: IEEE. Software Engineering (SBES), 2014Brazilian Symposium on. [S.l.], 2014. p. 11–20.

BARBOSA, E. A.; GARCIA, A.; MEZINI, M. Heuristic strategies for recommendation ofexception handling code. In: IEEE. Software Engineering (SBES), 2012 26th BrazilianSymposium on. [S.l.], 2012. p. 171–180.

BARBOSA, E. A. et al. Enforcing exception handling policies with a domain-specificlanguage. IEEE Transactions on Software Engineering, IEEE, v. 42, n. 6, p. 559–584,2016.

BLOCH, J. Effective java. [S.l.]: Pearson Education India, 2008.

CHARMAZ, K. Constructing grounded theory. [S.l.]: Sage, 2014.

COELHO, R. de S. Analyzing Exception Flows of Aspect-Oriented Programs. Tese(Doutorado) — PUC-Rio, 2008.

EBERT, F.; CASTOR, F. A study on developers’ perceptions about exception handlingbugs. In: ICSM. [S.l.: s.n.], 2013. p. 448–451.

EBERT, F.; CASTOR, F.; SEREBRENIK, A. An exploratory study on exceptionhandling bugs in java programs. Journal of Systems and Software, Elsevier, v. 106, p.82–101, 2015.

GARCIA, A. F. et al. A comparative study of exception handling mechanisms for buildingdependable object-oriented software. Journal of systems and software, Elsevier, v. 59, n. 2,p. 197–222, 2001.

GLASER, B. G. The grounded theory perspective: Conceptualization contrasted withdescription. [S.l.]: Sociology Press, 2001.

79

GLASER, B. G. S. et al. The discovery of grounded theorystrategies for qualitativeresearch. [S.l.], 1967.

GOODENOUGH, J. B. Exception handling: issues and a proposed notation.Communications of the ACM, ACM, v. 18, n. 12, p. 683–696, 1975.

GOULDING, C. Grounded theory: some reflections on paradigm, procedures andmisconceptions. University of Wolverhampton, 1999.

GREILER, M.; DEURSEN, A. van; STOREY, M.-A. Test confessions: a study of testingpractices for plug-in systems. In: IEEE. 2012 34th International Conference on SoftwareEngineering (ICSE). [S.l.], 2012. p. 244–254.

JAKOBUS, B. et al. Contrasting exception handling code across languages: An experiencereport involving 50 open source projects. In: IEEE. Software Reliability Engineering(ISSRE), 2015 IEEE 26th International Symposium on. [S.l.], 2015. p. 183–193.

JUNIOR, R. J. S. Uma abordagem para a verificação do comportamento excepcional apartir de regras de designe e testes. Universidade Federal do Rio Grande do Norte, 2013.

KIENZLE, J. On exceptions and the software development life cycle. In: ACM. Proceedingsof the 4th international workshop on Exception handling. [S.l.], 2008. p. 32–38.

LAPRIE, J.-C. Dependable computing and fault-tolerance. Digest of Papers FTCS-15, p.2–11, 1985.

LEMOS, R. de; ROMANOVSKY, A. Exception handling in the software lifecycle.International Journal of Computer Systems Science and Engineering, CRL Publishing,v. 16, n. 2, p. 167–181, 2001.

MARINESCU, C. Are the classes that use exceptions defect prone? In: ACM. Proceedingsof the 12th International Workshop on Principles of Software Evolution and the 7thannual ERCIM Workshop on Software Evolution. [S.l.], 2011. p. 56–60.

MARINESCU, C. Should we beware the exceptions? an empirical study on the eclipseproject. In: IEEE. Symbolic and Numeric Algorithms for Scientific Computing (SYNASC),2013 15th International Symposium on. [S.l.], 2013. p. 250–257.

MELO, H. et al. In-depth characterization of exception flows in software product lines: anempirical study. Journal of Software Engineering Research and Development, SpringerBerlin Heidelberg, v. 1, n. 1, p. 1, 2013.

MONTONI, M. A. Uma investigação sobre os fatores críticos de sucesso em iniciativas demelhoria de processos de software. Tese (Doutorado) — Universidade Federal do Rio deJaneiro, 2010.

NG, K.; HASE, S. Grounded suggestions for doing a grounded theory business research.Electronic Journal of Business Research Methods, v. 6, n. 2, p. 155–170, 2008.

RADATZ, J.; GERACI, A.; KATKI, F. Ieee standard glossary of software engineeringterminology. IEEE Std, v. 610121990, n. 121990, p. 3, 1990.

80

RAHMAN, M. M.; ROY, C. K. On the use of context in recommending exceptionhandling code examples. In: SCAM. [S.l.: s.n.], 2014. p. 285–294.

SAWADPONG, P.; ALLEN, E. B.; WILLIAMS, B. J. Exception handling defects: Anempirical study. In: IEEE. High-Assurance Systems Engineering (HASE), 2012 IEEE 14thInternational Symposium on. [S.l.], 2012. p. 90–97.

SENA, D. et al. Understanding the exception handling strategies of java libraries: anempirical study. In: ACM. Proceedings of the 13th International Workshop on MiningSoftware Repositories. [S.l.], 2016. p. 212–222.

SHAH, H.; GÖRG, C.; HARROLD, M. J. Visualization of exception handling constructsto support program understanding. In: ACM. Proceedings of the 4th ACM symposium onSoftware visualization. [S.l.], 2008. p. 19–28.

SHAH, H.; GÖRG, C.; HARROLD, M. J. Why do developers neglect exception handling?In: ACM. Proceedings of the 4th international workshop on Exception handling. [S.l.],2008. p. 62–68.

SHAH, H.; GORG, C.; HARROLD, M. J. Understanding exception handling: Viewpointsof novices and experts. IEEE Transactions on Software Engineering, IEEE, v. 36, n. 2, p.150–161, 2010.

SHAHROKNI, A.; FELDT, R. A systematic review of software robustness. Informationand Software Technology, Elsevier, v. 55, n. 1, p. 1–17, 2013.

SOLINGEN, R. V.; BERGHOUT, E. The Goal/Question/Metric Method: a practicalguide for quality improvement of software development. [S.l.]: McGraw-Hill, 1999.

STOL, K.-J.; RALPH, P.; FITZGERALD, B. Grounded theory in software engineeringresearch: a critical review and guidelines. In: ACM. Proceedings of the 38th InternationalConference on Software Engineering. [S.l.], 2016. p. 120–131.

WIRFS-BROCK, R. J. Toward exception-handling best practices and patterns. IEEEsoftware, IEEE, v. 23, n. 5, p. 11–13, 2006.

81

APÊNDICE A -- Roteiro base dasentrevistas

INTRODUÇÃO

1.Contextualização rápida da pesquisa

2.Fale brevemente sobre sua experiência profissional

3.Fale um pouco sobre o seu dia a dia do trabalho (como é sua equipe, quais seuspapeis)

EXCEÇÕES NO SEU CONTEXTO

1.Com que frequência você implementa código que tem relação com tratamento deexceções (ex: relança, captura)?

2.Você lança exceções (dá um new exception())? Em quais ocasiões você faz isso?

3.Você costuma capturar exceções? O que você faz?

4.Mostrar a hierarquia de exceções da instituição. Você conhece essa hierarquia?

5.Quais dessas exceções você lida com mais frequência? Essas exceções representamquais problemas no sistema?

6.Você acha que a hierarquia das exceções representa bem os problemas do sistema?

7.Você já precisou criar uma classe de exceção especifica?

8.Na sua opinião, o que o sistema ganha ao utilizar o mecanismo de tratamento deexceções?

9.Você vê alguma desvantagem?

82

POLÍTICA DE TRATAMENTO DE EXCEÇÕES

1.Você já leu ou encontrou informações sobre como o tratamento de exceções deve serfeito no sistema que você desenvolve?

2.Você tem alguma sugestão de como melhorar a forma de lidar com exceções nosistema que você desenvolve?

3.Você ja se deparou com alguma informação sobre tratamento de exceções que poderiaser aplicado na instituição?

4.É comum você corrigir chamados de correções de erros? Com que frequência? Quaissão as principais causas?

EXCEÇÕES E LIBS

1.Quando você utiliza um método implementado por terceiros, você consulta as exceçõesque podem ser lançadas por ele?

2.Você trata as exceções lançadas da mesma forma que as exceções da sua aplicação?

EXCEÇÕES JAVA

1.Você acha que clausula throws te ajuda ou atrapalha durante o desenvolvimento?

2.Como você aprendeu sobre o tratamento de exceções? Você teve alguma aula oucurso sobre o assunto?

3.Você ja enfrentou dificuldades ao trabalhar com exceções em Java? Quais? (Porexemplo: dúvida se você deve tratar a exceção em um dado método ou relançá-la)

4.Você acha que o tratamento de exceções do Java ajuda ou atrapalha seu trabalho?Por que?

CONCLUSÃO

1.Perguntar se podemos entrar em contato se faltar alguma coisa

2.Agradecer a participação

83

APÊNDICE B -- Códigos mantidos após acodificação seletiva

Códigos relativos à palavra-chave "Obstáculos"

84

Códigos relativos à palavra-chave "Práticas"

85

Códigos relativos à palavra-chave "Vantagens/desvantagens"

86

APÊNDICE C -- Survey de validação

Como você lida com o tratamento de exceções?

Nós estamos interessados em saber como você, desenvolvedor, utiliza o tratamento deexceções no seu dia a dia de trabalho!

Este questionário anônimo, que leva menos de 5 minutos para ser respondido, fazparte de um estudo sobre como desenvolvedores lidam com tratamento de exceções em umambiente real de desenvolvimento.

A sua participação nos ajudará a entender como os programadores encaram o meca-nismo de tratamento de exceções, desde sua viabilidade no sistema até as dificuldades decodificação que ocorrem no dia-a-dia.

Este estudo é independente e não possui fins comerciais. As evidências encontradas emnosso estudo serão compartilhadas publicamente, assim todos podem se beneficiar dele,mas todos os dados são sigilosos.

Agradecemos sua participação!

Taiza Montenegro, mestranda em Sistemas e - DIMAp - UFRN

Hugo Melo, doutorando em Sistemas e Computação - DIMAp - UFRN

Profa. Dra Roberta Coelho - DIMAp - UFRN

1.Qual o seu tempo de experiência profissional?

∙Menos de 6 meses

∙Entre 6 meses e 2 anos

∙De 2 a 4 anos

∙De 4 a 6 anos

∙De 6 a 10 anos

87

∙10 anos ou mais

Para cada afirmação abaixo, indique o seu grau de concordância de acordocom sua experiência na empresa em que trabalha. Se alguma pergunta não seaplica à sua realidade, simplesmente pule ela

1.O tratamento de exceções auxilia na correção de bugs.

2.Sem exceções o sistema/serviço cairia mais vezes.

3.O código com tratamento de exceções é de difícil manutenção.

4.Lidar com código de tratamento de exceções consome muito do meu tempo.

5.A empresa me preparou para lidar com as exceções que ocorrem no sistema.

6.Eu conheço boas e/ou más práticas de implementação de tratamento de exceções.

7.Eu recorro ao código de colegas quando estou implementando tratamento de exceções.

8.Eu conheço e sei quando devem ser usadas a maioria das exceções do sistema quedesenvolvo.

9.A documentação me ajuda a entender como usar exceções no sistema.

10.Existe um padrão na forma de lidar com exceções no sistema (quando lançar ecapturar exceções).

11.Essa forma padrão de tratamento de exceções sofreu alterações recentemente.

12.Eu me sinto confortável para escrever código de tratamento de exceções em meusistema.

13.Eu me preocupo com o tratamento que é dado às exceções.

14.Parte do meu tempo programando é voltado somente para pensar em como lidarcom exceções.

15.Eu me preocupo com o código normal antes de implementar o código de tratamentode exceções.

16.Antes de usar uma funcionalidade de um sistema externo, eu procuro saber quaisexceções ele pode lançar.

88

Considerações finais

1.Você gostaria de receber um email com os resultados dessa pesquisa?

2.Qual o seu email? (Se você respondeu "sim"na pergunta anterior)

3.Muito obrigado por participar desta pesquisa! Fique a vontade para colocar qualquercomentário, crítica ou sugestão no espaço abaixo.

Observação do Apêndice: para todas as questões, a opção de resposta é na forma deescala Likert de 5 níveis (variando de “Discordo fortemente” até “Concordo fortemente”),como exemplificado na Figura 16.

Figura 16: Exemplo de escala Likert usada no survey de validação

89

APÊNDICE D -- Definição da políticautilizada na avaliação daferramenta

<?xml version=" 1 .0 " encoding="UTF−8" ?><e c l>

<!−− A c l a s s e ViewFi l t e r tem a r e s p o n s a b i l i d a d e det r a t a r as s e g u i n t e s excecoes (R1, R2 , R4 e R5) : −−>

<ehru l e id="R1" type = " p a r t i a l " s i g n a l e r=" * "><except ion type=" ArqException ">

<handler s i gna tu r e=" br . u f rn . arq . web .ViewFi l t e r .* " />

</ except ion></ ehru l e>

<ehru l e id="R2" type = " p a r t i a l " s i g n a l e r=" * "><except ion type=" UFRNException ">



<!−− Regra removida , po i s a camada de Beans pode t r a t a ra excecao NegocioExcept ion para p e r s o n a l i z a r ore torno ao usuar io−−>

<!−− <ehru l e id="R3" type = " p a r t i a l " s i g n a l e r=" * ">−−><!−− <except ion type=" NegocioException ">−−>

<!−− <handler s i gna tu r e=" br . u f rn . arq . web. ViewFi l t e r .* " />−−>

90

<!−− </ except ion>−−><!−− </ ehru l e>−−>

<ehru l e id="R4" type = " p a r t i a l " s i g n a l e r=" * "><except ion type=" DAOException ">



<ehru l e id="R5" type = " p a r t i a l " s i g n a l e r=" * "><except ion type=" SegurancaException ">



<!−− Nenhum metodo do SIGRH pode t r a t a r a excecaoDAOException −−>

<ehru l e id="R6" type = " p a r t i a l " s i g n a l e r=" * "><except ion type=" DAOException ">

<cannot−handle s i gna tu r e=" * " /></ except ion>

</ ehru l e>

<!−− Nenhum metodo do SIGRH pode t r a t a r a excecaoExcept ion−−>

<ehru l e id="R7" type = " p a r t i a l " s i g n a l e r=" * "><except ion type=" Exception ">

<cannot−handle s i gna tu r e=" * " /></ except ion>

</ ehru l e>

91

<!−− A unica excecao que a camada DAO pode lancar e DAOexcep t i on −−>

<ehru l e id="R8" type = " f u l l " s i g n a l e r=" * . dao .* "><except ion type=" DAOException ">



<!−− As unicas excecoes que a camada JSF pode lancar saoas s e g u i n t e s : −−>

<ehru l e id="R9" type = " f u l l " s i g n a l e r=" * . j s f .* "><except ion type=" ArqException ">


</ except ion><except ion type=" NegocioException ">


</ except ion><except ion type=" SegurancaException ">


</ except ion><except ion type=" RuntimeNegocioException ">



</ e c l>

92

APÊNDICE E -- Avaliação da ferramentaExcpetionPolicyExpert

1.O uso da ferramenta lhe deixou mais a par de como as exceções devem ser trata-das/lançadas no sistema? Se sim, você pode exemplificar ou ilustrar um cenário emque isso ocorreu?

2.A ferramenta lhe ajudou no momento de implementar o código de tratamento deexceções? Como?

3.Em algum momento a ferramenta atrapalhou o processo de desenvolvimento? Como?

4.Você pode listar pontos negativos e pontos positivos do uso da ferramenta?

5.Você teria alguma sugestão de melhoria para a ferramenta?

Documents

ExceptionPolicyExpert: Uma Ferramenta para Auxiliar no Desenvolvimento do Tratamento ... · 2017-11-04 · Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática