1 t o −s c a d e :
2 S p e c ( SpecName , Types , C o n s t a n t s , Vars , Assume , A s s e r t , F u n c t i o n s )
3 −> 4 $ [ < ? xml v e r s i o n = " 1 . 0 " e n c o d i n g ="UTF−8"?>< F i l e x m l n s = " . . . > 5 < d e c l a r a t i o n s > 6 < P a c k a g e name = " [ SpecName ] " > 7 < d e c l a r a t i o n s > 8 [ Types ’ ] [ C o n s t a n t s ’ ] [ O p e r a t o r s ’ ] [ M a i n O p e r a t o r ’ ] 9 < / d e c l a r a t i o n s > 10 < p r a g m a s > . . . < / p r a g m a s > 11 </ P a c k a g e > 12 < / d e c l a r a t i o n s > 13 < / F i l e > ] 14 w i t h
15 I d S e t : = < u n i o n >( < t y p e s −i d −s e t > Types , < c o n s t −i d −s e t > C o n s t a n t s ) ; 16 R a n g e B a s e d T y p e S e t : = < conc > ( < c o l l e c t ( ? ( _ , I n t e g e r −t y p e ( _ , _ ) ) ) >
17 Types , < c o l l e c t ( ? ( _ , R e a l −t y p e ( _ , _ ) ) ) > T y p e s ) ; 18 Types ’ : = < t y p e s > T y p e s ;
19 C o n s t a n t s ’ : = < c o n s t a n t s ( | I d S e t ) > C o n s t a n t s ;
20 O p e r a t o r s ’ : = < o p e r a t o r s > ( Vars , F u n c t i o n s , I d S e t ) ;
21 M a i n O p e r a t o r ’ : = <main−o p e r a t o r > ( SpecName , Vars , Assume ,
22 A s s e r t , F u n c t i o n s , I d S e t , R a n g e B a s e d T y p e S e t )
Código 4.2 Regra1descrita na linguagem do Spoofax.
4.3
Regras de Tradução com Spoofax
Após construir a gramática deSCRcomSDF, as regras de tradução da Seção3foram implementadas usando a sintaxe do Spoofax. Uma regra de Spoofax manipula termos, que são construtores automaticamente gerados por ferramentas da coleção XT a partir de definições emSDF. Uma regra de tradução é similar a regra da Seção3com alguns elementos adicionais.
Por exemplo, o Código4.2mostra a Regra1da Seção3descrita usando a sintaxe do Spoofax. A regra de tradução é identificada pelo nome to-scade presente na Linha 1. As regras casam padrão com os elementos da Abstract Syntax Tree (AST) da especificação SCR de entrada. A Linha 2 do Código4.2mostra que a regra tentará casar padrão com o nó Spec(. . . ) da AST de entrada. Os elementos do nó Spec(. . . ) são argumentos, que são passados automaticamente pelo parser quando o nó é montado. O termo “->” (Linha 3) define o fim do lado esquerdo da regra de tradução, responsável pelo casamento de padrão, e inicia o lado direito da regra, que contém os termos que serão gerados como resultado da aplicação da regra. Os caracteres $[. . . ] (Linhas 4 à 13) definem uma seção que contém código concreto da linguagem de destino, que será gerado como resultado da aplicação da regra. Na Linha 8, é possível encontrar chamadas às variáveis auxiliares da
4.3. REGRAS DE TRADUÇÃO COM SPOOFAX
regra como por exemplo à variável MainOperator’. Os colchetes que englobam a variável auxiliar definem uma seção de código que será expandida através do processamento da variável auxiliar. Estas variáveis são definidas na seção iniciada pela palavra-chave with (Linhas 14 à 22). O conteúdo de cada variável pode ser definido através de chamadas a outras regras de tradução, que por sua vez fazem chamadas a outras regras e assim por diante até que todos os nós daASTsejam traduzidos.
Para poder traduzir toda a gramática modelada emSDF, foram criadas 226 regras de tradução no Spoofax. A quantidade de regras aumentou em relação às regras definidas no Capítulo3, pois na implementação em Spoofax foi necessário implementar regras auxiliares que antes foram descritas de forma abstrata sem definir uma regra específica. Por exemplo, não foi definida uma regra específica para selecionar uma variável de uma lista de variáveis, porém este comportamento foi implementado como uma regra no Spoofax.
Por fim, o resultado do uso do Stratego/XT através do plugin Spoofax do Eclipse em conjunto comSDFé uma ferramenta interna ao eclipse que permite tanto gerar a arvore sintática de uma especificaçãoSCRquanto gerar código XML doSCADE. Apesar de não possuir uma instalação prática, a ferramenta resultante é funcional. Não entrou no escopo deste trabalho exportar um plugin para o Eclipse. O desenvolvimento com Spoofax e Stratego/XT foi penoso, pois as tecnologias possuem uma documentação superficial com seções incompletas. As informações levantadas quando ocorre um erro de implementação também são pouco intuitivas dificultando o trabalho do desenvolvedor.
A ferramenta desenvolvida nada mais é do que um projeto de desenvolvimento do Spoofax que, em conjunto com o plugin do Spoofax, disponibiliza um menu de funcionali- dades extras no Eclipse. Neste menu é onde ficam disponíveis as funcionalidades de gerar árvore sintática e código para o SCADE. A Figura4.1ilustra o menu de funcionalidades. No lado esquerdo da figura é possível ver a estrutura de pastas da ferramenta. Do lado direito da figura fica o editor de código SCR que possui a capacidade de dar ênfase nas palavras-chave. Por fim, o menu Transform agrupa as funcionalidades Generate SCADE codee Show abstract syntax. A primeira funcionalidade executa as regras de tradução gerando código SCADE, enquanto que a segunda funcionalidade executa o parser automático do Stratego/XT construindo uma árvore sintática abstrata do código SCR.
4.3. REGRAS DE TRADUÇÃO COM SPOOFAX
5
Estratégia de Verificação
Para investigar se a estratégia de tradução gera modelos SCADE que correspondem corretamente à especificaçãoSCRde entrada, propomos neste capítulo uma estratégia de verificação de conformidade baseada na campanha de testes de acordo com a DO-178B fornecida pela suíte T-VEC. O objetivo da verificação é mostrar que os modelosSCADE gerados estão de acordo com uma campanha de testes baseada no padrão DO-178B, que é a principal referência que a indústria de software crítico usa para obter certificações.
A estratégia de verificação de conformidade proposta pode ser mais facilmente entendida através da análise do diagrama de atividades presente na Figura 5.1. Para explicar as atividades individualmente, são apresentadas algumas figuras da aplicação da estratégia de verificação em um dos estudos de caso do presente trabalho. Os estudos de caso são detalhados na Seção6.
A partir do diagrama de atividades, é possível ver que existem dois conjuntos con- correntes e independentes de atividades. O lado esquerdo do diagrama é explicado inicialmente apenas por conveniência.
• Modelar a Especificação Seguindo a Gramática definida emSDF: O primeiro esforço é em escrever uma especificaçãoSCRusando a gramática definida para o tradutor detalhada no ApêndiceA. A Figura5.2ilustra este passo mostrando uma janela do Eclipse referente ao tradutor construído no presente trabalho;
• Executar Tradutor: Assim que for finalizada a modelagem da especificaçãoSCR, é possível executar o tradutor para gerar modelosSCADE. O resultado da tradução é um arquivo XML com extensão XSCADE cujo conteúdo é similar ao Código2.4; • Importar Arquivo XSCADE noSCADE: Com o arquivo XML correspondente à especificaçãoSCADEem mãos, é possível importar o arquivo na suíteSCADE. A
Figura 5.1 Diagrama de atividades da estratégia de verificação.
suíte automaticamente executa análises sobre a conformidade do XML em relação à gramática deSCADE, garantindo a conformidade estática do XML gerado. A Figura5.3ilustra graficamente o modeloSCADEcorrespondente à especificação SCR. O lado esquerdo da figura mostra os nós operadores gerados pelo tradutor. O nó Safety Injection System é o nó principal e representa a especificação completa conectando todos os outros nós;
• Executar o Gerador de Código deSCADE: Com o programaSCADEimportado na ferramenta e apresentando nenhum erro, o próximo passo é executar o gerador de código certificado da ferramenta para gerar código C.
Figura 5.2 Estudo de caso modelado usandoSCRno tradutor.
vetores de testes pela ferramenta T-VEC para verificar se o código produzido pelo SCADE está em conformidade com a especificaçãoSCRusada como entrada. Como indicado previamente, são gerados vetores de testes suficientes para cobrir todos os fluxos da especificação baseando-se no padrão DO-178B. Como os vetores de teste gerados seguem o critério de coberturaMCDC(Kelly J. et al.,2001), a quantidade de testes é finita. Os testes gerados são todos aplicados nos estudos de caso esperando que seja alcançada a marca de 100% de sucesso. Se um único teste falhar, então a estratégia de verificação não obteve sucesso.
• Modelar a especificação usando T-VEC TTM: Inicialmente é necessário mo- delar manualmente a especificação usando a ferramentaTTMdescrita na Seção 2.2.1. ComTTM, é possível construir especificações usando uma sintaxe baseada emSCR. Idealmente, a modelagem com TTM deveria ser idêntica à modelagem usando a gramática definida para o tradutor, porém a modelagem com TTM possui algumas diferenças que estão descritas na Seção5.1. A Figura 5.4ilustra uma tabela modelada noTTM;
• Converter a especificação de TTM para VGS: Após finalizar a modelagem com a ferramentaTTM, é necessário converter a especificação para a ferramenta VGS através do procedimento automático fornecido pela própria TTM. Este procedimento executa análises estáticas simples sobre a especificação, garantindo a conformidade da especificação com a gramática deTTM. A Figura5.5mostra a
Figura 5.3 Estudo de caso importado no SCADE após a execução do tradutor.
janela Translation Options deTTM, pela qual é possível acionar o procedimento de conversão. Foi desmarcada a opção Generate Vectors for Outputs Only para garantir que seriam gerados vetores de testes para todas as tabelas de variáveis auxiliares e tabelas de variáveis de saída. As outras opções de tradução não foram alteradas mantendo-se o valor padrão;
• Compilar projeto VGS: Com a especificação corretamente importada como um projeto na ferramenta VGS, o próximo passo é gerar os vetores de teste para cada tabela. Este é um procedimento automático no momento em que o projeto é compilado pela ferramenta.
• Configurar arquivos de mapeamento: Para ser possível aplicar os vetores de teste no código C gerado peloSCADE, é necessário gerar drivers de teste. Isso é, é necessário gerar código C para cada vetor de teste gerado peloVGS. Para que oVGSpossa gerar os drivers, é necessário fornecer arquivos de mapeamento que possuem a configuração necessária para indicar aoVGScomo deve ser feito a geração de código C. Os arquivos de mapeamento são detalhados na Seção5.1.1. • Gerar drivers de teste: Após fornecer os arquivos de mapeamento, é possível
acionar oVGSpara gerar os drivers de teste.
Embora neste ponto já se tenha o código C gerado peloSCADEe o código C gerado pelo VGSreferente a cada vetor de teste, ainda é necessário adaptar o código gerado peloSCADEpara que seja possível compilar todos os artefatos. O gerador de código do SCADEnão gera automaticamente o código referente ao comportamento que o sistema deve ter caso um assume ou guarantee deSCADE falhe. Este é um comportamento