Quais são as barreiras que impedem a adoção generalizada de métodos formais? [fechadas]

Métodos formais podem ser usados ​​para especificar, provar e gerar código para um aplicativo. Isso é menos propenso a erros - portanto, usado principalmente em programas críticos / de segurança.

Por que não o usamos com mais frequência para programação diária, ou em aplicativos da web, etc ...?

Referências :

• Métodos formais
• Método B
• Hoare Logic

Um engenheiro é uma pessoa que pode fazer com um dólar o que qualquer idiota pode fazer com 10.

Restrições de recursos, restrições de orçamento, restrições de tempo, são todas importantes.

Desenvolver software usando métodos formais geralmente é significativamente mais caro e leva muito mais tempo do que sem. Além disso, para muitos projetos, a parte mais difícil é entender os requisitos de negócios. Tudo o que usar métodos formais o comprará nesse caso, é uma prova de que seu código corresponde 100% ao seu entendimento incompleto e incorreto dos requisitos comerciais.

Por esse motivo, o uso de métodos formais, provas, verificação de programas e técnicas similares geralmente se limita a "coisas importantes", como software aviônico, sistemas de controle para equipamentos médicos, usinas de energia, etc.

Programar ou não programar?

Para resolver um problema com um produto de software, depois de ter uma compreensão dos requisitos, você pode SEJA escrever um programa usando linguagens de programação OU especificar o programa usando uma linguagem formal e as ferramentas de geração de código uso. O último apenas adiciona um nível de abstração.

Fazendo as coisas certas ou fazendo as coisas certas?

A abordagem formal fornece uma prova de que seu software funciona de acordo com as especificações. Portanto, seu produto faz as coisas certas. Mas faz as coisas certas?

Os requisitos nos quais você está trabalhando podem ser incompletos ou ambíguos. Eles podem até estar de buggy. Na pior das hipóteses, as reais necessidades nem sequer são expressas. Mas uma imagem vale mais que mil palavras, apenas imagens do google para "O que o cliente deseja", por exemplo, neste artigo :

O custo da formalidade

Em um mundo perfeito, você teria requisitos detalhados e perfeitos desde o início. Você pode especificar completamente o seu software. Se você for formal, seu código será gerado automaticamente para que você seja mais produtivo. Os ganhos de produtividade compensariam o custo das ferramentas formais. E todo mundo agora usaria métodos formais. Então, por que não?

Na prática, isso raramente é a realidade! É por isso que muitos projetos em cascata falharam e por que os métodos de desenvolvimento iterativo (ágil, RAD etc.) assumiram a liderança: eles podem lidar com requisitos, projetos e implementações incompletos e imperfeitos e refiná-los até ficarem bem.

E aí vem o ponto. Com métodos formais, cada iteração requer uma especificação formal completamente consistente. Isso requer pensamento cuidadoso e trabalho adicional, porque a lógica formal não perdoa e não gosta de pensamentos incompletos. Experimentos simples de descarte ficam caros sob essa restrição. E o mesmo acontece com cada iteração que levaria ao retorno (por exemplo, uma idéia que não funcionou ou um requisito que foi mal interpretado).

Na prática

Quando não é obrigado a usar métodos formais por razões legais ou contratuais, você também pode obter uma qualidade muito alta sem sistemas formais, por exemplo, usando programação baseada em contrato e outras boas práticas (por exemplo, revisão de código, TDD , etc ...). Você não poderá provar que seu software funciona, mas seus usuários aproveitarão o software mais cedo.

Atualização: esforço medido

Na edição de outubro de 2018 da Communications of the ACM, há um artigo interessante sobre o software formalmente verificado no mundo real, com algumas estimativas do esforço.

Curiosamente (com base no desenvolvimento do SO para equipamentos militares), parece que a produção de software formalmente comprovado exige 3,3 vezes mais esforço do que com as técnicas de engenharia tradicionais. Portanto, é realmente caro.

Por outro lado, exige 2,3 vezes menos esforço para obter software de alta segurança dessa maneira do que com o software de engenharia tradicional, se você adicionar o esforço para tornar esse software certificado em um nível de segurança alto (EAL 7). Portanto, se você tiver requisitos de alta confiabilidade ou segurança, há definitivamente um caso de negócios para se formalizar.

O design do seL4 e o desenvolvimento do código levaram duas pessoas-ano. A soma de todas as provas seroespecíficas ao longo dos anos chega a um total de 18 pessoas / ano para 8.700 linhas de código C. Em comparação, o L4Ka :: Pistachio, outro microkernel da família L4, comparável em tamanho ao seL4, levou seis pessoas / ano para se desenvolver e não oferece um nível significativo de garantia. Isso significa que há apenas um fator 3.3 entre o software verificado e o software tradicionalmente projetado. De acordo com o método de estimativa de Colbert e Boehm, 8 uma certificação tradicional Common Criteria EAL7 para 8.700 linhas de código C levaria mais de 45,9 pessoas-ano. Isso significa que a verificação formal da implementação em nível binário já é mais do que um fator de 2,3 menos oneroso do que o nível mais alto de certificação de Critérios Comuns, mas oferece garantia significativamente mais forte.

Todo programa em qualquer idioma pode ser considerado uma especificação formal (equivalente a alguma máquina de tornear). Qualquer 'especificação formal' de nível superior a ser usada para provar a correção formal também é - apenas outro programa. Mas é (tipicamente) um programa ruim, incompleto, vago e insuficientemente pensado. E não por coincidência, normalmente escrito por pessoas que não sabem como programar (geralmente são especialistas em domínio).

E, provando que um programa é compatível (produz as mesmas respostas ou, no entanto, você o caracteriza) com seus requisitos formais de nível mais alto, invariável se resume à maneira como você resolve as ambiguidades na especificação formal de nível mais alto. Não existe uma boa maneira geral de fazer isso.

Esse mapeamento de requisitos de alto nível para detalhes de nível inferior é a essência do que é a programação real. Não deve surpreender que o trabalho principal que está sendo realizado por um programador, lendo e interpretando especificações, não possa ser substituído por um aceno manual e dizendo 'agora apenas veja se essa especificação formal de alto nível é cumprida por este programa de amostra'.

Mesmo nos primeiros dias da programação lógica, onde esse conceito parecia tão promissor pela primeira vez (porque tanto a especificação de alto nível quanto os programas subjacentes reais podiam ser escritos na mesma linguagem), esse problema central se mostrou intratável.