Aplicação prática da estratégia pela BTS

Como vimos na seção anterior, internamente a BTS gera arquivos CSP que são verifi- cados pelo FDR2. Nessa seção apresentaremos a estruturação desses arquivos e também apresentaremos a utilidade do typeChecker.

ponente que é um processo CSP descrito pelo usuário. Quando a ferramenta recebe esse comportamento, antes de ser integrado ao resto da especificação para que as asserções sejam analisadas, é necessário fazer uma verificação, visto que esse é suscetível a erros.

A Figura 4.14 mostra um exemplo de como o comportamento especificado pelo usuário é gerado para verificação. Utilizaremos o exemplo do Cliente-servidor descrito no Capítulo 2. Apresentaremos a seguir o comportamento do componente cliente.

Inicialmente, a BTS declara os tipos, canais e adiciona o comportamento CSP. Em se- guida, ela comunica com TypeChecker que faz a verificação de tipagem. O resultado é apresentado ao usuário através da apresentação dos ícones√e χ, como descrito na Figura 4.6 – A. A saída do TypeChecker pode ser visualizada através do click sobre esses ícones, que é descrita na Figura 4.15.

Realizada a verificação pelo TypeChecker a ferramenta está preparada para gerar e verificar as condições descritas na seção 2.3.

Verificando as condições de I/O Process

A verificação de I/O process é fundamental para que as propriedades e restrições do componente sejam garantidas e posteriormente a aplicação das regras de composição tenham o resultado desejado. O arquivo CSP gerado nessa fase é descrito através de um modelo de contrato que possui as seguintes características:

• Nome

• Comportamento • Tipos

• Canais

• Eventos de entrada e saída

A partir das características descritas acima, o corpo da especificação (gerada automa- ticamente) para verificação do comportamento de I/O process, do componente Cliente, possui a seguinte estrutura:

NUM = {0..20}

datatype DADOSMQ = rt.NUM | requisitaSaldo | ackRt.Bool | recSaldo.NUM datatype DADOSCL = insereCartao.NUM | digitaSenha.NUM | retiraDin.NUM | saldo | retiraCartao | recebeDin | mostraSaldo

channel cl : DADOSCL channel maq : DADOSMQ

Cliente = cl.insereCartao?num -> cl.digitaSenha?num -> (SAQUE [] SALDO) ; cl!retiraCartao -> Cliente

SAQUE = cl.retiraDin? val -> maq!rt.val -> maq.ackRt?a -> cl!recebeDin -> SKIP

SALDO = cl.saldo -> maq!requisitaSaldo -> maq.recSaldo?x -> cl!mostraSaldo -> SKIP

Figura 4.14: Exemplo de comportamento do componente

Figura 4.15: Interface de saída do TypeChecker

• Declaração de tipos e canais. Estes são descritos através das interfaces das Figuras 4.3 e 4.4. Internamente a BTS transforma em código CSP, como apresentado a seguir:

NUM = {0..20}

datatype DADOSMQ = rt.NUM | requisitaSaldo | ackRt.Bool | recSaldo.NUM datatype DADOSCL = insereCartao.NUM | digitaSenha.NUM | retiraDin.NUM | saldo | retiraCartao | recebeDin | mostraSaldo

channel cl : DADOSCL channel maq : DADOSMQ

• Processo (Comportamento): descrito pelo usuário.

Cliente = cl.insereCartao?num -> cl.digitaSenha?num -> (SAQUE [] SALDO) ; cl!retiraCartao -> Cliente

maq.ackRt?a -> cl!recebeDin -> SKIP

SALDO = cl.saldo -> maq!requisitaSaldo -> maq.recSaldo?x -> cl!mostraSaldo -> SKIP

• GET_CHANNEL: conjunto de canais do processo. Essa função é necessária para a verificação das saídas fortemente decisivas.

GET_CHANNELS(P) = let f = < (Cliente, { cl, maq }) > within apply(f,P )

• inputs: eventos de entrada do componente.

inputs(P) = let f = <

( Cliente, {| maq.ackRt, maq.recSaldo |}) >

within apply(f, P )

• outputs: eventos de saída do componente.

outputs(P) = let f = <

( Cliente, {| maq.rt, maq.requisitaSaldo |}) >

within apply(f,P)

• Condições de verificação, apresentadas na seção anterior. Estas representam as cinco condições que garantes ao componente o comportamento de I/O process.

assert not Test(inter(inputs(Cliente),outputs(Cliente)) == {}) [T= ERROR

assert not HideAll(Cliente):[divergence free [FD]]

assert LHS_InputDet(Cliente) [F= RHS_InputDet(Cliente)

assert LHS_OutputDec_A(Cliente) [F= RHS_OutputDec_A(Cliente)

assert LHS_OutputDec_B(Cliente,maq) [F= RHS_OutputDec_B(BricRingCell,maq) assert LHS_OutputDec_B(Cliente,cl) [F= RHS_OutputDec_B(Cliente,cl)

Além disso, o arquivo gerado inclui, na primeira linha, um arquivo ("auxiliar.csp"). Este tem as funções necessárias para realizar as verificações do comportamento de I/O

process descritos em [OLIVEIRA, 2012b], juntamente com as modificações realizadas,

apresentado no Capítulo 3.

Utilizamos o FDR2 para realizar a verificação dessas asserções. O resultado é salvo em um arquivo que é analisado e repassado para o usuário de maneira bem simples, como descrito na Figura 4.7. Nela, o resultado de todas as asserções é realizado com sucesso, descrito através do√verde. Caso alguma condição não seja atendida, seu resultado será apresentado como um χ no lugar do ícone verde. Além disso, ainda é possível visualizar a saída do FDR2 através da opção details.

Para realizar a verificação da composição, que tem os componentes selecionados atra- vés da interface descrita na Figura 4.10, antes é necessário instanciar os componentes (Fig. 4.8) que se deseja compor. Para gerar uma instância de contrato, basta existir um contrato implementado e verificado. Esse contrato tem o nome e canais renomeados e internamente esse comportamento é representado pela função rename de CSP.

Verificando a composição

Como descrito no Capítulo 2 existem quatro regras de composição que podem ser aplicadas entre os componentes e cada uma gera seu conjunto de verificação.

Nessa parte, a BTS recebe um ou dois componentes que são I/O process e define a seguinte estrutura:

• Corpo do documento. Construído igualmente ao documento que verifica o compor- tamento de I/O process, exceto a função GET_CHANNEL, que não é necessária nessa fase, e o conjunto de verificações que é diferente.

• Conjunto de asserções de acordo com regra selecionada. Para cada regra, existe um conjunto de verificações diferentes, como descrito a seguir:

Inteleave:

Para duas instâncias do processo Cliente (Cliente1 e Cliente2 ) temos os seguintes conjuntos de asserções:

--INTERLEAVING COMPOSITION

Cliente1_Cliente2_INTER = INTER(Cliente1,Cliente2)

assert STOP [T= RUN(inter(events(Cliente1),events(Cliente2)))

A composição em interleave é realizada através da função IN T ER(P 1, P 2), tal que P1e P2 são processos. A função IN T ER está implementada no arquivo rule.csp, o qual o arquivo deve importar.

Nessa regra de composição, considerando-se que um componente só pode ser com- posto caso atenda a condição de I/O process, verificado anteriormente, a única restrição imposta é que os componentes não devem possuir conjuntos de eventos em comum. A verificação da composição também é realizada através da ferramenta FDR2 e seu resul- tado apresentado para o usuário. Além disso, a BTS gera um novo componente repre- sentado pelo processo Cliente1_Cliente2_INTER que tem como comportamento a INTER(Cliente1,Cliente2).

Communication:

Para exemplificar a regra de composição em comunicação, apresentaremos a compo- sição do Cliente1 com a Máquina e os respectivos canais maq1 e maq. Nessa regra o conjunto de verificação é maior e mais complexo. Com isso, temos as seguintes asserções: