O que os programadores funcionais estão usando no lugar da UML?

Eu sou estudante de CS. Atualmente, estou participando de palestras, nas quais aprendemos Análise Objetiva e Design. Ele consiste principalmente em escrever casos de uso, analisar o problema que podemos enfrentar ao escrever um aplicativo para o cliente e como projetar o projeto para que ele seja extensível, claro para os desenvolvedores e não gera problemas quando o cliente discute sobre alguns características. Como é "objetivo", estamos aprendendo do ponto de vista da OOP (classes e outras).

Agora estamos usando a UML como uma ferramenta auxiliar. Acredito ter uma boa compreensão do POO, mas também aprendi o paradigma funcional e o usei com sucesso em alguns dos meus projetos menores.

Nosso professor, quando confrontado com "e o paradigma funcional?" pergunta, respondeu que ele não estava programando nenhum projeto maior em linguagens funcionais e não sabe qual ferramenta os programas funcionais podem estar usando.

Então, o que eles usariam? Existe alguma metodologia para isso? Ou talvez não haja necessidade disso?

Não posso falar por todos os programadores funcionais, mas todos que conheço começam escrevendo as assinaturas de tipo das funções de nível superior; depois, quando precisam de mais detalhes, escrevem as assinaturas de tipo das funções auxiliares, e assim por diante.

Isso funciona devido à falta de efeitos colaterais na programação funcional; portanto, todas as funções são especificadas em termos apenas de suas entradas e saídas. Isso torna suas assinaturas de tipo muito mais úteis como ferramenta de design do que na programação imperativa. Essa é uma das razões pelas quais você as vê usadas, mesmo quando o compilador as infere.

No que diz respeito às ferramentas de diagramação, com todo o respeito pelo seu professor, eu não as usei em nenhum grau significativo em nenhum paradigma desde que saí da escola.

O padrão UML define mais de uma dúzia de tipos diferentes de diagramas, conforme mostrado neste gráfico útil:

Fonte: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg

Consulte também a Figura A.5 A taxonomia dos diagramas de estrutura e comportamento na especificação UML 2.5.

^{Observe que este é um exemplo de diagrama de classes, com relacionamentos de subtipo is-a entre tipos de diagrama e tipos abstratos de diagrama em itálico. Embora esses tipos de diagrama sejam na verdade classes dentro do metamodelo UML, esse diagrama de classe ainda é útil para ilustrar uma hierarquia, sem nenhuma conexão com o OOP.}

Existem alguns tipos que claramente se aplicam apenas ao OOP, por exemplo, o diagrama de classes ou o diagrama de objetos . Mas o resto é mais amplamente aplicável do que apenas para sistemas orientados a objetos.

• Diagramas de máquina de estado - FP não evita estados, apenas os torna explícitos. Um diagrama de máquina de estado pode ser útil para explicar o fluxo de controle ou as várias transições de estado no programa.

• Diagramas de atividades - são úteis em casos semelhantes aos do diagrama de máquina de estado, mas em um nível superior. Eles podem ser usados ​​para explicar o fluxo de dados entre vários subsistemas ou para modelar processos de negócios externos.

• Diagramas de interação - modele as interações entre vários processos com estado. Claramente, isso não é útil para modelar os internos de um programa funcional puro. No entanto, a UML não se trata apenas de modelar a estrutura do código, mas principalmente de fornecer uma linguagem de modelagem universal. Com um diagrama de interação, eu poderia, por exemplo, usar diagramas de interação para modelar o comportamento externo entre sistemas, por exemplo, entre um navegador e um servidor da Web - mesmo quando escritos usando técnicas de FP.

• Diagramas de Casos de Uso - Casos de uso e requisitos são independentes da tecnologia usada para satisfazê-los. OOP ou FP é absolutamente irrelevante aqui.

• Diagramas de implantação - Este tipo de diagrama é usado para descrever a relação entre software executável e recursos de hardware. Se esse software foi escrito em uma linguagem FP, não importa.

• Diagramas de componentes - A maioria das linguagens funcionais tem suporte explícito à programação modular atualmente. Um diagrama de componentes descreve componentes / módulos e suas interfaces oferecidas e necessárias. Isso me lembra muitos módulos do OCaml Functor.

• Diagramas de perfis - descreva as extensões da própria UML e, como tal, nunca são realmente usadas.

• Diagramas de estrutura composta - descrevem a estrutura dos compostos. Pode ser usado para descrever estruturas de dados ou mesmo os pontos de interação de uma função. A Wikipedia mostra um diagrama para a função Fibonacci como um exemplo:

  

  Fonte: https://commons.wikimedia.org/wiki/File:Composite_Structure_Diagram.png

  Em certo sentido, essa seria a escolha dos programadores funcionais, em vez de um diagrama de classes, mas isso parece terrivelmente superengenhado….

• Diagramas de Pacotes - Pacotes são o equivalente UML de namespaces. Esse tipo de diagrama é mais parte da infraestrutura de linguagem UML do que um tipo de diagrama separado. Por exemplo, você pode usar pacotes para categorizar um diagrama de casos de uso grande.

Portanto, como vimos, vários tipos de diagrama UML ainda podem ser úteis ao executar a programação funcional.

Raramente senti o desejo de usar a UML ao projetar um sistema e, principalmente, usar a UML para fazer minha lição de casa atribuída, ou para comunicar o esboço de uma arquitetura com um esboço rápido. Mesmo para um sistema OOP, a UML não fornece valor suficiente para usá-lo o tempo todo - o código real indica mais de mil diagramas. Eu poderia imaginar usar diagramas do tipo UML para explicar as dependências entre várias funções e estruturas de dados em um programa FP, mas ainda não o fiz - meu estilo pessoal prefere uma combinação de OOP e FP, onde as técnicas de FP são usadas em escala local, mas não influenciam a arquitetura geral.