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

Question

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

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

Answer 1

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

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

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

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

Был недавно в related question на architectural thinking in functional languages.

Answer 2

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

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

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

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

• ID;

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

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

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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