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.

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 sub- classes 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.

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 S t a t i c P a r t j p = t h i s E n c l o s i n g J o i n P o i n t S t a t i c P a r t ; 12 S i g n a t u r e h a n d l e r S i g n a t u r e = j p . g e t S i g n a t u r e ( ) ; 13 c o n t r a c t C o n t r o l l e r . v e r i f y C o n t r a c t ( e , h a n d l e r S i g n a t u r e ) ; 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

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, per- mitindo 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

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.

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.