Modelo de Fluxo de Controle

Para ilustrar a definição de regras ativas, considere a Figura 6.1 que possui um modelo simplificado de regra escrita em SQL. A sintaxe indica uma separação entre as partes evento, condição e ação. Do ponto de vista de construção de grafo de fluxo de controle, o evento e a condição de regra podem ser representados por nós específicos. A ação de regra é representada por um subgrafo.

Em regras ativas escritas em SQL, um bloco b é definido como b = (dcl, sta, exp); dcl é o conjunto de variáveis declaradas e de escopo local ao bloco; sta representa os comandos que definem a tarefa do bloco; e exp consiste nas rotinas de tratamento das exceções ocorridas devido à execução do conjunto sta de comandos. O subgrafo atribuído à ação de regra é obtido pela extensão do bloco associado. Essa definição de bloco é similar à definição de Daou et al. (2001) para comando composto: um conjunto de comandos caracterizado por um único tratador de exceção, implícito ou explícito; os autores exploram a manipulação de tabelas por diversos módulos, a qual cria dependências de fluxo de controle entre os módulos e os dados gerados por um comando, e que são usados por outros comandos no mesmo módulo, ou outros módulos, criando relações de fluxo de dados.

ação condição evento CREATE TRIGGER <trigger name>

<trigger action time>

<trigger event> ON <table name> <granularity> WHEN <condition> <declare section> BEGIN <statement section> <exception section> END;

Figura 6.1 – Exemplo da estrutura de regra escrita em SQL.

No modelo de fluxo de controle adotado, uma regra r é representada por um grafo dirigido, dado por G(r) = (N, A, e, x), conforme ressaltado no Capítulo 2, onde: N representa o conjunto de nós; A denota o conjunto de arcos; o nó de entrada (evento da regra) é identificado por e; e x representa o nó de saída. A estrutura de controle de uma regra ativa segue o desenho apresentado na Figura 6.2; nessa figura são ressaltados: o disparo de regra e o controle interno de uma regra ativa. Seja P um processo que possui uma operação θ capaz de provocar eventos de disparo de regras; P pode ser uma aplicação do usuário, uma rotina gravada no banco de dados ou, mais especificamente, uma regra ativa da base de dados. Considere que ri e rj sejam regras

sem a presença de condição e com a presença de condição, respectivamente, cujos eventos de disparo podem ser provocados pela execução da operação θ. Particularmente, quando o evento de

Implementação dos Critérios Baseados na Interação entre Regras 142

ri é provocado, o controle é transferido do processo P para o escopo da regra ri, e retornado a P

após a execução de ri; o mesmo raciocínio aplica-se à regra rj. Considerando a estrutura de

controle de rj, o nó ej é o nó de entrada da regra, e representa o evento associado ao disparo da

regra; o nó cj denota a condição da regra, e significa uma seleção entre o subgrafo aj e o nó xj. O

subgrafo aj está associado à ação da regra. O nó xj é o nó de saída da regra rj.

ai xi cj ej aj xj

.

.

.

.

Figura 6.2 – Grafo de fluxo de controle para regras ativas com e sem condição, respectivamente representadas pelas regras ri e rj.

Cada ocorrência de comando de manipulação é representada por um nó dedicado no grafo de fluxo de controle. Abordagem similar foi usada em (Spoto, 2000; Daou et al., 2001); particularmente, Spoto (2000) altera a definição de grafo de programas escritos em linguagem C para acomodar os comandos executáveis de SQL em nós especiais, um comando em cada nó. No contexto de regras ativas, a adoção desse modelo permite explorar as relações de fluxos de dados entre os comandos de manipulação em uma mesma regra ativa e em regras distintas.

Conforme descrito no Capítulo 4, o modelo de fluxo de controle inter-regra que foi adotado no presente trabalho – política de ciclo recursiva e modos de acoplamento imediatos para

evento-condição e condição-ação – prevê que a execução de uma regra é interrompida quando o evento de disparo de alguma regra é provocado e o controle é transferido para esta regra. A Figura 6.3 ilustra o fluxo de controle para comandos de manipulação, com e sem disparo entre regras. Toda ocorrência de comando de manipulação ocasiona pelo menos duas alternativas de fluxo, representadas pelos arcos (s, nk) e (s, nj) para a execução normal do comando e para a

execução que provoca exceção, respectivamente. O nó s mapeia uma ocorrência de manipulação de dados persistentes; o nó nj representa o nó de saída da regra ou um subgrafo de uma rotina de

tratamento de exceção; e o nó nk representa um sucessor do nó s para execuções normais (sem

provocar exceção) do comando de manipulação. Em 6.3(b), o subgrafo r denota uma regra ativa que pode ser disparada a partir da execução do comando mapeado pelo nó s; observe que o disparo entre regras não ocorre quando exceções são provocadas.

normal exceção s nj nk normal exceção s nj nk r (b) (a)

Figura 6.3 – Fluxo de controle para comandos de manipulação de dados: (a) sem disparo entre regras; (b) com disparo entre regras.

No contexto de regras escritas em SQL, as extensões da linguagem relacionadas com construções estruturadas são similares àquelas usadas em linguagens do tipo Algol. Em geral, além dos comandos de manipulação de dados persistentes, encontram-se comandos associados a estruturas de controle como seleção e laço; neste sentido, está o modelo para a condição de regra, que considera uma estrutura de seleção simples entre o subgrafo que representa a ação da regra e o nó de saída da regra. Os modelos de fluxo de controle e de instrumentação para tais estruturas foram explorados pela literatura (Chaim, 1991; Maldonado, 1991; Spoto, 2000, Leitão et al.,

Implementação dos Critérios Baseados na Interação entre Regras 144

2002; Cardoso, 2004), não sendo, portanto, incluídos neste texto. Ênfase será dada às estruturas de tratamento de exceção, que constituem uma contribuição pertinente às regras escritas em SQL.

Segundo Daou et al. (2001), programação de exceção complica as dependências de fluxo de controle, resultando na construção de grafo de fluxo de controle diferente para módulos de banco de dados, em relação a programas convencionais. Cada bloco pode ter uma única área de tratamento de exceção, a qual deverá estar no final do bloco. Blocos podem ser aninhados dentro da ação de uma regra. Uma vez que o controle é desviado para a área de tratamento de exceção, ele não retorna mais para o bloco em que está inserido; o tratamento de exceção é processado e o controle prossegue no bloco imediatamente mais externo. Várias exceções podem ser tratadas em um único bloco; a cláusula OTHERS constitui um predicado genérico para o tratamento de exceções. Um exemplo de tratamento de exceção em blocos aninhados é apresentado na Figura 6.4.

DECLARE USER_EXC EXCEPTION; :::::::::: BEGIN :::::::::: DECLARE :::::::::: BEGIN :::::::::: EXCEPTION

WHEN TOO_MANY_ROWS THEN

::::::::: END;

:::::::::: (*)

EXCEPTION

WHEN USER_EXC THEN :::::::::

WHEN OTHERS THEN ::::::::: END;

Figura 6.4 – Exemplo de tratamento de exceção em blocos aninhados.

Sempre que uma exceção ocorrer, o seu tratamento é realizado dentro do bloco em que foi provocada; se não houver tratamento específico neste bloco, o controle é desviado para a área de tratamento em blocos mais externos; a presença da cláusula OTHERS evita que esse desvio ocorra. Ou seja, ocorrida uma exceção, o sistema prioritariamente busca um tratamento de exceção dentro do próprio bloco onde ocorreu a exceção; se não encontrar, vai buscar em blocos mais externos. Na Figura 6.4, uma exceção ocorrida no bloco mais interno que necessite ser tratada no bloco mais externo evita que o controle de fluxo alcance a área (*) localizada na

figura. Quando alguma exceção é provocada nas rotinas de tratamento de exceção, independentemente do nível do bloco, resultará em um erro na execução da regra, e a primeira exceção tratada na regra será retornada ao processo que possui a operação que provocou o evento de disparo da regra.

A Figura 6.5 apresenta o fluxo de controle e de instrumentação para rotinas de tratamento de exceção. O nó m refere-se a uma estrutura do tipo seleção múltipla, que utiliza o predicado da exceção ocorrida para a seleção da rotina para tratamento de exceção; os subgrafos S1, S2, ..., Sn

representam as rotinas para tratamento de exceção, onde os seus respectivos nós de entrada são t1, t2, ..., tn; o nó z denota o nó de saída do bloco. Os comandos de instrumentação são marcados com /*i*/ no início de cada linha. A indicação /*1*/ no final de linha indica que este comando de

instrumentação é utilizado quando as rotinas de tratamento de exceção referem-se ao bloco mais externo da regra ativa, caso contrário utiliza-se o comando com a indicação /*2*/.

BEGIN ::::::::::::: EXCEPTION WHEN <p1> THEN /*i*/ ponta-de-prova (m); /*i*/ ponta-de-prova (t1); ::::::::::::: /*i*/ ponta-de-prova (z); /*1*/ ::::::::::::: ::::::::::::: WHEN <pn> THEN /*i*/ ponta-de-prova (m); /*i*/ ponta-de-prova (tn); ::::::::::::: /*i*/ ponta-de-prova (z); /*1*/ END; /*i*/ ponta-de-prova (z); /*2*/ .... m S1 z Sn S2

Figura 6.5 – Fluxo de controle e de instrumentação para rotinas de tratamento de exceção.

Se o bloco mais externo não possuir rotina para tratamento de exceção para o predicado

OTHERS, esta é inserida visando a registrar o desvio para o nó de saída da regra.

Especificamente em ocorrências de manipulação de dados persistentes, a ausência de rotinas para tratamento de exceção é suprida pela inserção de rotina dedicada a cada comando; esse enfoque é

Implementação dos Critérios Baseados na Interação entre Regras 146

adotado para registrar o comando que provocou a exceção, em adição ao desvio para o nó de saída da regra, conforme demonstrado na Figura 6.6. Nesta figura, o nó n representa a ocorrência do comando update; o pseudoprocedimento contexto-excecao objetiva registrar a posição relativa do nó n em relação à seqüência de nós exercitados pela aplicação de casos de teste; o nó de saída da regra é mapeado para o nó x. Uma implementação para contexto-excecao é apresentada na Subseção 6.2.3, permitindo, para um particular caso de teste, comparar o contexto de exceções ocorridas entre as versões correta e defeituosa de um conjunto de regras.

... /*i*/ begin

/*i*/ ponta-de-prova (n); UPDATE ...; /*i*/ exception

/*i*/ when others then

/*i*/ contexto-excecao ( ... ); /*i*/ ponta-de-prova (x); /*i*/ return;

/*i*/ end; ...

Figura 6.6 – Instrumentação de fluxo de controle para comandos de manipulação desprovidos de rotinas de tratamento de exceção.