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

] подход "многие функции на одной структуре данных" идиоматического кода Clojure обводит типичную UML-диаграмму "это использует то", потому что многие функции в конечном итоге указывают на map/reduce/filter.[
] У меня сложилось впечатление, что поскольку Clojure - это несколько более []data centric language[], то способ [] визуализации потока данных [] может помочь больше, чем способ визуализации потока управления, если учитывать ленивые оценки. Было бы действительно полезно получить "трубопроводную" диаграмму функций, которые строят последовательности.[
]. карта, уменьшение и т.д. превратит их в деревья [

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

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

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

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

] [
• ][

  ]an ID;[

  ][
] [
• ][

  ] иногда описание;[

  ][
] [
• ][

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

  ][
] [
• ][

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

  ][
] [
• ][

  ] заявление правила, т.е. операция, которую выполняет функция;[

  ][
] [
• ][

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

  ][
] [

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

] Я, кажется, спускаюсь со стороны, говоря вам нет, UML не является разумным способом моделирования функциональных систем. Будет ли это обычным, скажет нам SO. [

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

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

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

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