Definição e implementação do sistema de tipos da linguagem circus

Texto

(1)Universidade Federal de Pernambuco Centro de Informática. Pós-gradua¸cão em Ciência da Computa¸cão. ˜ E IMPLEMENTAC ˜ DO DEFINIC ¸ AO ¸ AO SISTEMA DE TIPOS DA LINGUAGEM. Circus Manuela de Almeida Xavier ˜ DE MESTRADO DISSERTAC ¸ AO. Recife Julho, 2006.

(2)

(3) Universidade Federal de Pernambuco Centro de Informática. Manuela de Almeida Xavier ˜ E IMPLEMENTAC ˜ DO SISTEMA DE DEFINIC ¸ AO ¸ AO TIPOS DA LINGUAGEM Circus. 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.. Orientadora: Profa. Dra. Ana Cavalcanti Co-orientador: Prof. Dr. Augusto Sampaio. Recife Julho, 2006.

(4) iv.

(5) Aos meus grandes amores: minha m˜ ae, meu pai e Jorge..

(6)

(7) AGRADECIMENTOS Em primeiro lugar, agrade¸co a Deus por toda luz, equil´ıbrio e inspira¸cão. Sou eternamente grata a minha orientadora, Ana Cavalcanti, que muito contribuiu para o meu crescimento intelectual e pessoal. Agrade¸co pela sua dedica¸caõ e amizade durante estes cinco anos de orienta¸cão, desde a inicia¸caõ cient´ıfica até o mestrado. O ato de orientar, na minha concep¸cão, consiste em compartilhar conhecimento, cobrar resultados e vibrar com as vitórias. Estes, sem d´ uvida, foram os papéis muito bem desempenhados por ela, o que resulta na minha profunda admira¸cão pelo seu profissional. Agrade¸co também ao Augusto Sampaio pelo apoio na ausência de Ana e pelas sugestões no rumo da pesquisa. Augusto foi alguém com quem pude contar sempre nas horas de sufoco e com seu excelente bom humor desempenhou plenamente seu papel de co-orientador. Agrade¸co aos componentes da banca examinadora, Alexandre Vasconcelos e Márcio Cornélio, por todas as observa¸co˜es feitas ao trabalho realizado, contribuindo para a melhoria do mesmo. Gostaria de agradecer também às pessoas que contribu´ıram bastante na evolu¸cão do ˆ meu trabalho de pesquisa. Agrade¸co à Angela e Léo Freitas pela troca de idéias e apoio no desenvolvimento do verificador de tipos, pela evolu¸cão conjunta do analisador léxico e sintático de Circus, pelos testes e integra¸co˜es realizadas, e pelas sugestões de melhorias apresentadas. Apesar da distância, os dois foram pessoas bastante presentes durante este u ´ltimo ano de mestrado. Agrade¸co também a minha querida amiga Carla, pelas dicas com o JLex e JCup, e pelo esclarecimento de d´ uvidas sobre CSP, juntamente com Alexandre Mota. Nada disso teria se realizado se não fosse o apoio dos meus pais. Agrade¸co a eles pelo amor constante, carinho, paciência e recursos disponibilizados ao longo de toda minha vida. Admiro-os profundamente e agrade¸co pela oportunidade de estudo que me proporcionaram durante todos estes anos. Tudo o que tenho, ou que terei, devo a eles. Agrade¸co profundamente ao meu querido e amado Jorge pelo seu amor, palavras de otimismo, pelas horas de lazer sacrificadas e pela sua admirável paciência e apoio durante estes longos anos de gradua¸cão e mestrado. Só posso dizer que tudo isto fortaleceu a nossa rela¸cão e que agora podemos seguir na dire¸caõ da realiza¸cão do nosso grande sonho, que consiste na constru¸cão da nossa fam´ılia. Agrade¸co ao CNPq, pelo apoio financeiro no primeiro ano do meu mestrado, e ao SERPRO, em especial Helena Cristina e Pedro Rodrigues, pelo apoio prestado no final do mestrado. Por fim, agrade¸co a toda minha turma da gradua¸cão pela amizade e pelos momentos de descontra¸cão, aos amigos conquistados no mestrado, aos funcionários do Centro de Informática e a todos que, de uma forma ou de outra, contribu´ıram para a conclusão deste trabalho. vii.

(8)

(9) A felicidade e a paz interior dependem do calor do cora¸ c˜ ao. — DALAI LAMA.

(10)

(11) RESUMO A busca constante pelo desenvolvimento de sistemas de software com qualidade vem despertando o interesse das grandes empresas na aplica¸c˜ ao de técnicas formais. Dentre as linguagens formais, existem aquelas próprias para a modelagem de dados complexos, tal como Z, e outras próprias para a modelagem de comunica¸cão e concorrência, tal como CSP. Circus é uma linguagem de especifica¸c˜ ao, projeto e programa¸c˜ ao que combina Z e CSP. Além de possibilitar a especifica¸cão de aspectos de dados e comportamentais de sistema concorrentes, Circus inclui um cálculo de refinamentos. Este é seu diferencial em rela¸c˜ ao a outras integra¸cões de Z com uma álgebra de processos. Circus vem despertando interesse no meio industrial, manifestado através de colabora¸c˜ oes cient´ıficas e tecnológicas, e possui uma equipe envolvida na constru¸cão de ferramentas que visam facilitar sua utiliza¸c˜ ao. Muitas destas ferramentas precisam de um verificador de tipos para prover mais garantias quanto a consistência das especifica¸cões e programas, e, conseq¨ uentemente, de seus resultados. Neste trabalho, apresentamos uma defini¸c˜ ao formal para o sistema de tipos de Circus, com o intuito de auxiliar o desenvolvimento de um verificador de tipos para a linguagem. Optamos por primeiramente definir as regras de tipos de Circus para depois implementar o software que automatiza a aplica¸cão dessas regras. Esta decisão de projeto contribuiu para a constru¸c˜ ao robusta do verificador, pois a implementa¸c˜ ao consiste em um mapeamento direto das regras de tipos para linhas de código. O verificador desenvolvido também oferece recursos adicionais, tais como, a disponibilidade de informa¸c˜ oes de tipos para cada fragmento da especifica¸c˜ ao ou programa passado para análise, e o fornecimento de mensagens claras e objetivas dos poss´ıveis erros de tipos detectados ao longo da verifica¸c˜ ao. Adicionalmente, projetamos o verificador como um componente de fácil integra¸c˜ ao, manuten¸c˜ ao e extensão. Também apresentamos neste trabalho a nossa estratégia de valida¸c˜ ao do verificador. Elaboramos testes de pequeno e grande porte, a partir de estudos de casos de sistemas reais, tal como o sistema de SmartCard que descrevemos neste trabalho. Adicionalmente, integramos o verificador com outra ferramenta: o JCircus, que é um tradutor de Circus para Java. Também implementamos uma versão inicial de uma ferramenta de refinamentos, chamada CircusRefine, para integrar o verificador de tipos. Apesar de não termos constru´ıdo uma vers˜ ao completa de CircusRefine, nos preocupamos em definir a arquitetura da ferramenta de tal forma que sejam poss´ıveis futuras evolu¸cões de forma simples e estruturada. Os testes e integra¸c˜ oes contribu´ıram para a corre¸cão de defeitos da implementa¸c˜ ao e para a evolu¸c˜ ao e verifica¸c˜ ao de consistência do verificador de tipos de Circus. Ao definir o sistema de tipos de Circus, e disponibilizar um verificador de tipos, acreditamos que estamos dando uma importante contribui¸c˜ ao na evolu¸c˜ ao de Circus, esclarecendo pontos essenciais de sua defini¸cão como uma linguagem fortemente tipada e compat´ıvel com Z e CSP, e estamos também contribuindo para o desenvolvimento de outras ferramentas da linguagem. Esperamos que o nosso trabalho possa servir de base para a defini¸c˜ ao e implementa¸c˜ ao dos sistemas de tipos das extensões de Circus. Palavras-chave: Linguagens formais, concorrência, métodos formais, ferramentas.. xi.

(12)

(13) ABSTRACT The constant search for the development of systems with quality is resulting in industrial interest in the application of formal techniques. Currently, there are formal languages for modeling complex data structures, like Z, and others for modeling communication and concurrency, like CSP. Circus is a specification, design and programming language that combines Z and CSP. Besides making possible the specification of data and behavior aspects of concurrent systems, Circus includes a refinement calculus. This is its differential in comparison to other integrations of Z with an algebra of processes. Currently, Circus has a research team involved in the construction of tools that can facilitate its use. Many of these tools need a type checker to provide more guarantees about the consistency of the specifications and programs, and of its results. In this work, we present a formal definition of the Circus type system, with the intention of assisting the development of a type checker for this language. At first, we define the Circus type rules, and afterwards we describe how we implemented the type checker using a direct mapping of the type rules to code. This contributed to the robustness of the type checker. The developed type checker also offers extra facilities, such as the annotation of type information for each fragment of a specification or program, and the availability of clear and objective error messages. Additionally, we designed the type checker as a component of easy integration, maintenance and evolution. We also present in this work our validation strategy for the type checker. We elaborated tests using small specifications, to verify specific behaviors of the tool, and large specifications, from case studies of real systems, like the SmartCard specification that we describe in this work. Additionally, we integrated the type checker with another tool: JCircus, that it is a translator of Circus to Java. We also implemented an initial version of a refinement tool, called CircusRefine, to integrate the type checker. Although we have not constructed a complete version of CircusRefine, we defined the architecture of the tool to provide simple and structured evolutions. The tests and integrations have contributed for the correction of implementation defects and for the evolution and consistency verification of the Circus type checker. With the definition of the Circus type system and the implementation of its type checker, we believe that we are giving an important contribution in the evolution of Circus, clarifying essential points of its definition as a strongly typed language that is compatible with Z and CSP. Additionally, we are also contributing to the development of other tools for Circus. We hope that our work can serve as base for the definition and implementation of the type systems of the Circus extensions. Keywords: Formal languages, concurrency, formal methods, tools. xiii.

(14)

(15) ´ SUMARIO. Cap´ıtulo 1 – Introdu¸c˜ ao 1.1 1.2. 1.3 1.4. 1. Motiva¸cão . . . . . . . . . . . . . . . . . . . . . . . . . . . Tipos e Sistema de Tipos . . . . . . . . . . . . . . . . . . . 1.2.1 Formaliza¸cão de um Sistema de Tipos . . . . . . . 1.2.2 Inferência de Tipos . . . . . . . . . . . . . . . . . . 1.2.3 Sistemas de Tipos para Linguagens de Especifica¸caõ Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura da Disserta¸cão . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. Cap´ıtulo 2 – Circus 2.1 2.2. 2.3. 2.4. Histórico . . . . . . . . . . . . Descri¸caõ Informal da Sintaxe 2.2.1 Parágrafos de Circus . 2.2.2 Processos . . . . . . . 2.2.3 Parágrafos de Processo 2.2.4 A¸co˜es . . . . . . . . . 2.2.5 Comandos . . . . . . . Estudo de Caso . . . . . . . . 2.3.1 Modelo Abstrato . . . 2.3.2 Modelo Concreto . . . Considera¸co˜es Finais . . . . .. 9 . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. Cap´ıtulo 3 – Sistema de Tipos de Circus 3.1 3.2. 1 3 4 5 5 6 7. 9 11 12 13 16 17 19 21 21 24 33 35. Ambiente de Tipos . . . . . . . . . . . . Regras de Tipos . . . . . . . . . . . . . . 3.2.1 Programa . . . . . . . . . . . . . 3.2.2 Parágrafo de Circus . . . . . . . . 3.2.3 Declara¸caõ de Canal . . . . . . . 3.2.4 Expressão de Conjunto de Canais 3.2.5 Declara¸caõ de Processo . . . . . . 3.2.6 Defini¸caõ de Processo . . . . . . . 3.2.7 Processo . . . . . . . . . . . . . . 3.2.8 Expressão de Conjunto de Nomes 3.2.9 Parágrafo de Processo . . . . . . 3.2.10 Defini¸cão de A¸cão . . . . . . . . . xv. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 36 39 40 41 43 44 45 47 48 55 56 56.

(16) ´ SUMARIO. xvi. 3.3. 3.4 3.5. 3.2.11 A¸cão Parametrizada . . . . . . 3.2.12 A¸cão . . . . . . . . . . . . . . . 3.2.13 Comunica¸cão . . . . . . . . . . 3.2.14 Parâmetros de Comunica¸cão . . 3.2.15 Comando Parametrizado . . . . 3.2.16 Declara¸cão de Parâmetros . . . 3.2.17 Comando . . . . . . . . . . . . 3.2.18 A¸cões Guardadas . . . . . . . . Associa¸caõ entre as Regras de Tipos de 3.3.1 Parágrafo de Estado . . . . . . 3.3.2 Parágrafo Z . . . . . . . . . . . 3.3.3 Expressão . . . . . . . . . . . . 3.3.4 Expressão de Esquema . . . . . 3.3.5 Predicado . . . . . . . . . . . . 3.3.6 Declara¸caõ . . . . . . . . . . . . ´ Arvore de Julgamentos . . . . . . . . . Considera¸co˜es Finais . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Circus e as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regras de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . Z. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. Cap´ıtulo 4 – Verificador de Tipos de Circus 4.1. 4.2. 4.3. 4.4 4.5. 77. Cenário Inicial . . . . . . . . . . . . . . . . . . . . . 4.1.1 Padrão de Projeto Visitor . . . . . . . . . . 4.1.2 Verificador de Tipos para Z . . . . . . . . . CZT . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 O Padrão de Projeto Visitor do CZT . . . . 4.2.2 Verificador de Tipos do CZT . . . . . . . . . Verificador de Tipos de Circus . . . . . . . . . . . . 4.3.1 Arquitetura do Verificador . . . . . . . . . . 4.3.2 Classes Adicionais do Verificador de Circus . 4.3.3 Representa¸caõ do Ambiente de Tipos . . . . 4.3.4 Exemplo de Comportamento do Verificador Integra¸cão com o Verificador de Tipos de Circus . . Considera¸co˜es Finais . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. Cap´ıtulo 5 – Valida¸c˜ ao do Verificador de Tipos 5.1 5.2. 5.3. Testes . . . . . . . . . . . . . . Integra¸cões . . . . . . . . . . . 5.2.1 Integra¸caõ do Verificador 5.2.2 CircusRefine . . . . . . . Considera¸co˜es Finais . . . . . .. . . . . . . . . . . . . . . com JCircus . . . . . . . . . . . . . .. 57 58 62 64 66 66 67 70 71 72 72 72 73 73 73 73 74. 77 78 80 80 81 82 84 85 87 89 89 93 93 95. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 95 97 98 98 111.

(17) xvii. ´ SUMARIO. Cap´ıtulo 6 – Conclus˜ oes 6.1 6.2 6.3. 115. Contribui¸cões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 115 116 118. Apˆ endice A – Sintaxe de Circus. 121. Apˆ endice B – Fun¸c˜ oes Auxiliares. 123. B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.10 B.11 B.12 B.13 B.14 B.15 B.16 B.17 B.18 B.19 B.20 B.21 B.22 B.23 B.24 B.25 B.26 B.27 B.28 B.29 B.30 B.31 B.32 B.33 B.34. Fun¸cão Fun¸cão Fun¸cão Fun¸cão Fun¸cão Fun¸cão Fun¸cão Fun¸cão Fun¸cão Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ. Chan . . . . . . . . . Check . . . . . . . . . CheckChansRenaming CheckVarsRenaming . Compare . . . . . . . DeclareNewChans . . Decs . . . . . . . . . . DecsParDec . . . . . . Defs . . . . . . . . . . DefsAction . . . . . . DefsP . . . . . . . . . DefsPL . . . . . . . . DefsProc . . . . . . . DefsPSchema . . . . . DefsState . . . . . . . DiffDecs . . . . . . . . Extract . . . . . . . . ExtractAct . . . . . . ExtractActDefs . . . . ExtractFreeTypes . . . ExtractFT . . . . . . . ExtractGenTypes . . . ExtractGivenTypes . . ExtractParDecs . . . . ExtractProc . . . . . . ExtractProcDefs . . . ExtractVars . . . . . . ExtractVarsCP . . . . FindCA . . . . . . . . FindCComm . . . . . FindCCommand . . . FindCCSE . . . . . . FindCGA . . . . . . . FindCP . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 123 123 123 124 124 124 124 124 125 125 125 126 126 126 127 127 127 127 127 128 128 128 128 128 129 129 129 129 129 130 130 131 131 131.

(18) ´ SUMARIO. xviii B.35 B.36 B.37 B.38 B.39 B.40 B.41 B.42 B.43 B.44 B.45 B.46 B.47 B.48 B.49 B.50 B.51 B.52 B.53 B.54 B.55 B.56 B.57 B.58 B.59 B.60 B.61 B.62 B.63 B.64 B.65 B.66 B.67. Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ Fun¸caõ. FindCPP . . . . . . . . . FindImplicitChans . . . . FiniteDecs . . . . . . . . GenChans . . . . . . . . . GetTypeHead . . . . . . . GetTypeTail . . . . . . . . ImplicitChans . . . . . . . ImplicitRenameChans . . InstantiateTypesGenChan Into . . . . . . . . . . . . IsFinite . . . . . . . . . . IsNormalProc . . . . . . . MakeName . . . . . . . . MakeType . . . . . . . . . MakeTypeChan . . . . . . NewChans . . . . . . . . NewDefs . . . . . . . . . NoConflicts . . . . . . . . NoRep . . . . . . . . . . . NotInto . . . . . . . . . . NotRedeclare . . . . . . . NumTypes . . . . . . . . . NumTypesChan . . . . . . RefGenParam . . . . . . . RefState . . . . . . . . . . ReplaceChanType . . . . . Set . . . . . . . . . . . . . VarsC . . . . . . . . . . . VarsDec . . . . . . . . . . VarsParDec . . . . . . . . Verify . . . . . . . . . . . VerifyParDec . . . . . . . override . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Apˆ endice C – Regras de Tipos de Circus C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8. Regra de Programa . . . . . . . . . . . . . . . Regras de Listas de Parágrafos de Circus . . . Regras de Parágrafos de Circus . . . . . . . . . Regras de Declara¸caõ de Canais . . . . . . . . Regras de Expressões de Conjuntos de Canais Regras de Declara¸caõ de Processos . . . . . . Regras de Listas de Parágrafos de Processos . Regras de Processos . . . . . . . . . . . . . . .. 132 132 132 133 133 133 133 133 134 134 134 134 134 135 135 135 135 136 136 136 136 136 136 137 137 137 137 138 138 138 138 138 139 141. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 141 141 141 141 142 142 143 143.

(19) xix. ´ SUMARIO. C.9 Regras de Expressões de Conjuntos de Nomes . C.10 Regras de Parágrafos de Processo . . . . . . . . C.11 Regras de Defini¸cão de A¸cões . . . . . . . . . . C.12 Regras de A¸cões . . . . . . . . . . . . . . . . . . C.13 Regras de Comunica¸caõ . . . . . . . . . . . . . C.14 Regras de Listas de Parâmetros de Comunica¸caõ C.15 Regras de Parâmetros de Comunica¸caõ . . . . . C.16 Regras de Comandos Parametrizados . . . . . . C.17 Regras de Comandos . . . . . . . . . . . . . . . C.18 Associa¸co˜es com as Regras de Z . . . . . . . . .. . . . . . . . . . .. Apˆ endice D – Diagramas do Padr˜ ao de Projeto Visitor. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 145 145 145 145 147 148 148 148 148 149 151.

(20)

(21) LISTA DE FIGURAS 2.1 2.2 2.3. Especifica¸caõ do Processo CookieMachine . . . . . . . . . . . . . . . . . . Modelo Abstrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelo Concreto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20 22 25. 3.1 3.2 3.3. Contextos de um Programa de Circus . . . . . . . . . . . . . . . . . . . . ´ Arvore de Julgamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ambientes de Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38 74 75. 4.1 4.2 4.3 4.4 4.5 4.6 4.7. Estrutura do Código utilizando Visitor . . Estrutura de Classes do Padrão Visitor . . Hierarquia de Classes do CZT . . . . . . . Classes do verificador de tipos de Z . . . . Esquema para Integra¸cão do Verificador de Hierarquia das Classes de Circus . . . . . . Classes do verificador de tipos de Circus . .. . . . . . . .. . . . . . . .. . . . . . . .. 78 79 81 83 84 85 86. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14. Interface Gráfica de CircusRefine . . . . . . . . . . . . . . . . . . . . . Template das Leis de Refinamento de A¸cões . . . . . . . . . . . . . . Exemplo do Template de Lei Preenchido . . . . . . . . . . . . . . . . Integra¸cões de CircusRefine . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de casos de uso de CircusRefine . . . . . . . . . . . . . . . . Pacotes de CircusRefine . . . . . . . . . . . . . . . . . . . . . . . . . . Mensagem de Erro de Tipo . . . . . . . . . . . . . . . . . . . . . . . . Tela de Leis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tela de Argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lista das A¸co˜es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tela de Desenvolvimento com A¸cão Coletada . . . . . . . . . . . . . . Diagrama de Classes do Verificador de Tipos das Leis de Refinamento Mensagem de Erro de Tipo da Lei . . . . . . . . . . . . . . . . . . . . Templates da Lei Assumption Introduction . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. 100 101 101 103 104 105 106 107 107 108 108 109 111 114. D.1 Estrutura de Classes do Padrão Visitor . . . . . . . . . . . . . . . . . . . D.2 Diagrama de Seq¨ uência do Padrão Visitor . . . . . . . . . . . . . . . . .. 151 151. xxi. . . . . . . . . . . . . . . . . Tipos . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . ..

(22)

(23) CAPÍTULO 1. Introdu¸c˜ ao Neste cap´ıtulo, apresentamos as motiva¸cões e os objetivos do nosso trabalho. Também descrevemos os conceitos de tipos e sistemas de tipos e destacamos sua importância para linguagens de especifica¸caõ e programa¸cão. Por fim, apresentamos uma visão geral deste documento, destacando o que será apresentado nos demais cap´ıtulos.. 1.1. Motiva¸c˜ ao. Apesar de décadas de preocupa¸co˜es na ind´ ustria e no meio acadêmico com o desenvolvimento de sistemas com qualidade, ainda são comuns as falhas, muitas vezes custosas, de grandes projetos de software. Os métodos formais têm sido cada vez mais utilizados para resolver problemas de desenvolvimento de software, contribuindo para a produ¸caõ de programas corretos ou, pelo menos, para minimizar a ocorrência de erros. Uma vez tendo a especifica¸caõ formal de um sistema, podemos provar propriedades sobre a especifica¸caõ, assim como provar que um programa satisfaz a especifica¸caõ. Métodos formais são utilizados hoje em dia em projetos industriais, e estes métodos têm se mostrado efetivos no desenvolvimento de sistemas de software de larga escala, cujo custo de falhas em termos econômicos é alto; e também no desenvolvimento de sistemas de seguran¸ca cr´ıtica, onde o custo de falhas é medido em termos de danos pessoais e vidas. Entre os muitos exemplos de aplica¸co˜es industriais de métodos formais, podemos citar o projeto SLAM [2] da Microsoft, que tem por objetivo verificar automaticamente se programas escritos em C utilizam corretamente as interfaces de uma biblioteca externa. O projeto utiliza e estende idéias de verifica¸caõ de modelos, análise de programas e prova de teoremas. O objetivo da Microsoft ao utilizar métodos formais é provar a consistência destes programas. A IBM é outra empresa que utiliza técnicas formais. O IBM CICS é um grande sistema de processamento de transa¸co˜es e foi utilizada a linguagem formal Z [57] para especifica¸cão parcial de alguns de seus componentes. A utiliza¸caõ das técnicas formais na IBM resultou na redu¸caõ de erros e no aumento da qualidade do produto final [28, 15]. Por sua vez, a equipe de projeto da empresa Praxis utilizou uma combina¸caõ de métodos formais para ajudar a especificar, projetar e verificar o CDIS, um grande sistema responsável por exibir informa¸cões dentro de um sistema de controle de tráfego aéreo (ATC). O resultado do projeto mostrou que a utiliza¸cão de métodos formais em projetos reais de larga escala, além de ser praticável, trouxe muitos benef´ıcios [23]. Já a empresa Intel tem aplicado métodos formais para vários problemas que surgem durante o processo de definir as arquiteturas de plataforma para fam´ılias de processadores [1]. Propostas de melhorias para a qualidade de software incluem, entre outras idéias, uma grande quantidade de técnicas que ajudam a garantir que um sistema de software se 1.

(24) 2. ˜ INTRODUC ¸ AO. comporta corretamente com respeito a alguma especifica¸caõ do comportamento desejado. A escolha de uma linguagem adequada para a especifica¸cão e programa¸cão do sistema é um fator de extrema importância para a busca pela qualidade do software. De todas as linguagens formais, a linguagem de especifica¸caõ Z [57, 66] tem sido a mais aceita na academia e na ind´ ustria. Z é bastante utilizada na descri¸caõ de sistemas seq¨ uenciais e seu ponto forte é a modelagem de dados complexos. No entanto, esta linguagem tem recursos limitados para modelagem de aspectos comportamentais, e não consegue expressar concorrência diretamente. Por sua vez, a linguagem de especifica¸cão CSP [25, 50] também vem sendo bastante aceita na ind´ ustria e tem como proposta a modelagem de comunica¸caõ e concorrência. Trata-se de uma álgebra de processos que enfatiza a ordem de execu¸cão das opera¸cões de um sistema. Diferentemente de Z, o ponto forte de CSP é a modelagem comportamental. No entanto, CSP não tem facilidades para defini¸caõ de estruturas de dados complexas e opera¸co˜es sobre elas. A modelagem de dados é simulada pela parametriza¸caõ de processos, com os parâmetros manipulados utilizando uma linguagem funcional. As duas linguagens possuem pontos positivos e negativos, mas as duas se completam. Enquanto Z é mais bem utilizada para modelagem de dados, e CSP para a modelagem de comunica¸caõ e concorrência, a combina¸caõ das duas linguagens pode resultar em uma linguagem bastante poderosa e que atende aos aspectos estruturais e comportamentais na modelagem de sistemas. Desta forma, com o intuito de agregar as qualidades de duas linguagens de especifica¸caõ consolidadas, Z e CSP, e com o objetivo de propor e formalizar um cálculo de refinamentos para programas concorrentes, surgiu o projeto de cria¸caõ da linguagem Circus [67, 68]. Existem na literatura diversas outras propostas de integra¸cões de linguagens formais para modelagem de dados com álgebras de processos. Fischer [16] propõe a linguagem CSP-Z, que combina CSP com esquemas de Z para a descri¸caõ de tipos de dados. Nesta linguagem, para cada evento usado na parte CSP existe uma opera¸caõ correspondente na parte de Z, diferentemente de Circus, que dissocia comunica¸caõ de opera¸cões sobre o estado. Já em [17], Fischer define uma combina¸caõ de Object-Z, uma extensão orientada a objetos de Z, com CSP. A linguagem resultante, CSP-OZ, estende Object-Z com a no¸cão de canais de comunica¸caõ e a sintaxe de CSP. Em [42] é investigada a no¸cão de heran¸ca para a linguagem CSP-OZ. A linguagem TCOZ [35, 33, 34], por sua vez, descreve uma nota¸cão para especifica¸caõ de sistemas de tempo real, concorrentes e reativos. A linguagem inclui primitivas de tempo e suporta a modelagem de concorrência m´ ultipla. Em [49] é proposta a tradu¸caõ de especifica¸co˜es Z em CSP. Smith, em [56], propõe a integra¸cão do Real-Time Object-Z [55] com a álgebra de processos CSP, com o objetivo de possibilitar a especifica¸caõ de sistemas concorrente de tempo real. Já em [27] é apresentada a linguagem CSP-OZ-DC, que estende a linguagem CSP-OZ com o aspecto de tempo real cont´ınuo. Buscando uma integra¸cão com outra álgebra de processos, em [20, 59] é proposta uma integra¸cão da linguagem Z e do value-passing CCS. Já em [4, 3] é descrita uma técnica para o projeto de sistemas distribu´ıdos utilizando a nota¸caõ de máquina abstrata B. Em [5] é apresentada a ferramenta csp2B que converte especifica¸cões escritas em CSP em especifica¸co˜es B. Já em [62, 51, 63] é descrita uma forma de usar a álgebra de processos.

(25) 1.2 TIPOS E SISTEMA DE TIPOS. 3. CSP para permitir a intera¸caõ controlada entre máquinas B concorrentes. Circus, no entanto, não é apenas mais uma proposta de integra¸caõ de Z com uma álgebra de processos. Ela também inclui construtores da linguagem de comandos guardados de Dijkstra [13]. Em Circus não existe a separa¸caõ expl´ıcita da parte de dados da parte comportamental. Os construtores de Z e de CSP são utilizados livremente dentro da especifica¸cão. Adicionalmente, Circus é uma linguagem de refinamentos, pois inclui uma teoria e um cálculo de refinamentos que permite se chegar a código a partir de uma especifica¸caõ abstrata de um sistema. Sua semântica é baseada na UTP [26] e redefine as semânticas de Z e CSP. Uma linguagem de especifica¸cão ou programa¸caõ deve fornecer todos os recursos necessários para a constru¸cão de programas corretos. O conceito de tipos de dados é um importante aux´ılio para linguagens, já que incorporam caracter´ısticas desejáveis de corretude, abstra¸cão, seguran¸ca, flexibilidade e portabilidade. Uma linguagem que tem um sistema de tipos associado pode agregar a verifica¸caõ de tipos no seu próprio compilador, no caso de uma linguagem de programa¸caõ, ou em outras ferramentas de processamento, no caso de uma linguagem de especifica¸caõ ou de projeto. Um sistema de tipos é um método sintático para provar ausência de certos comportamentos do programa pela classifica¸caõ de expressões de acordo com os valores que elas denotam [47]. Na programa¸caõ, os tipos podem esclarecer várias questões, tais como a caracteriza¸caõ de valores que surgem dinamicamente no curso de uma computa¸caõ e a conformidade de representa¸caõ de tais valores. Tipos também podem impor certas limita¸cões que irão ajudar a refor¸car a corretude dos programas. O uso de uma linguagem bem projetada e que disponibiliza uma verifica¸caõ automática de tipos garante a ausência de certas classes de erros em tempo de execu¸caõ. Apesar das linguagens de programa¸cão terem sido a base para o desenvolvimento da teoria de tipos [24], também podemos aplicar muitos dos conceitos desta teoria para as linguagens de especifica¸cão formal. Linguagens de especifica¸cão são formas especiais de linguagens de programa¸cão que não podem ser executadas. Embora exista uma grande quantidade de métodos ou nota¸cões formais dispon´ıveis atualmente, tais métodos e nota¸cões ainda são menos utilizados na comunidade industrial que no meio acadêmico. Uma das principais razões para isto é a indisponibilidade e, muitas vezes, as limita¸co˜es das ferramentas de suporte automatizadas, tais como verificadores sintáticos e verificadores de tipos. Certamente, a disponibilidade de tais ferramentas é essencial para a aplica¸caõ bem sucedida dos métodos formais em problemas de escala industrial. A existência destas ferramentas pode encorajar e facilitar a utiliza¸caõ dos métodos formais, reduzindo a possibilidade de ocorrências de erros; e pode aumentar a produtividade e a qualidade na produ¸caõ de especifica¸cões formais.. 1.2. Tipos e Sistema de Tipos. Um sistema de tipos é uma cole¸caõ de regras de tipos para uma linguagem de programa¸cão ou de especifica¸caõ. As regras de tipos determinam condi¸co˜es necessárias para a execu¸caõ correta de programas. Sistemas de tipos podem adicionar regularidade às linguagens. Quando uma linguagem está associada a um sistema de tipos, dizemos que ela é uma.

(26) ˜ INTRODUC ¸ AO. 4. linguagem tipada. Sistemas de verifica¸cão de tipos para linguagens de programa¸caõ podem ser classificados como estáticos ou dinâmicos. Em uma linguagem estaticamente tipada, o tipo de cada expressão pode ser deduzido, e cada programa pode ser verificado em tempo de compila¸cão. Um sistema de verifica¸caõ estático detecta erros de tipos e previne a gera¸caõ de código executável inapropriado. Assim, nós podemos dizer que um programa que foi verificado estaticamente é livre de erros de tipo em tempo de execu¸caõ. Isto permite que o compilador gere código executável de forma mais eficiente, pois não é necessário incluir qualquer tipo de informa¸caõ ou mecanismos de verifica¸cão de tipos no código. Já em uma linguagem dinamicamente tipada, apenas os valores têm tipos fixos. Uma variável ou parâmetro não tem um tipo associado, mas pode receber valores de tipos diferentes em tempos diferentes. Isto implica que os operandos devem ter seus tipos verificados imediatamente antes de uma opera¸caõ ser realizada em tempo de execu¸cão. Sistemas de verifica¸caõ de tipos dinâmicos geralmente abortam a execu¸cão do programa quando um erro é detectado. Linguagens em que todas as variáveis e expressões são garantidamente usadas de forma consistente são chamadas de linguagens fortemente tipadas. Se uma linguagem é fortemente tipada, seu compilador pode garantir que os programas que ele aceita serão executados sem erros de tipos. Todas as linguagens que precisam apenas de verifica¸caõ estática são fortemente tipadas, mas o inverso nem sempre é verdadeiro, pois algumas linguagens fortemente tipadas precisam da determina¸cão de alguns tipos em tempo de execu¸cão. No caso de linguagens de especifica¸caõ, se o sistema de tipos não permite verifica¸cão estática, isto significa que a verifica¸caõ de tipos não pode ser feita automaticamente. Conseq¨ uentemente, estabelecer que uma especifica¸cão está bem tipada requer prova de teorema. Em geral, não é poss´ıvel executar a especifica¸caõ e testar a conformidade de tipos à medida que a execu¸cão evolui como é feito no caso de linguagens de programa¸caõ. Os teoremas que garantem conformidade de tipos se tornam obriga¸co˜es de prova do especificador, e tornam a tarefa de especifica¸caõ mais dif´ıcil. Esta é mais uma razão para projetar o sistema de tipos de uma linguagem de forma a possibilitar verifica¸cão estática. 1.2.1. Formaliza¸c˜ ao de um Sistema de Tipos. O objetivo de se formalizar o sistema de tipos de uma linguagem é eliminar ambig¨ uidades em questões de tipos que uma defini¸caõ informal pode apresentar. Isto, conseq¨ uentemente, pode garantir a constru¸cão robusta de verificadores de tipos para a linguagem, e uma vez se baseando na defini¸cão formal do sistema de tipos, projetos distintos de verificadores apresentarão o mesmo comportamento. A formaliza¸caõ de sistemas de tipos requer a defini¸cão de nota¸co˜es precisas. O sistema de tipos formal de uma linguagem de programa¸cão ou especifica¸caõ é uma caracteriza¸caõ matemática do sistema de tipos informal descrito nos manuais desta linguagem. Para a formaliza¸cão do sistema de tipos de uma linguagem, essencialmente é necessária a formaliza¸cão de toda a linguagem. O primeiro passo na formaliza¸cão de uma linguagem é a descri¸cão de sua sintaxe. O próximo passo é definir as regras de escopo da linguagem.

(27) 1.2 TIPOS E SISTEMA DE TIPOS. 5. que associam, sem ambig¨ uidades, as ocorrências de identificadores aos locais onde eles são declarados. Uma vez estabelecidas as regras de escopo, o próximo passo consiste na defini¸cão das regras de tipos da linguagem. Entretanto, as regras de tipos não podem ser formalizadas sem antes ser definido o ambiente de tipos estático da linguagem. Este ambiente de tipos define o escopo das variáveis de um termo em análise. Por fim, o u ´ltimo passo na formaliza¸cão de uma linguagem consiste na defini¸caõ de sua semântica. A viola¸caõ do sistema de tipos de uma linguagem resulta na manipula¸caõ dos dados de forma não intencional, causando resultados não esperados em programas escritos nesta linguagem. Com o objetivo de prevenir viola¸cões no sistema de tipos, é geralmente imposta aos programas uma estrutura de tipos estática. No caso das expressões com pouca ou nenhuma informa¸caõ de tipo fornecida explicitamente, um sistema de inferência de tipos é usado para determinar os tipos destas expressões. 1.2.2. Inferˆ encia de Tipos. Em linguagens tipadas convencionais, o compilador atribui um tipo para toda expressão e sub-expressão. Contudo, o programador não precisa especificar o tipo de toda expressão e sub-expressão: as informa¸co˜es de tipos precisam apenas ser colocadas em pontos cr´ıticos de um programa e o restante é deduzido do contexto. Este processo de dedu¸cão é chamado inferência de tipos. No geral, a informa¸cão de tipo é dada para variáveis locais e para argumentos e resultados de fun¸cões. Os tipos de expressões e comandos podem ser inferidos, já que os tipos de variáveis e constantes são conhecidos. A inferência de tipos de um termo escrito em um determinada linguagem está muito relacionada ao sistema de tipos desta linguagem. Um algoritmo de inferência de tipos pode ser muito simples, muito complexo, ou imposs´ıvel de se determinar, dependendo do sistema de tipos. A utilidade prática de um sistema de tipos depende da disponibilidade de um bom algoritmo de inferência de tipos. 1.2.3. Sistemas de Tipos para Linguagens de Especifica¸c˜ ao. Na linha das linguagens de especifica¸caõ formal, Z se destaca por possuir uma defini¸caõ formal bem estabelecida do seu sistema de tipos e diversas implementa¸cões do seu verificador de tipos. Em [72, 61] estão definidas todas as regras de tipos da linguagem, juntamente com a defini¸cão de sua sintaxe e semântica. A descri¸caõ de um verificador de tipos para Z, resultante da implementa¸cão destas regras, pode ser encontrada em [37, 39]. Já em [32] é definido um sistema de tipos de segunda ordem [9] para CSP. Um sistema de tipos é chamado de segunda ordem quando inclui quantificadores universais e existenciais para modelar fun¸co˜es genéricas, tipos de dados abstratos e subtipos. No entanto, as regras propostas neste sistema de tipos de CSP focam mais no cálculo de processos e, desta forma, não contemplam toda a sintaxe da linguagem. Adicionalmente, não encontramos na literatura implementa¸co˜es de verificadores de tipos de CSP que referenciem este sistema de tipos. Em [53], são definidas regras de tipos para classes de Object-Z, e, em [14], estas regras de tipos são estendidas para os construtores adicionais de TCOZ. Em [30], são apresentadas algumas defini¸cões informais das regras de tipos de Object-Z e é apresentado.

(28) ˜ INTRODUC ¸ AO. 6. o projeto do verificador de tipos da linguagem. Não é feita nenhuma rela¸cão entre as regras de tipos propostas em [53] e o verificador de Object-Z. Finalmente, em [65], é dada uma breve descri¸caõ do verificador de tipos da linguagem B, mas não são feitas referências às regras de tipos da linguagem. Os usuários de Circus vêm assumindo que temos uma linguagem fortemente tipada, compat´ıvel com Z e CSP. Mas não há, na literatura, qualquer detalhamento ou descri¸caõ formal das regras de tipos de Circus.. 1.3. Objetivos. Nesta disserta¸caõ, definimos o sistema de tipos de Circus, com o intuito de auxiliar o desenvolvimento e garantir a ausência de erros de tipos de especifica¸co˜es e programas escritos nesta linguagem, sendo este um passo importante para o desenvolvimento de sistemas de qualidade. Circus é uma linguagem relativamente nova, que vem sendo muito bem aceita pela ind´ ustria e atualmente possui uma equipe envolvida na sua evolu¸cão e na constru¸cão de ferramentas que visam facilitar sua utiliza¸caõ [46, 18, 19]. Muitas das ferramentas em desenvolvimento pelo grupo de Circus precisam de uma integra¸cão com um verificador de tipos da linguagem para possibilitar a gera¸caõ de resultados com maior confiabilidade. O objetivo do nosso trabalho é formalizar o sistema de tipos de Circus tomando como base a defini¸cão formal do sistema de tipos de Z e preservando também o comportamento de CSP do ponto de vista de tipos. A idéia é manter a compatibilidade entre as linguagens e tornar mais fácil o uso de Circus por pessoas já familiarizadas com Z e CSP. A defini¸caõ formal do sistema de tipos de Z envolve 57 regras e 2 ambientes; para CSP, temos 45 regras e 1 ambiente. Nosso desafio é integrar e harmonizar estas defini¸cões, e ainda considerar os construtores adicionais de Circus. Isto envolve a necessidade de inferência de tipos. Não é do nosso interesse redefinir as regras de tipos de Z, uma vez que o sistema de tipos da linguagem já é muito bem estabelecido. O nosso objetivo é reutilizar as regras de Z em nosso sistema de tipos e, para tal, fazer associa¸co˜es entre as regras de Circus e as de Z. A formaliza¸caõ do sistema de tipos de uma linguagem possibilita a verifica¸caõ de programas para garantir o uso consistente de valores e expressões dos diversos tipos dispon´ıveis na linguagem. Adicionalmente, a formaliza¸caõ do sistema de tipos é uma especifica¸caõ precisa para um verificador de tipos e, como tal, um artefato importante para o seu desenvolvimento com qualidade. Uma defini¸cão informal do sistema de tipos poderia levar a constru¸co˜es amb´ıguas de verificadores de tipos de uma mesma linguagem. Com o intuito de automatizar o sistema de tipos que propomos neste trabalho, e, desta forma, possibilitar a execu¸cão das demais ferramentas de Circus com especifica¸cões válidas e bem tipadas, também é nosso objetivo implementar um verificador de tipos para Circus. Para a constru¸caõ robusta do verificador, faremos um mapeamento direto de cada regra de tipos, definida na formaliza¸cão do sistema de tipos, para código. O desenvolvimento do verificador de Circus torna poss´ıvel sua integra¸caõ com as demais ferramentas da linguagem já desenvolvidas ou em fase de desenvolvimento. No entanto, é de nosso interesse fazer com que o verificador ofere¸ca recursos adicionas às.

(29) ˜ 1.4 ESTRUTURA DA DISSERTAC ¸ AO. 7. ferramentas de Circus, e não apenas retorne sucesso ou erro no final de uma verifica¸caõ. Para tal, o nosso propósito é fazer com que o verificador disponibilize informa¸cões de tipos de cada fragmento da especifica¸cão ou programa passado para análise. Com tais informa¸cões, as ferramentas de Circus podem acessar os tipos de fragmentos de uma especifica¸caõ que foi analisada sem precisar implementar recursos adicionais para capturar estas informa¸co˜es. Adicionalmente, é de nosso interesse fazer com que o verificador, no caso de encontrar erros de tipos, apresente mensagens claras, objetivas e precisas dos erros capturados. ´ nosso objetivo também desenvolver o verificador como um componente de fácil inE tegra¸cão com as demais ferramentas de Circus. Para tal, decidimos pela implementa¸caõ do verificador utilizando o padrão de projeto visitor e o framework do CZT [37, 39], que consiste em um projeto para o desenvolvimento estruturado de ferramentas de Z e de suas extensões. Além do verificador, outras ferramentas de Circus também foram implementadas utilizando este framework, tais como o verificador de modelos [19] e JCircus, um tradutor de Circus para Java [18]. Um outro objetivo é projetar o verificador de forma que seja poss´ıvel sua fácil manuten¸cão e futuras extensões para eventuais evolu¸cões da linguagem Circus. Para tal, seguiremos um processo de desenvolvimento, passando pelas fases de análise, projeto, implementa¸cão e testes. Documenta¸caõ apropriada tanto no n´ıvel de projeto quanto de código é fundamental; em particular, utilizamos diagramas e artefatos UML. A decisão de projeto de utilizar o padrão visitor e o framework do CZT também contribuirá para a manuten¸cão ou evolu¸cão do verificador sem impacto nas demais ferramentas. Isto, sem d´ uvida, é de grande importância para o desenvolvimento conjunto de ferramentas para Circus. Com o intuito de validar o verificador de tipos de Circus, elaboramos testes e realizamos integra¸co˜es com outras ferramentas da linguagem, com o objetivo de detectar poss´ıveis falhas e melhorias na implementa¸caõ do verificador. Dentre as integra¸cões a realizar, escolhemos a ferramenta JCircus, que já se encontra desenvolvida, e propomos uma implementa¸cão inicial da ferramenta de refinamentos de Circus, chamada CircusRefine. A necessidade de desenvolvimento desta ferramenta surgiu devido ao fato de ainda não existirem ferramentas suficientes de Circus em um estágio adequado para a integra¸caõ. Pretendemos, com o desenvolvimento de CircusRefine, validar a utilidade do verificador de tipos e apresentar uma proposta inicial de uma ferramenta u ´til para o refinamento de especifica¸co˜es da linguagem. Enfim, nosso objetivo principal é a execu¸caõ do trabalho cient´ıfico e tecnológico necessário para resolver o problema de verifica¸cão de tipos de especifica¸cões e programas em Circus. Assim, contribu´ımos para o desenvolvimento de outras ferramentas da linguagem.. 1.4. Estrutura da Disserta¸c˜ ao. Além deste cap´ıtulo introdutório, este documento é composto de outros cinco cap´ıtulos e três apêndices. No Cap´ıtulo 2, descrevemos a linguagem formal Circus, apresentamos sua sintaxe.

(30) 8. ˜ INTRODUC ¸ AO. e exibimos um estudo de caso. Neste estudo de caso apresentamos uma especifica¸cão abstrata de um sistema de controle de cartões, o SmartCard, e sugerimos um refinamento apresentando uma especifica¸cão concreta do sistema. No Cap´ıtulo 3, apresentamos a formaliza¸caõ de um sistema de tipos para a linguagem Circus, onde descrevemos o ambiente de tipos da linguagem, destacando os registros que guardam informa¸co˜es sobre os tipos, e apresentamos as regras de tipo para cada estrutura sintática de Circus. Ainda neste cap´ıtulo mostramos as associa¸cões entre as regras de tipos de Circus e as regras de tipos de Z. No Cap´ıtulo 4, apresentamos o projeto do verificador de tipos de Circus, onde discutimos as estratégias de desenvolvimento, o framework utilizado, e apresentamos um exemplo de comportamento do verificador. O sistema de tipos definido no Cap´ıtulo 3, com as regras de tipos elaboradas, foi mapeado em código, resultando no verificador de tipos apresentado. No Cap´ıtulo 5, discutimos as estratégias de valida¸caõ do verificador de tipos desenvolvido e descrevemos os testes e as integra¸co˜es realizadas com o verificador. Adicionalmente, apresentamos CircusRefine, uma ferramenta de refinamentos para Circus que foi desenvolvida especialmente para integra¸caõ com o verificador. Finalmente, no Cap´ıtulo 6, fazemos considera¸cões gerais sobre o trabalho realizado, discutimos em detalhe alguns trabalhos relacionados, e descrevemos algumas propostas de trabalhos futuros. Este documento possui quatro apêndices. A sintaxe completa da linguagem Circus é apresentada no Apêndice A. O Apêndice B lista e define todas as fun¸co˜es usadas na defini¸cão das regras de tipos de Circus. O Apêndice C lista todas as regras de tipos definidas neste trabalho. Finalmente, o Apêndice D exibe diagramas que ilustram a estrutura do padrão de projeto visitor..

(31) CAPÍTULO 2. Circus Neste cap´ıtulo, descrevemos a linguagem Circus. Na Se¸cão 2.1, apresentamos um breve histórico da linguagem. Uma descri¸cão informal da sua sintaxe pode ser encontrada na Se¸cão 2.2. Na Se¸cão 2.3, apresentamos um exemplo de especifica¸caõ de um sistema real com a linguagem Circus. Finalmente, na Se¸cão 2.4, fazemos algumas considera¸co˜es finais sobre a linguagem.. 2.1. Hist´ orico. Circus (Concurrent Integrated Refinement CalculUS) [67, 68] é uma linguagem de especifica¸cão, projeto e programa¸cão que combina outras duas linguagens: Z [57, 66], que possibilita a especifica¸caõ de estruturas de dados complexas; e CSP [25], que é uma álgebra de processos que suporta a modelagem de comunica¸caõ e concorrência. Adicionalmente, Circus engloba alguns construtores do cálculo de refinamentos de Morgan [40] e os construtores da linguagem de comandos guardados de Dijkstra [13]. Os objetivos principais do projeto de Circus são: facilidade de uso para usuários acostumados com Z e CSP, especifica¸caõ e projeto, baseado em refinamento, de sistemas concorrentes e distribu´ıdos envolvendo estruturas de dados complexas, e a possibilidade de reuso de teorias, técnicas e métodos já existentes. A semântica de Circus é baseada na Unifying Theories of Programming [26]. A linguagem Z é amplamente utilizada na descri¸caõ de sistemas seq¨ uenciais, mas não consegue expressar concorrência diretamente. Existem alguns trabalhos que definem conven¸co˜es para definir concorrência em Z. O resultado, no entanto, é artificial porque a linguagem não oferece construtores apropriados. Já CSP (Communicating Sequential Processes) é uma linguagem de especifica¸caõ própria para sistemas concorrentes, pois ela enfatiza a ordem em que as opera¸co˜es dos sistemas podem ser executadas. No entanto, CSP não tem facilidades para defini¸caõ de estruturas de dados e opera¸cões associadas mais complexas. Os dados são tratados em CSP como parâmetros de processos e manipulados usando uma linguagem funcional. O objetivo ao se integrar uma linguagem formal para especifica¸cão e modelagem de dados com uma álgebra de processos é justamente agregar as principais caracter´ısticas destas linguagens, possibilitando uma modelagem mais adequada e ampla de sistemas. Diversos outros trabalhos se propõem a integrar Z, ou uma de suas extensões, com alguma álgebra de processos. A linguagem CSP-Z [16] tem a mesma proposta de Circus ao utilizar CSP para descrever aspectos dinâmicos de um sistema e Z para especificar a parte de dados. No entanto, diferentemente de Circus, em CSP-Z existe a separa¸cão clara da parte de dados e da parte de controle. O processo de nome main define a ordem de execu¸cão das opera¸co˜es, usando 9.

(32) 10. CIRCUS. CSP, e a parte Z consiste de esquemas que definem o espa¸co de estado local, o estado inicial, e as opera¸co˜es para os canais. Para cada evento E, utilizado na parte CSP, existe um esquema de nome com E que define as atualiza¸co˜es nas variáveis de estado do sistema quando o evento ocorre. A idéia semântica desta linguagem é que o processo main e a parte Z são executadas em paralelo. Toda comunica¸cão do sistema afeta ambas as partes. Já em [49], é dada uma tradu¸cão informal de especifica¸co˜es Z para CSP. A idéia apresentada é a separa¸cão de cada opera¸caõ de Z em duas partes, sendo uma que trata dos parâmetros de entrada e a outra que trata dos parâmetros de sa´ıda, e a associa¸cão de uma a¸cão para cada parte. Depois da separa¸caõ, as a¸co˜es criadas podem ser colocadas em um processo do framework de CSP. A combina¸caõ de CSP e Object-Z, uma extensão orientada a objetos de Z, é apresentada em [17, 42]. Este trabalho segue a mesma linha de CSP-Z [16]. A idéia da integra¸cão é definir a semântica dinâmica de uma classe de Object-Z utilizando o modelo semântico de CSP. A linguagem resultante, CSP-OZ, estende Object-Z com a no¸cão de canais de comunica¸caõ e a sintaxe de CSP. Em [17], é apresentada a sintaxe e semântica da linguagem CSP-OZ. Já em [42], é investigada a no¸cão de heran¸ca da linguagem. O Real-Time Object-Z [55] é uma integra¸caõ da linguagem de especifica¸caõ formal Object-Z com a nota¸cão de tempo para modelagem de variáveis cont´ınuas e de restri¸cões de tempo real. O trabalho apresentado em [56] descreve o acréscimo da habilidade do Real-Time Object-Z para especificar sistemas concorrentes de tempo real pela integra¸cão semântica desta linguagem com a álgebra de processos CSP. Esta integra¸caõ se baseia em trabalhos já existentes que integram o Object-Z padrão com CSP [17, 42]. TCOZ [34, 33, 35] é uma linguagem que se propõe a modelar os aspectos de estado e de processo de sistemas complexos incluindo as primitivas de tempo e suportando a modelagem de concorrência m´ ultipla. A linguagem é resultante da combina¸caõ de ObjectZ, que serve para modelagem de algoritmos e dados complexos, e Timed CSP, que é uma extensão da álgebra de processos CSP adicionando-se as primitivas para modelagem de tempo real, tais como delay e timeout. Os trabalhos em [34, 33] apresentam a sintaxe concreta de TCOZ e suas produ¸cões, além de definir as extensões das opera¸co˜es e classes de Object-Z para suportar a integra¸caõ. Já em [35], é apresentada a sintaxe abstrata e a semântica de TCOZ, mas não são discutidos os aspectos semânticos de referências a objetos e nem o refinamento de dados. Em [27], é apresentada uma combina¸caõ das técnicas formais para especifica¸cão de processos (CSP), dados (Object-Z) e tempo (Duration Calculus [71]), resultando no CSPOZ-DC. Este trabalho estende CSP-OZ com aspectos de tempo real cont´ınuo. Também são apresentados os construtores de CSP-OZ-DC, a semântica da combina¸caõ, e é ilustrado um exemplo de aplica¸cão. A integra¸cão de Z com uma álgebra de processos diferente de CSP é apresentada em [59]. A álgebra de processos escolhida é o value-passing CCS, que permite a passagem de valores entre processos para especificar sistemas concorrentes. Adicionalmente, em [20], é apresentado o estilo e a sintaxe da linguagem resultante, ZCCS, é descrito um pequeno exemplo de especifica¸caõ, e é apresentada a semântica operacional da linguagem. Em [4, 3], é mostrado como o método B pode ser usado para projetar sistemas distribu´ıdos inserindo sistemas de a¸co˜es dentro deste método. No entanto, em [4], é dada.

(33) ˜ INFORMAL DA SINTAXE 2.2 DESCRIC ¸ AO. 11. uma visão baseada em eventos do sistema de a¸co˜es. Neste trabalho, é utilizada a técnica de CSP para os sistemas de a¸cões para permitir que as intera¸co˜es entre os subsistemas sejam realizadas pela passagem de mensagens sincronizadas e sem compartilhamento de dados. Já em [3], é considerada uma visão baseada no estado do sistema de a¸cões. Este trabalho mostra como sistemas de a¸co˜es podem ser transformados em máquinas abstratas dentro do método B e são comparadas as no¸co˜es de refinamento de sistemas de a¸co˜es e de B. Em [5], é apresentada uma ferramenta que gera especifica¸co˜es em B a partir da descri¸cão de um sistema em CSP, o csp2B. No entanto, csp2B não suporta o operador de escolha interna de CSP e possui restri¸cões no suporte aos operadores de composi¸caõ paralela e interleaving. O trabalho em [5] apresenta também uma justificativa baseada em semântica operacional para a forma em que é feita a tradu¸cão de CSP para B. Uma combina¸caõ de CSP com B é apresentada em [62, 51]. Em [62], é proposta a defini¸cão de um processo de CSP para agir como um controlador e seus eventos servirem como guias para as opera¸co˜es das máquinas de B. Também é apresentada a consistência entre CSP e B em termos dos seus modelos semânticos existentes. Já em [51], é descrita uma forma de usar a álgebra de processos CSP para permitir a intera¸caõ controlada entre máquinas B concorrentes. Diferentemente do trabalho apresentado em [62], que se concentra em um u ńico processo controlador encapsulando um u ńico fluxo de controle para uma máquina B, o trabalho em [51] considera como uma cole¸caõ de combina¸cões de máquinas B com seus controladores podem interagir. Por fim, o trabalho apresentado em [63] foca em um estudo de caso que aplica as técnicas descritas em [62, 51]. Os resultados definem um framework teórico para especifica¸cão combinada usando CSP e B. Um ponto forte de Circus, que a torna diferente de muitas outras propostas de linguagens que integram Z (ou uma de suas extensões) com uma álgebra de processos, é que ela inclui um cálculo de refinamentos, o que permite que a partir de uma especifica¸cão abstrata da linguagem se chegue a código. Em Circus não existe a separa¸caõ expl´ıcita da parte de dados e a parte comportamental. Os construtores de Z e CSP podem ser usados livremente dentro de uma especifica¸caõ e sem uma ordena¸caõ pré-estabelecida. Isto a torna mais próxima de uma linguagem de programa¸cão. Desde sua cria¸caõ, Circus vem passando por evolu¸cões: desde a defini¸cão de sua sintaxe e semântica [68, 46], até a defini¸caõ de suas estratégias de refinamento [10, 11] e defini¸co˜es de regras que traduzem programas escritos em Circus para Java [18, 44]. Atualmente, o grupo de pesquisa de Circus vem trabalhando na extensão da linguagem e na elabora¸caõ de ferramentas que automatizem seu uso. O que se espera, no futuro, é integrar todas as ferramentas e usá-las para o desenvolvimento de programas a partir de especifica¸co˜es abstratas de Circus.. 2.2. Descri¸c˜ ao Informal da Sintaxe. Nesta se¸caõ, nós apresentamos uma descri¸caõ informal de Circus e sua sintaxe. Uma descri¸cão completa da sintaxe abstrata se encontra no Apêndice A; a semântica formal da linguagem foi descrita inicialmente em [68], e mais recentemente em [46]. Um programa de Circus é formado por uma lista de parágrafos, onde cada parágrafo pode ser um parágrafo Z, uma defini¸caõ de canal, uma defini¸caõ de conjunto de canais,.

(34) 12. CIRCUS. ou uma defini¸cão de processo. Program. ::= CircusParagraph∗. CircusParagraph ::= Paragraph | channel CDeclaration | chanset N == CSExpression | ProcessDeclaration A lista de parágrafos pode ser vazia. 2.2.1. Par´ agrafos de Circus. Um parágrafo de Circus, definido como um parágrafo Z, permite a defini¸caõ de constantes e tipos globais. Para exemplificar alguns construtores de Circus, vamos especificar uma máquina de biscoitos. Esta máquina vai acumulando o valor até chegar no total do pre¸co do biscoito (podendo ultrapassar o valor). Quando chegar no valor do biscoito, é enviada uma mensagem de sucesso e o pre¸co do biscoito é decrementado do valor depositado. No caso de sobrar dinheiro, a máquina retorna o troco. Os primeiros parágrafos desta especifica¸caõ são apresentados abaixo. cookieValue, cookieQuantity : N COOKIE ::= ok | notok O primeiro parágrafo Z define as constantes globais cookieValue, que representa o pre¸co do biscoito; e cookieQuantity, que representa a quantidade de biscoitos contida na máquina. Já o segundo parágrafo Z define um tipo livre COOKIE que contém os valores ok e notok . Tais nomes, uma vez definidos, podem ser usados na especifica¸caõ como constantes e tipos globais, respectivamente. CDeclaration. ::= SimpleCDeclaration | SimpleCDeclaration; CDeclaration. SimpleCDeclaration ::= N+ | N+ : Expression | [N+ ] N+ : Expression Os canais são as interfaces entre o sistema e o ambiente externo. Um canal pode comunicar valores ou não. Quando um canal não comunica valores, dizemos que ele é de sincroniza¸cão. Para defini¸cão de um canal, utilizamos a palavra-chave channel, seguida pelo nome do canal e pelo tipo dos valores que ele comunica. No caso de um canal de sincroniza¸cão, este tipo é omitido. No exemplo a seguir, definimos os canais in e change que podem transportar n´ umeros naturais; e um canal out que transporta valores do tipo.

(35) ˜ INFORMAL DA SINTAXE 2.2 DESCRIC ¸ AO. 13. COOKIE , isto é, os valores ok e notok .. channel in, change : N channel out : COOKIE. Adicionalmente, Circus permite a defini¸cão de canais genéricos. Um canal genérico pode comunicar valores de diversos tipos, dependendo de sua instancia¸caõ. Para exemplificar, vamos considerar a seguinte declara¸caõ de canal genérico: channel [X ]chan : X . Se a instancia¸cão do canal for chan[N], os valores que este canal comunica devem ser do tipo natural. Desta forma, um canal genérico só pode comunicar valores se ele for previamente instanciado. Um detalhe importante é que um canal em Circus só é classificado como genérico se o tipo dele for composto por pelo menos um de seus parâmetros genéricos. No caso da declara¸caõ de um canal ser channel [X ]chan : N, apesar do formato da declara¸cão permitir a introdu¸caõ de canais genéricos, chan não é genérico, pois seu tipo não envolve o parâmetro X . Nós podemos introduzir também conjuntos de nomes de canais, desde que estes já tenham sido declarados. A defini¸cão de um conjunto de canais é feita através da palavrachave chanset, seguida pelo nome do conjunto e pela expressão que determina os canais que constituem o conjunto. A expressão de conjunto de canais pode ser um conjunto vazio, representado por {| |}; um conjunto enumerado, como por exemplo {| in, out |}; uma referência a outro conjunto de canais; ou uma combina¸caõ de expressões de conjuntos de canais, utilizando os operadores de interseçcão, união e diferen¸ca de conjuntos. Finalmente, um parágrafo de Circus pode definir um processo.. ProcessDeclaration::=process N = b ProcessDefinition | process N[N+ ] = b ProcessDefinition. Uma declara¸caõ de processo é composta pela palavra-chave process, seguida pelo nome e pela defini¸cão do processo. No caso de um processo genérico, após o nome do processo, listamos os parâmetros genéricos dele. 2.2.2. Processos. Um processo pode ser parametrizado ou indexado. Nos dois casos, é necessária a defini¸caõ dos parâmetros ou ´ındices do processo, e isto é feito através de uma declara¸caõ como em Z. No caso de um processo parametrizado, após a declara¸caõ dos parâmetros, utilizamos o s´ımbolo • seguido pelo corpo do processo; e no caso do processo indexado, usamos o s´ımbolo ¯. Um processo não parametrizado e não indexado não requer uma declara¸caõ antes da defini¸caõ do processo em si..