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

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

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

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

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

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

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

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

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

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

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