Как должна выглядеть UML диаграмма компонентов для функционального подхода?

Question

[Marcenary]

Не понятно как делать диаграмму для работы. В примере программа состоит из классов, там всё понятно как делать. Но у меня написана программа на другом языке из за чего надобность в классах отсутствует, классы есть, но их мало. А если всё грести под классы, то выйдет маленькая диаграмма

Answer 1

[mayton2019]

Во первых. Функциональное программирование не запрещает дата-объекты. Вот к примеру если у вас есть таблица Employee из стандартного учебного набора Oracle то она может быть отражена таким образом в Haskell:

data Employee = Employee {
 empno :: Integer,
 ename :: [Char],
 job :: [Char],
 mgr :: Maybe[Integer],
 hiredate :: Day,
 sal :: Integer,
 comm :: Maybe[Integer],
 deptno :: Integer
}

В том что Haskell это достаточно строгий язык который лежит в категории ФП я надеюсь никто не сомневается.

А в мультипарадигменных языках типа Scala с объектами
вообще нет проблем. Берите - делайте объекты сколько надо.

Во вторых, UML проектирование - это такой-себе уровень абстракций, который удобно
обсуждать с бизнесом и показывать на слайдах. Но он вовсе не обязан следовать буква-в-букву коду.
Архитектура - это вообще не про код. Это про намерения, про взаимодействие, про стандарты и смыслы.

Методы UML объектов вы можете сделать функциями. Я не вижу в этом чего-то нерешаемого.
Рассматривайте метод как функцию где первый аргумент - это сам объект. Это такой легкий
троллинг ООП. Типа ООП - это функции где первый аргумент == this.

Answer 2

[Александр Скуснов]

Функции это блок обработки данных (вход -> выход). Можете рисовать поток данных аналогично обработке в DSP (цифровых сигнальных процессорах).