Как программы clojure / lisp моделируются в виде диаграммы?

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

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

Какие решения были предложены? Есть ли какие-нибудь общепринятые стандарты? Что вы порекомендуете? Какие инструменты ты используешь?


clojure lisp diagram
person jk.    schedule 01.03.2011    source источник
comment
[ссылка] stackoverflow.com/questions/2005538/. И этот, больше нацеленный на haskell / F # / scala: [ссылка] stackoverflow.com/questions/2003487/   -  person Gene T    schedule 26.03.2011
comment
JFYI: для моделирования можно использовать github.com/vbauer/lein-plantuml.   -  person Vladislav Bauer    schedule 20.08.2014

Ответы (6)


arrow_upward
13
arrow_downward

Это зависит от того, что вы хотите описать в своей программе.

Зависимости

Используйте диаграммы классов для моделирования зависимостей между пространствами имен; в этом случае будет более понятно, если вы используете на диаграмме пакеты вместо классов.

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

Поток данных

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

Или, в случае акторов, изобразите каждого актера как объект, а каждое сообщение как метод.

В любом случае бесполезно пытаться описывать алгоритм вашей программы на UML. По моему опыту, их лучше описать в комментариях в исходном файле.

person Leonel    schedule 01.03.2011

arrow_upward
9
arrow_downward

Я думаю, дело не столько в языке, сколько в вашей концептуальной модели. Если вы используете подход «потоковой обработки», то диаграмма сети потока данных может быть правильным подходом, как в некоторых из Схематические диаграммы в SICP. Если вы используете более объектно-ориентированный подход (который хорошо поддерживается в Lisp), тогда диаграммы активности UML могут иметь больше смысла.

person Maurice Flanagan    schedule 01.03.2011
comment
Мне очень нравятся эти примеры для моделирования низкого или среднего уровня. Вот аналогичный ресурс для блок-схем, используемых при моделировании систем управления: en.wikibooks.org/wiki/ Control_Systems / Block_Diagrams - person jk.; 02.03.2011
comment
Отличная ссылка, и я согласен, что это работает лучше всего, когда вы смотрите на низкий / средний уровень. Иногда можно сложить большие объемы кода внутри блока с относительно простыми входными / выходными сигналами. - person Maurice Flanagan; 02.03.2011

arrow_upward
8
arrow_downward

Моя личная мысль - моделировать поток данных, а не структуру кода, потому что из того, что я видел в больших (не очень больших) проектах Clojure, макет кода имеет тенденцию быть действительно скучным. с огромной кучей составляемых утилит и одним классом, который объединяет их вместе с транзакциями map, redure и STM.

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

person Arthur Ulfeldt    schedule 01.03.2011

arrow_upward
8
arrow_downward

Что ж, UML глубоко уходит корнями в объектно-ориентированный дизайн (с C ++!), Поэтому будет очень сложно отобразить функциональный подход с помощью UML. Я не так хорошо знаю Clojure, но вы можете представить вещи, которые напоминают классы и интерфейсы Java (протоколы?), Для всех остальных это будет действительно сложно. FP больше похож на серию преобразований от ввода к выводу, для этого нет четкой диаграммы UML (может быть, диаграмм активности?). Наиболее распространенные диаграммы предназначены для статической структуры и взаимодействия между объектами, но они не очень полезны для парадигмы FP. В зависимости от вашей цели могут быть применимы схемы компонентов и развертывания.

person GClaramunt    schedule 01.03.2011

arrow_upward
5
arrow_downward

Я не думаю, что что-то вроде UML подойдет для Clojure - UML скорее ориентирован на объектно-ориентированную парадигму, которая обычно не приветствуется в Clojure.

Когда я занимаюсь функциональным программированием, я гораздо больше думаю о данных и функциях:

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

Если вы достаточно хорошо обдумали вышесказанное, то преобразовать код на Clojure довольно просто.

  1. Определите одну или несколько функций-конструкторов для ваших структур данных и напишите пару тестов, чтобы убедиться, что они работают.
  2. Напишите функции преобразования снизу вверх (т.е. сначала запустите и протестируйте самые основные операции, а затем скомпонуйте их вместе, чтобы определить более крупные функции). Напишите тесты для каждой функции.
  3. Если вам нужны служебные функции для графического интерфейса пользователя или ввода-вывода и т. Д., Напишите их по запросу по мере необходимости.
  4. Склейте все вместе, протестируйте на REPL, чтобы убедиться, что все работает.

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

Общая логика моего кода - это обычно последние несколько строк моего основного файла исходного кода.

person mikera    schedule 03.03.2012

arrow_upward
2
arrow_downward

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

Однако, как только вы начнете использовать HOF, это вообще не будет работать.

Обычные диаграммы UML для пакетов работают нормально для пространств имен, но этого мало.

person Alex Miller    schedule 01.03.2011