Можно ли использовать UML для моделирования функциональной программы?

Ответ 1

Функциональные программисты, как правило, не очень полезны для диаграмм. Многие функциональные программисты (но не все) считают, что записывать типы - это хороший способ инкапсулировать конструктивные отношения, которые программисты OO помещают в диаграммы UML.

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

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

Ответ 2

UML - это не только диаграммы классов, вы знаете?

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

Ответ 3

UML - это сборник различных типов моделирования. Если вы говорите об объектной диаграмме (диаграмме классов), вы не найдете ничего, что бы соответствовало вашему желаемому использованию. Но если вы говорите о Диаграмме взаимодействия (диаграмме активности) или диаграмме требований (используйте диаграмму случая), то, конечно, они помогут вам и станут частью базы UML.

Ответ 4

Функциональные программисты имеют собственную версию UML, она называется Теория категорий.

(В этом есть определенная правда, но она предназначена для чтения с легким юмором).

Ответ 5

UML - это объектный подход, потому что на графическом уровне вы не можете определить функциональное моделирование. Трюк заключается в том, чтобы напрямую добавлять ограничения и заметки в модель, а не в уровни диаграмм. Я имею в виду, что вы можете написать полную функциональную документацию по каждому элементу модели непосредственно в метамодели и отобразить только представление объекта с помощью редактора UML. Это, наверное, глупо, но я нашел эту демонстрацию на французском языке именно по той же теме и используя EclipseUML Omondo: OCL и UML 2.2 (демо на французском языке 3mn): http://www.download-omondo.com/regle_ocl.swf

В этой демонстрации объясняется, как добавлять ограничения непосредственно к методам на уровне метамодели. Интересным моментом этой демонстрации является то, что использование единой модели для всего проекта позволяет быть достаточно гибким, чтобы расширить традиционный UML и избежать моделей SysML, BPMN, DSL, поскольку вся информация построена на вершине метамодели UML 2.2. Я не знаю, будет ли это успешным, но эта инициатива очень интересна, потому что уменьшает сложность моделирования и открывает новые границы!

Ответ 6

Чтобы моделировать функциональную программу, используя диаграмму, а не текстовое представление, вы можете использовать обозначение, подобное тому, которое используется для программирования в Viskell или Luna

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

Класс - это просто абстракция понятия, которое связывает функциональность его методов вместе более дружелюбно. Например, класс WaveGenerator может включать в себя методы Sine, Sawtooth и SquareWave. Все три метода явно связаны с генератором классов. Однако все трое также не имеют гражданства. Если они разработаны правильно, им не нужно сохранять информацию о состоянии вне метода. Это делает их объектами без гражданства, которые, если я правильно понимаю, делают их неизменяемыми функциями, которые являются основной концепцией в функциональной парадигме.

С концептуальной точки зрения я не вижу разницы между

let Envelope Sine =...

и

пусть Envelope Generator.Sine =...

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