Esta Seção descreve os trabalhos relacionados à verificação de conformidade das regras de design. Esses trabalhos foram selecionados, devido possuírem abordagens semelhantes à proposta deste trabalho. A ideia é descrever cada trabalho e conduzir uma discussão comparativa em relação à abordagem proposta.
A abordagem proposta por (SALES; COELHO, 2011) implementada na ferramenta VIT- TAE propõe uma técnica focada na verificação das regras do comportamento excepcional integrada ao JUnit e facilmente consegue verificar exceções interceptadas de forma errada, que era um problema dos testes normais usando JUnit. Porém essa abordagem possui a geração de casos de testes de integração feitos de forma manual o que inviabiliza em muitos casos o seu uso, devido ao grande esforço necessário para a criação dos casos de teste. Além de ser difícil exercitar exceções que percorrem várias classes/pacotes utilizando testes unitários. Outra limitação dessa abordagem é que as regras são definidas utilizando XML o que não dificulta a criação das regras, visto que é uma linguagem de propósito geral e não uma linguagem especifica para definir fluxos excepcionais.
A JavaMOP é um framework de monitoramento específico para programas Java (JIN et al., 2012). JavaMOP permite a definição de propriedades baseadas em eventos e gera código AspectJ para realizar o monitoramento. Este código é tecido no programa alvo em tempo de compilação. Quando uma especificação é validada ou violada pelo usuário, ações são executadas. Essas ações podem ser qualquer código Java, como por exemplo, logging ou recuperação em tempo de execução. Nossa abordagem difere da JavaMOP, pois a nossa abordagem é para especificar, monitorar e checar as regras de design do tratamento de exceções. A sintaxe da ECL é mais simples do que é necessário especificar as propriedades da JavaMOP e há uma ação disponível na nossa abordagem (enviar informações de violação ao servidor).
Terra e Valente (TERRA; VALENTE, 2009) propuseram um sistema de verificação estática de arquitetura. A ideia baseia-se na criação de uma linguagem de restrição de
dependência para a especificação de dependências aceitáveis e inaceitáveis de acordo com a arquitetura do sistema. Depois de especificadas, as restrições são checadas automaticamente através de uma ferramenta intitulada DCL Check, que automaticamente detecta pontos de código fonte que violam as restrições arquiteturais especificadas. A abordagem proposta por Terra e Valente faz a verificação de regras de design em tempo de compilação, além disso, não possui mecanismos para a verificação de exceções tratadas indevidamente, ou seja, uma classe A lança uma exceção X e quem deveria tratar essa exceção seria uma classe C, mas quem trata é uma classe B. A abordagem proposta nesse trabalho pode ser usado de forma complementar a abordagem proposta por Terra e Valente.
Para realizar a verificação das regras de design Brunet e Guerrero propuseram uma técnica baseada em testes, intitulada de teste de design, para dar apoio às tarefas de verificação de conformidade. A abordagem contempla um mecanismo de especificação de regras de design e uma técnica de checagem de violações dessas regras na implementação do software (BRUNET; GUERRERO; FIGUEIREDO, 2009). As regras de design são escritas como teste de software na mesma linguagem de programação da aplicação analisada, utilizando o framework JUnit, facilitando assim sua adoção. Como prova de conceito foi desenvolvida a ferramenta DesingWizard que implementa esse conceito. A abordagem de teste de design é utilizada em tempo de compilação, fazendo uso da análise estática o que te impõe às limitações das abordagens de análise estática.
A linguagem TamDera (GURGEL et al., 2014) possui duas características: suporte a especificação e definição de regras para a erosão e deriva (drift) arquitetural; suporte a hierarquia e reutilização de regras, por exemplo, TamDera permite que os arquitetos definam regras abstratas anti-degradação que por meio de herança são mais tarde especializadas em projetos concretos. A linguagem foi projetada para apoiar a descoberta de sintomas de degradações arquiteturais no código fonte. Essa descoberta baseia-se na análise estática para extrair dependências estruturais dos módulos da aplicação. Uma erosão está ligada a quebra de uma regra arquitetural como, por exemplo, a política de dependência entre pacotes, já um sintoma de deriva (drift) está ligada a métricas estruturais, como por exemplo, uma grande quantidade de linhas de código de uma classe, pode indicar que ela possui responsabilidades de mais e pode ser quebrada em outras classes. Erosão e deriva são sintomas que tendem a ser interligados. Sintomas de deriva (drift) costumam promover a introdução posterior de sintomas de erosão e vice-versa.
A linguagem EPL (Exception Handling Policies Language) (BARBOSA et al., ) tem como objetivo verificar as políticas de tratamento de exceções em Java de forma estática.
A linguagem suporta relações de dependência, manuseio, propagação e relançamento de exceções, possibilitando assim cobrir todas as dependências estruturais entre os elementos de código fonte e tipos comuns de exceções em linguagens de programação.
A linguagem DCL Check tem como objetivo verificar as restrições de dependência da arquitetura que corresponde ao conceito de erosão arquitetural na linguagem TamDera, está última por sua vez também permite definir regras para extrair propriedades estruturais a fim de evitar sintomas de deriva (drift), existem também diferenças quanto ao poder de expressão entre as linguagens. Já a DesignWizard também propõe verificar as regras de design (restrições de dependência) só que a criação das regras é feita usando a própria linguagem de desenvolvimento. As três oferecem indiretamente formas de verificar alguns casos de tratamento de exceções (como exemplo, especificar que uma exceção X só pode ser tratada por uma classe Y), porém realizam essa análise de forma estática, e assim não conseguem verificar com exatidão a política de tratamento de exceções, apontando assim falso-positivos. Já a linguagem EPL é específica para criar regras para verificar a política tratamento de exceções só que de forma estática.
Tabela 13: Comparativo da ECL com outras técnicas.
VITTAE JavaMOP DCL TamDera DesignWizard EPL ECL
REQ1 3 3 7 7 7 7 3 REQ2 3 7 7 7 7 7 7 REQ3 7 7 3 3 3 3 7 REQ4 3 7 3 7 7 3 3 REQ5 3 7 7 7 7 3 3 REQ6 3 7 7 7 7 3 3 REQ7 7 3 3 3 7 3 3 REQ8 3 7 7 7 7 3 3
Atendido:3 Não Atendido:7
A Tabela 13 mostra uma comparação entre as características das ferramentas que possuem relação com esse trabalho. A seguinte lista de características foi utilizada na comparação das ferramentas:
∙ REQ1: Utiliza análise dinâmica.
∙ REQ2: Necessita de testes.
∙ REQ4: Possibilita indicar as exceções sinalizadas.
∙ REQ5: Possibilita indicar as exceções capturadas.
∙ REQ6: Possibilita definir em qual local o tratamento de uma dada exceção deve ocorrer.
∙ REQ7: Possui uma linguagem própria.
∙ REQ8: Abordagem específica para o tratamento de exceções.
Como podemos ver na Tabela 13, quando comparamos a ECL/DAEH com relação às demais ferramentas, vemos que ela é a única que oferece uma linguagem específica que permite definir regras de tratamento e checar estas regras dinamicamente. O fato da ECL/DAEH utilizar análise dinâmica limita a análise aos fluxos excepcionais exercitados. Esta limitação não é enfrentada por abordagens baseadas em análise estática por não haver a necessidade de executar a aplicação. Porém devido a limitações inerentes de abordagens de analise estática, e características das linguagens modernas (e.g., herança, polimorfismo e chamadas virtuais) ferramentas baseadas em analise estática podem reportar muitos falsos positivos.