É prática comum transformar especificações de requisitos em lógica de predicados para programação funcional?


8

Recentemente, fui designado para trabalhar em um pequeno projeto que está sendo implementado em Haskell. Vindo de um background imperativo / imperativo, estou acostumado a converter requisitos / histórias de usuários em casos de uso e diagrama de sequência antes da codificação.

No entanto, no projeto Haskell ao qual fui designado, a equipe prefere transformar os requisitos do usuário em proposições / proposições lógicas predicadas. Eu sabia que a lógica era usada em sistemas críticos de segurança e métodos formais para engenharia de software, mas não tanto na programação do dia a dia. Esta prática é comum no campo do FP? Onde posso aprender mais sobre isso?

Parece uma maneira natural de 'modelar' os requisitos e derivar as 'funções' dos predicados, além de anotar as especificações de tipo necessárias para as funções operarem. Mas é assim que é feito / recomendado na prática ou é algo peculiar à minha equipe?

(Tentei pesquisar bastante antes de fazer essa pergunta aqui. A pesquisa por "especificação de requisitos em programação funcional" (e diferentes sinônimos e combinações de palavras-chave) não leva a nada significativo.)


Respostas:


1

Eu direi que não se limita à programação funcional, está mais relacionado ao objetivo do projeto. Usando a lógica de predicado (lógica de ordem superior), você pode criar uma prova para a lógica usada no requisito. Traduzir a lógica para idiomas funcionais é provavelmente mais fácil. Também é possível traduzir a implementação comprovada da linguagem funcional em linguagens procedurais para obter algum tipo de maneira comprovada de implementá-la.

Se pudermos provar o programa, não precisamos testá-lo. Mesmo se um programa passou em 1000 testes, ainda não está comprovado. Obviamente, não é fácil criar as provas, apenas criamos testes.

Você também pode querer procurar provador de teoremas, isabelle / hol.


-1

Essa é uma maneira de lidar com a programação funcional. Ele tende a cair dos fluxogramas e diagramas de fluxo de dados dos "velhos tempos". Em vez de pensar em termos de objetos, a programação funcional tende a se concentrar em quais ações precisam ser executadas. Os dados tornam-se incidentais, pedaços de cotão para transportar e manter o que você está tentando fazer.


este lê mais como um comentário, consulte Como responder
mosquito

2
Desculpa. O comentário de uma pessoa é a resposta de outra pessoa. Este não é o meu primeiro rodeio de Stack Exchange.
Joe Sewell

Não tenho certeza se eu concordo. A pergunta em si vai reunir opiniões, então talvez haja problemas com a pergunta, mas a resposta que acredito realmente aborda a pergunta. Fluxogramas e fluxos de dados são uma parte importante das especificações de requisitos de negócios.
Maple_shaft
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.