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.

1 ehrule {

2 type = f u l l

3 s i g n a l e r = DAO. *

4 exceptionAndHandlers = {

5 [ exception = DAOException handler = [ S e r v l e t +] ]

6 }

7 }

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.

Todas as capturas de exceções dentro do contexto da aplicação analisada são intercep- tadas (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

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).