5 Estudo de Caso
5.2.1 Contrato BRIC de Cell e Controller
Como apresentado na Seção 2.3, um contrato de componente possui um comporta- mento (processo CSP), portas (canais) e interface (tipos). Os contratos que representam a Cell e o Controller, descritos nas Figuras 5.2 e 5.3 são definidos a seguir e representam os valores de entrada da ferramenta:
CtrCell= * Cell, rd7→ Direction x V alue, wrt7→ Direction x V alue ,{Direction x V alue},{rd,wrt} +
CtrController= * Controller,
read7→ CellId x Direction x V alue, write7→ CellId x Direction x V alue
,
{ CellId x Direction x Value}, {read, write} i
Para demonstrarmos comos esses dados são descritos na BTS, apresentaremos a cri- ação do contrato CtrCell. A Figura 4.6 nos apresenta a tela de contrato, onde definimos
o comportamento B e a lista de canais, que possuem os tipos associados representando a relação de um para o outro.
Além do conjunto de entradas que representam o contrato BRIC, a descrição dos eventos de entrada e saída, apresentadas a seguir, são definidos através da interface na Figura 5.4, onde o usuário seleciona o canal e define manualmente o canal de comunicação, seja para a entrada ou para a saída. No exemplo da Figura, está sendo definido o valor de inputs para o canal rd.
Figura 5.4: Interface para descrição de eventos de entrada e saída
inputs(rd, CtrCell) ={|rd.req|}
inputs(wrt, CtrCell) ={|wrt.req|}
outputs(rd, CtrCell) ={|rd.ack|}
outputs(wrt, CtrCell) ={|wrt.ack|}
inputs(read.1, CtrController) ={|read.1.ack|}
inputs(read.2, CtrController) ={|read.2.ack|}
inputs(read.3, CtrController) ={|read.3.ack|}
inputs(write.1, CtrController) ={|write.1.ack|}
inputs(write.2, CtrController) ={|write.2.ack|}
inputs(write.3, CtrController) ={|write.3.ack|}
inputs(input, CtrController) ={|input|}
outputs(read.2, CtrController) ={|read.2.req|}
outputs(read.3, CtrController) ={|read.3.req|}
outputs(write.1, CtrController) ={|write.1.req|}
outputs(write.2, CtrController) ={|write.2.req|}
outputs(write.3, CtrController) ={|write.3.req|}
outputs(output, CtrController) ={|output|}
Descrito esse conjunto de definições de entrada, todas as outras características, como verificação e composição são gerados automaticamente. Inicialmente, para cada contrato descrito, a ferramenta verifica se esse possui o comportamento de I/O process. Para isso, internamente é gerado o arquivo CSP que possui toda descrição do contrato juntamente com o conjunto de verificações que é analisado pelo FDR2.
Concluindo que CtrCell e CtrController são contratos válidos, agora é possível compor
esses componentes. O contrato de cada célula descrita na Figura 5.1 é definido como uma instância de CtrCell.
Cell1 = Inst(CtrCell,{rd 7→ rd_i.1,wrt 7→ wrt_i.1})
Cell2 = Inst(CtrCell,{rd 7→ rd_i.2,wrt 7→ wrt_i.2})
Cell3 = Inst(CtrCell,{rd 7→ rd_i.3,wrt 7→ wrt_i.3})
onde Cell1, Cell2 e Cell3 possuem o mesmo comportamento que Cell, porém, com os canais renomeados e cada instância representa um contrato de componente válido.
5.2.2
Composição
Para realizar a verificação da composição é necessário gerar o protocolo para cada canal do componente. Na descrição do contrato existe a opção, para cada canal, de adicionar seu protocolo e dual-protocol, que são representados por processos CSP, como podemos observar na Figura 5.5. Na Figura, encontramos a definição do protocolo e dual de Cell sobre o canal rd, estes estão representados como uma chamada de função, pois os processos que os representam foram definidos anteriormente em "auxiliar process", opção que a BTS fornece ao usuário, para definir processos que ele deseja inserir no arquivo da especificação final. Em nosso estudo de caso, temos os seguintes protocolos e protocolos
dual para Cell e Controller:
Figura 5.5: Interface para descrição protocolo e dual-protocols
Dual_P rot_Cell(e) = |˜| v1 : V alue @ e.req.v1→ e.ack?v2 → Dual_P rotCell(e)
P rotController(e)=|˜|v1 : V alue @ e.req.v1→ e.ack?v2 → P rotController(e)
Dual_P rotController(e)= |˜| v2 : V alue @ e.req?v1→ e.ack.v2 → Dual_P rotController(e)
Para analisar o comportamento das composições, a BTS nos fornece a interface des- crita na Figura 5.6, onde no exemplo da Figura temos a seleção de dois componentes (Cell1 e Cell2 ) e da regra de interleaving. Como nessa regra não são necessários os canais (port), estes não precisam ser descritos. Apresentaremos a seguir a ordem da aplicação das regras pela BTS.
Interleave
Nesse estudo de caso, a composição em interleave consiste em validar a comunicação entre as três células que formam o anel de buffer (Fig. 5.1). Primeiramente, compomos em interleave Cell1 e Cell2.
Figura 5.7: Composição em interleave de Cell1 e Cell2
Cell1_Cell2 = Cell1 [|||] Cell2
Para que a aplicação da regra seja válida, basta que seus conjuntos de eventos, o que é verificado pela BTS, não sejam iguais (como observado na instanciação desses processos). O resultado dessa composição é o processo Cell1_Cell2 (Fig. 5.7) que pode então ser composto com Cell3.
Figura 5.8: Composição em interleave de Cell1, Cell2 e Cell3
Cell1_Cell2_Cell3 = Cell1_Cell2 [|||] Cell3
A composição desses componentes (Fig. 5.8) completam a composição das células em nosso exemplo, as quais não têm comunicação entre si, mas apenas com o ambiente.
Communication
Em nosso exemplo do Buffer Circular, a composição em comunicação consiste em verificar a interação entre os componentes, ou seja, essa regra faz a verificação da comu- nicação do Controller com as células e requer um conjunto de análise mais complexo. Na ferramenta, compomos o Controller com o resultado da composição entre as três células
(Fig. 5.9). Nesse estudo de caso, realizamos a composição em comunicação com entre os canais wrt_i.1 e write.1. A análise da composição entre esses componentes é realizada a partir da comunicação entre esses dois canais.
Figura 5.9: Composição em Communication do Controller com as Células
Feedback
Na composição por feedback são selecionados dois canais do componente, gerado a partir da composição entre o Controller e as células. Essa regra verifica se a comunicação em um canal não interfere na comunicação do outro. Para nosso estudo de caso, realizamos três composições em feedback: compomos os canais rd_i.1 e read.1 ; wrt_i.2 e write.2 ;
rd_i.2 e read.2.
Figura 5.10: Composição em feedback do componente resultante das células com o Con-
troller
Reflexive
A última composição verificada é a reflexiva (Fig. 5.11) entre dois canais do com- ponente resultante da composição em feedback. Essa regra verifica se existem problemas
de dependência sobre a comunicação dos eventos no sistema. A composição foi realizada entre os canais wrt_i.3 e write.3 ; rd_i.3 e read.3.
Figura 5.11: Composição em reflexive do componente resultante da composição em feed-
back
5.3
Análise do Estudo de Caso
Assim como descrito no processo original, nossa ferramenta foi capaz de gerar e veri- ficar toda especificação do estudo de caso apresentado em [OLIVEIRA, 2012b]. Esse veio validar nossa ferramenta, em relação a abordagem manual, quanto à facilidade, redução da complexidade, tempo de resposta e confiabilidade.
Todo conjunto de regras e leis são definidos internamente pela ferramenta, de forma automática, através de asserções FDR2. A tabela a seguir apresenta o conjunto de asser- ções gerado automaticamente em cada fase do estudo de caso. Os testes foram realizados em uma máquina Pentium(R) Dual-Core CPU T4400 @ 2.20GHz, com 4Gb RAM e sis- tema operacional Ubuntu 12.04.
Asserções geradas e verificadas
Chamadas a proces- sos externos
Total de linhas no
script CSP tempo de execução
I/O process de Cell (3) 21 48 705 2s07ms
I/O process de Controller (1) 9 16 261 14s.
Composições em Interleave (2) 2 4 508 1s8ms Composição em communication (1) 43 62 372 3s64ms Composições em feedback (3) 135 192 1122 7m58s Composições em reflexive (2) 88 132 782 4m77s Total 298 454 3750 17m21s
Como podemos observar na tabela, cada coluna representa um uma fase de verificação, como por exemplo, o resultado da verificação de I/O process das três celulas.
Na primeira linha da tabela podemos observar a quantidade de asserções geradas e verificadas. Ou seja, para a verificação de I/O process das três células, por exemplo, temos a totalidade de 21 asserções geradas. Já as três composições em feedback totalizaram 135 asserções geradas automaticamente.
A BTS também inclui alguns arquivos externos que possuem a implementação de processos usados na verificação das asserções, como descrito na segunda linha da tabela. Esta representa a quantidade de chamadas a esses processos na execução dos arquivos gerados. Além disso, a tabela apresenta a quantidade de linhas de código gerada e o tempo de processamento em cada fase. Esse tempo foi medido manualmente e representa desde o momento de solicitação para aquela verificação, até a apresentação do resultado pela BTS ao usuário.
Uma das grandes contribuições da aplicação deste estudo de caso é a geração e verifi- cação automática de 298 asserções de forma oculta ao usuário, além das 454 chamadas à processos, que implementam as propriedades e regras descritas em [RAMOS, 2011], sendo estas, através do FDR2, capazes de avaliar e validar a composição de componentes no sistema. Além disso, os scripts CSP gerados em cada fase totalizaram 3750 linhas de código.