Моделирование / документирование функциональных программ

Большинство функциональных программистов предпочитают типы диаграмм. (Я имею в виду типы в очень широком смысле, включая такие вещи, как «типы модулей» Caml, «сигнатуры» SML и «единицы» схемы PLT.) Чтобы сообщить, как работает большое приложение, я предлагаю три вещи:

• Укажите тип каждого модуля. Поскольку вы используете Clojure, вы можете попробовать язык «Единицы», изобретенный Мэтью Флаттом и Матиасом Фелляйзеном. Идея состоит в том, чтобы задокументировать типы и операции, от которых зависит модуль и которые он предоставляет.

• Дайте импортные зависимости интерфейсов. Здесь может быть полезна диаграмма; во многих случаях вы можете создать диаграмму автоматически, используя dot. Это имеет то преимущество, что диаграмма всегда точно отражает код.

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

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

подход «много функций в одной структуре данных» идиоматического кода Clojure размывает типичную диаграмму UML «это использует эту», потому что многие функции в конечном итоге указывают на карту / уменьшение / фильтр.
У меня сложилось впечатление, что, поскольку Clojure - это несколько более язык, ориентированный на данные. Способ визуализации потока данных может помочь больше, чем способ визуализации потока управления, когда вы принимаете во внимание ленивую оценку. Было бы действительно полезно получить "конвейерную" диаграмму функций, которые строят последовательности.
map и reduce и т. Д. Превратят их в деревья.

Это интересный вопрос (я проголосовал за него), я ожидаю, что вы получите как минимум столько же мнений, сколько и ответов. Вот мой вклад:

Что вы хотите изобразить на своих диаграммах? В ОО один из ответов на этот вопрос может заключаться в рассмотрении диаграмм классов, состояний (или атрибутов, если хотите) и методов. Итак, очевидно, что я бы предположил, что диаграммы классов не подходят для начала, поскольку функции не имеют состояния и, как правило, реализуют одну функцию (также известную как метод). Может ли какая-либо из других диаграмм UML лучшая отправная точка для вашего размышления? Ответ, вероятно, да, но вам нужно подумать о том, что вы хотите показать, и самому найти эту отправную точку.

После того, как вы написали (подсистему) на функциональном языке, у вас есть (UML) компонент для представления на стандартных типах диаграмм, но, возможно, это будет для вас слишком высокоуровневым и абстрактным.

Когда я пишу функциональные программы, что, я признаю, не так уж много, я стараюсь документировать функции, как если бы я документировал математические функции (я работаю в области научных вычислений, много математики возится, так что для меня это вполне естественно). Для каждой функции я пишу:

• an ID;

• иногда описание;

• спецификация домена;

• спецификация ко-домена;

• утверждение правила, то есть операция, которую выполняет функция;

• иногда я также пишу постусловия, хотя они обычно адекватно определяются совмещением домена и правилом.

Для этого я использую LaTeX, он хорош для математической записи, но подойдет любой другой достаточно гибкий текст или текстовый процессор. Что касается диаграмм, то не так уж и много. Но это, вероятно, отражение примитивного состояния дизайна систем, которые я программирую функционально. Большая часть моих вычислений выполняется на массивах чисел с плавающей запятой, поэтому большинство моих функций очень легко составить ad-hoc, а структурирование системы очень нечеткое. Я представляю себе диаграмму, которая показывает функции как узлы и входы / выходы как края между узлами - в моем случае в большинстве случаев между каждой парой узлов были бы края. Не уверен, что рисование такой диаграммы мне вообще поможет.

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

Это то, с чем я тоже пытался экспериментировать, и после нескольких лет программирования на Ruby я привык к моделированию классов / объектов. В конце концов, я думаю, что типы дизайнов, которые я создаю для библиотек Clojure, на самом деле очень похожи на то, что я сделал бы для большой программы C.

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

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

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