Geração mecanizada de abstrações seguras para especificações CSP

Texto

(1)Universidade Federal de Pernambuco Centro de Informática. Pós-gradua¸cão em Ciência da Computa¸cão. ˜ MECANIZADA DE GERAC ¸ AO ˜ ABSTRAC ¸ OES SEGURAS PARA ˜ ESPECIFICAC ¸ OES CSP Adriana Carla Damasceno ˜ DE MESTRADO DISSERTAC ¸ AO. Recife 29 de maio de 2008.

(2)

(3) Universidade Federal de Pernambuco Centro de Informática. Adriana Carla Damasceno ˜ MECANIZADA DE ABSTRAC ˜ GERAC ¸ AO ¸ OES SEGURAS PARA ˜ ESPECIFICAC ¸ OES CSP. Trabalho apresentado ao Programa de P´ os-gradua¸ c˜ ao em Ciˆ encia da Computa¸ c˜ ao do Centro de Inform´ atica da Universidade Federal de Pernambuco como requisito parcial para obten¸ c˜ ao do grau de. Mestre em Ciˆ encia da Com-. puta¸ c˜ ao.. Orientador: Prof. Dr. Alexandre Cabral Mota. Recife 29 de maio de 2008.

(4) Damasceno, Adriana Carla Geração mecanizada de abstrações seguras para especificações CSP / Adriana Carla Damasceno – Recife: O Autor, 2008. xix, 83 p. : il., fig., tab. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2008. Inclui bibliografia. 1. Engenharia de software. I. Título. 005.1. CDD (22.ed.). MEI2008-076.

(5) Aos meus pais, que sempre foram meu porto seguro..

(6)

(7) AGRADECIMENTOS Aos meus pais, Gloria e Damasceno, por me darem todo o suporte emocional e financeiro que puderam durante toda a minha vida. Ao meu irmão Juan Damasceno, por me esclarecer d´ uvidas sobre a linguagem de programa¸cão Java, necessária para elabora¸cão de projetos das disciplinas, e por sempre me apoiar nos momentos de desafio. Aos amigos “velhos”de Jacumã, Luziene, Otac´ılio e aos “intrometidos”que sempre passam por lá. Sem essas pessoas, não seria poss´ıvel minha fam´ılia ser tão maravilhosa como é. ` familia Calumbi, que considero como meus “parentes de cora¸caõ”, por tanta bonA dade, preocupa¸caõ, aten¸caõ e desprendimento. ` Maria Célia e Formiga, que sempre me mostraram o quão digno é o of´ıcio do ensino, A sendo em grande parte responsáveis pela minha decisão em cursar mestrado. ` colegas de apartamento Josilene Aires, e Roberta Queiroz, pelo companheirismo e As coopera¸caõ. Aos amigos do CIn, Marcos Dósea, Juliana Arruda, Rafael Duarte, Márcio Ribeiro, Rodrigo Bonifácio, Carlos Pontual e Leopoldo Motta pelo conv´ıvio diário, paciência, aten¸cão e amizade constantes. Finalmente, gostaria de agradecer a Alexandre Mota e Adalberto Farias, por tantos conselhos em rela¸cão ao desenvolvimento e escrita da disserta¸caõ, assim como incentivo para que ela fosse conclu´ıda. Mais do que isso, gostaria de agradecer a Alexandre Mota por toda a paciência e inje¸co˜es de ânimo ao longo da execu¸caõ desse projeto.. vii.

(8)

(9) A verdadeira medida de um homem n˜ ao ´ e como ele se comporta em momentos de conforto e conveniˆ encia, mas como ele se mant´ em em tempos de controv´ ersia e desafio. — MARTIN LUTHER KING JR.

(10)

(11) RESUMO Com a crescente demanda por diminui¸cão de custos no desenvolvimento de software, há a necessidade de que os programas possam ser constru´ıdos de acordo com uma especifica¸caõ concordante com os requisitos do cliente. Nesse sentido, a especifica¸caõ formal pode ser utilizada para representar os requisitos do sistema. Uma vez que a especifica¸caõ formal foi desenvolvida, ela pode ser usada como base para investigar determinadas propriedades através de um verificador de modelos. Ele aceita modelos e propriedades que o sistema final deve satisfazer. Então, a ferramenta gera uma resposta positiva se um dado modelo satisfaz uma dada especifica¸cão ou um contra-exemplo, em caso negativo. O contra-exemplo detalha a situa¸caõ em que o modelo não foi satisfeito. Mas na maioria das vezes, problemas do mundo real não podem adotar essa abordagem porque usam dom´ınios infinitos (levando ao problema da explosão de estados). Como forma de resolver essa questão, técnicas de abstra¸cão de dados são empregadas para gerar especifica¸co˜es abstratas finitas a partir de sistemas infinitos concretos. A linguagem de especifica¸cão usada nesse trabalho é CSP (Communicating Sequential Processes). Ela é uma linguagem formal que é usada para descrever padrões de intera¸cão em sistemas concorrentes. Uma das técnicas de abstra¸caõ para especifica¸cões poss´ıveis para essa linguagem é a abstra¸caõ segura de dados. Essa abstra¸caõ visa gerar um modelo abstrato a partir de um equivalente concreto que conserve as propriedades do sistema com respeito ao comportamento (modelo de traces) através da escolha de um dado do dom´ınio abstrato para cada subconjunto do dom´ınio concreto. O objetivo desse trabalho é propor um algoritmo para gera¸caõ mecanizada de abstra¸cões seguras para sistemas CSP seq¨ uenciais com recursão simples. A especifica¸caõ do algoritmo é apresentada usando o paradigma funcional e elementos da linguagem Z, com a introdu¸cão da estratégia através de exemplos. No estudo de caso, o software Mathematica é usado para instanciar os valores das variáveis e realizar a simplifica¸caõ dos predicados constru´ıdos a partir desse algoritmo. Com esse trabalho, é poss´ıvel gerar abstra¸cões seguras de forma mecânica, e por conseq¨ uência verificar o comportamento de modelos infinitos. Ademais, a gera¸cão de dados de testes automática também é beneficiada, já que com o dom´ınio abstrato dos dados é poss´ıvel percorrer todos os caminhos do sistema, gerando 100% de cobertura do modelo. Esse esfor¸co é justificado pela importância que a fase de testes tem para a qualidade do software. Estudos prévios mostraram que essa fase demanda mais de 50% do custo de seu desenvolvimento, e uma pesquisa detalhada realizada nos Estados Unidos quantifica os altos impactos econômicos de uma infra-estrutura de software inadequada. Palavras-chave: Abstra¸cão de dados, gera¸caõ de dados de testes, CSP xi.

(12)

(13) ABSTRACT The need for minimizing costs in software development demands programs to be built according to a specification in agreement with costumer requirements. In this way, a formal specification can be used to represent system requirements. Once the formal specification is developed, it can be used to support the analysis of certain properties through a model checker. It accepts models and properties that the final system must fulfill. Therefore, this kind of tool generates a positive answer if a certain model fulfills a specification or a counter-example, if not. The counter-example details the situation in which the model was not satisfied. However, most of the times problems from real world cannot be adopted by this approach, as they use infinite domains (leading to state explosion problem). As a way of solving this issue, data abstraction techniques are employed to generate finite abstract specifications from concrete infinite systems. The specification language used in this work is CSP (Communicating Sequential Processes). It is a formal language used to describe interaction patterns in concurrent systems. One of the possible abstractions techniques for this language specification is safe abstraction. This type of abstraction generates an abstract model from its concrete one, preserving system properties at behavior level (traces model), through the selection of one element from the abstract domain for each partition in the concrete domain. The purpose of this work is to present an algorithm to mechanically generate safe abstractions for sequential CSP systems with simple recursion. The specification is presented using the functional paradigm and elements from the Z language, introducing the strategy with examples. In the case study, the Mathematica software is used to instantiate variable values and perform predicate simplifications built from this algorithm. With the results of this work, it is possible to generate safe abstractions mechanically, and consequently verify the behavior of infinite systems, as well as generating a data set which can be applied to a system, performing all its paths with 100% code coverage. This effort is needed because test phase has many influence in software quality. Recent studies show that this phase demands more than 50% of the total software cost development, and a detailed research performed in United States quantifies the high economic impacts of a unsuitable software infrastructure. Keywords: Data abstraction, data test generation, CSP. xiii.

(14)

(15) ´ SUMARIO. Cap´ıtulo 1—Introdu¸c˜ ao 1.1. 1. Organiza¸caõ da Disserta¸caõ . . . . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 2—CSP 2.1 2.2. 2.3. 2.4 2.5 2.6. 7. Introdu¸caõ . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sintaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Expressões . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1.1 Identificadores . . . . . . . . . . . . . . . . 2.2.1.2 Inteiros . . . . . . . . . . . . . . . . . . . . 2.2.1.3 Booleanos . . . . . . . . . . . . . . . . . . . 2.2.1.4 Conjuntos . . . . . . . . . . . . . . . . . . . 2.2.1.5 Seq¨ uências . . . . . . . . . . . . . . . . . . 2.2.1.6 Tuplas . . . . . . . . . . . . . . . . . . . . . 2.2.2 Canais e Eventos . . . . . . . . . . . . . . . . . . . . 2.2.2.1 Tipos de Comunica¸cão . . . . . . . . . . . . 2.2.3 Casamento de Padrões . . . . . . . . . . . . . . . . . 2.2.4 Processos . . . . . . . . . . . . . . . . . . . . . . . . Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Semântica Algébrica . . . . . . . . . . . . . . . . . . 2.3.2 Semântica Operacional . . . . . . . . . . . . . . . . . 2.3.2.1 LTS e Firing Rules . . . . . . . . . . . . . . 2.3.3 Semântica Denotacional . . . . . . . . . . . . . . . . 2.3.3.1 O Modelo de Traces . . . . . . . . . . . . . Refinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifica¸caõ de Modelos e Suporte a Ferramentas para CSPM Considera¸co˜es Finais . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 3—Abstra¸c˜ ao de Dados e Gera¸c˜ ao de Dados de Teste 3.1 3.2 3.3. 4. ´ Abstra¸co˜es Segura e Otima para CSP . . . . . . . . . . Independência de Dados . . . . . . . . . . . . . . . . . Gera¸caõ de Dados de Testes . . . . . . . . . . . . . . . 3.3.1 Gera¸caõ de Dados de Teste Estática e Dinâmica 3.3.2 Técnicas de Gera¸cão de Dados de Testes . . . . 3.3.2.1 Software Mathematica . . . . . . . . . 3.3.3 Sele¸caõ de Caminhos . . . . . . . . . . . . . . . xv. . . . . . . .. . . . . . . .. 7 8 8 8 8 8 9 9 9 9 10 10 11 13 13 14 14 16 16 17 17 18 19. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 19 22 24 26 28 29 31.

(16) ´ SUMARIO. xvi. 3.4. 3.3.4 Desafios em Gera¸caõ de Dados de Teste . . . . . . . . . . . . . . . Considera¸co˜es Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 4—Gera¸c˜ ao Autom´ atica de Abstra¸c˜ ao Segura de Dados 4.1 4.2 4.3 4.4. Abstra¸caõ Segura: Estratégia de Obten¸caõ Abstra¸caõ Segura: Algoritmo . . . . . . . Abstra¸caõ Segura × Cobertura de Testes . Considera¸co˜es Finais . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 37 . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. Cap´ıtulo 5—Estudo de Caso 5.1 5.2 5.3 5.4. Apresenta¸cão do Problema . . . . . Especifica¸caõ do Problema . . . . . Aplica¸caõ da Estratégia . . . . . . 5.3.1 Passo-a-passo do Algoritmo Considera¸co˜es Finais . . . . . . . .. 37 55 60 61 63. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. Cap´ıtulo 6—Conclus˜ oes 6.1 6.2. 33 34. Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63 64 65 65 71 73 74 75.

(17) LISTA DE FIGURAS. 2.1. Exemplos de LTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. 3.1 3.2 3.3 3.4 3.5 3.6 3.7. Arquitetura de um sistema de gera¸caõ de dados de teste [Edv99] Código que troca dois inteiros e sua árvore de execu¸caõ [VPK04] Abordagem dinâmica de gera¸cão de dados de teste [Kap04] . . . Ambiente do software Mathematica . . . . . . . . . . . . . . . . Uso das fun¸cões FindInstance e Reduce . . . . . . . . . . . . . Combina¸cão de predicados para Branch coverage . . . . . . . . Hierarquia de critérios de controle de fluxo [VB06] . . . . . . . .. . . . . . . .. 25 27 28 30 31 33 34. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11. Fluxo para o Exemplo 4.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . LTSs para o Exemplo 4.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . Fluxos para o Exemplo 4.1.2 . . . . . . . . . . . . . . . . . . . . . . . . . LTS para o Exemplo 4.1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . Grafo de fluxos para o Exemplo 4.1.3 . . . . . . . . . . . . . . . . . . . . Mapeamento entre os dom´ınios concreto e abstrato para o exemplo 4.1.3 LTS para o Exemplo 4.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . Grafo de fluxos para o Exemplo 4.1.4 . . . . . . . . . . . . . . . . . . . . LTS para o Exemplo 4.1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . Grafo de fluxos para o Exemplo 4.1.5 . . . . . . . . . . . . . . . . . . . . LTS para o Exemplo 4.1.5 . . . . . . . . . . . . . . . . . . . . . . . . . .. 38 40 41 42 43 45 46 47 50 51 55. 5.1. Grafo de fluxos para o processo Potencia’ . . . . . . . . . . . . . . . . .. 66. xvii. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . ..

(18)

(19) LISTA DE TABELAS. 3.1. Correspondência entre operadores lógico-relacionais de CSP e Mathematica 30. 4.1 4.2 4.3 4.4. Combina¸cão das guardas para o Exemplo 4.1.3 . . . . . . . . . . . . . . Combina¸cão de predicados para o Caminho 1 no Exemplo 4.1.3 . . . . . Combina¸cão de predicados para o Caminho 2 no Exemplo 4.1.3 . . . . . Combina¸cão das guardas para descobrir parti¸co˜es no dom´ınio concreto do Exemplo 4.1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Combina¸cão de predicados para o Caminho 1 no Exemplo 4.1.4 . . . . . 4.6 Combina¸cão de predicados para os Caminhos 2 e 3 no Exemplo 4.1.4 . 4.7 Combina¸cão das guardas para descobrir parti¸co˜es do dom´ınio concreto no Exemplo 4.1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Combina¸cão de predicados para os Caminhos 2 e 3 no Exemplo 4.1.5 (parti¸cão 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Combina¸cão de predicados para o Caminho 1 no Exemplo 4.1.5 (parti¸cão 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Combina¸caõ de predicados para os Caminhos 1 e 2 no Exemplo 4.1.5 (parti¸cões 3 e 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43 44 45. 5.1 5.2. 67. Combina¸cão de guardas compat´ıveis para o processo Potencia’ . . . . . Combina¸cão de guardas e resolu¸cão de predicados usado o Mathematica para o processo Potencia’ . . . . . . . . . . . . . . . . . . . . . . . . . .. xix. 47 47 48 51 52 52 54. 68.

(20)

(21) CAPÍTULO 1. ˜ INTRODUC ¸ AO Com a crescente demanda por diminui¸cão de custos no desenvolvimento de software, há a necessidade de que os programas possam ser constru´ıdos de acordo com uma especifica¸caõ concordante com os requisitos do cliente [vL00]. Além disso, a clareza e consistência da especifica¸caõ devem ser atingidas como forma de reduzir os gastos oriundos de se encontrar erros em fases posteriores de um projeto. Nesse sentido, a especifica¸caõ formal pode ser utilizada para representar os requisitos do sistema. Ela é uma descri¸caõ matemática de software ou hardware que pode ser usada para desenvolver uma implementa¸caõ, descrevendo procedimentos e objetivos para as a¸co˜es do sistema [vL00]. O uso de formalismo durante a especifica¸caõ permite a elimina¸cão de ambig¨ uidades, isto é, inconsistências que apenas seriam detectadas mais tarde durante fases de implementa¸caõ e testes do ciclo de desenvolvimento de um sistema. Uma vez que a especifica¸caõ formal foi desenvolvida, ela pode ser usada como base para verificar determinadas propriedades. Essa verifica¸caõ pode ser realizada através do ser humano (provas matemáticas) ou automatizadas (verificador de modelos e provador de teoremas). Um provador de teoremas é uma ferramenta que tenta produzir uma prova formal para um dado teorema a partir da descri¸cão de um sistema, um conjunto de axiomas lógicos e um conjunto de regras de inferência. Em geral, apesar de realizar muitas tarefas de forma automática, este requer interven¸caõ humana em algumas delas. Já o verificador de modelos investiga certas propriedades através da procura exaustiva em todos os poss´ıveis estados que o sistema pode assumir durante sua execu¸cão [HJMS03]. Ele aceita modelos e propriedades que o sistema final deve satisfazer. Então, a ferramenta gera uma resposta positiva se um dado modelo satisfaz uma dada especifica¸cão ou um contra-exemplo, em caso negativo. O contra-exemplo detalha a situa¸caõ em que o modelo não foi satisfeito. Apesar de serem completamente automáticos, os verificadores de modelos necessitam de uma especifica¸cão que gere um modelo finito a ser analisado. Por isso, muitos problemas do mundo real não podem ser usados, já que são baseados em dom´ınios infinitos (inteiros, por exemplo). Esse problema é conhecido como explosão de estados e pode ser contornado através de diversas abordagens [CGJ+ 01]: • Algoritmos simbólicos evitam a constru¸cão de grafos para máquinas de estados finitos, representando-os através de lógica proposicional. O uso de BDDs (Binary Decision Diagrams — técnica de redu¸caõ de uma tabela-verdade) [Bry92] também é contextualizado nesse cenário. • Limita¸caõ do verificador de modelos para expandir a máquina de estados criada até um n´ umero x de passos, verificando se um contra-exemplo é encontrado [McM03]. O 1.

(22) 2. ˜ INTRODUC ¸ AO. processo é repetido com valores maiores de x a cada itera¸caõ até todas as viola¸cões poss´ıveis terem sido listadas. • Redu¸co˜es simétricas que induzem uma rela¸caõ equivalente no espa¸co de estados enquanto realizam a análise do espa¸co de estados em que seja poss´ıvel descartar um estado se o seu equivalente já foi explorado. • A abstra¸caõ de dados objetiva provar propriedades de um sistema observando apenas algumas de suas propriedades. O sistema abstrato passa a conservar algumas das propriedades do seu equivalente original. • Refinamentos de abstra¸co˜es guiadas a contra-exemplos come¸cam com uma abstra¸caõ imprecisa que é refinada iterativamente. Quando um contra-exemplo é encontrado, a ferramenta verifica se a abstra¸cão é incompleta ou se esse é o resultado de um erro da especifica¸caõ. Se a abstra¸cão for incompleta, isso é reportado ao usuário; caso contrário, o erro encontrado é usado para refinar a abstra¸cão e o processo come¸ca novamente. • Independência de dados [Wol86] permite que os dom´ınios de dados dos processos a serem analisados pelo verificador de modelos possam ser reduzidos, de forma a torná-los finitos. No entanto, condi¸co˜es sobre esses processos devem ser observadas, de forma a garantir a poss´ıvel redu¸caõ. Dentre essas abordagens, o uso de independência de dados e algoritmos de abstra¸cão baseados na teoria de interpreta¸caõ abstrata têm recebido muita aten¸caõ da comunidade acadêmica relacionada à verifica¸cão de modelos [VHB+ 03]. A interpreta¸cão abstrata [CC04] pode gerar especifica¸co˜es abstratas que conservem determinadas propriedades de sua especifica¸caõ concreta original. A idéia básica é o uso de mapeamentos de elementos do dom´ınio concreto (dom´ınio real de um sistema) para seus equivalentes no dom´ınio abstrato. O verificador de modelos então gera automaticamente o grafo de estados sobre os dados abstratos. A linguagem usada para especifica¸cão neste trabalho é CSP (Communicating Sequential Processes) [Ros98]. Ela foi projetada para descrever padrões de intera¸cões em sistemas concorrentes. Decidiu-se usar CSP nesse trabalho por ser uma linguagem madura em sua área de atua¸caõ [Hoa78], possuir ferramentas de verifica¸cão para propriedades de concorrência, APIs Java que podem implementar sua especifica¸caõ [WM00] e esfor¸cos de sua combina¸cão com várias outras linguagens formais, dando origem a Circus [WC02], CSP-OZ [Fis97] e CSP-Z [MS98], entre outras linguagens. A independência de dados para CSP foi inicialmente proposta em [Laz98]. Este trabalho diz que um processo é independente de dados em rela¸caõ a um tipo quando as opera¸co˜es que ele pode realizar com seus valores nesse conjunto são entrada, cópia e armazenamento, sa´ıda e testes de igualdade/desigualdade (Se¸cão 3.2). Os tipos envolvidos nos processos a serem analisados são reduzidos a um dom´ınio finito de valores e ainda assim garantem que a propriedade a ser verificada no dom´ınio finito tenha o mesmo resultado que nos processos originais. Especificamente neste trabalho, a independência de.

(23) ˜ INTRODUC ¸ AO. 3. dados é usada para justificar a substitui¸cão de dom´ınios de variáveis que não influem no comportamento do sistema em um valor do dom´ınio concreto. Como qualquer outra linguagem de especifica¸caõ, CSP também pode modelar sistemas que possuem o problema da explosão de estados. Dentre as abstra¸co˜es poss´ıveis para CSP, este trabalho usa a abstra¸cão segura, apresentada em [FMS08]. A abstra¸cão segura preserva o que o sistema pode fazer (modelo de traces), enquanto que a abstra¸caõ ótima preserva também as recusas (modelos de falhas), detalhados na próxima se¸caõ. No entanto, para situa¸cões onde somente a seq¨ uência de eventos que pode ser realizada é suficiente, a abstra¸caõ segura se torna uma alternativa bastante atraente. Ela conserva o sistema concreto sob o ponto de vista destes eventos. Portanto, todas as seq¨ uências de a¸cões que pertencem ao grafo simbolizador do sistema concreto também devem ser encontradas no grafo representante do dom´ınio abstrato. Diante deste panorama, o objetivo deste trabalho é propor um algoritmo para gera¸caõ mecanizada de abstra¸cões seguras para sistemas CSP seq¨ uenciais com recursão simples. O algoritmo recebe o sistema de acordo com algumas restri¸cões a serem explicadas no Cap´ıtulo 4 e retorna a rela¸caõ de abstra¸cão resultante para as variáveis de comunica¸caõ e de dados presentes, assim como o sistema abstrato. A rela¸cão que um sistema concreto tem com a sua versão abstrata segura tem forte rela¸cão com testes de software. Uma vez que seja poss´ıvel analisar um sistema abstrato finito que conserve certas propriedades de seu equivalente concreto e infinito, as propriedades desse sistema podem ser observadas através do verificador de modelos. Além disso, os dados obtidos para as variáveis na abstra¸caõ sempre permitem que a ocorrência de todas as seq¨ uências de traces do sistema concreto do sistema sejam conservadas no sistema abstrato. Sendo assim, se esses dados forem inseridos no sistema, todos os caminhos podem ser exercitados, de forma a proporcionar 100% de cobertura de código em rela¸caõ a um dos critérios de cobertura descritos na literatura, conforme mostrado na Se¸caõ 4.3. O esfor¸co para encontrar dados de teste para cobertura de código é justificado pela importância que a fase de testes tem para a qualidade do software. Estudos prévios mostraram que essa fase demanda mais de 50% do custo de seu desenvolvimento [Bei90], e uma pesquisa detalhada realizada nos Estados Unidos [Tas02] quantifica os altos impactos econômicos de uma infra-estrutura de software inadequada. Essa fase demanda muito esfor¸co, e ainda assim não é o bastante para provar a ausência de falhas porque os testes são criados por humanos e a qualidade dos testes gerados como um todo depende da experiência deles. Como se não bastasse, não é poss´ıvel atestar que um software está livre de erros [Mye04], pois não há como garantir que todos os cenários poss´ıveis foram testados. Com a gera¸caõ automática dos dados de teste, a automa¸cão de execu¸caõ de testes se torna uma alternativa bastante atraente para esse panorama, já que os testes automáticos podem ser executados com interven¸cão humana muito menor do que em testes manuais. Isso evita que novos erros sejam introduzidos em documentos e execu¸co˜es de procedimentos de testes, por exemplo. Ademais, o custo demandando para dar suporte a um processo de testes se torna elevado, então a automa¸cão desse processo seria uma economia tanto de custo quanto de tempo. Podem ser citadas as seguintes contribui¸cões realizadas por esse trabalho:.

(24) ˜ INTRODUC ¸ AO. 4. Adapta¸ c˜ ao da defini¸c˜ ao de abstra¸c˜ ao segura Uma adapta¸caõ defini¸caõ de abstra¸caõ segura, baseada na defini¸caõ apresentada no Cap´ıtulo 3, é apresentada, de forma a viabilizar a gera¸caõ de dados mecanizada. Estrat´ egia de obten¸c˜ ao de abstra¸co ˜es seguras Uma estratégia para obten¸caõ de abstra¸caõ segura baseada em satisfatibilidade de predicados é apresentada (Se¸caõ 4.1). Elabora¸c˜ ao de um algoritmo para gera¸c˜ ao de abstra¸co ˜es seguras Um algoritmo é proposto no Cap´ıtulo 4 com exemplos introdutórios da estratégia (Se¸cão 4.1) e sua especifica¸caõ em linguagem funcional é apresentada na Se¸caõ 4.2. Fornecimento de dados de testes para cobertura de 100% de modelo O conjunto abstrato definido para a abstra¸caõ segura pode ser usado como um conjunto de dados de testes que, se aplicados ao sistema, gera 100% de cobertura de modelo, como mostra a Se¸caõ 4.3. 1.1. ˜ DA DISSERTAC ˜ ORGANIZAC ¸ AO ¸ AO. O Cap´ıtulo 2 fornece uma introdu¸caõ à linguagem CSP. A sintaxe da linguagem é explicada, mostrando seus tipos básicos, casamento de padrões, conceito de processos e seus operadores básicos. A seguir, a semântica de CSP é discutida na Se¸cão 2.3, através da caracteriza¸cão de LTSs (Labelled Transition Systems) e o modelo de traces. Então, as rela¸cões de refinamento entre processos são discutidas na Se¸cão 2.4 e um panorama geral de verifica¸caõ de modelos e suporte de ferramentas para essa linguagem é fornecido na Se¸cão 2.5. O Cap´ıtulo 3 exibe a teoria de abstra¸cão segura de dados sobre a qual este trabalho está fundamentado, com seu conceito e implica¸cões (Se¸cão 3.1). Então, a independência de dados é citada como forma de justificar o tratamento especial dado a determinadas variáveis durante a computa¸cão do algoritmo (Se¸caõ 3.2). Na seq¨ uência, alguns trabalhos que formam o estado da arte de gera¸caõ automática de dados de testes são apresentados (Se¸cão 3.3). O Cap´ıtulo 4 concentra a maior parte das contribui¸co˜es dadas por esse trabalho. Uma idéia geral do algoritmo é criada através de exemplos que retratam diversas situa¸cões a serem tratadas na Se¸cão 4.1. A seguir, uma formaliza¸caõ do algoritmo em linguagem funcional é descrita (Se¸cão 4.2) com estruturas de dados sendo definidas para que sejam manipuladas por ele. A teoria de independência de dados mostrada no Cap´ıtulo 3 também é situada nesse contexto e uma nova defini¸cão de abstra¸cão segura é criada. O Cap´ıtulo 5 apresenta o estudo de caso para a estratégia mostrada no Cap´ıtulo 4. O problema da potencia¸caõ é codificado no paradigma imperativo e então em CSP (Se¸cão 5.2), e uma equivalência entre as duas implementa¸co˜es é estabelecida. Depois, o algoritmo descrito no Cap´ıtulo 4 é usado para a gera¸caõ da abstra¸caõ segura desse problema (Se¸caõ 5.3.1), exibindo o resultado de cada fun¸cão ao longo de sua execu¸cão. Uma discussão sobre a rela¸caõ entre cobertura de modelo e abstra¸caõ segura também é lan¸cada na Se¸cão 4.3..

(25) ˜ DA DISSERTAC ˜ 1.1 ORGANIZAC ¸ AO ¸ AO. 5. Finalmente, o Cap´ıtulo 6 mostra as considera¸co˜es finais da disserta¸caõ e apresenta os trabalhos relacionados e futuros (Se¸co˜es 6.1 e 6.2)..

(26)

(27) CAPÍTULO 2. CSP Este cap´ıtulo trata da introdu¸cão à nota¸cão CSP (Se¸cão 2.1), explicando sua sintaxe (Se¸cão 2.2) e semântica (Se¸caõ 2.3). Além disso, será dada a no¸cão de refinamento na Se¸cão 2.4 e uma introdu¸caõ a técnica de verifica¸cão de modelos (refinamentos) e ferramentas para seu suporte (Se¸caõ 2.5). 2.1. ˜ INTRODUC ¸ AO. CSP (Communicating Sequential Processes) é uma nota¸caõ para descrever sistemas concorrentes cujos processos componentes interagem entre si através de comunica¸cões [Ros98]. A dificuldade no entendimento dessas intera¸cões surge devido a diferentes componentes estarem em estados diferentes e independentes em um código paralelo, porque esse n´ umero cresce exponencialmente com o n´ umero de componentes e não linearmente como no código seq¨ uencial [Ros98]. Os processos são usados para capturar comportamento e são compostos por eventos, operadores e outros processos. Os processos são entidades auto-contidas com interfaces particulares e é através delas que há intera¸cão com o ambiente (observador externo). Essa é uma visão composicional, já que se dois processos formam um sistema maior, esse é novamente uma entidade auto-contida. Um evento descreve um tipo particular de a¸cão atômica que pode ser sofrida pelo processo. Descrita pela primeira vez em 1978 por C. R. Hoare [Hoa78], a nota¸caõ CSP evoluiu desde então em certos aspectos. Roscoe [Ros98] propôs ajustes à teoria de CSP, particularmente no que diz respeito à teoria de refinamento de processos e no suporte de ferramentas. A partir das adapta¸cões propostas por Roscoe, surgiu a linguagem CSPM , que é a versão ASCII de CSP usada pelo verificador de modelos FDR [Sys05]. Em particular, esse cap´ıtulo trabalho introduz e usa CSPM ao invés de CSP. Essa nota¸cão tem sido aplicada na ind´ ustria como uma ferramenta para especificar e verificar aspectos concorrentes de uma variedade de sistemas, como o processador T9000 [Bar95], sistemas de e-commerce seguros [HC02] e protocolos [BR02], sistemas em tempo real, seguran¸ca de computadores, protocolos de comunica¸cão, tolerância a falhas entre outros [Ros98]. Algumas propriedades clássicas de sistemas concorrentes são analisadas em sistemas CSP, como o deadlock, livelock e não-determinismo. Um sistema é não-determin´ıstico se ele pode se comportar de mais de uma maneira dado a mesma entrada. Determinado sistema está em deadlock se seus componentes não podem realizar qualquer progresso, geralmente porque um está esperando o outro. O livelock é similar ao anterior, exceto pelo fato de que os estados dos processos envolvidos no livelock sempre mudam em rela¸caõ aos outros, mas mesmo assim não progridem. Então a situa¸caõ é também chamada de divergência e é parecida com o que acontece em loops infinitos, onde não há intera¸cão 7.

(28) 8. CSP. exterior com o ambiente. Assim, em um comportamento divergente, um processo realiza uma seq¨ uência infinita de a¸co˜es internas que não podem ser vistas pelo ambiente. Nas se¸co˜es a seguir, apresentamos a linguagem CSPM em mais detalhes, iniciando por sua sintaxe. 2.2. SINTAXE. A nota¸caõ CSPM é a versão ASCII de CSP adaptada para interpreta¸cão de máquina que analisa especifica¸co˜es dessa linguagem. CSPM pode ser vista como a integra¸caõ entre uma linguagem para capturar comportamentos e uma linguagem funcional (para modelar estruturas de dados). A parte funcional foi a grande contribui¸cão de CSPM à CSP. A sintaxe dessa linguagem é composta por expressões, tipos definidos pelo usuário e primitivos, identificadores, canais e eventos, assim como os processos e seus operadores. As expressões serão abordadas primeiro por se tratar da parte mais básica da nota¸caõ. 2.2.1. Express˜ oes. As expressões CSPM são compostas por identificadores e os tipos que operam com eles, como n´ umeros, seq¨ uências, conjuntos, tuplas entre outros, vistos a seguir. Devido a limita¸cões operacionais, CSPM não suporta Strings e n´ umeros de ponto flutuante [Ros98]. 2.2.1.1 Identificadores Identificadores em CSPM come¸cam com um caractere alfabético e são seguidos por caractereres alfanuméricos ou sublinha, sendo seguidos opcionalmente por qualquer caractere. Não existe limite no tamanho dos identificadores. Apesar deste cap´ıtulo usar identificadores com nomes simples, muitas vezes de apenas um caractere (por exemplo: S, P ou x), especifica¸cões reais devem ter nomes significativos, uma vez que a legibilidade é fator relevante para qualquer tipo de documenta¸caõ, especificamente a formal. 2.2.1.2 Inteiros N´ umeros inteiros são introduzidos pela palavra reservada int. Dados dois n´ umeros p e q, os operadores são: p + q (soma), p - q (diferen¸ca binária), - p (diferen¸ca unária), m * n (produto), p / q (quociente) e p % q (resto). 2.2.1.3 Booleanos Tipos booleanos são válidos e usados como em qualquer linguagem de programa¸caõ convencional. Dados dois operandos booleanos a e b e dois n´ umeros x1 e x2 , as opera¸co˜es básicas sobre o tipo booleano são: • a and b: A conjun¸caõ entre as variáveis a e b, isto é, a ∧ b; • a or b: A disjun¸caõ entre as variáveis a e b, isto é, a ∨ b, • x1 == x2 , x1 != x2 : As rela¸cões de igualdade/desigualdade entre os operandos x1 e x2 ;.

(29) 9. 2.2 SINTAXE. • not a: A nega¸caõ de a, isto é ¬ a; • x1 > x2 , x1 < x2 , x1 >= x2 , x1 <= x2 : As opera¸cões de ordem sobre os n´ umeros; • if a then P else Q: A expressão condicional que resulta no processo P se a for verdadeiro, ou em Q, se este for falso. 2.2.1.4 Conjuntos Tipo derivado diretamente do suporte funcional [BW88] de CSPM . Considerando dois conjuntos c1 e c2 , s uma seq¨ uência e x um elemento de um conjunto, as opera¸co˜es em CSPM para conjuntos são: • union(c1 , c2 ): c1 ∪ c2 ; • inter(c1 , c2 ): • diff(c1 , c2 ):. c 1 ∩ c2 ; c 1 \ c2 ;. • member(x, c1 ): x ∈ c1 ; • set(s): Converte uma seq¨ uência s em um conjunto. 2.2.1.5 Seq¨ uˆ encias Tipo também derivado diretamente do suporte funcional [BW88] de CSPM . Os elementos podem ser repetidos e a ordem deles é conservada ao longo da existência desse tipo. Todos os elementos devem ser do mesmo tipo. Sendo assim, uma seq¨ uência de literais pode ser definida na forma <6,4,5>, por exemplo. A fun¸cão lenght(s) ou #s dá o comprimento de uma seq¨ uência, enquanto que s^t retorna a concatena¸caõ de duas seq¨ uências s e t. Já elem(x,s) testa se o elemento x ocorre na seq¨ uência s, enquanto que head(s) retorna o primeiro elemento da seq¨ uência s (a qual não pode ser vazia). A fun¸cão tail(s) retorna s sem o primeiro elemento e null(s) retorna verdadeiro se a seq¨ uência s for vazia. ´ um tipo composto formado por dois ou mais tipos já pré-definidos. 2.2.1.6 Tuplas E Então, (6,4) e ({},<>) são duas tuplas, sendo que a primeira é formada por dois elementos inteiros e a segunda por um conjunto e uma seq¨ uência vazios. 2.2.2. Canais e Eventos. Em CSPM , sistemas são modelados em termos de eventos que acontecem em canais de ´ através de eventos que valores de um determinado tipo são comunicados. comunica¸cão. E Pode-se dizer então que canais são tags que formam a base para os eventos. Um canal se torna um evento quando valores são suficientes para completá-lo. Esses eventos são observados pelo ambiente e é somente assim que os processos se comunicam com ele. A intera¸cão entre o ambiente e os processos ocorre da mesma forma que entre os processos: os eventos só acontecem quando ambos os lados concordam. A seguinte declara¸caõ corresponde à declara¸caõ do canal in do tipo inteiro e do evento out:.

(30) 10. CSP. channel out channel in:int. 2.2.2.1 Tipos de Comunica¸ c˜ ao Também é poss´ıvel a comunica¸caõ ao longo de canais. A sa´ıda c!v está apta a comunicar no canal c a sa´ıda da expressão (neste caso um simples identificador) v. Similarmente, a entrada c?x:T pode aceitar qualquer entrada restrita ao tipo T ao longo do canal c e armazená-la no identificador x. Da mesma forma, c.x transmite ao longo do canal c o valor x sem caracterizar entrada ou sa´ıda de dados. 2.2.3. Casamento de Padr˜ oes. Vários exemplos desse trabalho usam casamento de padrões para decompor valores. Por exemplo, a fun¸cão reverse a seguir retorna o inverso da seq¨ uência fornecida como entrada. Nesta defini¸caõ, usa-se casamento de padrões para dois propósitos: (1) Lidar com o caso base (seq¨ uência vazia) e o caso mais geral; (2) No caso geral, capturar o primeiro elemento da seq¨ uência e seu resto.. reverse(<>) = <> reverse(<x>^s) = reverse(s) ^ <x>. A defini¸caõ anterior é equivalente a. reverse(s) = if null(s) then <> else reverse(tail(s)) ^ head(s). Os padrões podem ocorrer de várias formas em CSPM [Sys05]. No exemplo do processo reverse definido anteriormente, a chamada da fun¸caõ contendo uma seq¨ uência vazia é um padrão de valor simples. Sempre que reverse recebe esse valor como parâmetro, o retorno oferecido é uma seq¨ uência vazia. Para outros casos, a segunda chamada da fun¸cão é aplicada e <x>^s se tornam padrões de variáveis que casam quaisquer valores às mesmas, fazendo com que estes possam ser usados ao longo da defini¸caõ da fun¸caõ em substitui¸cão às variáveis. O casamento de padrões também pode ocorrer através de defini¸cões diretas, como por exemplo em (x, y) = (7, 2). Uma liga¸cão entre a variável x e o valor 7 é realizada, assim como entre y e 2. Já para o caso de compreensões sobre conjuntos, o exemplo dado é { x + y|(x,y) <{(1,2),(2,3)}}, onde o operador <- significa que (x,y) pertence ao conjunto {(1,2),(2,3)}..

(31) 2.2 SINTAXE. 11. Há uma filtragem dos valores, de forma que somente os valores que casam os padrões determinados sejam selecionados. Como nesse exemplo todos os casamentos são verdadeiros, o conjunto resultante é {3,5}. Há também o caso de casamentos de padrões sobre comunica¸cões de variáveis. O trecho d?(x,y) -> c!x+y -> STOP realiza o casamento dos valores recebidos como entrada às variáveis x e y, retornando o resultado da expressão x+y como sa´ıda do canal c. 2.2.4. Processos. Processos são as entidades descritas por expressões CSPM em termos de poss´ıveis eventos e canais. Sendo assim, tornam-se unidades básicas para captar comportamento. Em geral, são usados para garantir o conceito de modularidade. Nesse trabalho, assume-se que cada processo tem um alfabeto espec´ıfico dado por αP , tal que αP ⊆ Σ. Σ é denominado de alfabeto da especifica¸cão (ou do sistema). Em CSPM , cada processo é definido por uma equa¸caõ do tipo P = Proc onde P é o nome do processo que está sendo definido e Proc é o corpo do processo, o qual deve obedecer à seguinte gramática, onde e é um evento, X é um conjunto de processos, b é uma expressão booleana e a é um conjunto de eventos. Proc ::= STOP | SKIP | e -> Proc | Proc [ ] Proc | Proc |∼| Proc | Proc ||| Proc | Proc \ X | Proc [|a|] Proc | Proc; Proc | if b then Proc else Proc | b & Proc A sintaxe acima omite o processo div, que representa divergência, assim como vários operadores como o paralelismo alfabetizado, piping, escolhas indexadas, timeout e interrup¸cão [Ros98]. Informalmente, esses processos de CSPM se comportam como segue. STOP é um processo terminal, portanto depois dele nenhuma comunica¸caõ é permitida. Ele é usado para denotar funcionalidades defeituosas e quando aparece num processo, significa que há uma situa¸cão de deadlock. SKIP é um processo terminal, mas sua ocorrência significa termina¸cão com sucesso. O processo e -> P oferece o evento e ao ambiente e aguarda indefinidamente por sua aceita¸cão. Se o evento e for aceito, este processo passa a se comportar como P..

(32) 12. CSP. O processo P [ ] Q (pronunciado P escolha externa Q) está inicialmente disposto a se comportar como P ou Q, onde a escolha é resolvida pelo ambiente desses dois processos. O processo P |∼| Q (pronunciado P escolha interna Q) pode se comportar como P ou Q, sendo que o ambiente não tem autonomia sobre essa decisão, caracterizando não-determinismo. O processo P \ X, que usa o operador hiding, se comporta como P, mas com todos os eventos de X sendo comunicados somente para o processo P. O processo b & P indica que se a guarda booleana b for verdadeira, se comporta como P, caso contrário, se comporta como STOP. Essa é uma abrevia¸caõ para if b then P else STOP. Os processos podem ser compostos em paralelo. Se a é um conjunto de eventos, então o processo P |[a]| Q se comporta como P e Q agindo concorrentemente, com a condi¸cão de que eles têm que sincronizar em qualquer evento do conjunto a. Assim, eventos que não estão em a são realizados pelos processos de forma independente dos outros. Os processos também podem ser definidos recursivamente através de equa¸co˜es. Por exemplo, BUFFER = in?x:T -> out!x -> BUFFER aceita um valor no canal in e então gera uma sa´ıda no canal out repetidamente. Os parâmetros de um processo representam seu estado. Devido ao caráter funcional da linguagem CSPM , não há o conceito de atribui¸caõ. Portanto, atualiza¸caõ do estado se dá através de recursão. Um processo parametrizado pode ter qualquer n´ umero fixo de parâmetros. Considere o seguinte processo em CSPM : Rec(x) = in!x -> Rec(x + 1) Este processo possui apenas um parâmetro x (o tipo de x não é apresentado, já que ele é determinado pelo seu uso em expressões no corpo do processo), o qual é comunicado através do canal in e depois ocorre a chamada recursiva Rec(x+1), onde o valor inicial de x é incrementado de 1. Em particular, este processo tem o problema do dom´ınio de dados da variável x ter estados infinitos pois os poss´ıveis valores que x poderá assumir não são restringidos. Além dos operadores apresentados, há também outros que não serão extensamente utilizados nesse trabalho, mas que também são muito importantes na constitui¸cão da nota¸cão CSPM . São eles: P;Q A composi¸cão seq¨ uencial dos processos P e Q. Este processo se comporta como P até que ele termine com sucesso e depois se comporta como Q. P[[a <- b]] O processo de renomea¸caõ mapeia todos os eventos a em eventos b. P|||Q Os processos P e Q estão rodando em paralelo, sem sincroniza¸caõ de eventos. P[a||a’] Os processos P e Q estão sendo executados em paralelo, sendo que o conjunto de interseçcão de a e a’ obriga a sincroniza¸cão desses processos. ;x:s@P A composi¸caõ seq¨ uencial replicada executa o processo P para cada elemento em s seq¨ uencialmente. Cada ocorrência de x em P é trocada pelo elemento atual de s..

(33) ˆ 2.3 SEMANTICA. 13. []x:s@P A escolha externa replicada oferece os eventos iniciais para todos os processos P, nos quais x é trocado por um elemento de s. |∼|x:s@P A escolha interna replicada oferece os eventos iniciais de um processo P, onde x é trocado por um elemento de s, desde que esse não esteja vazio. |||x:s@P O interleave replicado roda todos os processos em paralelo sem sincroniza¸cão sobre quaisquer eventos, onde cada ocorrência de x em P é trocada por um elemento de s. [|a|]x:s@P O paralelismo replicado compartilhado roda todos os processos P em paralelo, onde cada ocorrência de x em P é trocada por um elemento de s e a sincroniza¸caõ é obrigatória nos eventos pertencentes a a. Depois de introduzir a sintaxe de CSPM , sua semântica é considerada na próxima se¸cão. 2.3. ˆ SEMANTICA. Apesar de CSPM também ter uma semântica, nesta se¸caõ a semântica de CSP é usada por ser mais simples e abstrata. Isso não introduz grandes problemas pois a semântica de CSPM simplesmente adiciona detalhes à de CSP sobre como a parte funcional interage com a parte comportamental. Existem três formas de entender o significado da sintaxe de CSP, através de semântica. São elas a denotacional, operacional e algébrica. A semântica operacional interpreta programas como diagramas de transi¸caõ, com a¸cões vis´ıveis e invis´ıveis para que haja o movimento entre os vários estados do programa (Se¸cão 2.3.2). Ela é, como o próprio nome sugere, muito próxima à implementa¸caõ. Assim, pode-se definir a semântica operacional como uma formaliza¸cão matemática de alguma estratégia de implementa¸caõ [Ros98]. A semântica denotacional mapeia uma linguagem de programa¸caõ em modelos abstratos de forma que o significado de qualquer componente do programa seja determinado diretamente pelos significados de seus constituintes (composicionalidade). Existem várias semânticas denotacionais em CSP (Se¸caõ 2.3.3), todas baseadas em itens como traces, falhas e divergências. O significado delas em qualquer programa depende da combina¸caõ desses conjuntos. A semântica algébrica é definida por um conjunto determinado de leis algébricas. Em vez de construir um modelo matemático expl´ıcito, como na semântica denotacional, as leis são os axiomas básicos de uma semântica algébrica, e a equivalência de processos é definida em termos de que igualdades podem ser provadas usando-as. Algumas leis serão apresentadas como forma de introduzir essa abordagem na Se¸cão 2.3.1. 2.3.1. Semˆ antica Alg´ ebrica. Uma forma de definir o comportamento dos operadores de CSP é o uso de step laws. Essas regras permitem definir o primeiro passo do comportamento de um operador (isto.

(34) 14. CSP. é, a sele¸caõ das a¸cões iniciais adicionado aos processos que sucedem cada a¸caõ) dentro do sistema em que ele está envolvido. Por exemplo, sejam P = c?x:A -> P’ e Q = c?x:B -> Q’. A step law para o processo P ||| Q é a seguinte: P ||| Q = c?x:A ∪ B -> if (x ∈ A ∩ B) then (P’ ||| Q) |~| (P ||| Q’) else if (x ∈ A) then (P’ ||| Q) else (P ||| Q’) Sendo assim, se o próximo evento pertence à intercessão dos processo P e Q, uma escolha não-determin´ıstica será realizada. Caso contrário, o processo ao qual o evento corrente pertence será evolu´ıdo. Analogamente, para o processo P [|X|] Q, onde X é um conjunto de eventos, tem-se: P [|X|] Q = c?x:C -> if (x ∈ X) then (P’ [|X|] Q’) else if (x ∈ A ∩ B) then (P’ [|X|] Q) |~| (P [|X|] Q’) else if (x ∈ A) then (P’ [|X|] Q) else (P [|X|] Q’) A step law é u ´til como um pré-processamento para uma semântica operacional (Se¸caõ 2.3.2), mas a sua natureza é puramente algébrica. 2.3.2. Semˆ antica Operacional. A semântica operacional de CSP é composta por firing rules e Labelled Transition Systems (Se¸cão 2.3.2.1), uma representa¸caõ gráfica do comportamento do sistema ao n´ıvel de estados e eventos. Firing rules [Ros98] são um conjunto de regras de transi¸cão, sendo cada uma aplicada a um operador da nota¸caõ CSP. Nesta se¸caõ, o objetivo é mostrar como processos CSP são representados como grafos, mas sem apresentar detalhadamente as firing rules. 2.3.2.1 LTS e Firing Rules Um LTS (Labelled Transition Systems) é uma tupla S = (Q, A, T, q0 ) onde Q é um conjunto finito de estados, A é um conjunto finito de rótulos, T é uma rela¸caõ de transi¸caõ (Q × A × Q), e q0 é o estado inicial (q0 ∈ Q). Os poss´ıveis rótulos a serem usados em um LTS provêm do conjunto Σ (o conjunto de eventos do sistema ou alfabeto da especifica¸cão) e os eventos especiais τ e X. As a¸co˜es em Σ são vis´ıveis ao ambiente externo, e podem apenas acontecer com a coopera¸caõ dele. A a¸caõ τ não pode ser vista de fora do processo e acontece automaticamente, representando transi¸co˜es não-determin´ısticas. A a¸caõ especial X representa uma termina¸caõ com.

(35) ˆ 2.3 SEMANTICA. 15. sucesso. Ela é diferente dos outros eventos porque é sempre o u ´ltimo evento que acontece e é vis´ıvel ao ambiente. Sendo assim, é melhor pensar nela como não requerendo coopera¸caõ do ambiente. Também existe o estado especial Ω, que indica que o processo foi terminado. Depois de se chegar a ele, não é poss´ıvel instanciar o processo novamente. Um LTS pode ser finito ou infinito (em termos de conjunto de estados), e apenas as transi¸cões de um estado n que podem ser alcan¸ca´veis são relevantes quando se descreve o comportamento de n. Um processo é dito de estados finitos se ele pode ser representado por um LTS finito. A Figura 2.1 mostra dois LTSs, um finito (a) e outro infinito (b). O LTS (a) é o finito porque ele possui dois estados. A cada execu¸caõ do processo que ele representa, o evento a é oferecido ao ambiente e ele volta ao estado -70. Analogamente, em (b) temos um LTS que representa um processo infinito, em que o evento a é sempre oferecido ao ambiente, mas o n´ umero de estados que o processo assume cresce infinitamente.. Figura 2.1 (a)Um LTS finito (b)Um LTS infinito. Os LTSs são constru´ıdos com base na semântica dos operadores CSP e de seus operandos e eventos. Como forma de exemplificar os eventos especiais de X e Ω, a firing rule para o processo SKIP é mostrada, como definido a seguir[Ros98]. √. (.). SKIP −→ Ω. Não existe nada sobre a linha horizontal porque não há restri¸co˜es para a a¸caõ especificada. Então, quando o processo SKIP é oferecido ao ambiente, a a¸cão X é comunicada ao mesmo e este assume o estado Ω, isto é, termina¸caõ do sistema. O Processo STOP não tem a¸co˜es, então não há firing rule para ele. Não há a¸cões na semântica operacional porque não existe possibilidade de provar que ele tenha alguma..

(36) 16. CSP. 2.3.3. Semˆ antica Denotacional. CSP tem vários modelos de semântica denotacional, principalmente baseada em conjuntos de comportamentos como traces, falhas e divergências. Os traces de um processo P, traces(P), são definidos como o conjunto de seq¨ uências finitas de eventos de Σ que P pode realizar [Ros98] (Se¸caõ 2.3.3.1). As falhas (F) de um processo P são definidas como o conjunto failures(P), que contém pares de traces e rejei¸cões de um processo em um determinado contexto. Assim, uma falha (s, X) significa que depois de realizar os eventos do trace s, o processo rejeita os eventos do conjunto X. Já as divergências [Ros98] (D) de um processo P, divergences(P), são os traces que podem levar P a realizar uma seq¨ uência infinita de eventos invis´ıveis ao ambiente, isto é, livelock [Ros98, Hoa78]. O modelo (FD) de falhas/divergências de um processo P é composto pelo par (failures(P), divergences(P)) [Hoa78]. Este trabalho se concentra em achar uma abstra¸caõ segura para um determinado sistema, utilizando somente o modelo de traces, e por isso esses outros modelos não serão detalhados. 2.3.3.1 O Modelo de Traces Para qualquer processo P, os traces(P) são definidos como o conjunto de todos os traces finitos membros do conjunto Σ∗ , uma seq¨ uência finita de eventos. Por exemplo: • traces(STOP) = {hi} — O u ńico trace que pode ser realizado é o trace vazio. • traces(a → b → STOP) = {hi, h a i, h a,b i} — Este processo pode comunicar nada, realizar o evento a apenas, ou a e b. • traces((a → STOP) [ ] (b → STOP)) = {hi, h a i, h b i} — Pode-se escolher um evento, então existe mais de um trace dispon´ıvel de comprimento um. • traces((a → P) [] (b → STOP)) = {h a in , h a in _ h b i | n ∈ N} — Este processo pode realizar quantos a’s o ambiente quiser, seguidos por b e depois disso não pode haver comunica¸cão. As regras para constru¸caõ de conjuntos de traces para alguns operadores são dadas a seguir: • traces(SKIP) = {hi, hXi} • traces(a → P) = {hi}∪{h a i _ s | s ∈ traces (P)} — Este processo não faz nada ou seu primeiro evento é a seguido pelo trace de P. • traces(?x : A → P) = {hi}∪{h a i _s | a ∈ A ∧ s ∈ traces(P[a/x])} — Similar ao anterior exceto pelo fato do evento inicial ser agora escolhido do conjunto A e o comportamento subsequente depende do que é oferecido pelo ambiente. P[a/x] significa a substitui¸caõ de x por todas as ocorrências de a. • traces(c?x : A → P) = {hi}∪{h c.a i _s| a ∈ A ∧ s ∈ traces(P[a/x])} — O mesmo que o anterior, exceto pelo uso do nome do canal..

(37) 2.4 REFINAMENTO. 17. • traces(P [ ] Q) = traces(P) ∪ traces(Q) — Já que o processo se comporta como P ou Q, os traces são os traces de P e Q. • traces(P |∼| Q) = traces(P) ∪ traces(Q) — Este processo oferece os traces de P e Q. S • traces(|∼|x:s@P) = {traces(P)|P ∈ s} para qualquer conjunto não vazio s de processos. • traces(if b then P else Q) = traces(P) se ele evolui para verdadeiro ou traces(Q) se ele evolui para falso. O conjunto traces(P) de um processo P não serve somente para entender seu comportamento. Ele também pode ser comparado com os traces de outro processo de forma a comparar esses dois conjuntos. Isso é feito através das rela¸co˜es de refinamento, apresentadas a seguir. 2.4. REFINAMENTO. Para caracterizar a preserva¸caõ do comportamento original de um processo, com a eventual adi¸caõ de um novo comportamento, emprega-se a rela¸caõ de refinamento. Assim, P v Q significa que Q é melhor que (refina) P em algum sentido. No modelo de traces, a rela¸cão de refinamento é definida em termos da rela¸caõ de inclusão entre conjuntos, ou seja, P vT Q ⇔ traces(Q) ⊆ traces(P) Um resultado mais forte ainda é a no¸caõ de equivalência: P ≡T Q ⇔ traces(P)⊆traces(Q)∧traces(Q)⊆traces(P) isto é, para que um processo P seja equivalente a um processo Q ao n´ıvel do modelo de traces, é necessário que o conjunto de traces de P esteja contido no conjunto de traces de Q e que o inverso também seja verdadeiro. Assim como as rela¸co˜es de refinamento são poss´ıveis para o conjunto de traces, elas também operam sobre os conjuntos de falhas e de falhas/divergências. Embora os traces sejam muito u ´teis, em alguns casos em que se quer ver além do comportamento do sistema, observando também livelocks e não-determinismos, somente o conjunto de falhas/divergências seria o bastante. Como o escopo desse trabalho está concentrado nos traces do sistema, essas outras rela¸co˜es de refinamento não serão alvo de discussão. 2.5. ˜ DE MODELOS E SUPORTE A FERRAMENTAS PARA CSPM VERIFICAC ¸ AO. Verifica¸caõ de modelos é uma técnica para analisar automaticamente propriedades de sistemas concorrentes de estados finitos [Edv99]. Sua versão clássica usa propriedades sobre o sistema que são expressas como fórmulas lógico-temporais e algoritmos simbólicos eficientes são usados para analisar se a especifica¸cão é ou não concordante..

(38) 18. CSP. A classe de verificadores de modelos a ser estudada nesse trabalho é a baseada em refinamentos. O resultado dessa classe é a confirma¸caõ de que a propriedade é verdadeira ou há o fornecimento de um contra-exemplo falsificando a propriedade. A princ´ıpio, verifica¸cão de modelos é um procedimento de decisão. Ele sistematicamente diz “sim”ou “não”às propriedades do sistema. Entretanto, isso pode ser inalcan¸ca´vel devido à manipula¸cão de dom´ınios de dados infinitos, por exemplo. Apesar de verifica¸cão de modelos poder ser altamente automatizada, ela é restrita ao tamanho e tipo de sistemas para os quais ela pode ser aplicada e também é afetada pelo problema da explosão de estados. Por essa razão, foi proposto limitar o verificador de modelos para expandir a máquina de estados criada até um n´ umero x de passos [McM03]. Também é comum aplicar verifica¸caõ de modelos a instâncias de sistemas pequenos. O verificador de modelos mais usado para CSPM é o FDR [Sys05]. Este fornece suporte a todos os recursos mencionados, mas não deixa o usuário interagir com o processo, exceto pela inser¸cão de assertivas que comparam propriedades entre esses processos. Sendo assim, ele explora todas os estados dos processos envolvidos para retornar se a assertiva é verdadeira ou falsa. Por exemplo, a assertiva assert spec [T= imp retorna se spec é refinado por imp no modelo de traces ou não. Os LTSs dos processos envolvidos precisam ser finitos para que todas as situa¸co˜es que envolvam a assertiva possam ser verificadas. Outra ferramenta bastante interessante é o animador ProBE [Sys05], onde o usuário consegue visualizar os eventos de um processo que levam a outros estados. Ele usa uma lista hierárquica para mostrar as a¸co˜es poss´ıveis e estados de um processo. Seu objetivo é mostrar a intera¸cão entre os vários processos de um sistema de forma intuitiva. 2.6. ˜ CONSIDERAC ¸ OES FINAIS. Nesse cap´ıtulo, a nota¸caõ CSPM foi introduzida. Foram explicados conceitos básicos da linguagem, tipos de dados suportados, como é realizada a cria¸caõ de novos tipos e sua sintaxe, incluindo seus operadores básicos e casamento de padrões. Além disso, a semântica também foi alvo de estudo, com o uso de LTSs, modelos de traces e no¸cões de refinamento. Finalmente, uma introdu¸caõ à verifica¸caõ de modelos foi realizada, mostrando que existem duas ferramentas muito usadas para aux´ılio a análise de especifica¸cões CSPM : FDR e ProBE..

(39) CAPÍTULO 3. ˜ DE DADOS E GERAC ˜ DE DADOS ABSTRAC ¸ AO ¸ AO DE TESTE O segredo da vida é abstrair. Autor desconhecido. Especifica¸co˜es CSP podem resultar em sistemas com dom´ınio de dados infinitos para análise. Assim, o dom´ınio desses processos torna-se muito grande para ser processado por um verificador de modelos. Técnicas de abstra¸cão de dados podem ser usadas para criar sistemas abstratos finitos equivalentes sob determinado aspecto a sistemas infinitos concretos. Portanto, um verificador de modelos pode ser usado para descobrir propriedades desses sistemas abstratos e conseq¨ uentemente dos sistemas concretos. Com a descoberta dos modelos fornecidos por essas ferramentas, todos os estados do sistema podem ser explorados, de forma a extrair o comportamento dele no n´ıvel de traces, por exemplo. Esse tipo de modelo informa os eventos oferecidos ao ambiente, e conseq¨ uentemente a sua intera¸caõ com agentes externos. Sendo assim, todas as possibilidades de testes podem ser realizadas a partir desse tipo de abordagem e os dom´ınios abstratos descobertos podem ser usados como dados de teste para o sistema. Esse cap´ıtulo apresenta a teoria de abstra¸caõ de dados em que esse trabalho é fundamentado (Se¸cão 3.1), além de exibir a teoria sobre independência de dados usada (Se¸caõ 3.2) e alguns trabalhos sobre a gera¸caõ automática de dados de testes (Se¸caõ 3.3) 3.1. ˜ ´ ABSTRAC ¸ OES SEGURA E OTIMA PARA CSP. A interpreta¸caõ abstrata é uma forma de mapear semânticas e pode ser usada para abstrair dados [CC04]. A sua idéia é interpretar um programa em um dom´ınio abstrato usando opera¸cões abstratas. A principal vantagem é que o programa concreto não precisa ser executado completamente, apesar de ser poss´ıvel obter informa¸cões sobre sua execu¸cão real. Por exemplo, supondo que se queira saber o sinal resultante da expressão 5 * -3, esta pode ser observada como pos e ∗ neg = neg, onde pos representa um n´ umero positivo, neg um n´ umero negativo e e ∗ a nova versão do operador de multiplica¸caõ onde só os sinais são observados. Portanto, não é necessário avaliar a expressão para que o sinal resultante seja descoberto. Para verifica¸cão formal, o princ´ıpio básico da interpreta¸caõ abstrata é construir um modelo abstrato da especifica¸caõ no qual as propriedades abstratas possam ser provadas e revelar informa¸co˜es sobre o processo concreto. Dessa forma, o problema da explosão de estados pode ser contornado através do uso de um modelo abstrato e menos preciso (com menos informa¸caõ), mas que seja relevante para a(s) propriedade(s) que se deseja provar. 19.

(40) 20. ˜ DE DADOS E GERAC ˜ DE DADOS DE TESTE ABSTRAC ¸ AO ¸ AO. Sendo assim, o sistema abstrato deve refletir o comportamento do sistema concreto do ponto de vista das propriedades que se deseja conservar. Para garantir isso, condi¸co˜es sobre as interpreta¸co˜es abstratas devem ser impostas. Por isso, as interpreta¸co˜es segura e ótima foram idealizadas [Weh00]. A primeira conserva o modelo de traces do sistema e demanda menos esfor¸co computacional que a segunda, sendo suficiente para refletir o comportamento de um sistema no n´ıvel de testes. Já a abstra¸caõ ótima conserva o modelo de falhas e divergências, refletindo mais fidedignamente o comportamento da especifica¸caõ, capturando também livelock e não-determinismo (Se¸cão 2.3.3). As abstra¸cões segura e ótima de dados são baseadas em interpreta¸caõ abstrata de programas e podem ser vistas como um complemento a outras técnicas existentes. A idéia geral de ambas é determinar parti¸cões do dom´ınio concreto e escolher um dado para representar cada parti¸cão no dom´ınio abstrato. Dessa forma, para um conjunto de parti¸co˜es do dom´ınio concreto, existem conjuntos de dados eleg´ıveis e finitos que representarão o dom´ınio abstrato. Originalmente, essas abstra¸cões foram definidas para CSP-OZ [Fis97], uma combina¸cão das nota¸co˜es CSP e Object-Z. Nesse contexto, CSP é o responsável pelos aspectos dinâmicos do sistema, ao passo que Object-Z permite a descri¸caõ de seus aspectos estáticos. Os dom´ınios de dados a serem abstra´ıdos são os associados às variáveis de estado: D1 , ..., Dn para as variáveis v1 , ..., vn , e os dom´ınios associados aos canais: M1 , ..., Mk para os canais ch1 , ..., chk (mensagens). Infelizmente o trabalho reportado em [Weh00] possui algumas limita¸co˜es, já que é fundamentado em fun¸co˜es de abstra¸cão, o que faz com que sistemas que possuam um dado no dom´ınio concreto com mais de um correspondente no dom´ınio abstrato não possam ser expressos com essa nota¸caõ. O trabalho apresentado em [FMS08] estende a classe de problemas a ser tratada. Sistemas que possuem estados no dom´ınio concreto com mais de um equivalente no dom´ınio abstrato não podem utilizar fun¸co˜es e sim rela¸co˜es. Para isso, são usados dom´ınios de dados abstratos DiA e MiA e as rela¸co˜es αin e αout que representam as rela¸co˜es de abstra¸cão para os canais de entrada e sa´ıda do sistema concreto para o abstrato, respectivamente e a rela¸caõ de abstra¸caõ αs para uma variável de dado (estado), conforme segue: αs : (D1 × . . . × Dn ) ↔ (D1A × . . . × DnA ) αin : (M1in × . . . × Mkin ) ↔ (M1in,A × . . . × Mkin,A ) αout : (M1out × . . . × Mjout ) ↔ (M1out,A × . . . × Mjout,A ) As defini¸cões de abstra¸caõ segura e ótima utilizam as fun¸co˜es e opera¸co˜es de abstra¸cão, cada uma definida por uma habilita¸caõ (pré-condi¸cão) e efeito (pós-condi¸caõ). A semântica de uma opera¸caõ é dada por: [[enableop ]] : (D1 × . . . × Dn ) × (M1in × . . . × Mkin ) → B [[effectop ]] : (D1 × . . . × Dn ) × (M1in × . . . × Mkin ) → (D1 × . . . × Dn ) ↔ (M1out × . . . × Mjout ) A Defini¸caõ 3.1.1 conceitua a abstra¸cão segura formalmente. Defini¸ c˜ ao 3.1.1 (Abstra¸c˜ ao Segura). Uma interpreta¸caõ abstrata [[op]]S de predicados enable e effect de uma opera¸caõ é segura com respeito a rela¸co˜es αS , αin e αout se e somente se ∀ d ∈ D, in ∈ M in • ∃ d A ∈ D A , in A ∈ M in,A | (d , d A ) ∈ αs ∧ (in, in A ) ∈ αin • [[enableop ]]S (d A , in A ) ⇔ [[enableop ]](d , in).