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

Ответ 1

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

• идентификатор;

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

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

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

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

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

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

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

Ответ 4

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

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

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

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