El estándar UML define más de una docena de tipos de diagramas diferentes, como se muestra en este gráfico útil:
Fuente: enlace
Vea también 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 diagramas 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 la POO, por ejemplo, el diagrama de clases o el diagrama de objetos . Pero el resto es más ampliamente aplicable que solo para sistemas orientados a objetos.
Diagramas de máquina de estado : FP no evita los 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 como en el Diagrama de máquina de estado, pero en un nivel superior. Se pueden utilizar para explicar el flujo de datos entre varios subsistemas o para modelar procesos de negocios externos.
Diagramas de interacción : modela 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 solo se trata de modelar la estructura del código, sino principalmente de proporcionar un lenguaje de modelado universal. Con un diagrama de interacción, p. Ej. use 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 PF.
Diagramas de casos de uso : los casos y requisitos de uso 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 usa para describir la relación entre el software ejecutable y los recursos de hardware. No importa si ese software fue escrito en un lenguaje de PF.
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 los componentes / módulos, y sus interfaces ofrecidas y requeridas. Esto me recuerda a muchos módulos de Functor de OCaml.
Diagramas de perfil : describe las extensiones de UML y, por lo tanto, nunca se usan.
-
Diagramas de estructura compuesta : describe la estructura de los compuestos. Puede usarse para describir estructuras de datos, o incluso los puntos de interacción de una función. Wikipedia muestra un diagrama para la función de Fibonacci como ejemplo:
Fuente: enlace
En cierto sentido, esta sería la opción de los programadores funcionales en lugar de un diagrama de clase, pero esto parece horriblemente excesivo de ingeniería ...
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 del lenguaje UML que un tipo de diagrama separado. Por ejemplo, podría usar paquetes para categorizar un gran Diagrama de casos de uso.
Como hemos visto, varios tipos de diagramas UML pueden ser útiles cuando se realiza la programación funcional.
Raramente he sentido el deseo de usar UML al diseñar un sistema, y principalmente uso UML para hacer la tarea asignada, o para comunicar el esquema de una arquitectura con un boceto rápido. Incluso para un sistema OOP, UML no proporciona el valor suficiente para usarlo todo el tiempo; el código real dice más de mil diagramas. Podría imaginarme usando diagramas similares a UML para explicar las dependencias entre varias funciones y estructuras de datos en un programa de PF, pero aún tengo que hacerlo, mi estilo personal prefiere una combinación de OOP y PF donde las técnicas de PF se usan a escala local. pero no influyen en la arquitectura general.