functional-programming - que - programacion funcional javascript

Modelado/documentación de programas funcionales.

Question

He encontrado que UML es útil para documentar varios aspectos de los sistemas OO, particularmente los diagramas de clase para la arquitectura general y los diagramas de secuencia para ilustrar rutinas particulares. Me gustaría hacer lo mismo para mis aplicaciones de clojure. Actualmente no estoy interesado en el desarrollo basado en modelos, simplemente en comunicar cómo funcionan las aplicaciones.

¿Es UML un enfoque común / razonable para modelar la programación funcional? ¿Hay una mejor alternativa a UML para FP?

Answer 1

El enfoque de "muchas funciones en una sola estructura de datos" del código idiomático de Clojure diluye el típico diagrama UML de "esto usa eso" porque muchas de las funciones terminan apuntando al mapa / reducir / filtrar.
Me da la impresión de que, dado que Clojure es un lenguaje un tanto más centrado en los datos, una forma de visualizar el flujo de datos podría ayudar más que una forma de visualizar el flujo de control cuando se toma en cuenta la evaluación perezosa. Sería realmente útil obtener un diagrama de "línea de tubería" de las funciones que crean secuencias.
mapa y reducir, etc. convertiría estos en árboles

Answer 2

Es una pregunta interesante (la he votado con anterioridad), espero que obtengas al menos tantas opiniones como respuestas. Aquí está mi contribución:

¿Qué quieres representar en tus diagramas? En OO, una respuesta a esa pregunta podría ser, considerando los diagramas de clase, el estado (o atributos, si lo prefiere) y los métodos. Entonces, obviamente, sugeriría que los diagramas de clase no son lo correcto desde el principio ya que las funciones no tienen estado y, en general, implementan una función (método aka). ¿Alguno de los otros diagramas UML proporciona un mejor punto de partida para su pensamiento? La respuesta es probablemente sí, pero debes considerar lo que quieres mostrar y encontrar ese punto de partida.

Una vez que haya escrito un (sub) sistema en un lenguaje funcional, entonces tiene un componente (UML) para representar en el tipo de diagrama estándar, pero tal vez eso sea demasiado alto, demasiado abstracto, para usted.

Cuando escribo programas funcionales, lo que no es mucho lo admito, tiendo a documentar funciones como documentaría funciones matemáticas (trabajo en computación científica, hay muchas matemáticas por lo que esto es bastante natural para mí). Para cada función escribo:

• una identificación;

• a veces, una descripción;

• una especificación del dominio;

• una especificación del co-dominio;

• una declaración de la regla, es decir, la operación que realiza la función;

• a veces escribo post-condiciones también, aunque estas usualmente son especificadas adecuadamente por el co-dominio y la regla.

Utilizo LaTeX para esto, es bueno para la notación matemática, pero cualquier otro procesador de texto o texto razonablemente flexible haría. En cuanto a los diagramas, no tanto. Pero eso es probablemente un reflejo del estado primitivo del diseño de los sistemas que programo funcionalmente. La mayor parte de mi computación se realiza en matrices de números de punto flotante, por lo que la mayoría de mis funciones son muy fáciles de componer ad-hoc y la estructuración de un sistema es muy vaga. Imagino un diagrama que muestra funciones como nodos y entradas / salidas como bordes entre nodos; en mi caso, habría bordes entre cada par de nodos en la mayoría de los casos. No estoy seguro de que dibujar un diagrama así me ayudaría en absoluto.

Parece que me estoy decantando por decirte que no, que UML no es una forma razonable de modelar sistemas funcionales. Si es común así nos lo dirá.

Answer 3

Esto es algo con lo que he intentado experimentar también, y después de algunos años de programación en Ruby, estaba acostumbrado al modelado de clase / objeto. Al final, creo que los tipos de diseños que creo para las bibliotecas de Clojure son en realidad muy similares a lo que haría para un programa de C grande.

Comience haciendo un esquema del modelo de dominio. Enumere las principales piezas de datos que se mueven alrededor de las funciones principales que se realizan en estos datos. Escribo esto en mi cuaderno y muchas veces será solo un nombre con 3-5 puntos de viñeta debajo de él. Este esquema probablemente será una buena aproximación de sus espacios de nombres iniciales, y debe señalar algunas de las interfaces clave de alto nivel.

Si parece bastante sencillo, crearé funciones vacías para la interfaz de alto nivel y comenzaré a completarlas. Por lo general, cada función de alto nivel requerirá un par de funciones de soporte y, a medida que desarrolle toda la interfaz, encontrará oportunidades. por compartir más código, así que lo refactoriza a medida que avanza.

Si parece ser un problema más difícil, comenzaré a hacer un diagrama de la estructura de los datos y el flujo de funciones clave. Muchas veces, el diagrama y el modelo conceptual que tenga más sentido dependerán del tipo de abstracciones que elija utilizar en un diseño específico. Por ejemplo, si usa una biblioteca de flujo de datos para una interfaz gráfica de usuario de Swing, entonces tendría sentido usar un gráfico de dependencia, pero si está escribiendo un servidor para procesar consultas de bases de datos relacionales, es posible que desee diagramar grupos de agentes y tuberías para procesar tuplas. Creo que este tipo de modelos y diagramas también son mucho más descriptivos en términos de transmitir a otro desarrollador cómo se diseña un programa. Muestran más de la conectividad funcional entre los aspectos de su sistema, en lugar de la información bastante no específica transmitida por algo como UML.

Answer 4

La mayoría de los programadores funcionales prefieren los tipos a los diagramas. (Me refiero a tipos muy generales, para incluir elementos como "tipos de módulo" de Caml, "firmas" de SML y "unidades" de esquema PLT.) Para comunicar cómo funciona una aplicación grande, sugiero tres cosas:

• Indica el tipo de cada módulo. Dado que está utilizando Clojure, puede consultar el lenguaje "Unidades" inventado por Matthew Flatt y Matthias Felleisen. La idea es documentar los tipos y las operaciones de las que depende el módulo y que proporciona el módulo.

• Dar las dependencias de importación de las interfaces. Aquí un diagrama puede ser útil; en muchos casos puedes crear un diagrama automáticamente usando un dot . Esto tiene la ventaja de que el diagrama siempre refleja con precisión el código.

• Para algunos sistemas es posible que desee hablar sobre importantes dependencias de implementaciones. Pero generalmente no, el punto de separar las interfaces de las implementaciones es que las implementaciones solo pueden entenderse en términos de las interfaces de las que dependen.

Recientemente hubo una pregunta relacionada con el pensamiento arquitectónico en lenguajes funcionales .