Gerando modelos SCADE a partir de especificações descritas em SCR

Pós-Graduação em Ciência da Computação

“

Gerando Modelos SCADE a Partir de

Especificações Descritas em SCR

”

Por

Marcelo Costa Melo de Andrade Dissertação de Mestrado

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA

PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

MARCELO COSTA MELO DE ANDRADE

“GERANDO MODELOS SCADE A PARTIR DE

ESPECIFICAÇÕES DESCRITAS EM SCR"

ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.

ORIENTADOR(A): ALEXANDRE CABRAL MOTA

CO-ORIENTADOR(A): MÁRCIO LOPES CORNÉLIO

Catalogação na fonte

Bibliotecária Jane Souto Maior, CRB4-571

Andrade, Marcelo Costa Melo de

Gerando modelos SCADE a partir de especificações descritas em SCR / Marcelo Costa Melo de Andrade. - Recife: O Autor, 2013.

xii, 98 f.: il., fig., tab.

Orientador: Alexandre Cabral Mota.

Dissertação (mestrado) - Universidade Federal de Pernambuco. CIn, Ciência da Computação, 2013.

Inclui referências e apêndice.

1. Engenharia de software. 2. Métodos formais. I. Mota, Alexandre Cabral (orientador). II. Título.

Dissertação de Mestrado apresentada por Marcelo Costa Melo de Andrade à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título “Gerando Modelos SCADE a Partir de Especificações Descritas em SCR” orientada pelo Prof. Alexandre Cabral Mota e aprovada pela Banca Examinadora formada pelos professores:

______________________________________________ Prof. Juliano Manabu Iyoda

Centro de Informática / UFPE

______________________________________________ Prof. Adalberto Cajueiro de Farias

Departamento de Sistemas e Computação / UFCG

_______________________________________________ Prof. Alexandre Cabral Mota

Centro de Informática / UFPE

Visto e permitida a impressão. Recife, 23 de agosto de 2013.

___________________________________________________ Profa. Edna Natividade da Silva Barros

Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.

Dedico este trabalho aos meus pais, aos meus irmãos e à minha esposa.

Agradecimentos

Gostaria de agradecer às seguintes pessoas:

• Aos Professores Alexandre Cabral Mota e Márcio Lopes Cornélio, que me orientaram nesta pesquisa de forma muito presente.

• A Bob Busser, Mark Blackburn e Maureen Murtha pelo esclarecimento de dúvidas.

• Aos membros do Software Reliability Group1, pelos ricos encontros e discussões.

Resumo

Requisitos são um dos principais artefatos no desenvolvimento de um sistema. Para sistemas críticos, os requisitos são artefatos obrigatórios para satisfazer critérios de certificações tais como os descritos no guia de certificação DO-178B. Apesar de sua importância, estes artefatos são geralmente descritos informalmente através de lingua-gem natural. O uso da lingualingua-gem natural propicia a descrição de requisitos ambíguos, incompletos e inconsistentes. Para sanar este problema foi definido o método Software Cost Reduction (SCR), que permite a descrição formal de requisitos de forma precisa e relativamente amigável através do uso de tabelas preenchidas com expressões lógicas. Em particular, de forma a nos aproximarmos ainda mais das tecnologias usadas na indústria de sistemas críticos, neste trabalho nossoSCRé o implementado na ferramenta TTM da suíte T-VEC (um conjunto de ferramentas que suporta a sintaxe deSCRe possibilita a geração de vetores de testes e análise de propriedades), a qual é capaz de gerar casos de teste seguindo o guia DO-178B. Além dos requisitos, a certificação do código implemen-tado também é uma obrigação para sistemas críticos e o uso de SCR somente não garante isso. Enquanto o método SCR auxilia na descrição detalhada de requisitos, o ambiente de desenvolvimento baseado em modelos denominado Safety Critical Application Deve-lopment Environment (SCADE) auxilia na modelagem de software crítico. SCADE é também usado para gerar código certificado de acordo com o DO-178B.

Neste trabalho apresentamos como obter modelos SCADE a partir de especificações descritas em SCR através da aplicação de regras de tradução. Com isto obtemos código certificado a partir de requisitos formais em uma única solução. Para aplicar as regras de forma automática, construímos uma ferramenta tradutora usando o framework Strate-go/XT. Por fim, aplicamos nosso tradutor em dois estudos de caso descritos em SCR. Foi feito uso de uma estratégia de verificação baseada em testes para atestar que os modelos SCADE produzidos por nosso tradutor correspondem às descrições em SCR. A estratégia de verificação consiste em usar T-VEC para gerar vetores de testes de acordo com o critério de cobertura MCDC e então aplicar os testes no código C gerado peloSCADE. Apesar de nosso tradutor não ser provado correto, podemos argumentar indiretamente que o mesmo preserva as propriedades descritas em SCR nos modelos SCADE gerados automaticamente. Quanto a certificação do tradutor, isto fica a cargo de nosso parceiro industrial Embraer S.A. .

Palavras-chave: especificação formal, regras de tradução, Stratego/XT, vetores de teste, Software Cost Reduction, SCADE

Abstract

Requirements are the main artefacts in the development of a system. For critical systems, the requirements artefacts are required to meet certifications criteria such as those descri-bed in the guide to DO-178B certification. Despite their importance, these artefacts are usually described informally using natural language. The use of natural language favors ambiguous, incomplete and inconsistent description of requirements. To remedy this problem, the Software Cost Reduction (SCR) method was defined, allowing the formal, accurate and relatively friendly description of requirements by the use of tables filled with logical expressions. In particular, in order to get closer to the technologies used in the industry of critical systems, in this research ourSCRis the implemented in the T-VEC toolset (a set of tools that supports the syntax ofSCRand enables the generation of test vectors and the analysis of properties), which is able to generate test cases following the DO-178B guide. In addition to the requirements, the certification of implemented code is also a must for critical systems and the use ofSCRalone does not guarantee this. While the SCR method helps in the description of requirements, the development environment based on models called Safety Critical Application Development Environment (SCADE) helps in critical software modelling. SCADE is also used to generate certified code according to DO-178B.

In this research, we present how to get SCADE models from SCRspecifications, through the application of translation rules. With this, we can have certified code from formal specifications in only one solution. To apply the rules automatically, we built a translator tool using the Stratego/XT2framework. Finally, we executed our translator using two case studies described inSCR. We applied a test based verification strategy to our case studies to certify that the SCADE models produced by our translator correspond to the specifications described in SCR. The verification strategy consists in using T-VEC to generate test vectors based on the MCDC criteria and then apply the tests to the C code generated bySCADE. Although our translator is not proved correct, we argue indirectly that the generatedSCADEmodels preserve the properties of theSCRspecifications. As for certification, it is the responsibility of our partner Embraer Inc.3.

Keywords: formal specification, translation rules, Stratego/XT, test vectors, Software Cost Reduction, SCADE

2_{http://strategoxt.org/} 3_{http://www.embraer.com/}

Sumário

Lista de Figuras ix

Lista de Tabelas x

Lista de Códigos xi

Lista de Acrônimos xii

1 Introdução 1 1.1 Problema . . . 1 1.2 Proposta de Solução . . . 2 1.3 Organização . . . 3 2 Fundamentação Teórica 5 2.1 Métodos Formais . . . 5 2.1.1 Especificação Formal . . . 6 2.2 SCR . . . 7 2.2.1 Ferramentas de Apoio . . . 12 2.3 SCADE . . . 13 2.4 Transformações de Programas . . . 16 3 Regras de Tradução 19 3.1 Regras Principais . . . 21 3.1.1 Tipos . . . 21 3.1.2 Constantes . . . 22 3.1.3 Eventos . . . 23 3.1.4 Tabelas . . . 23 3.1.5 Operador Principal . . . 25

3.1.6 Assumptions and Assertions . . . 25

4 Tradutor 27 4.1 Stratego/XT e Spoofax . . . 27

4.2 Syntax Definition Formalism . . . 28

5 Estratégia de Verificação 33

5.1 Modelagem com TTM e VGS . . . 37

5.1.1 Arquivos de Mapeamento . . . 39

6 Estudos de Caso 41 6.1 Sistema de Injeção de Segurança . . . 41

6.2 Sistema de Controle de Cruzeiro . . . 43

7 Conclusão 48 7.1 Trabalhos Relacionados . . . 49 7.2 Trabalhos Futuros . . . 51 Referências Bibliográficas 52 Apêndice 55 A Gramática de SCR 56 B Regras de Tradução 64 B.1 Tipos . . . 66 B.2 Constantes. . . 68

B.3 Tabelas para Operadores . . . 69

B.4 Representação de Operadores . . . 80

B.5 Operador Principal . . . 82

B.6 Equações do Operador Principal . . . 85

B.7 Assumptions e Assertions. . . 88

B.8 Representação do Operador Principal . . . 89

C Estudo de caso Safety Injection System 93

Lista de Figuras

2.1 Componentes básicos de um sistema de controle. . . 8

2.2 Tabela modelada na ferramenta Tabular Modeller (TTM) referente à Tabela 2.1.. . . 12

2.3 Tabela modelada na ferramenta TTM referente à Tabela 2.2. . . 12

2.4 Tabela modelada na ferramenta TTM referente à Tabela 2.3. . . 13

2.5 Lógica interna do operador Safety Injection System.. . . 14

2.6 Relações entre transformações de programas. . . 16

3.1 Resumo da tradução. . . 20

4.1 Menu de funcionalidades da ferramenta tradutora no Eclipse. . . 32

5.1 Diagrama de atividades da estratégia de verificação. . . 34

5.2 Estudo de caso modelado usando SCR no tradutor. . . 35

5.3 Estudo de caso importado no SCADE após a execução do tradutor. . . . 36

5.4 Tabela de saída do estudo de caso modelada em TTM.. . . 37

5.5 Procedimento de tradução de TTM para VGS. . . 37

5.6 Assumptionmodelada no TTM.. . . 38

6.1 Especificação do Sistema de Injeção de Segurança. . . 42

Lista de Tabelas

2.1 Tabela de transição de modo para a classe de modo mcPressure. . . 8

2.2 Tabela de evento para o termo tOverridden. . . 9

2.3 Tabela condicional para a variável controlada cSafety Injection. . . 9

5.1 Tabela de evento auxiliar para o operador DUR. . . 39

6.1 Tabela de evento para o termo tOverridden. . . 42

6.2 Tabela de transição de modo para a classe de modo mcPressure. . . 43

6.3 Tabela condicional para a variável controlada cSafety Injection. . . 43

6.4 Resultados do Sistema de Injeção de Segurança. . . 44

6.5 Tabela de transição de modo para a classe de modo mcCruise. . . 45

6.6 Tabela de evento para o termo dur tDesiredSpeed true time 1. . . 45

6.7 Tabela de evento para o termo tDesiredSpeed. . . 46

6.8 Tabela condicional para a variável controlada cThrottle. . . 46

6.9 Resultados do Sistema de Controle de Cruzeiro. . . 47

Lista de Códigos

2.1 Tabela mcPressure descrita textualmente. . . 11

2.2 Parte da gramática livre de contexto de SCR obtida de Leonard and Heitmeyer (2003). . . 11

2.3 Operador SCADE descrito em forma textual. . . 15

2.4 Parte do código XML do operador Safety Injection System. . . 15

3.1 Código SCR de declaração de tipos enumeráveis com valores iguais. . . 22

3.2 Código SCR representando uma expressão com apóstrofo. . . 22

3.3 Código XML de SCADE que representa um diagrama textual. . . 24

3.4 Código SCR exemplificando uma Assumption contendo uma variável de saída com valor no estado corrente do sistema. . . 26

4.1 Exemplo de módulo de Syntax Definition Language (SDF). . . 29

4.2 Regra 1 descrita na linguagem do Spoofax. . . 30

5.1 Exemplo de código do arquivo de mapeamento que descreve como um vetor de teste deve ser traduzido para código C. . . 40

5.2 Seção de código do arquivo de mapeamento que descreve como uma instrução de atribuição da variável mBlock será traduzida para código C. 40 5.3 Parte do código gerado após a interpretação do arquivo de mapeamento. 40 6.1 Parte do código SCR do Sistema de Controle de Cruzeiro que contém problemas de ambiguidade. . . 45

A.1 Módulo inicial. . . 56

A.2 Módulo referente a Assumption e Assertion. . . 56

A.3 Módulo referente a constantes. . . 56

A.4 Módulo referente a eventos.. . . 57

A.5 Módulo referente a expressões. . . 57

A.6 Módulo referente a expressões com a possibilidade de terem variáveis em dois estados de sistema consecutivos. . . 59

A.7 Módulo referente a funções. . . 60

A.8 Módulo léxico. . . 61

A.9 Módulo referente a tipos. . . 62

A.10 Módulo referente a variáveis. . . 63

C.1 Estudo de caso Safety Injection System descrito em SCR. . . 93

Lista de Acrônimos

ASM Abstract State Machines

AST Abstract Syntax Tree

CSP Communicating Sequential Processes

DO-178B Software Considerations in Airborne Systems and Equipment Certification

EBNF Extended Backus-Naur Form

FAA Federal Aviation Administration

MCDC Modified Condition/Decision Coverage

NRL U.S. Naval Research Laboratory

SCADE Safety Critical Application Development Environment

SCR Software Cost Reduction

SDF Syntax Definition Language

SGLR Scannerless Generalized LR Parser

TTM Tabular Modeller

VDM Vienna Development Method

VGS Vector Generation System

1

Introdução

Sistemas críticos são aqueles que podem colocar em risco a vida de pessoas, propriedades ou o meio ambiente. Um software crítico, por sua vez, é qualquer software que pode contribuir para tais riscos (Hansen and Wells,2006). Como existe o risco de causar grandes perdas, faz-se necessário regulamentar o desenvolvimento de sistemas críticos criando-se padrões de desenvolvimento e certificações de software e hardware. Os certificados de segurança (safety) de software tentam garantir à sociedade que a construção e comercialização de sistemas críticos não trará grandes riscos (Rushby, 2011). O certificado Software Considerations in Airborne Systems and Equipment Certification (DO-178B), por exemplo, é o padrão adotado pela Federal Aviation Administration (FAA) como guia para determinar se o software de um sistema aeronáutico se comportará de forma confiável (RTCA,1992). Garantir que um determinado sistema está de acordo com um padrão de desenvolvimento e que o mesmo está apto a receber um certificado que permite o seu uso comercial é um dos principais desafios no desenvolvimento de um sistema crítico.

1.1

Problema

Para as entidades certificadoras, os sistemas críticos devem ter todos os artefatos, in-cluindo código e especificação, em conformidade com padrões de qualidade como, por exemplo, o DO-178B. Idealmente, a especificação deveria ser descrita formalmente, permitindo que seja precisa, não ambígua e completa, além de possibilitar ser usada para provar propriedades críticas de um sistema (Leonard and Heitmeyer,2003).

Por outro lado, apenas ter a especificação descrita formalmente não é o suficiente. Os outros artefatos de um sistema, em particular o código (software) implementado que será embarcado em hardware de sistemas críticos, também devem estar em conformidade com

1.2. PROPOSTA DE SOLUÇÃO

padrões de certificação.

É comum fazer uso de métodos formais para descrição de especificações precisas, completas e não ambíguas. Neste sentido, Software Cost Reduction (SCR) é um método formal baseado em tabelas para a descrição de especificações de sistemas de controle. Ele foi originalmente desenvolvido pelo U.S. Naval Research Laboratory (NRL) para documentar a especificação do programa de vôo da aeronave U.S. Navy’s A-7 (Heninger and,U.S.).

Para auxiliar no desenvolvimento de código certificado para sistemas críticos existe a suíte de ferramentas Safety Critical Application Development Environment (SCADE). A linguagem de programação usada pela suíte é também chamada deSCADEe é baseada no paradigma síncrono e na linguagem Lustre (Halbwachs et al.,1991). A suíte possui um ambiente de desenvolvimento e um gerador automático de código que produz código Ccertificado seguindo o padrão DO-178B. Os modelos descritos em SCADE seguem a notação de blocos que se conectam e são o ponto de partida para a geração de código.

Embora seja possível encontrar trabalhos que derivam código a partir de modelos SCR (Leonard and Heitmeyer,2003;Rothamel et al.,2006), bem como o uso independente de SCReSCADEpara modelar e analisar sistemas críticos (Heninger and,U.S.;Heitmeyer and Bharadwaj,2000;Lakehal and Parissis,2007), não encontramos na literatura trabalhos que relatem a integração entreSCReSCADEpara produzir código certificado a partir de especificações formais. A implementação em SCADE de uma especificação SCR só poderia ser alcançada através da modelagem manual de diagramas de SCADE. A integração automática entre SCR e SCADE é tida como um ponto de interesse da indústria, de acordo com o nosso parceiro Embraer S.A.1, pois permite a descrição de especificações completas e não ambíguas através do uso deSCRe a implementação do software crítico usando uma ferramenta já aceita pela indústria.

1.2

Proposta de Solução

A proposta deste trabalho é traduzir especificaçõesSCR, criadas e analisadas na ferra-menta TTM/T-VEC, em termos da linguagem de modelosSCADE. Com isto, a partir de um modeloSCRé possível gerar código certificado viaSCADEde forma automática. Foi escolhida a ferramenta T-VEC principalmente devido ao fato dela permitir a geração de casos de teste a partir de especificações modeladas em SCR e também pela praticidade de acesso à sua licença. O trabalho propõe um conjunto de regras de tradução para tornar

1.3. ORGANIZAÇÃO

possível a integração entre as ferramentas. Apesar de conseguir traduzir praticamente toda a gramática de SCR, o conjunto de regras de tradução ainda possui pequenas limitações que são detalhadas na Seção3.

Apenas a criação das regras de tradução para integrar as duas tecnologias não é o suficiente para as necessidades da indústria. O presente trabalho também inclui um tradutor automático, construído a partir da implementação das regras usando o framework de transformação de software Stratego/XT2 com a ajuda do plugin Spoofax3 para o Eclipse4. O Spoofax tem como objetivo auxiliar o desenvolvimento de transformações de software usando as facilidades do Stratego/XT e do ambiente de desenvolvimento Eclipse.

Para investigar o funcionamento e a corretude da estratégia de tradução do presente trabalho, utilizamos dois exemplos de especificaçãoSCRgerando modelosSCADE cor-respondentes com auxílio do tradutor. Em ambos os exemplos utilizamos uma estratégia de verificação para investigar que os modelos SCADEestão em conformidade com a especificação. A estratégia de verificação consiste em usar T-VEC5(um conjunto de ferramentas que suporta a sintaxe deSCRe possibilita a geração de vetores de testes) para gerar vetores de testes baseados nos exemplos e então aplicar os testes no código C gerado peloSCADE. Apesar de não provarmos a corretude das regras de tradução, os dois estudos de caso exercitam uma quantidade significativa de elementos de SCR fazendo com que os resultados iniciais demonstrem um bom indício de que o conjunto de regras é robusto.

1.3

Organização

O Capítulo 2 apresenta os fundamentos que utilizamos neste trabalho como noções sobre Métodos Formais, SCR, SCADEe transformação de software. O métodoSCR é detalhado explicando de forma sucinta os elementos principais que formam uma especificação, além das ferramentas usadas para auxiliar a modelagem dos estudos de caso. A ferramenta SCADEtambém é apresentada incluindo informações sobre o paradigma de desenvolvimento usado pela ferramenta e como a mesma armazena os modelos.

O Capítulo3 resume o passo-a-passo da tradução e descreve um subconjunto das

2_{http://strategoxt.org/} 3_{http://strategoxt.org/Spoofax} 4_{http://www.eclipse.org/} 5_{http://www.t-vec.com/}

1.3. ORGANIZAÇÃO

regras de tradução elaboradas pelo trabalho. As principais regras criadas para tornar a tradução entre os métodos possível são descritas neste capítulo. O conjunto completo das regras é descrito no ApêndiceB.

O Capítulo4mostra detalhes das ferramentas e linguagens de programação usadas na construção do tradutor. O framework Stratego/XT e o plugin Spoofax são apresentados. O capítulo também inclui informações sobre como as regras são modeladas no framework e como a gramática deSCRfoi modelada usando a Syntax Definition Language (SDF).

O Capítulo5mostra a estratégia de verificação usada pelo trabalho para investigar se a tradução consegue manter o comportamento definido pela especificação após a geração de códigoSCADE. A estratégia é detalhada passo-a-passo através da explicação de um diagrama de atividades.

O Capítulo6descreve os estudos de caso usados no presente trabalho além de analisar o resultado da aplicação da estratégia de verificação. O capítulo também inclui uma avaliação sobre a quantidade de elementos deSCRcobertos pelos exemplos.

Por fim, o Capítulo7finaliza o trabalho citando trabalhos relacionados e apresentando sugestões de trabalhos futuros.

2

Fundamentação Teórica

Este capítulo introduz conceitos e tecnologias que serão usados neste trabalho. Primeira-mente apresentamos alguns conceitos de Métodos Formais para Engenharia de Software. Em seguida, apresentamos o métodoSCR, incluindo a ferramenta de apoio T-VEC. A ferramentaSCADEtambém é detalhada. Por fim, são apresentadas noções teóricas sobre técnicas de transformação de software.

2.1

Métodos Formais

Métodos formais utilizam notações com fundamentação matemática que permitem a especificação, o desenvolvimento e a verificação de sistemas de software e hardware, com o objetivo de aumentar a corretude dos sistemas por mais complexos que sejam. O rigor matemático desses métodos fornece mecanismos para provar que um dado sistema ou componente realmente faz o que era suposto fazer (Woodcock et al.,2009;Davis,2005).

O uso de métodos formais é motivado pelo fato de que, assim como em outras engenharias, o uso de técnicas matemáticas para auxiliar o desenvolvimento de um projeto contribui para a corretude do produto final. É importante notar que o uso de métodos formais não garante a priori a corretude dos sistemas, mas aumenta consideravelmente o seu entendimento revelando inconsistências, ambiguidades e incompletudes que podem passar despercebidas (Clarke and Wing,1996). Fazer uso de métodos formais nas fases iniciais de um projeto auxilia na busca por falhas fazendo com que o custo de correção destas falhas seja muito menor do que em fases posteriores como teste e manutenção. Apesar das muitas vantagens, o uso de métodos formais requer uma curva de aprendizado considerada longa ou mesmo uma formação mais especializada o que acaba dificultando a sua adoção.

de-2.1. MÉTODOS FORMAIS

senvolvimento. A escolha dos métodos formais que serão usados e em quais fases do desenvolvimento serão aplicados dependerá do nível de criticidade do sistema e por quais processos de certificação o mesmo deverá passar.

2.1.1

Especificação Formal

Uma especificação é um artefato que descreve um produto existente ou a ser construído. Especificações de software, por sua vez, descrevem um produto de software. Assim como uma especificação define um produto, é preciso saber identificar se um produto satisfaz uma especificação. É comum na engenharia de software, que as especificações sejam descritas informalmente através de linguagem natural, diagramas ou pseudo-código. Uma especificação é formal se for expressa em uma linguagem de especificação formal, ou seja, uma linguagem que possui uma sintaxe precisa (definida por uma gramática livre de contexto) e que cada sentença possui um significado matemático único correspondente. Especificações formais são usadas como contrato e meio de comunicação entre clientes e desenvolvedores, e também de guia para o desenvolvimento de um sistema. Além disto, uma especificação formal permite ser usada como base para a geração de casos de teste, de simulações e também de análises formais com o objetivo de prever comportamentos não esperados antes da implementação.

Especificações são caracterizadas por terem informações de alto nível omitindo deta-lhes de implementação. O nível de detadeta-lhes definidos em uma especificação dependerá de qual fase do ciclo de vida de desenvolvimento de software a especificação será usada. Em geral, mais informações são omitidas nas primeiras fases do ciclo de desenvolvimento. Como consequência da omissão de informações de implementação, uma especificação pode ter várias implementações possíveis.

Durante o desenvolvimento de um sistema, a especificação formal sofre vários refina-mentos aumentando o seu nível de detalhes. Em certo momento a especificação estará tão detalhada que será facilmente traduzida em uma linguagem de implementação. Vários métodos formais de especificação de software provêem geradores automáticos de código como é o caso doSCADE.

Uma característica de uma especificação formal é a sua precisão. Um dos principais problemas em usar linguagem natural para descrever uma especificação é o fato de que algumas sentenças podem ser ambíguas ou incompletas. Em uma especificação formal, o especificador é forçado a não deixar inconsistências e ambiguidades, já que a mesma possui uma representação matemática única que não permite interpretações ambíguas ou contraditórias.

2.2. SCR

Por terem forte base matemática, as especificações formais permitem serem analisadas matematicamente. Com isto é possível provar propriedades de uma especificação com o objetivo de validá-la, além de verificar possíveis refinamentos. Neste sentido, uma verificação é o ato de investigar se um produto de software (projeto ou código) está de acordo (satisfaz) com sua especificação. Uma verificação é responsável por investigar a corretude de um produto de software em relação a sua especificação. Por outro lado, para investigar se uma especificação descreve corretamente um sistema, pode-se fazer uma validação. Especificações formais podem ser validadas formalmente através da declaração de propriedades na forma de instruções matemáticas. Tais instruções são provadas matematicamente como consequência da especificação. Vale ressaltar que as propriedades devem ser elaboradas manualmente de tal forma que validem características importantes da especificação.

Devida a sua sintaxe precisa, é possível gerar casos de teste automaticamente a partir de uma especificação formal. A ferramenta Vector Generation System (VGS) da suíte T-VEC permite gerar casos de teste a partir de uma especificação formal descrita em uma linguagem com sintaxe baseada emSCR. A execução de uma campanha de testes não garante que um software esteja livre de problemas, porém o conjunto de casos de teste gerados a partir de uma especificação formal de acordo com critérios de cobertura de teste como o Modified Condition/Decision Coverage (MCDC) (Kelly J. et al.,2001) usado pelo guia DO-178B representa uma campanha de testes robusta.

2.2

SCR

O métodoSCRé útil para descrever o comportamento de sistemas de controle usando tabelas. Este método foi inicialmente criado para documentar os requisitos do programa de vôo da aeronave U.S. Navy’s A-7 (Heninger and,U.S.). O método evoluiu e foi usado na prática em alguns sistemas de controle reais incluindo sistemas aeronáuticos, redes de telefonia e componentes críticos de usinas nucleares.

Um sistema de controle genérico é composto por sensores, que captam informações do ambiente externo ao sistema, e atuadores, que modificam o ambiente a partir do processamento das informações oriundas dos sensores. A Figura2.1ilustra de forma resumida os componentes principais de um sistema de controle genérico. Os sensores funcionam como entradas do sistema monitorando o ambiente enquanto os atuadores funcionam como saídas controlando o ambiente.

2.2. SCR

Figura 2.1 Componentes básicos de um sistema de controle. Tabela 2.1 Tabela de transição de modo para a classe de modo mcPressure.

Old mode Event New mode

TooLow @T(mWaterPres ≥ Low) Permitted

Permitted @T(mWaterPres ≥ Permit) High

Permitted @T(mWaterPres < Low) TooLow

High @T(mWaterPres < Permit) Permitted

conjunto de tabelas. As tabelas definem como as variáveis de entrada do sistema, que representam sensores, serão processadas para gerarem valores para as variáveis de saída, que representam atuadores. Cada tabela define quais serão os valores de uma variável de saída ou auxiliar a partir da avaliação de expressões booleanas.

Para auxiliar na explicação sobreSCR, as Tabelas2.1,2.2e2.3em conjunto represen-tam uma versão simplificada da especificação de um sistema de controle para injeção de segurança em uma usina nuclear adaptada deLeonard and Heitmeyer(2003);Heitmeyer et al.(1996). Basicamente o objetivo do sistema é monitorar a pressão da água no reator e, caso a pressão esteja em um nível considerado muito baixo, o sistema injeta uma subs-tância refrigeradora. O sistema especificado possui três entradas (mWaterPres, mBlock e mReset) e uma saída (cSafety Injection) além de duas variáveis internas auxiliares (tOverridden e mcPressure). As Tabelas 2.1,2.2e2.3definem o comportamento das variáveis mcPressure, tOverridden e cSafety Injection respectivamente. Cada tabela é composta de expressões booleanas (predicados), que por sua vez fazem uso das variáveis da especificação. A seguir, os elementos deSCRserão detalhados e o sistema de exemplo será usado para ilustrar tais elementos.

Em SCR existem quatro tipos de variáveis. As variáveis monitoradas e controladas representam quantidades do ambiente que devem ser monitoradas e controladas respec-tivamente (entradas e saídas). Para tornar a modelagem da especificação mais prática

2.2. SCR

Tabela 2.2 Tabela de evento para o termo tOverridden.

Variable Events

@T(mBlock = On) WHEN (mReset = Off AND

NOT(mcPressure = High))

@T(mcPressure = High) OR @T(NOT(mcPressure = High)) OR @T(mReset = On) WHEN NOT(mcPressure = High)

tOverridden’ True False

Tabela 2.3 Tabela condicional para a variável controlada cSafety Injection.

Mode Conditions

High, Permitted True False

TooLow tOverridden NOT tOverridden

cSafety Injection Off On

e eficiente, SCRintroduz duas variáveis auxiliares: termos e classes de modo. Uma classe de modo representa uma máquina de estados, onde os estados são chamados de modos e as transições são disparadas por eventos (por exemplo a variável mcPressure cujo comportamento é definido pela Tabela2.1). Um termo é uma variável de estado, definida pela composição de variáveis monitoradas, classes de modo e outros termos.

Existem dois tipos de predicados em SCR: condições e eventos. Um predicado é uma expressão booleana definida em termos de estados de sistema, os quais são funções que mapeiam cada variável de estado a um valor. Uma variável de estado é qualquer variável monitorada, controlada, ou auxiliar. Um predicado do tipo condição é uma expressão que possui variáveis definidas em apenas um estado do sistema. Diferentemente, um predicado do tipo evento possui variáveis definidas em dois estados de sistema consecutivos (Bravenboer et al.,2005;Heitmeyer and Bharadwaj,2000). A expressão “@T(c) WHEN d”, por exemplo, define um evento que depende de uma condição. O evento será avaliado como verdade caso a expressão c seja verdadeira no estado corrente, falsa no estado anterior, e a expressão d seja verdadeira no estado anterior (Heitmeyer and Bharadwaj,2000).

Para especificar o comportamento de uma variável e sua relação com outras variáveis, existem três tipos de tabelas: tabelas condicionais, de evento e de transição de modo. Cada tabela define, como uma função, o valor de uma variável que está associada à tabela. Uma tabela condicional define o valor de uma variável de controle ou um termo como uma função composta por condições. Semelhantemente, uma tabela de evento descreve o valor de uma variável de controle ou um tempo como uma função composta por eventos. Uma tabela de transição de modo é semelhante a uma tabela de evento, porém específica para definir o comportamento de uma variável de modo. A Tabela

2.2. SCR

2.1 representa uma tabela de transição de modo que define como a classe de modo mcPressuredeve alterar o seu valor dependendo do seu estado inicial. Vale ressaltar que é pelo fato da Tabela2.1definir o comportamento da variável mcPressure, que esta não aparece nas expressões da tabela. Por exemplo, a primeira linha afirma que a variável mcPressureirá mudar seu valor para Permitted se inicialmente estiver em TooLow e a expressão @T(mWaterPres ≥ Low) for avaliada como verdade, ou seja, se a pressão da água se tornar igual ou maior que a constante Low. A Tabela2.2representa uma tabela de evento que define o valor do termo tOverridden dependendo do valor da classe de modo mcPressure. Por fim, a Tabela2.3representa uma tabela condicional que define o valor da variável controlada cSafety Injection também dependendo do valor da classe de modo mcPressure.

Para adicionar restrições a uma especificação,SCRimplementa as seguintes notações: Assumption e Assertion. Uma Assumption descreve as restrições impostas nas variá-veis monitoradas e controladas pelo ambiente em que o sistema modelado se encontra (Leonard and Heitmeyer,2003). Uma Assertion, por sua vez, é usada para verificar propriedades, como por exemplo propriedades de segurança e confiabilidade, que uma especificação deve satisfazer (Leonard and Heitmeyer,2003).

SCRtambém possui em sua semântica duas premissas chamadas One-Input Assump-tione Synchrony Assumption (Heitmeyer et al.,1996;Rothamel et al.,2006). A premissa One-Input Assumption define que exatamente um evento de entrada ocorrerá a cada transição de estado. Ou seja,SCRpermite que apenas uma variável monitorada mude de valor de um estado para outro. Já a premissa Synchrony Assumption obriga que um novo evento de entrada só poderá ocorrer após o sistema ter processado o evento de entrada do ciclo passado. Logo, uma variável monitorada só poderá ter seu valor alterado após o ciclo anterior ter processado por completo todas as entradas.

Para facilitar a comunicação entre ferramentas,SCRpossui uma representação tex-tual. Por exemplo, a Tabela2.1é representada textualmente no Código2.1como uma função com um comando CASE e comandos de evento para cada opção do CASE. Um subconjunto da gramática livre de contexto obtida de Leonard and Heitmeyer (2003) mostrando a sintaxe resumida para tabelas é apresentada no Código2.2. A gramática completa adaptada para o tradutor do presente trabalho está disponível no ApêndiceA.

O Código2.2mostra uma pequena parte da gramática deSCR, na qual uma especi-ficaçãoSCRé composta por uma palavra chave spec, seguida de um identificador (Id), uma lista de definições de tipos (TypeDefs), uma lista de definições de constantes (Cons-tantDefs) e uma lista de definições de variáveis (VarDeclarations) incluindo variáveis

2.2. SCR 1 v a r m c P r e s s u r e : = 2 c a s e m c P r e s s u r e 3 [ ] TooLow 4 ev 5 [ ] @T( m W a t e r P r e s >= Low ) −> P e r m i t t e d 6 ve 7 [ ] P e r m i t t e d 8 ev 9 [ ] @T( m W a t e r P r e s >= P e r m i t ) −> High 10 [ ] @T( m W a t e r P r e s < Low ) −> TooLow 11 ve 12 [ ] High 13 ev 14 [ ] @T( m W a t e r P r e s < P e r m i t ) −> P e r m i t t e d 15 ve 16 e s a c

Código 2.1 Tabela mcPressure descrita textualmente.

1 spec : : = spec Id TypeDefs ConstantDefs VarDeclarations

2 Assumptions Assertions FunctionDefs

3 FunctionDefs : : = function definitions (FunctDef)∗ 4 FunctDef : : = var Id ( == CondTab | := EventTab) 5 CondTab : : = CaseIF | IfStmt

6 CaseIF : : = case Id (CaseBranchIf )+ esac 7 CaseBranchIf : : = [] Id (, Id)∗ I f S t m t

8 IfStmt : : = if ( [] BoolExpr -> Expr)+ fi 9 EventTab : : = CaseEv | EvStmt

10 CaseEv : : = case Id (CaseBranchEv)+ esac 11 CaseBranchEv : : = [] Id ( , Id)∗ EvStmt

12 EvStmt : : = ev ( [] Eventp -> ExprPrime)+ ve

Código 2.2 Parte da gramática livre de contexto de SCR obtida deLeonard and Heitmeyer(2003).

monitoradas, controladas e auxiliares (termos e classes de modo). A especificação ainda inclui uma lista de Assumptions, Assertions e definições de funções (FunctionDefs). As definições de funções começam com as palavras-chave function definitions, seguida de uma lista de funções. Cada função possui uma identificação (Id) e uma tabela de evento ou condicional associada. Uma tabela condicional pode ser composta de uma lista de comandos condicionais IF, ou uma combinação de lista de comandos IF em conjunto com um comando condicional CASE. Semelhantemente às tabelas condicionais, as tabelas de evento possuem a mesma combinação de comandos CASE e IF, porém possuem eventos ao invés de expressões condicionais.

2.2. SCR

Figura 2.2 Tabela modelada na ferramentaTTMreferente à Tabela2.1.

Figura 2.3 Tabela modelada na ferramentaTTMreferente à Tabela2.2.

2.2.1

Ferramentas de Apoio

SCRpossui basicamente duas ferramentas que lhe dão suporte: SCR Toolset e T-VEC. A ferramenta SCR Toolset foi descartada deste trabalho, pois a permissão para uso só é concedida à Agências do Governo Federal dos Estados Unidos.

T-VEC é uma suíte de ferramentas focada no desenvolvimento de especificações e na geração automática de casos de teste. T-VEC inclui o Tabular Modeller (TTM) para o desenvolvimento de especificações fazendo uso de uma linguagem baseada emSCR. O TTMauxilia o desenvolvimento de modelos de requisitos de software. Estes modelos suportam a análise automática de defeitos e a geração de testes a partir do uso integrado da ferramentaVGStambém da T-VEC. Em resumo, a ferramentaTTMmodela requisitos baseados emSCRe traduz estes requisitos para a ferramentaVGS, que por sua vez gera casos de teste.

A ferramenta VGS foi construída a partir de um provador de teoremas dedutível, porém desenvolvida e customizada com foco na geração de vetores de testes. A geração de vetores de testes necessita que um dado requisito seja satisfeito. Em outras palavras, VGStenta satisfazer as restrições das equações de uma expressão de requisito escolhendo valores do domínio finito das variáveis restritas e não restritas das condições pré e pós da expressão. Se o requisito for satisfeito, um vetor de testes é criado contendo valores de entrada que satisfazem as pré-condições e valores de saída que satisfazem as pós-condições. Se o requisito não for satisfeito, T-VEC não poderá criar nenhum vetor de testes para o requisito.

2.3. SCADE

Figura 2.4 Tabela modelada na ferramentaTTMreferente à Tabela2.3.

modelagem dos requisitos na ferramentaTTM. Um modelo de requisitos emTTMé um refinamento dos requisitos de um sistema e descreve os relacionamentos entre as suas entradas e as saídas. As Figuras2.2,2.3e2.4mostram as Tabelas2.1,2.2e2.3modeladas na ferramentaTTM. Em seguida é feita a tradução dos modelos para a ferramentaVGS para tornar possível a verificação do modelo e a geração de casos de teste. A tradução de TTM para VGS é um procedimento automático da própria ferramenta TTM. A ferramenta VGSfunciona como uma primeira análise, identificando contradições e inconsistências no modelo que apontam para possíveis erros na modelagem dos requisitos. Após a correção da modelagem, a ferramentaVGSpode gerar os casos de teste, que por sua vez irão validar os requisitos implementados.

2.3

SCADE

SCADEé um ambiente de desenvolvimento dirigido a modelos e dedicado a software crítico embarcado. Uma das ferramentas incluídas é o gerador automático de código C que gera código em conformidade com as regras do padrão DO-178B nível A.

Um programa modelado emSCADEé constituído por um conjunto de nós operadores, que definem operações complexas. Os nós podem ser conectados uns com os outros através de canais de entrada e saída. Um nó pode também possuir variáveis locais para facilitar a modelagem. Os programas modelados em SCADEdescrevem a evolução paralela de canais de saída fazendo uso de equações confiando no paradigma Synchronous Data Flows. Esta visão de computação é baseada em diagramas de blocos (Lakehal and Parissis,2007) nos quais um sistema é constituído de uma rede de nós operadores atuando em paralelo e em acordo com a frequência de entradas. Um programa deve reagir a qualquer estímulo externo em um tempo limite discreto. Cada instante do tempo discreto representa um ciclo onde entradas são capturadas e processadas e saídas são geradas. Programas modelados emSCADEnão podem explicitamente manipular o tempo, porém as equações de saída podem mencionar o valor de uma variável em um estado anterior do

2.3. SCADE

Figura 2.5 Lógica interna do operador Safety Injection System.

sistema.

Com SCADE também é possível adicionar restrições a um programa através da notação de Assumes e Guarantees. A cláusula Assume corresponde a expectativas de um programa e pode conter em suas expressões entradas com valores do estado atual e anterior do sistema e saídas apenas com valores do estado anterior do sistema. A cláusula Guaranteegarante propriedades de um programa e permite em suas expressões, além dos mesmos valores de variáveis de um Assume, saídas com valores do estado atual do sistema.

A Figura2.5mostra como exemplo a lógica interna de um nó operador se conectando com outros internamente. No lado esquerdo, três entradas são instanciadas (mWaterPres, mBlock e mReset). Três outras variáveis (mcPressure, tOverriden e cSafety Injection) são também instanciadas, resultando em valores do ciclo anterior do sistema devido ao uso do operador last. O uso do operador last realimenta o sistema com informações armazenadas do ciclo anterior. A partir das entradas e das variáveis locais, saem canais de dados que se conectam com três nós internos. Estes nós operadores computam os resultados e os enviam através de outros canais de dados até a saída (cSafety Injection), além de realimentar as variáveis locais para um novo ciclo.

Além da representação gráfica presente na Figura2.5,SCADEtambém possui uma representação textual. O Código 2.3descreve a mesma lógica definida na Figura2.5, porém usando a sintaxe textual deSCADE. As Linhas 1, 2, 3, 4, 6 e 8 definem as entradas do sistema incluindo tanto variáveis de entrada quanto variáveis locais que realimentam o sistema através do uso do operador last. As Linhas 5, 7, e 9 definem as saídas do sistema incluindo as variáveis locais que armazenarão valores para o próximo ciclo. Por fim, as Linhas 10, 11 e 12 representam as chamadas aos outros nós operadores do sistema.

2.3. SCADE 1 L _ i n _ m W a t e r P r e s = m W a t e r P r e s ; 2 L_in_mBlock = mBlock ; 3 L _ i n _ m R e s e t = mReset ; 4 L _ l a s t _ c S a f e t y _ I n j e c t i o n = l a s t ’ c S a f e t y _ I n j e c t i o n ; 5 c S a f e t y _ I n j e c t i o n = L _ i n _ c S a f e t y _ I n j e c t i o n ; 6 L _ l a s t _ t O v e r r i d d e n = l a s t ’ t O v e r r i d d e n ; 7 t O v e r r i d d e n = L _ i n _ t O v e r r i d d e n ; 8 L _ l a s t _ m c P r e s s u r e = l a s t ’ m c P r e s s u r e ; 9 m c P r e s s u r e = L _ i n _ m c P r e s s u r e ; 10 L _ i n _ m c P r e s s u r e = S a f e t y _ I n j e c t i o n _ S y s t e m : : m c P r e s s u r e ( L _ i n _ m W a t e r P r e s , L _ l a s t _ m c P r e s s u r e ) ; 11 L _ i n _ t O v e r r i d d e n = S a f e t y _ I n j e c t i o n _ S y s t e m : : t O v e r r i d d e n ( L_in_mBlock , L _ i n _ m R e s e t , L _ i n _ m c P r e s s u r e , L _ l a s t _ t O v e r r i d d e n ) ; 12 L _ i n _ c S a f e t y _ I n j e c t i o n = S a f e t y _ I n j e c t i o n _ S y s t e m : : c S a f e t y _ I n j e c t i o n ( L _ i n _ m c P r e s s u r e , L _ i n _ t O v e r r i d d e n , L _ l a s t _ c S a f e t y _ I n j e c t i o n ) ;

Código 2.3 Operador SCADE descrito em forma textual.

1 < O p e r a t o r k i n d =" n o d e " name =" S a f e t y \ _ I n j e c t i o n \ _ S y s t e m " > 2 < i n p u t s >< V a r i a b l e name =" m W a t e r P r e s " >

3 < t y p e ><NamedType >< t y p e > 4 < TypeRef name =" yWPres " / > 5 < / t y p e > </ NamedType > </ t y p e > 6 < l a s t > 7 < C o n s t V a l u e v a l u e = " 0 " / > 8 < / l a s t > 9 < p r a g m a s > 10 < ed : V a r i a b l e o i d = " ! ed / 7 eb6 / 3 BEF / D74 / 4 e f 3 2 6 4 0 1 c 0 1 " / > 11 < / p r a g m a s > 12 </ V a r i a b l e > . . . < / i n p u t s > . . . < / O p e r a t o r >

Código 2.4 Parte do código XML do operador Safety Injection System.

(XML) com a extensão .xscade. OXMLno Código2.4exemplifica o conteúdo de um arquivo xscade e mostra uma parte de como o operador da Figura2.5 é armazenado (grande parte do códigoXMLfoi ocultado através do uso de “. . . ”, pois agregariam pouco valor e consumiriam muito espaço desta dissertação). O arquivo de armazenamento inclui informações de equações e operadores além de informações sobre o posicionamento gráfico dos nós ou a ordem das equações caso seja feita opção pelo formato textual.

SCADEinclui o módulo Design Verifier, que é uma ferramenta de verificação formal que auxilia os engenheiros a verificarem a corretude de seus diagramas. Esta ferramenta é usada para verificar requisitos críticos que são usualmente apenas testados e simulados. Ela permite verificar propriedades descritas como expressões booleanas contendo con-dições sobre variáveis booleanas, variáveis de dados e ciclos do sistema. É importante notar que o Design Verifier espera que a expressão avaliada seja verdadeira. Se uma

2.4. TRANSFORMAÇÕES DE PROGRAMAS

Figura 2.6 Relações entre transformações de programas.

propriedade for avaliada como falsa por qualquer combinação de entradas, isso significa que a propriedade é falsificável.

2.4

Transformações de Programas

Neste trabalho fazemos forte uso de técnicas de transformação de software para integrar as tecnologiasSCReSCADE. Esta seção detalha alguns conceitos teóricos sobre técnicas de transformação de software.

Técnicas de transformação de programas estão presentes em várias áreas da enge-nharia de software sendo usadas para síntese, otimização e refatoração de programas e também para engenharia reversa e documentação. Enquanto a estrutura sintática de uma linguagem de programação permite transformações sintáticas de programas, a semântica permite comparar diferentes programas e avaliar tais transformações.

Transformação de programas (Visser,2001) é o ato de alterar um programa gerando outro, que pode ser na mesma linguagem ou não do programa original. A linguagem em que são escritos o programa a ser transformado e o programa a ser gerado são chamadas de fonte e destino.

É possível distinguir dois grandes cenários do uso de transformações: o primeiro é aquele no qual a linguagem fonte e destino são diferentes e no segundo as duas linguagens são as mesmas. Quando as linguagens de fonte e destino são diferentes, a transformação pode ser chamada de tradução. Uma tradução pode ser diferenciada pelo seu efeito no nível de abstração de um programa. Apesar das traduções tentarem preservar a semântica de um programa, em geral não é possível reter todas as informações através de uma

2.4. TRANSFORMAÇÕES DE PROGRAMAS

tradução. A Figura2.6adaptada deVisser(2001) mostra exemplos de diferentes tipos de transformações.

• Síntese: A síntese de programas é uma classe de transformações na qual o nível de abstração de um programa é alterado para um nível mais baixo. Em geral as informações de alto nível do programa são trocadas por estruturas mais eficientes, porém mais complexas. O refinamento de software é um tipo de síntese onde uma implementação é derivada de uma especificação de alto nível (Smith,1990). Uma compilação é outro tipo de síntese na qual uma linguagem de alto nível é convertida para código de máquina (Muchnick,1997). Outros exemplos de síntese são parser e pretty-printer muito úteis para manipulação de gramáticas livres de contexto (van den Brand and Visser,1996);

• Migração: Na migração, um programa é transformado em outra linguagem no mesmo nível de abstração. Pode ser a tradução entre dialetos de uma mesma lin-guagem, como Fortran 77 e Fortran90, ou mesmo a tradução entre duas linguagens distintas como portar um programa Pascal para C;

• Engenharia Reversa A engenharia reversa tem como objetivo extrair um programa descrito em alto nível ou mesmo uma especificação a partir de um programa de baixo nível. A engenharia reversa eleva o nível de abstração e é o inverso da síntese. Os exemplos do uso de engenharia reversa incluem a geração de documentação e a extração de detalhes arquiteturais descritos em uma linguagem de modelagem como UML;

• Análise A análise tem como objetivo reduzir um programa para apenas um de seus aspectos, como por exemplo, o seu fluxo de dados ou de controle. Logo, uma análise é a transformação para uma sub-linguagem que representa apenas uma parte do programa de fonte;

• Reformulação Reformulações são transformações de programas nas quais a lingua-gem de fonte e destino são as mesmas. A reformulação tem como objetivo descrever um mesmo programa de outra maneira para tentar melhorar algum aspecto do pro-grama, como por exemplo seu desempenho ou coesão. A reformulação pode ser dividida em vários cenários incluindo normalização, otimização, refatoração e renovação.

A proposta desta dissertação de traduzir especificaçõesSCRparaSCADEpode ser classificada como uma síntese. A construção de uma transformação complexa é, em

2.4. TRANSFORMAÇÕES DE PROGRAMAS

geral, alcançada através do uso de um número consecutivos de pequenas transformações. Para isso se faz uso de regras e estratégias de transformações. Enquanto uma regra de transformação é um formalismo para descrever um pequeno passo na transformação de um programa, uma estratégia combina um conjunto de regras para alcançar uma transformação mais complexa. Mais informações sobre regras de transformação são apresentadas no Capítulo3.

3

Regras de Tradução

Nesta seção, a transformação de especificaçõesSCRem modelosSCADEatravés do uso de regras de tradução é detalhada. Espera-se que uma especificaçãoSCRseja correta e consistente antes de aplicar as regras. Conforme foi citado no Capítulo2, uma regra de tradução é um formalismo para expressar transformações de código (Bravenboer et al., 2005). A expressão

[[p1]]RuleName_{I p2}

proviso Pred 

representa uma regra de tradução genérica, expressando que um fragmento de programa que segue o padrão p1 do lado esquerdo da regra (um construtor da gramática deSCR) será reescrito seguindo o padrão p2 do lado direito da regra (um construtor deSCADE ou outros fragmentos deSCR). Nota-se, porém, que uma regra assim só será disparada se o predicado Pred, definido após o proviso, for verdade. Esta seção mostra apenas um subconjunto de todas as 146 regras de tradução criadas para este trabalho. Todas as outras regras de tradução podem ser encontradas no ApêndiceA.

Para um completo entendimento das regras descritas nesta seção, é importante en-tender algumas notações complementares. A notação representada pela Equação 3.1 abaixo

hElementoi a Lista 3.1

representa uma lista de elementos onde o elemento inicial é destacado através dos caracteres h i. O caractere a representa o operador de concatenação de listas. Para representar conjuntos, são usadas chaves para conter elementos separados por vírgulas. Por exemplo, {1, 2, 3} é o conjunto contendo os elementos 1, 2 e 3. Por outro lado, elementos separados por vírgulas entre parenteses representam tuplas. Por exemplo, (1, 2, 3) é a tupla contendo os elementos 1, 2 e 3.

Figura 3.1 Resumo da tradução.

A Figura3.1resume como o conjunto de regras de tradução transforma uma especifi-caçãoSCR. De forma bem simplificada, a tradução gera um operador emSCADEpara cada tabela deSCR. Esses operadores possuem o mesmo comportamento e as mesmas entradas e saídas da tabela que representam. Em uma especificaçãoSCR, só é possível obter o resultado final do processamento de um ciclo após o processamento de todas as tabelas em conjunto. Para replicar este comportamento, a tradução gera um operador extra emSCADEque irá coordenar o processamento entre os diversos operadores criados. Este operador extra é chamado de operador principal e representa toda a especificação.

3.1. REGRAS PRINCIPAIS

3.1

Regras Principais

A seguir serão apresentadas algumas das regras de tradução com o objetivo de ilus-trar detalhes da estratégia de tradução elaborada no presente trabalho. A estratégia de tradução começa com a Regra1, que recebe como entrada uma especificaçãoSCR completa e produz alguns fragmentos de código SCADE além de fazer chamadas a outras regras de tradução. O códigoSCADEconcreto criado declara um pacote de nome SpecName, uma serie de declarações delimitadas pela tag <declarations>. . . </ declara-tions>correspondendo a definições de tipos ([[Types]]Types), declarações de constantes ([[Constants]]Constants), definições de operadores ([[(Vars, Functions, [[Types]]TypesIdSet∪ [[Constants]]ConstIdSet)]]Operators) e a criação de um operador principal que conectará os outros operadores ([[(SpecName, Vars, Assume, Assert, Functions)]]MainOperator). Neste trabalho, quando a parte de código XML do lado direito de uma regra de tradução for simples, ele será descrito explicitamente. Para blocos de código XML muito longos ou complexos, preferiu-se encapsula-los em funções abstratas para melhorar a legibilidade do trabalho.

Rule 1. [[spec SpecName Types Constants Vars Assume Assert Functions]]spec_I <Package name="SpecName"> <declarations>

[[Types]]Types [[Constants]]Constants

[[(Vars, Functions, [[Types]]TypesIdSet∪ [[Constants]]ConstIdSet_)]]Operators

[[(SpecName, Vars, Assume, Assert, Functions, [[Types]]TypesIdSet ∪ [[Constants]]ConstIdSet_)]]MainOperator

</declarations>[[SpecName]]Pragmas </Package> 

3.1.1

Tipos

Para cada definição de tipo emSCR, um tipo é criado emSCADE. Diferentemente de SCR,SCADEnão suporta definição de limites para tipos numéricos. Assim, na Regra2 um tipo inteiro com limites entre Sint1 e Sint2 é transformado em um tipo inteiro em SCADEdesconsiderando os limites.

Para corrigir esta limitação, um conjunto de Assumes e Guarantees são criados no decorrer da tradução para limitar as entradas e saídas que são de algum tipo numérico que possui restrições emSCR.

Rule 2. [[(ID, integer in [Sint1, Sint2])]]UdType_I

3.1. REGRAS PRINCIPAIS

Outra limitação deSCADEcomparado comSCR, é o fato de queSCADEnão suporta enumeradores diferentes com valores com nomes iguais. Por exemplo, o Código 3.1 ilustra dois tipos enumeráveis declarados em SCRonde ambos possuem B e C como opções de valores. Em SCADE isso não é possível.

1 t y p e _ A : enum i n {A , B , C } ; 2 t y p e _ B : enum i n {B , C , D} ;

Código 3.1 Código SCR de declaração de tipos enumeráveis com valores iguais.

Atualmente a tradução não suporta especificaçõesSCRque possuam esses elementos. É necessário ajustar a especificação antes de aplicá-la à tradução. A Regra3manipula uma lista de enumeradores criando uma tagXMLpara cada elemento da lista. O Atributo oid da tag ed:Value define um identificador para cada enumerador. O termo !ed do atributo oid é um termo inicial padrão doSCADEpara identificadores.

Rule 3. [[(ID, hCaseValueiaCaseVList)]]EnumValue_I <Value name="CaseValue"><pragmas>

<ed:Value oid="!ed/enumValue/ID CaseValue"/></pragmas></Value>

[[(ID, CaseVList)]]EnumValue 

3.1.2

Constantes

Semelhantemente a tradução de tipos, uma constante é criada em SCADE para cada constante definida em SCR. A tradução de uma lista de constantes é resolvida pela Regra4. A declaração do tipo da constante é traduzida pelo termo [[Type]]TypeInstancee a expressão que define o valor da constante pelo termo [[(0, Expr)]]Expression. O parâmetro 0 indica que a tradução da expressão não levará em consideração o apóstrofo de uma variável tratando todas as variáveis da expressão a ser traduzida como variáveis do estado corrente. Por exemplo, a expressão apresentada no Código3.2mostra que a variável A foi declarada com um apóstrofo enquanto a variável B não. Isto indica que, para fins de cálculo, serão usados o valor no ciclo corrente da variável A e o valor no ciclo anterior da variável B.

1 A’ > B

Código 3.2 Código SCR representando uma expressão com apóstrofo.

Rule 4. [[hID = Expr : Type;iaConstantList]]ConstantDef _I <Constant name="ID"><type>[[Type]]TypeInstance</type> <value>[[(0, Expr)]]Expression</value>

3.1. REGRAS PRINCIPAIS

<pragmas><ed:Constant oid="!ed/Constant/ID"/>

</pragmas></Constant>[[ConstantList]]ConstantDef 

3.1.3

Eventos

A Regra5traduz um evento deSCR. Como explicado no Capítulo2.2, a notação “@T(c)” define um evento que será considerado verdadeiro se c for verdade no estado corrente do sistema e for falso no estado anterior. A regra cria um operador AND com dois argumentos. O primeiro argumento é o resultado de um operador Unary-NOT que nega a expressão BoolExpr. O segundo argumento é a própria expressão BoolExpr. Em SCR, quando uma variável não é seguida de um apóstrofo em uma expressão de evento, isso indica que o valor da variável será o do ciclo anterior do sistema. O número 1 passado como argumento na regra [[(1, BoolExpr, IdSet)]]Expression entre as tags UnaryOp indica que, para a expressão a ser traduzida, cada variável que não possuir um apóstrofo retornará seu valor no estado anterior do sistema. Quando é passado o número 0 como argumento, a expressão não levará em consideração o apóstrofo de uma variável tratando todas as variáveis da expressão a ser traduzida como variáveis do estado corrente, semelhantemente ao que ocorre na Regra [[(0, Expr)]]Expression descrita na Seção3.1.2.

Rule 5. [[(Flag, @T(BoolExpr), IdSet)]]Expression_I

<NAryOp operator="and"><operands><UnaryOp operator="not"> <operand>[[(1, BoolExpr, IdSet)]]Expression</operand>

</UnaryOp>[[(0, BoolExpr, IdSet)]]Expression</operands></NAryOp> 

3.1.4

Tabelas

Para cada tabela deSCR, a tradução cria um nó operador emSCADE. Este comporta-mento é definido pela Regra6. As variáveis monitoradas, controladas, os termos e as classes de modo são concatenadas em uma lista de declarações de variáveis chamada AllVarDecls. Esta lista será útil para regras internas poderem casar padrão entre entra-das, saídas e variáveis locais deSCADEcom as variáveis definidas emSCR. O termo [[(AllVarDecls, FunctName)]]TypeFindretorna o tipo da variável cujo nome é igual ao nome da tabela FunctName.

A lista das entradas necessárias para o nó operador que será criado é extraída do conteúdo da tabela em questão. A saída do nó operador é a própria variável cujo comportamento a tabela define. O resultado da Regra6é uma sequencia de equações em formato textual que representa o conteúdo e o comportamento de uma tabela deSCR.

3.1. REGRAS PRINCIPAIS

Rule 6. [[(monitored variables MDecls; controlled variables CDe-cls;

term variablesTDecls; mode classes MCDecls;, FunctName, TableData, ConstTypeIdSet)]]CreateOperator_I <Operator kind="node"name="FunctName">

<inputs>[[(AllVarDecls, TableData, FunctName)]]InputsTable</inputs> <outputs>[[([[(AllVarDecls, FunctName)]]VarFind, FunctName)]]OutputTable </outputs><locals>[[([[(AllVarDecls, FunctName)]]TypeFind,

AllVarDecls, FunctName, TableData)]]LocalsTable

</locals><data>[[(FunctName, TableData, ConstTypeIdSet)]]TableLogic </data><pragmas><ed:Operator oid="!ed/op FunctName» <diagrams>[[(FunctName, TableData)]]TableDiagramBase</diagrams> </ed:Operator></pragmas></Operator>

where AllVarDecls = MDecls a CDecls a TDecls a MCDecls  Para finalizar a criação de nós operadores deSCADE, é necessário gerar também código referente a como o nó será apresentado na ferramenta. Como explicado na Seção 2.3,SCADEpossui dois tipos de diagramas: textual e gráfico. As regras foram modeladas para gerarem nós em formato textual devido a simplicidade para gerar esta representação comparada com os diagramas gráficos. O Código 3.3 exemplifica o código XMLde um diagrama textual de SCADE. Algumas seções do código XML foram substituídas por “. . . ” para facilitar a sua leitura. A Linha 1 declara um diagrama textual nomeando-o. A Linha 2 inicia a seção de elementos de apresentação, na qual cada elemento será uma instrução textual de SCADE.

1 < T e x t D i a g r a m name =" d i a g r a m _ c S a f e t y _ I n j e c t i o n " . . . > 2 < p r e s e n t a t i o n E l e m e n t s > 3 <FlowTE p r e s e n t a b l e = " ! ed / E x p r / m c P r e s s u r e / C a s e / 0 " / > 4 <FlowTE p r e s e n t a b l e = " ! ed / E x p r / TooLow / i f T h e n E l s e / 0 " / > 5 . . . 6 <FlowTE p r e s e n t a b l e = " ! ed / E x p r / m c P r e s s u r e / C a s e O u t / 0 " / > 7 </ p r e s e n t a t i o n E l e m e n t s > 8 < / T e x t D i a g r a m >

3.1. REGRAS PRINCIPAIS

3.1.5

Operador Principal

Após criar um nó operador para cada tabela deSCR, a tradução cria mais um nó operador para representar toda a especificação. Este nó faz chamadas aos outros nós que represen-tam as tabelas deSCR. As variáveis monitoradas de uma especificação são traduzidas para entradas do nó, as variáveis controladas para saídas e os termos e classes de modo são traduzidas para variáveis locais.

A Regra7constrói um operador principal que contém toda a lógica descrita na espe-cificação. O termo [[(SpecName, VarDecls, Functs)]]VarDeclsMainda regra cria as entradas, saídas e variáveis locais do operador principal. Adicionalmente, o termo [[(SpecName, VarDecls, Functs)]]FunctionsMain gera as equações, que em combinação com as entradas, saídas, variáveis locais e outros nós, compõem o comportamento da especificação. A tradução dos Assumptions e Assertions é feita pelos termos [[(IdSet, Assume)]]Assumptions e [[(IdSet, Assert)]]Assertions, que são detalhados na Seção 3.1.6. Finalmente, o termo [[(SpecName, VarDecls, Functs, Assume, Assert)]]MainPragmascria a tag TextDiagram, que encapsula os elementos de apresentação textual dos nós.

Rule 7. [[(SpecName, VarDecls, Assume, Assert, Functs, IdSet)]]MainOperator I <Operator kind="node"name="SpecName">

[[(SpecName, VarDecls, Functs)]]VarDeclsMain

<data>[[(SpecName, VarDecls, Functs)]]FunctionsMain

[[(IdSet, Assume)]]Assumptions [[(IdSet, Assert)]]Assertions</data>

[[(SpecName, VarDecls, Functs, Assume, Assert)]]MainPragmas</Operator> 

3.1.6

Assumptions and Assertions

As regras de tradução criam um Assume de SCADEpara cada Assumption de SCRe um Guarantee de SCADE para cada Assertion deSCR. É importante notar que um AssumedeSCADEsuporta, em suas equações, saídas apenas com referência a valores do ciclo anterior do sistema. Como os Assumptions deSCRsuportam saídas com valores do estado anterior ou do estado corrente, nossas regras de tradução apenas suportam especificaçõesSCRque não possuem Assumptions com saídas em suas equações que fazem referência ao valor do estado corrente. Por exemplo, o Código3.4contém uma Assumptionde SCR que possui em sua expressão uma variável de saída no estado corrente do sistema. A variável output em conjunto com um apóstrofo representa uma variável de saída cujo valor a ser levado em consideração na expressão é o do estado corrente do sistema. Esse tipo específico de expressão não é passível de tradução de acordo com o

3.1. REGRAS PRINCIPAIS

conjunto de regras proposto neste trabalho.

1 a s s u m p t i o n s

2 N1 : ( o u t p u t ’ − o u t p u t ) <= 1 0 0 ;

Código 3.4 Código SCR exemplificando uma Assumption contendo uma variável de saída com valor no estado corrente do sistema.

A Regra 8 cria uma tag Assertion com “assume” como sendo o tipo da tag para cada Assumption de uma especificação. O termo [[(1, Predicate, IdSet)]]Expression traduz a expressão Predicate.

Rule 8. [[(IdSet, assumptions hID PredicateiaAssumList)]]Assumptions_I <Assertion kind="assume"name="A ID»<definition>

[[(1, Predicate, IdSet)]]Expression </definition><pragmas>

<ed:Assertion oid="!ed/assume/ID"/></pragmas></Assertion>

4

Tradutor

Após descrever as regras de maneira textual, o próximo passo foi construir uma ferra-menta tradutora. Para construir a ferraferra-menta de forma a se aproximar ao máximo das regras de tradução introduzidas no capítulo anterior, foi usado o framework de transfor-mação Stratego/XT (Bravenboer et al.,2008). O Stratego/XT, dentre outras soluções de transformação de software, é o que possui uma linguagem de programação de regras de transformação que mais se aproxima da sintaxe usada para definir as regras na Seção3. Este capítulo detalha como o Stratego/XT funciona e como as regras de tradução foram modeladas.

4.1

Stratego/XT e Spoofax

Stratego/XT é uma linguagem e também ferramenta para transformações de programas. O termo Stratego é referente a uma linguagem de transformação de programas baseada em regras e estratégias de tradução. O termo XT é referente a uma coleção de ferramentas de transformações, reusáveis e extensíveis, como por exemplo geradores de parser e pretty-print.

Stratego/XT suporta o desenvolvimento de transformações em um alto nível de abstração fazendo uso de regras de tradução para expressar transformações básicas, de estratégias de tradução para controlar a aplicação das regras, de sintaxe concreta para expressar padrões de regras na sintaxe da linguagem de entrada, e de regras de tradução dinâmicas para expressar transformações sensíveis ao contexto (Bravenboer et al.,2008).

Em Stratego/XT, uma regra possui a seguinte forma:

4.2. SYNTAX DEFINITION FORMALISM

Na Equação4.1, R é o nome da regra, p1 representa o padrão de entrada da regra e p2 o padrão de saída da regra. Um padrão é composto por termos com variáveis e um termo é uma estrutura da seguinte forma:

c(t1, . . . , tn)   4.2 onde c é um construtor e ti(1 ≤ i ≤ n) representam outros termos.

Para definir quais serão os termos de uma linguagem a ser transformada, é necessá-rio fornecer a gramática da linguagem modelada usando o formalismoSDF, o qual é uma meta-sintaxe usada para definir gramáticas livre de contexto. As ferramentas do conjunto XT dependem da tecnologia de parsing deSDFpara fornecer um gerador de interpretadores além de um Scannerless Generalized LR Parser (SGLR) (Visser,1997).

Atualmente, Stratego/XT faz parte do ambiente de desenvolvimento Spoofax Lan-guage1, que nada mais é do que uma plataforma para o desenvolvimento de linguagens específicas de domínio incluindo o auxílio completo de um ambiente de desenvolvimento baseado no Eclipse2. O Spoofax foi usado no desenvolvimento da ferramenta tradutora deste trabalho.

4.2

Syntax Definition Formalism

O SDF(Heering et al.,1989) é uma meta-sintaxe usada para definir gramáticas livre de contexto. Além de permitir a definição de uma gramática, o uso de SDFpermite gerar um parser referente à gramática descrita. Um parser é uma ferramenta que recebe como entrada um bloco de código da linguagem descrita na gramática emSDFe retorna uma estrutura de dados em árvore representando o código de entrada de forma mais estruturada.

Uma definição de sintaxe descrita emSDFé construída através de um conjunto de módulos. Cada módulo é uma estrutura que encapsula parte de uma gramática e importa definições de outros módulos, além de exportar as suas próprias. As definições de um módulo consistem de um conjunto de tipos que representam construtos específicos da linguagem.

Semelhantemente à Extended Backus-Naur Form (EBNF),SDFdefine uma gramática através de um conjunto de regras contendo símbolos terminais e não-terminais. EmSDF, uma regra apresenta primeiramente os símbolos terminais e não terminais e logo em seguida o nome da regra. Como um primeiro passo para construir o tradutor,SCRfoi

1_{http://strategoxt.org/Spoofax} 2_{http://www.eclipse.org/}