Projeto e Validação de Protocolos de
Computadores
Disciplina: Especificação Formal e Validação de Protocolos de Comunicação
Jo ˜ao Borges
Orientadora: PhD. Rossana Andrade
Motivação
• Problema antigo:
Ambiguidade dos protocolos de comunicação
• Polybius, historiador Grego (200 A.C.) • Telégrafo de Tochas (Polybius Square) • Sequências inesperadas de eventos
“O maior problema no projeto de protocolos é que o inesperado deve ser esperado.” [2]
Problemas
• Como um projetista pode garantir que os requisitos do
projeto foram atendidos?
• Como projetar conjuntos de regras mínimas para troca de
informação?
◦ Consistentes ◦ Completas
◦ Fácil implementação
• Como um analista pode demonstrar que o projeto está
conforme os requisitos (corretude)?
Problema fundamental: Projeto e validação de protocolos não ambíguos.
Protocolos como Linguagens
• Como uma linguagem de computador a linguagem do
protocolo não pode ser ambígua.
◦ Sintaxe - Formato preciso de mensagens válidas,
◦ Gramática - Um vocabulário de mensagens, regras e
procedimentos para troca de dados
◦ Semântica - Significados de mensagens, especificação
de serviços
• Devem especificar comportamentos de processos
5 Elementos de um Protocolo
1. O serviço a ser provido pelo protocolo
2. As restrições do ambiente no qual o protocolo será executado
3. O vocabulário de mensagens usado para implementar o protocolo
4. A codificação (sintaxe/formato) de cada mensagem do vocabulário
5. As regras de procedimento que garantem a consistência da troca de mensagens (gramática/comportamento)
O coração da definição do protocolo é o elemento 5. [1] Difícil de projetar e validar.
Projeto Estruturado de Protocolos
• Simplicidade - Protocolos Peso Leve
• Modularidade - Uma Hierarquia de Funções • Protocolos Bem-Definidos (Well-Formed )
◦ Limitado (não ultrapassa os limites do sistema)
◦ Auto-estabilizado (retornar para um estado desejável) ◦ Auto-adaptado (controle de taxa de fluxo)
• Robustez - Tratamento de eventos inesperados • Consistência
◦ Deadlocks ◦ Livelocks
10 Regras de Projeto
1. O problema deve estar bem-definido.
2. Defina o serviço antes das estruturas (O quê vem antes de Como). 3. Projete funcionalidades externas antes das internas (caixa-preta)
4. Faça-o Simples (KISS) [6]. Fácil de implementar, validar e mais eficiente. 5. Não conecte o que é independente. Separe interesses ortogonais.
6. Não introduza o que é imaterial. Um bom projeto é “open-ended ”.
7. Antes de implementar, construa um protótipo e verifique sua corretude. 8. Implemente o projeto, meça sua performance, e se necessário, otimize-o. 9. Teste sua implementação final, se é equivalente ao projeto validado.
10. Não pule as regras de 1 a 7.
Requisitos de Corretude
• Para validar um projeto é preciso especificar o que significa
sua corretude.
• Critérios de corretude:
◦ Ausência de deadlocks ◦ Ausência de livelocks
◦ Ausência de términos inesperados
• Um bom projeto é provavelmente livre de deadlocks.
“Não basta que seja possível uma interpretação correta de uma especificação, é preciso que uma interpretação incorreta não seja possível.”[2]
O Modelo de Validação
Uma metodologia.
• Comportamento, é o conjunto das sequências de execução
que o modelo pode efetuar. (Inevitável ou impossível)
• Sequência de execução, é um conjunto finito de estados. • Estado, é onde se especificam os valores para variáveis,
pontos de controle de fluxo e conteúdos das mensagens de canais.
• Um modelo pode alcançar um estado pela execução de
instruções.
• Um modelo pode ser colocado em um estado através da
Validade de Estados
• O estado inicial da sequência (i = 1) é o estado inicial do modelo, com todas as variáveis zeradas e mensagens vazias.
• Se o modelo está colocado em um estado i, há pelo menos uma instrução executável que o leve ao estado i + 1.
A união dos estados do comportamento do sistema é chamado o conjunto de estados alcançáveis do modelo.
Ferramentas de Validação
• Algumas ferramentas para automatização da validação já
foram propostas [4].
• Algumas utilizam técnicas de simulação exaustiva de todos
os possíveis comportamentos, buscando comportamentos errôneos ou indesejáveis [3].
• Provêem informações sobre onde no protocolo pode haver
bugs.
• Podem ser usadas para grandes protocolos (escalável). • Podem diminuir o tempo gasto nos processos de validação
V&V Inicial
• Para os dias atuais, a necessidade de V&V nas fases
iniciais do desenvolvimento é alta [5].
• Para sistemas críticos, pervasivos
• Deve-se ter certeza que o sistema é correto, de acordo com
sua semântica formal
• Em [5] é proposto uma abordagem orientada a Gols. • Gols são objetivos que o sistema em construção deve
atingir.
• Auxiliam no refinamento dos requisitos, utilizando uma
linguagem semi-formal, e na precisa definição destes, utilizando uma linguagem formal.
Teste de Conformidade
• Usado para checar um comportamento externo de um
protocolo implementado.
• Checar se a especificação formal é logicamente
consistente.
• A implementação de ser equivalente à sua especificação
formal.
“Se uma especificação formal tem um erro de projeto, a implementação dessa especificação passará no Teste de Conformidade se ela conter o mesmo erro.” [2]
Metodologia de Testes
• A implementação é uma caixa preta com entradas e saídas. • Passam-se mensagens de entrada e observam-se os
resultados nas saídas.
• O teste terá sucesso se as saídas observadas estiverem
conforme sua especificação formal.
• Estados são agora definidos como condições estáveis de
espera por entradas
• Transições são definidas como consumos de sinais,
Principais Problemas nos Testes
• Encontrar um procedimento geral e eficiente para gerar
uma suíte de testes para um determinado protocolo.
• Encontrar um método para aplicar o teste em uma
Tipos de Teste - Funcional
• Verificar a conformidade sem ter acesso aos detalhes
internos da implementação.
• Problema: é impossível testar exaustivamente todos os
possíveis comportamentos de uma implementação
desconhecida somente por observações de suas respostas.
Tipos de Teste - Estrutural
• Não há consideração em valores de parâmetros. • Ênfase na estrutura de controle do protocolo.
• Verifica-se se a estrutura de controle da implementação
está conforme a estrutura da especificação.
◦ Possuem a mesma estrutura se possuírem o mesmo
conjunto de estados e permitirem as mesmas transições de estados.
Requisitos para Testes de Conformidade
1. * Implementação determinística com número de estados e vocabulários conhecidos.
2. * Produz respostas às entradas em um tempo finito.
3. * Todos os estados são alcançáveis por uma ou mais transações. 4. Estados devem aceitar e responder (inclusive null) às entradas. 5. Pode aceitar mensagens de status informando seu estado atual. 6. Pode aceitar mensagens de reset movendo-se para o estado inicial.
7. Pode aceitar mensagens de set efetuando a transição para o estado especificado no parâmetro dessa mensagem.
Com esses 7 requisitos os testes de conformidade podem ser efetuados.
Conclusão
• Problemas na criação de protocolos que: ◦ Realizem um dado serviço.
◦ Faça-o de maneira sem erros.
• As metodologias de projeto e validação de protocolos
permitem:
◦ Protocolos mais eficientes. ◦ Mais leves.
◦ Fáceis de manter e modificar.
Refer ˆencias
[1] G. J. Holzmann. Tutorial: Design and validation of protocols. In B. Pehrson,
B. Jonsson, and J. Parrow, editors, Proc. 11th Int. Conf on Protocol Specification, Testing, and Verification, INWG/IFIP, Stockholm, Sweden, 1991.
[2] Gerard J. Holzmann. Design and validation of computer protocols. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1991.
[3] Gerard J. Holzmann. Protocol validation. Encyclopedia of Telecommunications, pages 185–194, 1994.
[4] J.J. Li and J.R. Horgan. A tool for efficient protocol validation and testing. In
Computer Communications and Networks, 2000. Proceedings. Ninth International Conference on, pages 14 – 17, Oct. 2000.
[5] C. Ponsard, P. Massonet, J. F. Molderez, A. Rifaut, A. Van Lamsweerde, and H. Tran Van. Early verification and validation of mission critical systems. Form. Methods
