Что функциональные программисты используют вместо UML?

Я студент CS. В настоящее время я посещаю лекции, где нас учат объективному анализу и дизайну. Он состоит в основном из написания сценариев использования, анализа проблемы, с которой мы можем столкнуться при написании какого-либо приложения для клиента, и того, как спроектировать проект так, чтобы он был расширяемым, понятным для разработчиков и не вызывал проблем, когда клиент спорил о некоторых функции. Поскольку это «объективно», мы изучаем его с точки зрения ООП (классы и тому подобное).

Теперь мы используем UML в качестве вспомогательного инструмента. Я считаю, что хорошо разбираюсь в ООП, но я также выучил функциональную парадигму и успешно использовал ее в некоторых своих небольших проектах.

Наш учитель, когда сталкивается с "как насчет функциональной парадигмы?" на вопрос ответил, что он не программировал какой-либо более крупный проект на функциональных языках, и он не знает, какой инструмент могут использовать функциональные программы.

Итак, что они будут использовать? Есть ли методология для этого? Или, может быть, такая вещь не нужна?

Я не могу говорить за всех функциональных программистов, но те, кого я знаю, все начинают с написания сигнатур типов функций верхнего уровня, затем, когда им требуется больше деталей, они пишут сигнатуры типов вспомогательных функций и так далее.

Это работает из-за отсутствия побочных эффектов в функциональном программировании, поэтому все функции определяются только в терминах их входов и выходов. Это делает их сигнатуры типов гораздо более полезными в качестве инструмента проектирования, чем в императивном программировании. Это одна из причин, по которой вы видите, что они используются, даже когда компилятор может их определить.

Что касается инструментов построения диаграмм, при всем уважении к вашему профессору, я не использовал их в какой-либо значительной степени ни в одной парадигме с тех пор, как закончил школу.

Стандарт UML определяет более десятка различных типов диаграмм, как показано на этой удобной диаграмме:

Источник: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg

См. Также рисунок A.5 Таксономия структурных и поведенческих диаграмм в спецификации UML 2.5.

^{Обратите внимание, что это пример диаграммы классов с отношениями подтипов is-между типами диаграмм и типами абстрактных диаграмм курсивом. Хотя эти типы диаграмм фактически являются классами в метамодели UML, эта диаграмма классов по-прежнему полезна для иллюстрации иерархии без какого-либо подключения к ООП.}

Есть несколько типов, которые явно применимы только к ООП, например, диаграмма классов или диаграмма объектов . Но остальное более широко применимо, чем просто для объектно-ориентированных систем.

• Диаграммы конечных автоматов - FP не избегает состояний, а просто делает их явными. Диаграмма конечного автомата может быть полезна для объяснения потока управления или различных переходов состояний в программе.

• Диаграммы действий - полезны в тех же случаях, что и для диаграммы состояний, но на более высоком уровне. Их можно использовать для объяснения потока данных между различными подсистемами или для моделирования внешних бизнес-процессов.

• Диаграммы взаимодействий - моделируют взаимодействия между несколькими процессами с состоянием. Очевидно, что это не полезно для моделирования внутренних компонентов чисто функциональной программы. Тем не менее, UML не только о моделировании структуры кода, но прежде всего о предоставлении универсального языка моделирования. С диаграммой взаимодействия я мог бы, например, использовать диаграммы взаимодействия для моделирования внешнего поведения между системами, например, между браузером и веб-сервером - даже когда они написаны с использованием методов FP.

• Диаграммы вариантов использования - варианты использования и требования не зависят от технологии, используемой для их удовлетворения. ООП или ФП здесь абсолютно неактуальны.

• Диаграммы развертывания - этот тип диаграммы используется для описания связи между работающими программными и аппаратными ресурсами. Было ли это программное обеспечение написано на языке FP, не имеет значения.

• Диаграммы компонентов - в наши дни большинство функциональных языков имеют явную поддержку модульного программирования. Диаграмма компонентов описывает компоненты / модули, а также предлагаемые и требуемые интерфейсы. Это напоминает мне много модулей Functor от OCaml.

• Профильные диаграммы - описывают расширения самого UML и, как таковые, никогда не используются.

• Диаграммы композитных структур - описывают структуру композитов. Его можно использовать для описания структур данных или даже точек взаимодействия функции. Википедия показывает диаграмму для функции Фибоначчи в качестве примера:

  

  Источник: https://commons.wikimedia.org/wiki/File:Composite_Structure_Diagram.png

  В некотором смысле, это был бы выбор функциональных программистов, а не диаграммы классов, но это кажется ужасно переоцененным….

• Диаграммы пакетов - пакеты представляют собой UML-эквивалент пространств имен. Этот тип диаграммы является большей частью языковой инфраструктуры UML, чем отдельный тип диаграммы. Например, вы можете использовать пакеты для категоризации большой диаграммы вариантов использования.

Итак, как мы видели, различные типы диаграмм UML все еще могут быть полезны при выполнении функционального программирования.

Я редко испытывал желание использовать UML при проектировании системы, и в первую очередь использовать UML, чтобы выполнить мою домашнюю работу или передать набросок архитектуры с помощью быстрого наброска. Даже для ООП-системы UML не предоставляет достаточной ценности для ее постоянного использования - в реальном коде написано более тысячи диаграмм. Я мог бы представить себе использование UML-подобных диаграмм для объяснения зависимостей между различными функциями и структурами данных в программе FP, но мне еще предстоит это сделать - мой личный стиль предпочитает сочетание ООП и FP, где методы FP используются в локальном масштабе, но не влияют на общую архитектуру.