Especificação e monitoramento dinâmico da política de tratamento de exceções

Texto

(1)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 Mestrado Acadêmico em Sistemas e Computação. Especificação e Monitoramento Dinâmico da Política de Tratamento de Exceções. Joilson Vidal Abrantes. Natal-RN Fevereiro/2016.

(2) Joilson Vidal Abrantes. Especificação e Monitoramento Dinâmico da Política de Tratamento de Exceções. Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito para a obtenção do grau de Mestre em Sistemas e Computação. Linha de pesquisa: Engenharia de Software. Orientadora. Profa . Dra . Roberta de Souza Coelho.. PPgSC – Programa de Pós-Graduação em Sistemas e Computação DIMAp – Departamento de Informática e Matemática Aplicada CCET – Centro de Ciências Exatas e da Terra UFRN – Universidade Federal do Rio Grande do Norte. Natal-RN Fevereiro/2016.

(3) Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Centro de Ciências Exatas e da Terra – CCET. Abrantes, Joilson Vidal. Especificação e monitoramento dinâmico da política de tratamento de exceções / Joilson Vidal Abrantes. - Natal, 2016. 75 f. : il. Orientadora: Profa. Dra. Roberta de Souza Coelho. Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. 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. Monitoramento – Dissertação. 4. Análise dinâmica – Dissertação. 5. Política de tratamento de exceções – Dissertação. I. Coelho, Roberta de Souza. II. Título. RN/UF/BSE-CCET. CDU: 004.41.

(4)

(5)

(6) Dedico este trabalho aos meus pais, José e Marina..

(7) Agradecimentos Em primeiro lugar, gostaria de agradecer aos meus pais todo o apoio e carinho que me foram dado em toda as fases da minha vida e à minha família por sempre estar ao meu lado em todos os momentos. A professora Roberta de Souza Coelho, por além de ser uma ótima orientadora, ser um exemplo de comprometimento, ética, humildade e sabedoria. A equipe do laboratório LETS da UFRN por todas as contribuições durante o desenvolvimento deste trabalho. Em especial a Wallace Medeiros. Aos companheiros da LogAp Sistemas que sempre me apoiaram e incentivaram a fazer este trabalho. Em especial Edson Jackson e Danilo Barros. A Dalton Dantas, Leandro Bezerra, Mário Melo e a Superintendência de Informática (SINFO/UFRN) pela colaboração com esta pesquisa. A sociedade brasileira, que pagou por minha educação. A todos vocês, meu sincero e profundo Muito Obrigado! Finalmente, agradeço a Deus por sempre estar ao meu lado e por ter me dado todas as ferramentas e oportunidades para que eu chegasse onde estou..

(8) Nossa maior fraqueza está em desistir. O caminho mais certo para vencer é tentar mais uma vez. Thomas Edison.

(9) Especificação e Monitoramento Dinâmico da Política de Tratamento de Exceções. Autor: Joilson Vidal Abrantes Orientador: Profa. Dra. Roberta de Souza Coelho.. Resumo A política de tratamento de exceções de um sistema compreende o conjunto de regras de design que especificam o comportamento e tratamento das condições excepcionais, ou seja, define como as exceções devem ser manuseadas e disparadas. Essa política geralmente não é documentada e fica definida implicitamente pelo arquiteto do sistema. Por essa razão os desenvolvedores podem pensar que apenas inserindo blocos try-cach em todos locais onde exceções podem potencialmente ser lançadas estão lidando adequadamente com as condições excepcionais de um sistema. Porém este comportamento pode transformar o tratamento das condições excepcionais em uma generalização do mecanismo "goto", tornando o programa mais complexo e menos confiável. Este trabalho propõe uma linguagem específica de domínio, chamada ECL (Exception Contract Language) para especificar a política de tratamento de exceções e uma ferramenta de monitoramento em tempo de execução que verifica dinamicamente a política de tratamento de exceções. Essa ferramenta é chamada de DAEH (Dynamic Analysis of Exception Handling) e é implementada na forma de uma biblioteca de aspectos, que pode ser adicionada a uma aplicação Java sem a necessidade de alterar o código fonte da mesma. Esta abordagem foi aplicada a dois sistemas WEB, a quatro versões do framework JUnit e a uma aplicação móvel. Os resultados indicam que esta abordagem pode ser usada para expressar e automaticamente verificar a política de tratamento de exceções de sistemas, e, consequentemente apoiar o desenvolvimento de sistemas Java mais robustos. Palavras-chave: tratamento de exceções, monitoramento, análise dinâmica, política de tratamento de exceções..

(10) Specification and Dynamic Monitoring Exception Handling Policy. Author: Joilson Vidal Abrantes Supervisor: Profa . Dra . Roberta de Souza Coelho.. Abstract The exception handling policy of a system comprises the set of design rules that specify its exception handling behavior how exceptions should be handled and thrown. Such policy is usually undocumented and implicitly defined by the system architect. For that reason, the developers may think that by just sprinkling the with catch-blocks in all places where exceptions may potentially be released they are adequately dealing with the exceptional conditions of a system. This lack of information may turn the exception handling into a generalized "goto"mechanism making the program more complex and less reliable. This work proposes a domain - specific language called ECL (Exception Contract Language) to specify the exception handling policy and a runtime monitoring tool which dynamically checks thise policy. This tool is called DAEH (Dynamic Analysis Of Exception Handling). It is implemented in the form of an aspect library, which can added to any Java system without the need to change the application source code. We applied this approach to two large-scale WEB systems and to the a set of versions to the well-known JUnit framework and a mobile application. The results indicate that this approach can be used to express and automatically check the exception handling policy of a system, and consequently support the development of more robust Java systems and more robust. Keywords: exception handling, monitoring, dynamic analysis, exception handling policy..

(11) Lista de figuras 1. Arquitetura de um sistema baseado em camadas. . . . . . . . . . . . . . p. 18. 2. Exemplo de código AspectJ. . . . . . . . . . . . . . . . . . . . . . . . . . p. 26. 3. Especificação da gramática da linguagem OlaMundo. . . . . . . . . . . . p. 28. 4. Editor da linguagem OlaMundo gerado pelo Xtext. . . . . . . . . . . . . p. 29. 5. Exception Contract Language (ECL) na notação Backus-Naur Form. . . p. 31. 6. Criação de contrato com a ECL. . . . . . . . . . . . . . . . . . . . . . . . p. 33. 7. Visão geral da DAEH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33. 8. Passos para utilização da DAEH. . . . . . . . . . . . . . . . . . . . . . . p. 35. 9. Diagrama de classes da ferramenta DAEH. . . . . . . . . . . . . . . . . . p. 37. 10. Trecho de código do aspect ContractChecking. . . . . . . . . . . . . . . p. 38. 11. Diagrama de sequência apresentando a inicialização da ferramenta DAEH. p. 40. 12. Diagrama de sequência apresentando as classes envolvidas na verificação das regras de design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41. 13. Arquitetura dos sistemas da família SIG. . . . . . . . . . . . . . . . . . . p. 44. 14. Hierarquia de exceções (primeiro nível). . . . . . . . . . . . . . . . . . . . p. 46. 15. Hierarquia de exceções filhas de UFRNException. . . . . . . . . . . . . . p. 46. 16. Hierarquia de exceções Runtime. . . . . . . . . . . . . . . . . . . . . . . . p. 47. 17. Interação entre as classes envolvidas no tratamento de exceções quando a aplicação não trata e chega até a classe ViewFilter. . . . . . . . . . . . p. 49. 18. Regras para os sistemas SIGRH e SIGAA, sintetizadas em uma única construção da ECL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51. 19. Esquema geral de interação entre a Rasthro e os módulos do servidor DAEH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54.

(12) 20. Definição da linguagem ECL no Xtext. . . . . . . . . . . . . . . . . . . . p. 75. 21. Comando para iniciar aplicação Java com o monitoramento da DAEH habilitado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76.

(13) Lista de tabelas 1. Exemplo de regras de design.. . . . . . . . . . . . . . . . . . . . . . . . . p. 28. 2. Métricas de versões dos sistema SIGRH e SIGAA. . . . . . . . . . . . . . p. 45. 3. Regras criadas para os sistemas SIGRH e SIGAA utilizando a linguagem ECL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 50. 3. Regras criadas para os sistemas SIGRH e SIGAA utilizando a linguagem ECL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51. 4. Texto enviado para o servidor DAEH devido a uma quebra de regra de design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52. 5. Número de violações de regras nos testes manuais. . . . . . . . . . . . . . p. 52. 6. Violações encontradas durante execução dos testes automatizados. . . . . p. 53. 7. Tempos de execução dos testes automatizados. . . . . . . . . . . . . . . . p. 53. 8. Características do projeto SIGAA Mobile. . . . . . . . . . . . . . . . . . p. 54. 9. Relação das exceções identificadas no aplicativo SIGAA Mobile. . . . . . p. 55. 10. Regras de design para o framework JUnit. . . . . . . . . . . . . . . . . . p. 57. 10. Regras de design para o framework JUnit. . . . . . . . . . . . . . . . . . p. 58. 10. Regras de design para o framework JUnit. . . . . . . . . . . . . . . . . . p. 59. 11. Violações das regras de design do framework JUnit. . . . . . . . . . . . . p. 60. 12. Resumo da análise de desempenho. . . . . . . . . . . . . . . . . . . . . . p. 61. 13. Comparativo da ECL com outras técnicas. . . . . . . . . . . . . . . . . . p. 65.

(14) Sumário. p. 16. 1 Introdução 1.1. O Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17. 1.2. Limitações das Abordagens Existentes . . . . . . . . . . . . . . . . . . . p. 18. 1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19. 1.4. Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19. 1.5. Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . . . p. 20. 2 Fundamentação Teórica. p. 21. 2.1. Tratamento de Exceções . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21. 2.2. Análise Dinâmica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22. 2.3. Programação Orientada a Aspectos . . . . . . . . . . . . . . . . . . . . . p. 23 2.3.1. 2.3.2. Aspectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24 2.3.1.1. Pontos de junção . . . . . . . . . . . . . . . . . . . . . . p. 24. 2.3.1.2. Adendos . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24. 2.3.1.3. Combinação de Aspectos . . . . . . . . . . . . . . . . . . p. 25. AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25 2.3.2.1. Combinação de Aspectos . . . . . . . . . . . . . . . . . . p. 25. 2.4. Regras de Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26. 2.5. Xtext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28. 3 Análise Dinâmica do Tratamento de Exceções 3.1. p. 30. Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30.

(15) 3.2. 3.3. A Linguagem ECL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30 3.2.1. Criação da Linguagem . . . . . . . . . . . . . . . . . . . . . . . . p. 31. 3.2.2. Elementos da ECL . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32. Ferramenta DAEH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33 3.3.1. Fluxo de Funcionamento . . . . . . . . . . . . . . . . . . . . . . . p. 34. 3.3.2. Paralelização na Verificação de Regras . . . . . . . . . . . . . . . p. 36. 3.3.3. Arquitetura da Ferramenta DAEH . . . . . . . . . . . . . . . . . p. 36. 3.3.4. Servidor DAEH . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41. 4 Estudos de Caso 4.1. 4.2. 4.3. p. 42. Sistemas Integrados de Gestão (SIGs) . . . . . . . . . . . . . . . . . . . . p. 42 4.1.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43. 4.1.2. Arquitetura dos SIGs . . . . . . . . . . . . . . . . . . . . . . . . . p. 43. 4.1.3. Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45. 4.1.4. Regras de Design . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46. 4.1.5. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52. 4.1.6. SIGAA Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53. 4.1.7. Análise dos resultados . . . . . . . . . . . . . . . . . . . . . . . . p. 55. Estudo de Caso para o framework JUnit . . . . . . . . . . . . . . . . . . p. 56 4.2.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56. 4.2.2. Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56. 4.2.3. Regras de Design . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57. 4.2.4. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59. 4.2.5. Análise dos resultados . . . . . . . . . . . . . . . . . . . . . . . . p. 60. Avaliação de desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61. 5 Trabalhos Relacionados. p. 63.

(16) 6 Considerações finais. p. 67. 6.1. Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68. 6.2. Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68. 6.3. Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68. Referências. p. 71. Anexo A -- Código Xtext da ECL. p. 75. Anexo B -- Execução da Ferramenta DAEH. p. 76.

(17) 16. 1. Introdução. Aplicações modernas têm de lidar com um número crescente de condições excepcionais que surgem como consequência de falhas no próprio aplicativo (por exemplo, acesso a referências nulas), entradas maliciosas fornecidas pelo usuário ou falhas no middleware ou hardware (AVIŽIENIS et al., 2004). O tratamento de exceções (GOODENOUGH, 1975) é uma das técnicas mais utilizadas para o desenvolvimento de sistemas robustos, permitindo que tais aplicações possam detectar e se recuperar de condições excepcionais. Embora o mecanismo de tratamento de exceções tenha sido incorporado em várias linguagens de programação convencional (por exemplo, Java, C++, C#), estudos têm mostrado que o código dedicado ao tratamento de exceções é muitas vezes mal compreendido, sendo a parte menos testada do sistema de software (GARCIA; RUBIRA et al., 2007) (GARCIA et al., 2001) (CABRAL; MARQUES, 2007) (COELHO et al., 2011). O comportamento do código de tratamento de exceções de um sistema é mal compreendido, porque é geralmente distribuído por vários artefatos de implementação e muitas vezes as construções de tratamento de condições excepcionais (por exemplo, declarações throws e blocos try-cach) levam os desenvolvedores a acreditar que apenas inserindo vários blocos try-catch pelo código eles podem (i) lidar com as situações excepcionais e (ii) focar no desenvolvimento de cenários chamados de "caminho feliz"(MANDRIOLI; MEYER, 1992). Esta abordagem de "ignore-for-now"pode tornar o tratamento de exceções em um mecanismo generalizado "goto"(MANDRIOLI; MEYER, 1992) tornando o programa mais complexo e ainda menos confiável. O código relacionado às exceções pode favorecer a introdução de falhas, tais como exceções uncaught (COELHO et al., 2008) - o que pode levar a falhas no sistema, tornando o sistema ainda menos robusto (CRISTIAN, 1982). O trabalho de Marisnescu (MARINESCU, 2011) realizou um estudo empírico para investigar se as classes que possuem tratamento de exceções são mais propensas a possuir defeitos do que as classes que não fazem tratamento de exceções. Seu estudo analisou três versões do Eclipse, 2.0, 2.1 e 3.0. O número de classes que possuem código de tratamento de exceções e que não possuem foi coletado para cada versão. Informações dos defeitos.

(18) 17. do eclipse após o lançamento de cada versão foram extraídas do CVS e do Bugzilla, para ver se os defeitos estavam numa classe que possuía tratamento de exceções ou não. Os resultados do estudo mostraram que as classes que usavam exceções eram mais propensas a apresentar defeitos do que as classes que não manipulavam exceções. O trabalho de Sawadpong (SAWADPONG; ALLEN; WILLIAMS, 2012) mostra que a densidade de defeitos no código de tratamento de exceções é cerca de três vezes mais elevado do que a densidade global de defeitos. A densidade do código de tratamento de exceções é a quantidade de defeitos advindos do código de tratamento de exceções dividido pela quantidade de linhas das classes que realizam o tratamento de exceções. Já a densidade global de defeitos é o número total de defeitos dividido pela quantidade de linhas do sistema.. 1.1. O Problema. Nesta subseção é apresentado um exemplo motivacional para levantar a aplicação de regras de design referentes ao tratamento de exceções. Considere um sistema em camadas típico que compreende as camadas de data, business e presentation - ver Figura 1. Uma possível regra de tratamento de exceções para essa arquitetura em camadas poderia ser: as exceções lançadas pela camada de data devem ser um subtipo de DAOException e devem ser manuseadas somente na camada de presentation. No entanto, geralmente essas regras são informalmente mantidas na documentação do sistema, ou mais frequentemente, não são documentadas e permanecem apenas no conhecimento implícito da equipe de desenvolvimento. Ambas as formas de lidar com as regras de tratamento de exceções ameaçam o desenvolvimento de sistemas robustos. Em primeiro lugar, uma vez documentadas tal documentação pode se tornar ultrapassada e ser de pouco uso. Em segundo lugar, as regras quando não documentadas podem não serem conhecidas pelos novos membros da equipe de desenvolvimento, e, por consequência, não vão ser seguidas. Além disso, nenhum destes cenários apoia a verificação automática das regras de tratamento de exceções durante a compilação ou execução do sistema. Vamos também considerar, que em tal sistema uma instância de DAOException é lançada pela camada de data e é erroneamente tratada por um tratador genérico definido da classe Facade (da camada de business). Impor e verificar automaticamente este tipo de regra de design é muitas vezes considerada uma tarefa desafiadora..

(19) 18 Legend: Presentation Layer Servlet2. Servlet1. Class Exception. Architecture Layer. Business Layer Facade. Exception flow. Association (UML). Data Layer. IDAO. Interface (UML). DAO. Implementation (UML) DAOException. Figura 1: Arquitetura de um sistema baseado em camadas.. 1.2. Limitações das Abordagens Existentes. Trabalhos têm mostrado que a falta de informação sobre como projetar e implementar as condições excepcionais leva o código de tratamento de exceções a complexas e "spaghetti-like"estruturas de exceções (ROBILLARD; MURPHY, 2000). Para o nosso melhor entendimento, poucos estudos têm sido propostos para melhor compreender e verificar o comportamento de tratamento de exceções em sistemas de software. Alguns deles são baseados no uso de ferramentas de análise estática (COELHO et al., 2008) (FU; RYDER, 2007) (ROBILLARD; MURPHY, 2000) e outros sobre as ferramentas de teste automatizado (BERNARDO et al.,. 2011) (SALES; COELHO, 2011). Ambas as abordagens, no entanto, possuem. limitações intrínsecas. As abordagens que utilizam análise estática (COELHO et al., 2008) (FU; RYDER, 2007) (ROBILLARD; MURPHY, 2003) propõem ferramentas para descobrir os caminhos que levam ao lançamento de exceções para manipuladores (ou seja, elementos responsáveis pela captura). No entanto, devido às limitações inerentes à análise estática combinadas com as características das linguagens modernas (por exemplo, herança, polimorfismo e chamadas virtuais) tais abordagens costumam notificar falsos positivos. Por outro lado, as abordagens baseadas na definição de casos de teste (BERNARDO et al., 2011) (SALES; COELHO, 2011) limitam a capacidade de verificar o comportamento de tratamento de exceções para os cenários cobertos por testes. Além disso, o elevado número de locais de tratamento e de sinalização a ser testado pode conduzir ao problema de explosão de testes (necessidade de uma grande quantidade de testes) (BRUNTINK; DEURSEN; TOURWÉ, 2006) (COELHO et al., 2008). Nenhum dos trabalhos mencionados acima permite o desenvolvedor especificar o.

(20) 19. comportamento do tratamento de exceções de um sistema e verificar esse tipo de comportamento, enquanto o sistema está sendo executado. Fazê-lo, possibilitaria usar os dados de entrada fornecidos por usuários reais ou testadores de aceitação, a fim de verificar o comportamento do tratamento de exceções de um sistema.. 1.3. Objetivos. Este trabalho possui dois objetivos principais: i. Definir uma linguagem de domínio específico para especificar a política de tratamento de exceções de um sistema. ii. Construir uma ferramenta de monitoramento para apoiar a checagem dinâmica da política de tratamento de exceções. Geralmente as políticas de tratamento de exceções não são documentadas e permanecem implícitas na forma de um conjunto de construções de tratamento de exceções, espalhada em vários métodos da aplicação. A linguagem específica de domínio (DSL) proposta neste trabalho consiste em um conjunto de regras de design que define o comportamento de tratamento de exceções de um sistema, indicando, como as exceções devem ser manuseadas e lançadas por seus principais elementos. A ferramenta de monitoramento permitirá que verifiquemos se o comportamento excepcional de um sistema está em conformidade com a política de tratamento de exceções definida antecipadamente através da linguagem. A linguagem e a ferramenta de monitoramento foram implementadas e para avaliar a utilidade das mesmas foi realizado dois estudos de caso. Foi especificado e verificada a política de tratamento de exceções dos sistemas SIGs (SIGRH e SIGAA) e do aplicativo SIGAA Mobile. Também foi analisado o framework de teste JUnit, para o qual foram analisadas quatro versões. Os resultados mostraram que a abordagem proposta pode ser utilizada para especificar e dinamicamente verificar a política de tratamento de exceções de ambos os sistemas.. 1.4. Resultados Obtidos. Os resultados obtidos até o momento são:.

(21) 20. i. ABRANTES, J. COELHO, R. Specifying and Dynamically Monitoring the Exception Handling Policy, The 27th International Conference on Software Engineering and Knowledge Engineering, Julho 2015. ii. ABRANTES, J. COELHO, R. BONIFÁCIO, R. DAEH: A Tool for Specifying and Monitoring the Exception Handling Policy. International Journal of Software Engineering and Knowledge Engineering (2016). Foram feitos dois estudos de casos: (i) estudo de caso realizado nos sistemas SIGs (SIGRH e SIGAA) onde foram validas duas abordagens: uma com testes de aceitação manuais e outra com testes de aceitação automatizados. Também foi avaliado uma aplicação mobile o SIGAA Mobile; (ii) estudo de caso realizado com o framework JUnit. Além dos estudos de caso foi feito um estudo para avaliar o impacto da ferramenta DAEH no desempenho da aplicações monitoradas.. 1.5. Organização do Documento. Este documento está organizado em mais 5 capítulos, além desse introdutório. O capítulo 2 apresenta a fundamentação teórica, descrevendo os conceitos essenciais relacionados com a verificação do comportamento excepcional e regras de design. O capítulo 3 apresenta o núcleo da dissertação, descrevendo a abordagem proposta, a linguagem e ferramenta desenvolvida. O capítulo 4 apresenta dois estudos de caso realizados através da aplicação da ferramenta em dois sistemas WEB de grande porte, incluindo um aplicativo mobile e em quatro versões do framework JUnit. O capítulo 5 apresenta os trabalhos relacionados com a pesquisa realizada nessa dissertação. Por fim o capítulo 6 apresenta as considerações finais..

(22) 21. 2. Fundamentação Teórica. O objetivo deste capítulo é apresentar uma fundamentação dos principais conceitos necessários para o entendimento do restante do trabalho. Inicialmente será apresentado o conceito de tratamento de exceções (Seção 2.1). Em seguida será abordado o conceito de análise dinâmica (Seção 2.2). Em seguida o conceito de programação orientada a aspectos (Seção 2.3). Será abordado também o conceito de regras de design na Seção 2.4. Por fim, é apresentando o framework Xtext para criação de DSL (Seção 2.5).. 2.1. Tratamento de Exceções. Um mecanismo de tratamento de exceções é composto por quatro conceitos principais (ou seja, a exceção, o sinalizador da exceção, o tratador da exceção e do modelo de exceção - que define como sinalizadores e os tratadores são ligados (GARCIA et al., 2001)) e dois conceitos de apoio (ou seja, os tipos de exceção e as interfaces de exceção) descritos a seguir. i. Exceção: uma exceção é gerada por um método quando um estado anormal é detectado. Em Java uma exceção é lançada usando a instrução throw (GOSLING, 2000). ii. Tratador de exceção: o tratador de exceção é o código chamado em resposta a uma exceção disparada. Ele pode ser ligado a regiões protegidas (por exemplo, métodos, classes e blocos de código) (GARCIA et al., 2001). Em Java o tratador é representado pelo bloco try-catch (GOSLING, 2000). iii. Modelo de exceção: em muitas linguagens, como em Java, a exceção até chegar ao tratador de exceções passa por uma sequência de invocações dinâmicas. Esta característica é necessária para aumentar a reutilização de software, uma vez que o solicitante de uma operação pode tratar a exceção em um contexto mais amplo (MILLER; TRIPATHI, 1997)..

(23) 22. iv. Interfaces de exceção: um chamador de um método precisa saber quais exceções podem atravessar a fronteira do método invocado. Desta forma, o chamador irá ser capaz de preparar o código previamente para as condições excepcionais que podem acontecer durante a execução do método invocado. Por esta razão, algumas linguagens fornecem construções para associar a assinatura de um método a uma lista de exceções que o método pode lançar. No entanto nem sempre é necessário realizar essas declarações (COELHO et al., 2008), por isso linguagens como Java oferecem meios para contornar esse mecanismo, isto é, conseguir disparar um tipo de exceção específico, chamada de exceção não verificada, que não requer qualquer declaração na assinatura do método. v. Tipos de exceção: linguagens orientadas a objeto geralmente suportam a classificação de tipos de exceções em hierarquias. A interface de exceção é, portanto, composta pelos tipos de exceção que podem ser lançadas por um método. Cada tratador está associado a um ou mais tipos de exceção, que especifica suas capacidades de tratamento de exceções - ou seja, quais exceções ele pode tratar. Em Java, as exceções são representadas de acordo com uma hierarquia de classes, em que cada exceção é uma instância da classe Throwable (GOSLING, 2000). Mecanismos de tratamentos de exceções estão embutidos em várias linguagens, facilitando assim o desenvolvimento de sistemas robustos. O foco desse trabalho será nos mecanismos de tratamento de exceções da linguagem JAVA.. 2.2. Análise Dinâmica. A análise dinâmica compreende um conjunto de técnicas que são caracterizada por envolverem a execução do programa e a observação do seu comportamento. A análise estática verifica o código fonte de um programa para extrair propriedades, já a análise dinâmica deriva propriedades de uma ou mais execuções do programa (geralmente através da instrumentação do programa) (LARUS; BALL, 1994). A análise dinâmica não pode provar uma propriedade específica, porém pode detectar violações de uma propriedade bem como fornecer informações úteis para os programadores sobre o comportamento dos seus programas. Análises estáticas e dinâmicas são técnicas complementares. A utilidade da análise dinâmica deriva de duas de suas características essenciais: i. Precisão da Informação: análise dinâmica envolve tipicamente a instrumentação.

(24) 23. do programa para examinar ou contabilizar certas propriedades de seu estado em tempo de execução. A instrumentação pode ser usada para coletar precisamente a informação necessária para resolver um problema particular, como por exemplo, um estado de uma pilha ao remover um elemento. ii. Dependência das entradas de um programa: a mesma característica que faz com que a análise dinâmica seja incompleta também fornece um mecanismo poderoso para relacionar as entradas e saídas de um programa (REPS et al., 1997). Com a análise dinâmica é simples e direto de relacionar mudanças nas entradas do programa com as mudanças internas do programa, bem com as mudanças nas saídas do programa, uma vez que todos são diretamente observáveis e ligados pela execução do programa. Aplicações de software modernas geralmente são muito complexas e possuem um grande número de propriedades funcionais e não funcionais. Diante disso o comportamento interno de sistemas de grande porte não podem facilmente ser determinado com base apenas no código fonte (CORNELISSEN et al., 2009) (LARUS; BALL, 1994). Além disso, a documentação desses projetos na maioria das vezes é pouca ou inexistente, o que dificulta a manutenção e alteração do sistema. Uma possível solução para esse cenário é realizar o monitoramento do sistema em tempo de execução, efetuando a coleta de dados sobre o comportamento do sistema e assim analisar os dados coletados para se chegar às falhas. As informações extraídas da análise dinâmica são dependentes do conjunto de execuções que são realizadas, ou seja, mesmo que cada execução seja representada fielmente, se parte importante do sistema não for executada/coberta por teste, essa parte não será analisada. O monitoramento da execução pode causar interferências na execução original do sistema, por exemplo, piorando seu desempenho durante a execução. Dependendo do tipo de análise, isso pode ser tão impactante a ponto de impossibilitar a instrumentação em determinadas fases de desenvolvimento (PINTO, 2015).. 2.3. Programação Orientada a Aspectos. A Programação Orientada a Aspectos é uma metodologia utilizada em conjunto com os paradigmas de programação orientado a objetos e procedural, que visa incrementá-los com conceitos e construções que permitam modularizar conceitos transversais do sistema (LADDAD, 2003). A Programação orientada a aspectos permite aos desenvolvedores e projetistas de.

(25) 24. software separarem e organizarem o código de interesse comum, como por exemplo, colocar as partes comuns de um sistema (conexão com banco de dados, logging, tratamento de exceções) encapsuladas em unidades de programação chamadas aspectos. A esses interesses comuns chamamos crosscutting concerns (interesses transversais).. 2.3.1. Aspectos. Um aspecto é a implementação de um interesse transversal (ELRAD; FILMAN; BADER, 2001) realizada de maneira independente da implementação dos requisitos centrais. Uma definição, mais informal, de aspectos em termos de programação orientada a objetos é (HIGHLEY et al., 1999): i. Um objeto é alguma coisa. ii. Um aspecto não é alguma coisa. Um aspecto é alguma coisa a respeito de alguma coisa. iii. Objetos não são dependentes de aspectos. 2.3.1.1. Pontos de junção. Pontos de junção são os locais no sistema que são afetados por interesses transversais (OSSHER; TARR, 1998). Eles representam a passagem por locais semanticamente bem definidos no sistema (ELRAD; FILMAN; BADER, 2001). Pontos de junção podem ser associados a operações do sistema, como passagem de mensagens entre objetos, chamadas de métodos, execução de sub-rotinas e tratamento de exceções. 2.3.1.2. Adendos. Em linguagens de programação orientadas a aspectos, adendos são construções de código que devem ser executadas quando determinados pontos de junção são alcançados. Em geral um adendo é uma construção semelhante a um método ou a uma sub-rotina, e que na ativação de um determinado ponto de junção (por exemplo, em uma chamada de método), será executada antes, depois, ou entorno dele..

(26) 25. 2.3.1.3. Combinação de Aspectos. Combinadores são usados para combinar componentes (o código principal do programa) e aspectos (a implementação dos interesses transversais) (ELRAD; FILMAN; BADER, 2001). Para que isso ocorra, é essencial que existam pontos de junção definidos. A combinação dos aspectos é o processo em que os componentes (programa principal) e os aspectos são integrados no sistema final. Esse processo é executado por um mecanismo denominado combinador (em inglês, weaver). A principal diferença entre os mecanismos de combinação está no momento em que é realizado. Nos mecanismos de combinação dinâmica (em inglês, dynamic weaving), ou seja em tempo de execução, a junção dos adendos aos componentes é realizada no momento da execução da aplicação. Isso pressupõe que a tecnologia utilizada fornece algum subsídio para a alteração em tempo de execução da estrutura de classes, e/ou um método para interceptar as mensagens inter e intra-objetos. Nesse caso, o combinador é capaz de fazer as modificações necessárias no programa principal em tempo de execução. Nos mecanismos de combinação estática (em inglês static weaving), ou seja em tempo de compilação, o combinador é um sistema transformativo que une os artefatos (em geral, código fonte ou código objeto) dos componentes e dos aspectos do sistema, gerando novos artefatos que serão usados para criar o sistema.. 2.3.2. AspectJ. AspectJ é uma linguagem de programação que pertence ao paradigma orientado a aspectos (LADDAD, 2003). É uma extensão para a linguagem de programação Java, por isso há uma preocupação pela compatibilidade entre as linguagens, assim dois conceitos são extremamente importantes e essências: todo programa Java válido é também um programa AspectJ válido; todo programa AspectJ pode ser executado em uma Java Virtual Machine (JVM). 2.3.2.1. Combinação de Aspectos. Tomemos como exemplo o caso de logging de uma aplicação, como mostrado no código abaixo na implementação de orientação a aspectos utilizando a linguagem AspectJ (ECLIPSE. . . , 2016a). Considere que um sistema deverá ter o logging de todas as operações realizadas na conta bancária, assim no código que realiza uma operação bancária seria necessário incluir manualmente código para armazenamento do logging, código este que não teria.

(27) 26. nenhuma relação com o objetivo da classe em que ele estaria sendo inserido. A este tipo de código chamamos de código entrelaçado. Agora imaginemos o quanto isso dificultaria a manutenção e evolução do sistema se houvesse uma quantidade grande de classes em que seria necessário fazer logging. A orientação a aspectos resolve esse problema e complementa a orientação a objetos com a criação de um aspecto para logging (exemplificado no código AspectJ da Figura 2) que encapsula a operação de logging e é ativado de acordo com uma regra indicada no aspecto (ativado em todas as operações bancárias). Vamos analisar melhor este código. O primeiro elemento que aparece é o pointcut (linhas de 7 a 8) - implementação do conceito de pontos de junção do Aspect - o pointcut define que toda execução dos métodos da classe Conta serão instrumentados. O segundo elemento do nosso aspecto é o advice (linhas de 10 a 12) - implementação do conceito de Adendos do Aspect. O advice define que após a execução do pointcut operacaoBancaria será executado um trecho de código, neste caso o trecho de logging. Dessa forma em apenas algumas linhas de código definimos um conceito transversal, evitando a replicação em diversas partes de código de logging. 1 2 3 4 5 6 7 8 9 10 11 12 13. package br . u f r n . a s p e c t s ; imports . . . public aspect Logging { pointcut o p e r a c a o B a n c a r i a ( ) : execution ( * br . u f r n . banco . Conta . * ( . . ) ) ; after ( ) : operacaoBancaria ( ) { Logger . l o g ( " Movimentação na c o n t a em " + dataAtual ) ; } }. Figura 2: Exemplo de código AspectJ.. 2.4. Regras de Design. A modularidade é um conceito que tem se mostrado útil ao ser usado em sistemas complexos. Duas ideias são derivadas do conceito geral de modularidade. O primeiro é a ideia de interdependência dentro de um módulo e o outro é de independência entres os módulos. Um módulo é uma unidade cujos elementos estruturais são fortemente ligados entre si e relativamente pouco ligados a elementos em outras unidades. Em outras palavras, os módulos são unidades de um sistema maior, que são.

(28) 27. estruturalmente independentes um do outro. O sistema como um todo, deve proporcionar uma estrutura que permita tanto a independência da estrutura e função de integração. A segunda ideia é proporcionar abstração, ocultação de informações e interfaces (BALDWIN; CLARK,. 2000). É reconhecido que um projeto com uma modularidade apropriada, pode. ter enorme valor técnico, organizacional e econômico. O conceito de modularidade aplicada ao desenvolvimento de software foi introduzido pela primeira vez por Parnas (PARNAS, 2002). A modularidade está intimamente relacionada a decisões de design que decompõem e organizam o sistema em um conjunto de módulos. Uma atividade comum a todo processo de software é o design do software. O design incorpora a descrição da estrutura do software, os dados que são manipulados pelo sistema, a descrição das interfaces entre os componentes do sistema, e algumas vezes o algoritmo utilizado (PETERS, 1981). Ele implementa importantes decisões sobre a arquitetura do software e possui um papel crucial no desenvolvimento, implantação e evolução do sistema (KRUCHTEN; LAGO; VLIET, 2006). Contudo, nem sempre a implementação reflete o design proposto. Isso acontece porque frequentemente a documentação que expressa o design é imprecisa e/ou obsoleta. Esta inconsistência entre o design documentado e a implementação tem sido apontada como uma das principais causas de baixa qualidade de software (PARNAS, 1994). Neste contexto, a verificação de conformidade entre o design e a implementação é uma prática que promove a qualidade do software. Neste sentido as regras de design (do inglês design rules) (BALDWIN; CLARK, 2000) especificam como as entidades de software devem ou não se relacionar com as demais. Essas regras definem contratos que devem ser rigidamente obedecidos em todas as fases posteriores do ciclo de vida do processo de construção do software. Dado um sistema com três módulos são eles módulo A, módulo B e módulo C podem existir as seguintes regras de design mostradas na Tabela 1. Essa tabela mostra as regras de design - dependências possíveis entre os módulos. As dependências que são aceitáveis são marcadas com ’X’, a leitura da tabela é feita na horizontal, ou seja a primeira linha da tabela define que o módulo A pode depender de todos os módulos..

(29) 28. Tabela 1: Exemplo de regras de design.. Módulo A. Módulo A. Módulo B. Módulo C. X. X. X. X. X. Módulo B Módulo C. 2.5. X. Xtext. Xtext (ECLIPSE. . . , 2016b) é um framework de suporte a desenvolvimento de linguagens, que podem ser de programação de propósito geral ou mesmo linguagens específicas de domínio (DSL). O framework funciona em ambiente Eclipse (ECLIPSE, 2016) e permite criar novas linguagens. Este framework permite que a definição da gramática de uma linguagem seja feita desde a criação de um metamodelo ou com base em metamodelo existente. Ao criar um projeto Xtext, o editor da gramática é apresentado, com as definições que podem ser editadas (no caso do projeto ter sido criado com base em um metamodelo existente) ou em branco. Nesse editor, definimos toda a sintaxe da linguagem, com suas regras e palavras reservadas. Definida a linguagem, o Xtext gera a infraestrutura da linguagem e o editor da linguagem já pode ser testado. A Figura 3 mostra a especificação da gramática da linguagem OlaMundo. grammar o r g . x t e x t . exemplo . olamundo . OlaMundo with o r g . e c l i p s e . x t e x t . common . Terminals 2 generate olaMundo " h t t p : / /www. x t e x t . o r g / exemplo / olamundo /OlaMundo " 1. 3 4 5. Modelo : s a u d a c o e s+=Saudacao * ; Saudacao : ’ Olá ’ name=ID ’ ! ’ ;. Figura 3: Especificação da gramática da linguagem OlaMundo. Na Figura 3, temos a definição de uma gramática exemplo que chamamos de ’OlaMundo’. As linhas 1 e 2 possuem a identificação da linguagem. Na linha de 4 é iniciada a definição da gramática, indicando o elemento raiz da gramática que é o elemento Modelo, que possui uma variável ’saudacoes’ que possui zero ou mais elementos de ’Saudacao’ (essa cardinalidade de zero ou mais é indicada pelo caractere *). Na linhas de 5 é definido o elemento ’Saudacao’ como sendo uma expressão que inicia com a palavra reservada Olá e.

(30) 29. logo em seguida possui uma texto de digitação livre e a expressão termina como o caractere ’!’. 1 2. Olá Mundo ! Olá DSL !. Figura 4: Editor da linguagem OlaMundo gerado pelo Xtext. A Figura 4 mostra o editor da linguagem OlaMundo, após a geração da infraestrutura da linguagem, com dois elementos ’Saudacao’: ’Olá Mundo’ e ’Olá DSL!’. O framework ainda permite traduzir a estrutura da linguagem para um XML, para facilitar a interpretação da linguagem por um aplicação que use uma linguagem definida através do Xtext..

(31) 30. 3. Análise Dinâmica do Tratamento de Exceções. O objetivo desse capítulo é apresentar a abordagem proposta e a estrutura da ferramenta desenvolvida neste trabalho que apoia a abordagem proposta, a DAEH (Dynamic Analysis of Exception Handling). Uma visão geral da abordagem proposta é apresentada na Seção 3.1. E na Seção 3.2 é apresentada a linguagem a ECL (Exception Contract Language). A Seção 3.3 mostra a ferramenta DAEH e a integração com a ECL.. 3.1. Visão Geral. Este trabalho propõe uma abordagem baseada em uma DSL e uma ferramenta de análise dinâmica para que os desenvolvedores definam e verifiquem o comportamento do tratamento de exceções de um sistema. Mais especificamente esta abordagem permite que o desenvolvedor crie regras de design para o fluxo excepcional e verifique se tais regras relacionadas com o código de tratamento de exceções são negligenciadas durante a execução do aplicativo. Para apoiar a abordagem proposta foi desenvolvida uma linguagem para definição de regras de design a Exception Contract Language (ECL) e para realizar a verificação das regras foi desenvolvida a ferramenta DAEH (Dynamic Analysis of Exception Handling).. 3.2. A Linguagem ECL. Foi desenvolvida uma linguagem específica de domínio que permite a definição de regras para verificação do fluxo excepcional, essa linguagem é chamada de ECL (Exception Contract Language). Assim, o objetivo principal da linguagem é possibilitar a criação de regras de design referentes ao tratamento de exceções que denominamos nesse trabalho de contratos..

(32) 31. 3.2.1. Criação da Linguagem. A gramática completa da linguagem ECL na notação BNF (Backus-Nahur Form) (SUDKAMP; COTTERMAN, 1988) é apresentada na Figura 5. Na versão da BNF utilizada, símbolos terminais são grafados em negrito e símbolos não terminais iniciam-se com maiúsculas. Além disso, A indica zero ou mais repetições de A e [A] indica que A é opcional. Com o intuito de simplificar o entendimento da gramática, foi ocultado a definição da variável ModID que representa os elementos terminais comuns que são cadeias de caracteres literais que não podem ser quebrados em unidades menores. S : Rule Rule : ehrule { type = ContractType , s i g n a l e r = NameSignaler , ExceptionAndHandlers = { L i s t E x c e p t i o n H a n d l e r } } ContractType : f u l l | p a r t i a l NameSignaler : NameWithWildcard | * ListExceptionHandler : ExceptionHandler { , ExceptionHandler } E x c e p t i o n H a n d l e r : exception = NameExption handler = [ L i s t H a n d l e r ] NameExption : QualifiedName | QualifiedName+ L i s t H a n d l e r : NameWithWildcard { , NameWithWildcard } NameWithWildcard : QualifiedName | QualifiedName+ | QualifiedName * | QualifiedName ( . . ) QualifiedName : ModID { . ModID}. Figura 5: Exception Contract Language (ECL) na notação Backus-Naur Form.. A linguagem foi criada utilizando o framework Xtext. No Anexo A está o código Xtext de criação da ECL..

(33) 32. 3.2.2. Elementos da ECL. A seguir, são descritos os elementos que compõem a ECL. i. ehrule: é o elemento inicial para a criação das regras na ECL, representa uma regra. ii. signaler: esse elemento representa um método ou pacote responsável por lançar, através de criação ou propagação, um ou mais tipos de exceção. iii. type: indica o tipo do contrato se é full ou partial. Em um contrato do tipo full todas as exceções que podem ser sinalizadas por um módulo (signaler) devem ser especificadas, caso contrário, se um tipo de exceção não especificada for sinalizada por esse módulo é considerada uma violação. Já um contrato do tipo partial indica que foi definido apenas um subconjunto de todas as exceções que podem ser sinalizadas por um módulo, e assim a sinalização pelo módulo de uma exceção não especificada não é considerada uma violação. iv. exception: identifica os tipos de exceções lançadas pelo signaler. v. handler: esse elemento representa um método, conjunto de métodos ou pacote que irá realizar o tratamento dos tipos de exceções definidas para serem lançadas pelo signaler; vi. exceptionAndHandlers: esse elemento é responsável por definir para um signaler uma tupla composta por uma exception e um handler. Dessa forma é possível definir em uma regra para um mesmo signaler mais de uma combinação exception/handler. Na Figura 6 é mostrado um exemplo de criação de contrato usando a ECL. Como pode ser observada, a linguagem suporta o wildcard ’*’ que é usado para indicar qualquer método de uma classe. Pode ser utilizado também o wildcard ’+’ no elemento exception ou no elemento handler para representar herança. No caso do exemplo está indicando que qualquer classe filha de Servlet pode tratar a exceção DAOException, desde que sinalizada pela classe DAO. Alguns elementos da linguagem como os wildcard foram baseados nas implementações existentes na linguagem AspectJ..

(34) 33 1. ehrule {. 2. type = f u l l. 3. s i g n a l e r = DAO. *. 4. exceptionAndHandlers = {. 5. [ exception = DAOException. 6. }. 7. handler = [ S e r v l e t +] ]. }. Figura 6: Criação de contrato com a ECL.. 3.3. Ferramenta DAEH. A ferramenta DAEH (Dynamic Analysis of Exception Handling) é responsável por analisar os programas e enviar as violações a um servidor central, este é responsável por receber todas as notificações das análises e armazená-las. As violações armazenadas podem ser consumidas por outras aplicações que podem construir dashboard ou realizar mineração dos dados. A ferramenta DAEH é um programa que é incorporado à aplicação que se deseja monitorar, ele realiza a verificação do fluxo excepcional. A incorporação da ferramenta a aplicação é feita através de aspectos, utilizando o processo de load-time weaving, que realiza a instrumentação da aplicação com os aspectos da ferramenta, isso é realizado quando as classes da aplicação vão ser carregadas na Java Virtual Machine, usando o processo (dynamic weaving) do AspectJ, não necessitando assim do código fonte da aplicação. Foi escolhido o processo de incorporação dos aspectos em tempo de execução ao invés de em tempo de carga, pois assim não é preciso do código fonte da aplicação, sendo necessário apenas o código compilado para a DAEH realizar a instrumentação e monitoramento. A Figura 7 mostra uma visão geral da ferramenta DAEH.. Figura 7: Visão geral da DAEH..

(35) 34. Todas as capturas de exceções dentro do contexto da aplicação analisada são interceptadas (sejam elas subclasses de Throwable, Exception ou RuntimeException). Quando uma exceção é interceptada por um aspecto, então é chamado um controlador que irá ser responsável por verificar se o fluxo excepcional está obedecendo às regras arquiteturais. Caso a ferramenta identifique que o fluxo excepcional não atende as regras de design, previamente definidas, então é repassada a violação para o módulo de comunicação que será responsável por tratar os dados e enviar as informações para o servidor da DAEH. A definição das regras de design excepcionais é essencial, visto que estas regras é que deverão ser obedecidas durante o desenvolvimento e manutenção do software. Além disso, as regras de design são muito úteis como uma forma de documentação complementar do sistema. Este tipo de regra de design pode ser definido em dois momentos no ciclo de desenvolvimento: i. Antes do início do desenvolvimento: Quando isso acontece às regras podem ser extraídas de documentos e modelos que definem a arquitetura, do conhecimento do arquiteto de como o sistema irá funcionar, das próprias especificações de requisitos do sistema e também de anti-padrões de tratamento de exceções e de padrões de bugs. ii. Estabelecidas ou evoluídas após o início do desenvolvimento: Nestes casos a variedade de fontes é maior. Além das fontes citadas anteriormente podemos nos valer de uma análise do código-fonte e dos relatórios de bugs e logs de exceção do sistema.. 3.3.1. Fluxo de Funcionamento. O Fluxo de trabalho da DAEH pode ser visto na Figura 8 e é composto por 5 passos..

(36) 35. Figura 8: Passos para utilização da DAEH.. i. Definição de regras de design: nessa etapa o arquiteto do sistema vai realizar um levantamento das regras referentes ao tratamento de exceções. ii. Escrita das regras na linguagem ECL: as regras definidas na primeira etapa serão escritas na linguagem ECL utilizando o ambiente Eclipse. iii. Inserção das regras na DAEH: nessa etapa as regras definidas serão fornecidas a ferramenta DAEH para que ela possa verificar as regras. iv. Executar/Testar o programa: o sistema monitorado será exercitado a fim de exercitar os fluxos excepcionais. v. Analisar as violações: as violações serão analisadas pelo arquiteto do sistema. Com base nessa análise poderá realizar mudanças e refinar as regras definidas no primeiro passo (i)..

(37) 36. 3.3.2. Paralelização na Verificação de Regras. Como foi mencionada na fundamentação teórica, a análise dinâmica pode interferir na execução original do sistema, podendo causar uma piora de desempenho. As aplicações, principalmente os sistemas corporativos, são multiusuários e possuem um grande número de fluxos possíveis. Diante dessas duas premissas, foi paralelizada a verificação das regras na DAEH. Esse mecanismo possibilita que caso tenha uma sobrecarga grande de requisições para verificação de regras na DAEH, ela possa realizar a checagem das regras de forma paralela, não gerando assim fila de espera para que as regras sejam verificadas. Para cada pedido de verificação é aberta uma nova Thread e esta é encarregada de realizar a verificação da regra. Como mecanismo de segurança o número máximo de Threads em execução é definido em um arquivo de configuração da DAEH, para evitar que seja aberto um grande número de Threads, o que poderia comprometer o funcionamento da máquina.. 3.3.3. Arquitetura da Ferramenta DAEH. A ferramenta DAEH é constituída pelos seguintes pacotes: aspectos; controladores; exceções; classes utilitárias; entidades; comunicação; threads. A Figura 9 mostra o diagrama de classes da ferramenta DAEH separado por pacote. Cada pacote será discutido abaixo bem como o processo de leitura e verificação das regras de design..

(38) 37. Figura 9: Diagrama de classes da ferramenta DAEH.. Pacote de Aspectos O pacote de aspectos (aspects) contém um único aspecto chamado ContractCheckingAspect. Esse aspecto é responsável por interceptar todas as capturas de exceções (sejam elas subclasses de Throwable, Exception ou RunTimeException) dentro de métodos da aplicação que está sendo verificada. Quando uma exceção é capturada, esse aspecto chama o ManagerThreads (pacote de threads) para criar uma Thread que irá verificar se existe alguma regra para a exceção capturada e, caso exista, se a regra foi quebrada. Parte do código do aspecto ContractCheckingAspect é mostrado na Figura 10. É definido um advice que inicia a verificação das regras de design antes da execução dos locais a serem instrumentados indicados pelo pointcut exceptionHandling. O pointcut exceptionHandling define os locais a serem instrumetados, que no caso serão os pontos que ocorrem tratamento de exceções(handler) - exceto as classes da própria DAEH..

(39) 38 1. public aspect C o n t r a c t C h e c k i n g A s p e c t {. 2 3. pointcut e x c e p t i o n H a n d l i n g ( Throwable e x c e p t i o n ) :. 4. ( handler ( Throwable+) ). 5. && ! within ( C o n t r a c t C h e c k i n g A s p e c t ). 6. && ! cflow ( execution ( * daeh . e n t i t i e s . C o n t r a c t . * ( . . ) ) ). 7. && ! cflow ( execution ( * daeh . c o n t r o l l e r . C o n t r a c t C t l . * ( . . ) ) ). 8. && args ( e x c e p t i o n ) ;. 9 10. before ( Throwable e ) : e x c e p t i o n H a n d l i n g ( e ) {. 11. StaticPart jp = thisEnclosingJoinPointStaticPart ;. 12. Signature handlerSignature = jp . getSignature () ;. 13. contractController . verifyContract (e , handlerSignature ) ;. 14. }. 15 16. //.... 17. }. Figura 10: Trecho de código do aspect ContractChecking.. A indicação de quais pacotes e/ou classes devem ser instrumentados é feita no arquivo aop.xml, para mais informações de onde fica localizado esse arquivo e como configurar, consultar o Anexo B. Pacote de Threads O pacote de threads contém duas classes uma chamada de ManagerThreads, responsável por gerenciar a criação das threads e outra chamada de CheckRuleRunnable, que é um segmento de thread responsável por realizar a verificação das regras. Pacote de Controladores O pacote de controladores contém uma classe chamada ContractController. O objetivo desta classe é orquestrar todas as verificações de regras de design realizadas pelo aspecto que verifica os contratos, assim como outras verificações que possam vir a ser realizadas por outros pacotes em possíveis extensões da ferramenta. É também responsabilidade deste controlador gerenciar o acesso às entidades que representam as regras de design, como signalers e handlers, por exemplo. Pacote de Entidades Esse pacote abriga as classes de entidade que representam os conceitos da ferramenta..

(40) 39. A seguir descrevemos cada uma dessas classes: i. Contract: Representa o contrato que descreve as regras de design; possui uma lista de itens de contrato (ContractItem); ii. ContractItem: Representa um item do contrato. Um item do contrato é formado por um Signaler e uma lista de ExceptionTargets; iii. ContractType: Representa o tipo do contrato se é partial ou full; iv. Signaler: Representa um método que lança uma exceção; v. Handler: Representa um método que é responsável por capturar uma exceção; vi. ExceptionTarget: Representa uma tupla formada por uma Exception definida no contrato e um conjunto de Handlers associados, isso porque uma mesma exceção pode ser capturada por vários handlers; vii. MethodExpression: Classe abstrata que representa uma expressão de método, permitindo inclusive o uso de wildcards, de forma semelhante aos pointcuts AspectJ. As classes Signaler e Handler herdam desta classe abstrata. Pacote de Comunicação Esse pacote contém a classe ComunicationServer. Essa classe é responsável por enviar as informações das notificações ao servidor DAEH via protocolo HTTP. Essa classe faz uso de uma biblioteca de comunicação fornecida pelo servidor DAEH, a biblioteca monitor-commons, que já possui todos os mecanismos para comunicação com o servidor DAEH. Pacote de Exceções Esse pacote contém a exceção ContractCheckingException que tem papel chave dentro da ferramenta. É ela que assinala quando um teste de fluxo excepcional falhou. Quando isso ocorre, a exceção fornece na sua mensagem a informação sobre qual exceção foi lançada, qual método definido na regra de design deveria ter feito o tratamento e qual o método que efetivamente realizou o tratamento. Pacote de Classes Utilitárias Esse pacote contém quatro classes utilitárias. LocationJar: possibilita identificar o local de instalação da ferramenta DAEH, isso é importante, por exemplo, para localizar a.

(41) 40. pasta de configuração da DAEH. ContractUtilXML: responsável por realizar a leitura e interpretação de um arquivo XML que contem as regras. MacAddressUtil: responsável por obter o endereço MAC do computador, esse endereço será incorporado nas violações das regras de design enviadas ao servidor da DAEH. PropertiesDAEH: gerencia as propriedades de configuração. Verificação da Regra de Design Quando uma aplicação está configurada para usar a ferramenta DAEH e a aplicação é iniciada, então o aspecto de checagem inicializa o controlador e os contratos são lidos como mostra o diagrama de sequência da Figura 11.. Figura 11: Diagrama de sequência apresentando a inicialização da ferramenta DAEH.. Quando uma exceção é capturada, o aspecto entra em ação. Como mostra a Figura 12 o aspecto aciona o ManagerThreads para que seja criada um segmento de Thread (CheckRuleRunnable) que é responsável por invocar o controller para que este verifique os contratos, para isso é realizado uma análise do stack trace da exceção. O controller por sua vez repassa a responsabilidade para a própria entidade de contrato, para verificar se nenhuma regra foi quebrada. Caso alguma regra seja violada a entidade Contract repassa a responsabilidade para o ComunicationServer que fica encarregado de enviar a notificação de violação de contrato ao servidor DAEH..

(42) 41. Figura 12: Diagrama de sequência apresentando as classes envolvidas na verificação das regras de design.. 3.3.4. Servidor DAEH. O servidor DAEH é um serviço que roda na nuvem e que disponibiliza Web Services para inserção e consulta de notificações. Sua estrutura foi elaborada de forma a ser possível receber informações tanto de computadores como de dispositivos móveis, a ferramenta DAEH desenvolvida nesse trabalho só roda na JVM, porém em um trabalho de graduação do grupo de pesquisa LETS foi desenvolvido um monitor para a plataforma Android (MEDEIROS, 2015). O servidor DAEH possui a entidade Aplication, que representa todas as aplicações que estão sendo monitoradas, isso indica que o servidor DAEH pode receber notificações de mais de uma aplicação, e as notificações são identificadas com base na chave de cada ferramenta DAEH enviada juntamente com as notificações. O servidor também foi preparado para o envio de logs de forma livre pelo desenvolvedor, ou seja, o desenvolvedor pode importar a ferramenta DAEH em sua aplicação e enviar logs que deseja que sejam armazenados no servidor. A entidade Event representa as notificações de violações de regras de design que podem ter especificação de EventDevice (evento vindo de um dispositivo móvel) ou EventHost (evento vindo de um computador). As informações do computador e do dispositivo móvel são salvas, sendo representadas respectivamente pelas entidades DeviceInformation e HostInformation..

(43) 42. 4. Estudos de Caso. Este capítulo descreve a aplicação da ferramenta DAEH e da linguagem ECL em dois sistemas reais de grande porte, o SIGRH (Sistema Integrado de Gerenciamento de Recursos Humanos) e o SIGAA (Sistema Integrado de Gestão de Atividades Acadêmicas), que são utilizados pela Universidade Federal do Rio Grande do Norte (UFRN) dentre outras universidades federais para o gerenciamento dos funcionários e gerenciamento das atividades acadêmicas respectivamente. A DAEH também foi aplicada a quatro versões do framework JUnit. Este capítulo está organizado nas seguintes subseções. A Seção 4.1 apresenta o estudo de caso para os sistemas SIGRH e SIGAA, que são da mesma família de sistemas chamada SIG, e para o aplicativo SIGAA Mobile. A Seção 4.2 apresenta o estudo de caso para o framework JUnit. A Seção 4.3 apresenta um estudo que avalia o impacto da ferramenta DAEH no desempenho das aplicações monitoradas.. 4.1. Sistemas Integrados de Gestão (SIGs). Os SIGs são um conjunto de sistemas integrados que informatizam diversos procedimentos da UFRN como atividades acadêmicas, recursos humanos e administração. Foram escolhidos dois sistemas da família de sistemas SIG para ser alvo deste estudo de caso, são eles SIGRH e SIGAA. O SIGRH é um sistema de gerenciamento de recursos humanos utilizado pela UFRN para gestão de seus servidores. O sistema informatiza procedimentos como marcação/alteração de férias, cálculos de aposentadoria, avaliação funcional, dimensionamento de força de trabalho, controle de frequência, concursos, capacitações dentro outros. O SIGAA é um sistema de gestão das atividades acadêmicas utilizado pela UFRN.O sistema informatiza os procedimentos da área acadêmica abrangendo os níveis de ensino pós-graduação, graduação, ensino técnico e infantil. Esta Seção está organizada como descrito a seguir. A subseção 4.1.1 apresenta os.

(44) 43. objetivos do estudo de caso. A subseção 4.1.2 apresenta a arquitetura dos sistemas SIGs. A subseção 4.1.3 descreve a metodologia aplicada no estudo de caso. A subseção 4.1.4 define as regras de design excepcionais para as aplicações escolhidas. A subseção 4.1.5 apresenta os resultados da aplicação da ferramenta DAEH. Por fim a subseção 4.2.5 avalia os resultados de acordo com os objetivos traçados.. 4.1.1. Objetivo. O objetivo desse estudo de caso é avaliar se a ferramenta DAEH e a linguagem ECL oferecem atributos de aplicabilidade e eficiência necessários para a verificação e definição de regras referentes ao tratamento de exceções pelos arquitetos de softwares dos Sistemas de Integrados de Gestão da UFRN. Algumas questões foram traçadas com o intuito de avaliar o objetivo, as questões definidas são: i. A linguagem ECL permitiu definir todas as regras referentes ao tratamento de exceção? ii. Os arquitetos de software entenderam a linguagem e a ferramenta bem como a necessidade da abordagem proposta para o desenvolvimento de software? iii. Com a ferramenta foi possível identificar violações de regras de design referente ao tratamento de exceção?. 4.1.2. Arquitetura dos SIGs. A arquitetura dos sistemas SIGs segue o padrão arquitetural MVC (Model-ViewController) (FOWLER, 2002) conforme ilustrado na Figura 13. A camada de modelo contém Objetos de Negócio (Business Objects), Objetos de Transferência de Dados (Data Transfer Objects ou DTO) e Objetos de Acesso a Dados (Data Access Objects ou DAOs). Nos Objetos de Negócio é onde ficam localizadas as regras de negócios. Os DTOs representam as entidades de domínio, tais como servidores, férias, progressão, etc. Já os DAOs fornecem uma interface para acesso ao framework de persistência de dados, nos SIGs é utilizado para persistência objeto/relacional o framework Hibernate. A camada de controle é responsável por receber os dados da Visão, manipular o Modelo e atualizar a Visão. Nos sistemas SIGs, o framework JSF é utilizado na camada de Controle.

(45) 44. Figura 13: Arquitetura dos sistemas da família SIG. para manipular as requisições HTTP. A camada de Visão é composta por Java Server Pages (JSP). Os sistemas SIGs são sistemas bastante complexos como pode ser observado nas métricas da Tabela 2. Possui vários fluxos excepcionais como pode ser observado na Tabela 2 pela quantidade de blocos catch e número de declarações de throw. Além de não possuir seus fluxos excepcionais documentados, sendo assim um bom estudo de caso, pois nos permite validar a abordagem desde o levantamento das regras de design até o monitoramento da aplicação através da ferramenta DAEH..