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

Question

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

Является ли UML распространенным / разумным подходом к моделированию функционального программирования? Есть ли лучшая альтернатива UML для FP?

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

• ID;

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

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

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

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

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

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

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

Answer 4

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

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

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

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