¿Qué utilizan los programadores funcionales en lugar de UML?

Soy estudiante de CS. Actualmente estoy asistiendo a conferencias, donde se nos enseña Análisis y diseño objetivo. Consiste principalmente en escribir casos de uso, analizar el problema que podemos enfrentar al escribir alguna aplicación para el cliente, y cómo diseñar el proyecto para que sea extensible, claro para los desarrolladores y no genere problemas cuando el cliente discute sobre algunos caracteristicas. Como es 'objetivo', lo estamos aprendiendo desde el punto de vista de OOP (clases y demás).

Ahora estamos usando UML como herramienta auxiliar. Creo que entiendo bien la POO, pero también aprendí el paradigma funcional y lo utilicé con éxito en algunos de mis proyectos más pequeños.

Nuestro maestro, cuando se enfrenta con "¿qué pasa con el paradigma funcional?" pregunta, respondió que no estaba programando ningún proyecto más grande en lenguajes funcionales, y no sabe qué herramienta pueden estar utilizando los programas funcionales.

Entonces, ¿qué usarían? ¿Hay alguna metodología para esto? ¿O tal vez no hay necesidad de tal cosa?

No puedo hablar por todos los programadores funcionales, pero todos los que conozco comienzan escribiendo las firmas de tipo de las funciones de nivel superior, luego, cuando necesitan más detalles, escriben las firmas de tipo de las funciones auxiliares, y así sucesivamente.

Esto funciona debido a la falta de efectos secundarios en la programación funcional, por lo que las funciones se especifican solo en términos de sus entradas y salidas. Esto hace que sus firmas tipo sean mucho más útiles como herramienta de diseño que en la programación imperativa. Esa es una de las razones por las que los ves incluso cuando el compilador podría inferirlos.

En lo que respecta a las herramientas de diagramación, con el debido respeto a su profesor, no las he usado en ningún grado significativo en ningún paradigma desde que abandoné la escuela.

El estándar UML define más de una docena de tipos de diagramas diferentes, como se muestra en este práctico gráfico:

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

Consulte también la Figura A.5 La taxonomía de los diagramas de estructura y comportamiento en la especificación UML 2.5.

^{Tenga en cuenta que este es un ejemplo de un diagrama de clase, con relaciones de subtipo is-a entre tipos de diagrama y tipos de diagrama abstracto en cursiva. Si bien estos tipos de diagrama en realidad son clases dentro del metamodelo UML, este diagrama de clase sigue siendo útil para ilustrar una jerarquía, sin ninguna conexión con OOP.}

Hay un par de tipos que claramente solo se aplican a OOP, por ejemplo, el diagrama de clase o el diagrama de objeto . Pero el resto es más ampliamente aplicable que solo para sistemas orientados a objetos.

• Diagramas de máquina de estado : FP no evita estados, simplemente los hace explícitos. Un diagrama de máquina de estado puede ser útil para explicar el flujo de control o las diversas transiciones de estado en el programa.

• Diagramas de actividad : son útiles en casos similares a los del Diagrama de máquina de estado, pero en un nivel superior. Se pueden usar para explicar el flujo de datos entre varios subsistemas o para modelar procesos comerciales externos.

• Diagramas de interacción: modele las interacciones entre múltiples procesos con estado. Claramente, esto no es útil para modelar las partes internas de un programa funcional puro. Sin embargo, UML no se trata solo de modelar la estructura del código, sino principalmente de proporcionar un lenguaje de modelado universal. Con un diagrama de interacción, podría, por ejemplo, usar diagramas de interacción para modelar el comportamiento externo entre sistemas, por ejemplo, entre un navegador y un servidor web, incluso cuando se escriben utilizando técnicas de FP.

• Diagramas de casos de uso: los casos de uso y los requisitos son independientes de la tecnología utilizada para satisfacerlos. OOP o FP es absolutamente irrelevante aquí.

• Diagramas de implementación : este tipo de diagrama se utiliza para describir la relación entre el software ejecutable y los recursos de hardware. Si ese software fue escrito en un lenguaje FP no importa.

• Diagramas de componentes : la mayoría de los lenguajes funcionales tienen soporte explícito para la programación modular en estos días. Un diagrama de componentes describe componentes / módulos y sus interfaces ofrecidas y requeridas. Esto me recuerda muchos de los módulos Functor de OCaml.

• Diagramas de perfil : describen las extensiones de UML y, como tales, nunca se usan realmente.

• Diagramas de estructura compuesta : describe la estructura de los compuestos. Se puede usar para describir estructuras de datos, o incluso los puntos de interacción de una función. Wikipedia muestra un diagrama para la función Fibonacci como ejemplo:

  

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

  En cierto sentido, esta sería la elección funcional de los programadores en lugar de un diagrama de clase, pero esto parece terriblemente diseñado en exceso ...

• Diagramas de paquetes: los paquetes son el equivalente UML de los espacios de nombres. Este tipo de diagrama es más parte de la infraestructura de lenguaje UML que un tipo de diagrama separado. Por ejemplo, podría usar paquetes para clasificar un gran diagrama de casos de uso.

Entonces, como hemos visto, varios tipos de diagramas UML pueden ser útiles cuando se realiza una programación funcional.

Raramente he sentido el deseo de usar UML al diseñar un sistema, y ​​principalmente uso UML para hacer mi tarea asignada, o para comunicar el bosquejo de una arquitectura con un bosquejo rápido. Incluso para un sistema OOP, UML no proporciona suficiente valor para usarlo todo el tiempo: el código real dice más de mil diagramas. Me podría imaginar el uso de diagramas tipo UML para explicar las dependencias entre varias funciones y estructuras de datos en un programa de FP, pero aún no lo he hecho; mi estilo personal prefiere una combinación de OOP y FP donde las técnicas de FP se utilizan a escala local, pero no influyen en la arquitectura general.