Dependendo da topologia do diagrama de blocos, o processo de geração do ambiente de ve- rificação da integração pode gerar diversas versões dos componentes Source e Checker. Seja um sistema qualquer com diagrama de blocos conforme ilustrado no item a da Figura 3.13, a integração Y◦Z, por exemplo, pode levar a construção de um novo componente Source para estimular o bloco Z, que não pode ser usado na simulação do bloco Z isoladamente, isto é, o novo Source serve somente para integração.
Figura 3.13: Exemplo de topologia com três blocos.
Conforme ilustrado na parte b) da Figura 3.14, o componente SourceZ foi originalmente implementado para gerar estímulos através de duas interfaces distintas: uma se refere aos estímulos que são produzidos pelo bloco X e a outra se refere aos blocos que são produzidos pelo bloco Y. Quando ocorre a integração, o SourceZ não precisa mais gerar os estímulos referentes ao bloco Y, pois estes estímulos serão fornecidos pelo bloco Y de fato (vide Figura 3.14, item c)). Da forma como os geradores de estímulos são construídos em VeriSC, não é possível desabilitar por meio de programação a geração dos estímulos referentes ao bloco Y. A geração de tais estímulos é desabilitada por meio de edição, através da qual o engenheiro deve remover os trechos de código referente à geração dos estímulos. Após esta integração, quando for o caso de executar novamente a verificação do bloco Z isoladamente, os trechos de código que foram removidos do componente SourceZ precisam ser inseridos novamente para que estímulos sejam gerados para as duas interfaces. A existência de múltiplas versões do componente Checker é indesejável porque exige o custo adicional de manter a consistên- cia entre os estímulos que são gerados para o bloco isoladamente e os que são gerados para a integração.
Este trabalho de inserir e remover código não é necessário para o componente SourceY da integração, pois ele pode ser reusado integralmente em seu ambiente de verificação original e no ambiente de verificação da integração(vide Figura 3.14, item a)).
Figura 3.14: Exemplos de ambiente de verificação para o sistema da Figura 3.13, item a.
Um sistema com diagrama de blocos conforme ilustrado no item b da Figura 3.13 tam- bém apresenta problemas no reuso dos componentes do ambiente de verificação. A inte- gração B◦A, por exemplo, pode levar à construção de um novo componente Checker para o bloco A, que não pode ser usado na simulação do bloco A isoladamente, isto é, o novo Checker serve somente para integração.
Conforme ilustrado na parte a) da Figura 3.15, o componente Checker do bloco A recebe valores de duas interfaces, uma referente aos dados que são produzidos para o bloco B e outra referente aos dados que são repassados para o bloco C. Quando ocorre a integração do bloco A com o bloco B, conforme ilustrado no item c da Figura 3.15, o componente Checker do bloco A deixa de receber dados da interface referente à comunicação com o bloco B, pois eles são repassados para o bloco B de fato. Conseqüentemente, o componente Checker da integração passa a receber apenas dados que seriam repassados para o bloco C. Isto leva a uma edição do componente Checker original de A para que ele funcione conforme ilustrado na Figura 3.15, item c. Assim, duas versões do componente Checker são necessárias, uma para a verificação do bloco A isoladamente e outra para verificação da integração B◦A.
Figura 3.15: Exemplos de ambiente de verificação para o sistema da Figura 3.13, item b.
demais componentes do ambiente de verificação, tais como geradores de estímulos e moni- tores. O papel de um Checker é apenas comparar os resultados produzidos pelo Modelo de Referência e pelo DUV. Assim, o melhoramento na especificação de geradores de estímulos e de critérios de cobertura não afeta diretamente o bloco Checker. No entanto, a existência de múltiplas versões deste componente requer, por parte do engenheiro, o trabalho adicional de configurar o ambiente de verificação para considerar os diversos componentes do tipo Checker que são produzidos na medida em que blocos de projeto são integrados. Este tra- balho adicional poderia ser suprimido caso fosse possível reusar o componente Checker na verificação isolada do bloco de projeto ou em alguma situação de integração. Em VeriSC, contudo, isso não é possível.
3.6.1
Refatoração do Ambiente de Verificação de VeriSC
Diante dos problemas com reuso dos componentes Source e Checker apresentados na seção anterior, é possível propor alterações na arquitetura do ambiente de verificação funcional de VeriSC para que tais problemas não mais ocorram. Estas alterações não modificam o
comportamento funcional de VeriSC, mas podem prover a flexibilidade e a simplicidade ne- cessárias para que os componentes mencionados sejam reusados de forma transparente em relação ao contexto da verificação sendo realizada: verificação do bloco isolado ou verifica- ção do bloco na fase de integração.
Um único componente Source pode não servir ao mesmo tempo para a verificação isolada do bloco e para a verificação na fase da integração se este Source tem como responsabilidade a geração de estímulos para mais de uma interface. Em outros termos, este problema ocorre porque, em VeriSC, um único componente Source é projetado para simular toda a parte do ambiente que produz estímulos para o bloco de projeto sendo verificado. Não importa se o bloco recebe dados de um, dois ou três blocos vizinhos, um único componente Source vai ser criado para simular a produção de estímulos pela sua vizinhança. Na medida em que ocorre a integração com os blocos vizinhos, este componente Source precisa ser alterado para que ele não gere mais os estímulos que são fornecidos pelo bloco vizinho que está sendo integrado.
Em VeriSC, diferentemente do componente Source, existe um componente TDriver para cada interface de entrada de dados. Esta característica faz com que componentes do tipo TDriver sejam reutilizados na verificação da integração tais como eles foram utilizados na verificação dos blocos isoladamente. Isto porque esses componentes apresentam um grau de coesão suficiente para desacoplá-los do contexto em que são utilizados. Este mesmo grau de coesão pode ser obtido para os geradores de estímulos fazendo-se com que para cada componente TDriver exista um bloco gerador de estímulos. Assim, em vez de possuir único Source para simular a produção de estímulos de todos os blocos vizinhos, o ambiente de verificação vai possuir um bloco Source para cada interface de entrada, isto é, cada vizinho tem a sua geração de estímulos simulada por um componente Source específico. Na medida em que os blocos vizinhos são integrados, os respectivos componentes do tipo Source são eliminados do ambiente de verificação. E como a eliminação de um componente gerador de estímulos não influência os demais geradores de estímulos, esta estratégia vai permitir que componentes do tipo Source sejam reusados de forma transparente em relação ao contexto da verificação: verificação do bloco isolado ou verificação do bloco na fase de integração.
A Figura 3.16 é uma ilustração do ambiente de verificação do bloco de projeto Z da Figura 3.13, item a), com um componente do tipo Source para cada interface de entrada. É importante observar na Figura 3.16 que os componentes SourceZ1 e SourceZ2 não estão
acoplados. A implementação de um não depende do outro e vice-versa. Assim, na integração de algum bloco vizinho na entrada do bloco de projeto Z, o respectivo bloco Source pode ser removido sem a necessidade de editar o outro bloco Source que será integrado em seguida.
Figura 3.16: Ambiente de verificação para o bloco de projeto Z da Figura 3.13.
Para resolver o problema com o reuso dos componentes do tipo Checker, podemos se- guir o mesmo raciocínio usado para resolver o problema com o reuso de componentes do tipo Source. Assim, para cada interface de saída de um bloco de projeto, vai existir um componente do tipo Checker. Esta estratégia também é capaz de tornar os componentes do tipo Checker coesos a ponto de que o seu reuso seja transparente em relação ao contexto da verificação. A Figura 3.6.1 é uma ilustração do ambiente de verificação do bloco de projeto A da Figura 3.13, item b), com um componente do tipo Checker para cada interface de saída. Observe que para cada interface de saída existe um TMonitor e um Checker.
Figura 3.17: Ambiente de verificação para o bloco de projeto A da Figura 3.13.