Существует ли язык или стиль визуального моделирования для парадигмы функционального программирования?
UML - это стандарт, нацеленный на моделирование программного обеспечения, которое будет написано на ОО-языках и идет рука об руку с Java. Тем не менее, может ли оно быть использовано для моделирования программного обеспечения, предназначенного для написания в парадигме функционального программирования? Какие диаграммы будут полезны с учетом встроенных визуальных элементов?
Есть ли язык моделирования, нацеленный на функциональное программирование, а точнее Haskell? Какие инструменты для составления диаграмм вы бы порекомендовали?
Под редакцией ФП 02 сентября 2009 г.:
То, что я ищу, - это самое наглядное и легкое представление того, что происходит в коде. Простые в использовании диаграммы, визуальные модели не обязательно предназначены для других программистов. Я очень скоро буду разрабатывать игру на Хаскелле, но, поскольку этот проект предназначен для моей выпускной работы, мне нужно ввести некоторую формализацию предложенного решения. Мне было интересно, если есть эквивалент стандарта UML+Java, но для Haskell. Должен ли я просто придерживаться раскадровок, письменных описаний, неформализованных диаграмм (некоторые мелкие изображения в виде блок-схем), неформализованных описаний вариантов использования?
Отредактировано jcolebrand 21 июня 2012 г.:
Обратите внимание, что изначально спрашивающий хотел получить визуальную метафору, и теперь, когда у нас было три года, мы ищем больше / лучше инструментов. Ни один из первоначальных ответов не касался концепции "инструмента визуального дизайна метафор", так что... это то, что ищет новая награда.
11 ответов
Мы используем теоремы для формального моделирования (с проверкой), такие как Изабель или Кок. Иногда мы используем языки, специфичные для предметной области (например, Cryptol), чтобы выполнить проектирование высокого уровня, прежде чем выводить реализацию Haskell "низкого уровня".
Часто мы просто используем Haskell в качестве языка моделирования и получаем реальную реализацию посредством переписывания.
Свойства QuickCheck также играют роль в проектной документации, наряду с разложением типов и модулей.
Я считаю, что язык моделирования для Haskell называется " математика". Это часто преподается в школах.
Да, для Haskell широко используются языки / методы моделирования / спецификации. Они не визуальные.
В Haskell типы дают частичную спецификацию. Иногда эта спецификация полностью определяет значение / результат, оставляя различные варианты реализации. Выходя за пределы языка Haskell к языкам с зависимыми типами, как, например, в Agda & Coq (среди прочих), типы гораздо чаще используются в качестве полной спецификации.
Там, где типов недостаточно, добавьте формальные спецификации, которые часто принимают простую функциональную форму. (Следовательно, я полагаю, что ответы, что языком моделирования для Хаскелла является сам по себе Хаскель или "математика".) В такой форме вы даете функциональное определение, оптимизированное для ясности и простоты, а не все для эффективности. Определение может даже включать невычислимые операции, такие как равенство функций в бесконечных областях. Затем, шаг за шагом, вы преобразуете спецификацию в форму эффективно вычисляемой функциональной программы. Каждый шаг сохраняет семантику (обозначение), и поэтому окончательная форма ("реализация") гарантированно будет семантически эквивалентна исходной форме ("спецификация"). Вы увидите этот процесс, называемый различными именами, в том числе "преобразование программы", "вывод программы" и "расчет программы".
Шаги в типичном выводе - это в основном приложения "эквационального мышления", дополненные несколькими приложениями математической индукции (и совместной индукции). Способность выполнять такие простые и полезные рассуждения была главной мотивацией для функциональных языков программирования в первую очередь, и они обязаны своей валидностью "денотативной" природе "действительно функционального программирования".
(Термины "денотативный" и "действительно функциональный" взяты из основополагающей статьи Питера Лэндена " Следующие 700 языков программирования".) Таким образом, объединяющий призыв к чисто функциональному программированию был "хорош для рациональных рассуждений", хотя я не слышал этого описания почти так же часто в эти дни. В Хаскеле денотативный соответствует типам, отличным от IO и типы, которые полагаются на IO (такие как STM). В то время как денотативный / неIO типы хороши для правильного эквалайзера, IO/ недетонативные типы предназначены для плохой эквалайзерной логики.
Конкретная версия деривации из спецификации, которую я использую как можно чаще в своей работе на Хаскеле, - это то, что я называю "морфизмами классов семантических типов" (TCM). Идея состоит в том, чтобы дать семантику / интерпретацию для типа данных, а затем использовать принцип TCM, чтобы определить (часто уникально) значение большинства или всех функциональных возможностей типа через экземпляры классов типов. Например, я говорю, что значение Image Тип является функцией от 2D-пространства. Затем принцип TCM говорит мне о значении Monoid, Functor, Applicative, Monad, Contrafunctor, а также Comonad экземпляры, соответствующие этим экземплярам для функций. Это много полезной функциональности для изображений с очень краткими и убедительными характеристиками!
(Спецификация - это семантическая функция плюс список классов стандартных типов, для которых должен соблюдаться принцип семантического TCM.) И все же у меня есть огромная свобода представления изображений, а принцип семантического TCM устраняет утечки абстракции. Если вам интересно увидеть некоторые примеры этого принципа в действии, ознакомьтесь с документом Denotational design с морфизмами классов типов.
Да, Хаскелл.
У меня складывается впечатление, что программисты, использующие функциональные языки, не чувствуют необходимости упростить свой язык выбора, когда думают об их дизайне, что является одним из (довольно бойких) способов просмотра того, что UML делает для вас.
Я посмотрел несколько видеоинтервью и прочитал несколько интервью с такими людьми, как Эрик Мейер и Саймон Пейтон-Джонс. Кажется, что когда дело доходит до моделирования и понимания проблемной области, они используют сигнатуры типов, особенно сигнатуры функций.
Диаграммы последовательности (UML) могут быть связаны с композицией функций. Статическая диаграмма классов (UML) может быть связана с сигнатурами типов.
В Haskell вы моделируете по типам.
Просто начните с написания сигнатур функций, классов и данных без какой-либо реализации и попытайтесь привести типы в соответствие. Следующий шаг - QuickCheck.
Например, для моделирования рода:
class Ord a where
compare :: a -> a -> Ordering
sort :: Ord a => [a] -> [a]
sort = undefined
затем тесты
prop_preservesLength l = (length l) == (length $ sort l)
...
и, наконец, реализация...
Хотя это и не рекомендация к использованию (поскольку она недоступна для загрузки), но система HOPS визуализирует графы терминов, которые часто представляют собой удобное представление функциональных программ.
Его также можно рассматривать как инструмент проектирования, поскольку он поддерживает документирование программ, а также их построение; Я верю, что это может также переписать термины, если вы хотите, чтобы вы могли видеть их разворачивание.
К сожалению, я считаю, что он больше не активно развивается.
Вы можете использовать сетевую модель процесса потока данных, как описано в статье Обработка сигналов в реальном времени: Поток данных, Визуальное и Функциональное программирование, автор Hideki John Reekie
Например, для кода вроде (Haskell):
fact n | n == 0 = 1
| otherwise = n * fact (n - 1)
Визуальное представление будет:
Я понимаю, что опаздываю на вечеринку, но я все равно дам свой ответ, если кто-то посчитает его полезным.
Я думаю, что я бы пошел на системные методологии, такие как SADT / IDEF0.
- https://en.wikipedia.org/wiki/Function_model
- https://en.wikipedia.org/wiki/Structured_Analysis_and_Design_Technique
Такие диаграммы могут быть сделаны с помощью программы Dia, которая доступна как в Linux, Windows, так и в MacOS.
Какой смысл в моделировании Haskell с помощью Maths? Я думал, что весь смысл Хаскелла в том, что он настолько тесно связан с математикой, что математики могут поднять его и использовать вместе с ним. Зачем вам переводить язык на себя?
При работе с другим функциональным языком программирования (F#) я использовал диаграммы на белой доске, описывающие большие блоки, а затем смоделировал систему OO-способом, используя UML, используя классы. Было небольшое несоответствие в строительных блоках в F# (разделить классы на структуры данных и функции, которые на них воздействовали). Но для понимания с точки зрения бизнеса это сработало. Я бы добавил, что проблема была ориентирована на бизнес / Интернет, и я не знаю, насколько хорошо этот метод будет работать для чего-то более финансового. Я думаю, что я бы, вероятно, захватил функции как объекты без состояния, и они должны хорошо вписываться.
Все зависит от домена, в котором вы работаете.
Я использую универсальный системный язык. Я изучаю Erlang, и я думаю, что это идеально подходит.
Жаль, что документация очень ограничена, и никто не использует ее. Больше информации здесь.