Checagem das Regras

O processo de Checagem das Regras é um processo automático de identificação das regras violadas e das respectivas causas a partir da especificação das regras da política. Como resultado, este processo produz (i) uma representação textual das regras que são violadas e as respectivas causas, e (ii) uma representação gráfica das dependências dos agrupamentos com informações que indicam a ocorrência de violações. Como citado anteriormente, as regras da atual implementação da abordagem proposta são baseadas na especificação da linguagem definida em [BARBOSA et al, 2016], ou seja, as regras definem restrições locais (i.e., nos métodos sinalizadores, propagadores ou tratadores). Como consequência, o processo de Checagem das Regras indica as causas das violações no método sinalizador ou no método tratador e não no fluxo

excepcional. Por exemplo, seja DAO must raise IOException uma regra da política, um possível resultado do processo de Checagem das Regras poderia ser app.dao.selectAll() throws FileNotFoundException, indicando que o método app.dao.selectAll() possui alguma instrução throw sinalizando Exception no seu contexto.

Portanto, os fluxos excepcionais que violam uma regra são identificados a partir da causa, para isso, consultas na base de dados que armazenam os fluxos excepcionais são necessárias.

Ao final da fase de Refinamento da Política de Tratamento de Exceções, uma representação textual composta pela especificação das regras é definida. O componente

Exception Rule Checker analisa este arquivo que contém a especificação e envia as

informações sobre as regras para a memória de acordo com o diagrama apresentado na Figura 18. Para ilustrar a representação em memória das regras definidas, a Figura 18 apresenta o diagrama de objetos da regra MEDIAACCESSOR may only handle NullAlbumDataException que pertence à política de tratamento do MobileMedia.

Figura 18: Diagrama de objetos de uma regra do MobileMedia.

Nesta figura, o objeto DRRule contém as informações do agrupamento (i.e., MEDIAACCESSOR) e da exceção relacionada (i.e., NullAlbumDataException), e dos objetos RuleType e DependencyType que contém as informações sobre o operador (i.e., MAYONLY) e a dependência (i.e., HANDLES), respectivamente.

Após enviar as regras da política para a memória, o componente Exception Rules

Checker identifica as regras violadas e as respectivas causas. O diagrama de classes da

Figura 19 apresenta as classes que descrevem as informações das regras violadas e das respectivas causas. Nesta figura, DRViolation é a classe responsável por associar as regras, representadas pela classe DRRule, aos elementos que causam as violações. Como citado na Seção 3.2.2 sobre o processo de Checagem das Regras, a causa de uma violação é um conjunto de métodos sinalizadores (i.e., classe EASignaler) ou um conjunto de métodos tratadores (i.e., classe EAHandler).

Figura 19: Diagrama de classes das violações e as respectivas causas.

Similarmente ao processo de Extração das Regras de Tratamento, o processo de

Checagem das Regras produz uma representação textual e uma representação gráfica que

indicam as regras violadas e as respectivas causas.

A Figura 20 apresenta a representação textual resultante das violações das regras do MobileMedia. Essa representação é formada por duas seções: Violation Index e

Violation Table. A seção Violation Index contém a lista de regras violadas onde cada item

é um link para a parte correspondente à regra violada na seção Violation Table que exibe a lista dos métodos (i.e., sinalizadores ou tratadores) responsáveis pelas violações. No exemplo apresentado na Figura 20, as regras SCREEN cannot raise * e MEDIAACCESSOR may only handle NullAlbumDataException foram violadas. A regra SCREEN cannot raise * indica que o agrupamento SCREEN não pode sinalizar qualquer exceção, entretanto, o método CaptureVideoScreen(..) que pertence a este agrupamento sinaliza a exceção Exception, como indicado na parte correspondente na seção Violation

Table. Como causas para a violação da regra MEDIAACCESSOR may only handle NullAlbumDataException, foram identificados dois métodos pertencentes ao agrupamento MEDIAACCESSOR que capturam ImageNotFoundException, os quais são: MusicMediaAccessor.resetRecordStore() e VideoMediaAccessor.resetRecordStore().

Figura 20: Representação textual resultante do processo de checagem das regras da política de tratamento do MobileMedia.

Para complementar a representação textual, o processo de Checagem das Regras produz uma representação gráfica. A Figura 21 exibe a representação gráfica das causas das violações das regras da política de tratamento do MobileMedia. Observe que essa representação gráfica é similar à representação gráfica produzida pelo processo de

Extração das Regras que foi exemplificada na Figura 16. Adicionalmente, a

representação gráfica resultante do processo de Checagem das Regras possui indicações dos elementos envolvidos nas violações. Quando existe uma violação, a borda do agrupamento que contém o método responsável pela violação é desenhada com a cor vermelha e um “x” é inserido na aresta, indicando se a causa é devido a existência ou ausência de sinalização (“x” na origem da aresta) ou de captura de exceções (“x” no destino da aresta).

Figura 21: Representação gráfica das interações entre os agrupamentos contendo informações sobre as causas das violações das regras da política de tratamento do

MobileMedia.

Como pode-se observar na Figura 21 , existe um “x” na origem da aresta que liga o agrupamento SCREEN ao agrupamento ENTRYPOINTS, ou seja, existe algum método no agrupamento SCREEN que é a causa da violação de alguma regra da política de tratamento do MobileMedia.

3.6. Resumo

Neste capítulo descrevemos os processos e os componentes que implementam a abordagem proposta, detalhando os objetivos, a arquitetura dos componentes, os recursos de entrada e de saída, e o fluxo entre os processos e os componentes. O principal objetivo deste capítulo foi descrever os aspectos conceituais em conjunto com a ferramenta desenvolvida que suporta a abordagem proposta.

A abordagem é dividida em 3 processos: (a) Extração das Regras de Tratamento

de Exceções, (b) Refinamento da Política de Tratamento de Exceções, e (c) Checagem das Regras de Tratamento de Exceções. A abordagem é iniciada com o processo de Extração das Regras de Tratamento de Exceções, seguido pelo processo de Refinamento da Política de Tratamento de Exceções, e, finalmente, a Checagem das Regras. Para

fornecer suporte a execução da abordagem, a ferramenta desenvolvida para este trabalho é composta por 4 componentes: Exception Flow Revealer, Handler Action Analyzer,

Rules Extractor e Rules Checker. Esses componentes foram implementados na linguagem

Java usando alguns frameworks de terceiros.

O código fonte, o bytecode da aplicação e a definição dos agrupamentos são os recursos de entrada para o processo de Extração, o qual resulta em uma representação textual e visual das regras de tratamento de exceções.

O processo de Extração das Regras inicia-se pela extração dos fluxos excepcionais. O componente Exception Flow Revealer é responsável por analisar o call

graph produzido pelo WALA a partir do bytecode do sistema e coletar os fluxos

excepcionais usando um algoritmo baseado em def-use.

Em seguida, as ações de tratamento são identificadas pelo componente Handler

Action Analyzer a partir da análise do AST do código fonte do sistema. E, finalmente, a

representação textual e visual das regras são obtidas pelo componente Rules Extractor a partir da análise dos fluxos excepcionais anotados com as informações das ações de tratamento e da definição dos agrupamentos.

As regras extraídas e os fluxos excepcionais são analisados pelos desenvolvedores no processo de Refinamento da Política com o objetivo de indicar as regras de tratamento válidas, identificando e ignorando das regras extraídas os falsos-positivos.

Como resultado do processo de Refinamento, as regras que compõem a política são definidas e especificadas textualmente, possibilitando a execução do processo de

Checagem das Regras que indica as regras de tratamento violadas e as respectivas causas.

O processo de Checagem das Regras é executado com o apoio do componente Rules

Checker a partir da análise dos fluxos excepcionais e das definições das regras que

4. ESTUDO EMPÍRICO DE EXTRAÇÃO DE POLÍTICA DE TRATAMENTO