Які функціональні програмісти використовують замість UML?

Я студент CS. Зараз я відвідую лекції, де ми викладаємо об'єктивний аналіз та дизайн. Він складається в основному з написання випадків використання, аналізу проблеми, з якою ми можемо зіткнутися під час написання якоїсь програми для клієнта, і як спроектувати проект таким чином, щоб він був розширюваним, зрозумілим для розробників, і не створював проблем, коли клієнт сперечається про деякі особливості. Оскільки це "об'єктивно", ми вивчаємо це з точки зору OOP (класи тощо).

Зараз ми використовуємо UML в якості помічника. Я вважаю, що я добре розуміюсь на OOP, але я також вивчив функціональну парадигму та успішно використовував її в деяких моїх менших проектах.

Наш вчитель, стикаючись з "як щодо функціональної парадигми?" На питання, відповів, що не програмує жодного більшого проекту на функціональних мовах, і він не знає, яким інструментом можуть користуватися функціональні програми.

Отже, що б вони використали? Чи існує якась методологія цього? А може, в цьому немає потреби?

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

Це спрацьовує через відсутність побічних ефектів у функціональному програмуванні, тому всі функції задаються лише їх входами та виходами. Це робить їхні підписи набагато кориснішими як інструмент проектування, ніж в імперативному програмуванні. Це одна з причин, коли ви бачите їх використання навіть тоді, коли компілятор міг зробити їх висновок.

Що стосується інструментів діаграмування, то з усією повагою до вашого професора, я не використовував їх у значній мірі в жодній парадигмі з моменту закінчення школи.

Стандарт UML визначає десяток різних типів діаграм, як показано на цій зручній діаграмі:

Джерело: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg

Дивіться також рисунок A.5 Таксономія діаграм структури та поведінки у специфікації UML 2.5.

^{Зауважимо, що це приклад діаграми класів, із-підзагортанням зв'язків між типами діаграм і абстрактними типами діаграм курсивом. Хоча ці типи діаграм насправді є класами в метамоделі UML, ця діаграма класів все ще корисна для ілюстрації ієрархії без будь-якого з'єднання з OOP.}

Існує кілька типів, які чітко застосовуються лише до OOP, наприклад діаграма класів або об'єктна діаграма . Але решта більше застосовується, ніж лише для об'єктно-орієнтованих систем.

• Діаграми державних машин - FP не уникає станів, а лише робить їх явними. Діаграма машини стану може бути корисною для пояснення потоку управління або різних переходів стану в програмі.

• Діаграми діяльності - корисні в аналогічних випадках, як і для Діаграми державного апарату, але на більш високому рівні. Вони можуть бути використані для пояснення потоку даних між різними підсистемами або для моделювання зовнішніх бізнес-процесів.

• Діаграми взаємодії - моделюють взаємодію між декількома станом стану. Зрозуміло, що це не корисно для моделювання інтернету чистої функціональної програми. Однак UML стосується не лише моделювання структури коду, а насамперед щодо надання універсальної мови моделювання. За допомогою діаграми взаємодії я можу, наприклад, використовувати схеми взаємодії для моделювання зовнішньої поведінки між системами, наприклад, між браузером та веб-сервером - навіть коли вони написані за допомогою FP-методів.

• Діаграми використання випадків - випадки та вимоги використання не залежать від технології, яка використовується для їх задоволення. OOP або FP тут абсолютно не мають значення.

• Діаграми розгортання - Цей тип діаграми використовується для опису співвідношення між програмованими програмними та апаратними ресурсами. Чи було це програмне забезпечення написане мовою FP, не має значення.

• Діаграми компонентів - Більшість функціональних мов мають явну підтримку модульного програмування в наші дні. Діаграма компонентів описує компоненти / модулі та їх запропоновані та необхідні інтерфейси. Це мені нагадує багато функціональних модулів OCaml.

• Профільні діаграми - описують розширення до самого UML і як такі ніколи фактично не використовуються.

• Діаграми складеної структури - описують структуру композитів. Він може бути використаний для опису структур даних або навіть точок взаємодії функції. Вікіпедія показує схему функції Фібоначчі як приклад:

  

  Джерело: https://commons.wikimedia.org/wiki/File:Composite_Structure_Diagram.png

  У певному сенсі це був би вибір функціональних програмістів, а не діаграма класів, але це здається жахливо переосмисленим….

• Пакетні діаграми - Пакети - це еквівалент UML-просторів імен. Цей тип діаграми є більш частиною мовної інфраструктури UML, ніж окремим типом діаграми. Наприклад, ви можете використовувати пакети для категоризації великої діаграми використання випадків.

Отже, як ми бачили, різні типи діаграм UML все ще можуть бути корисні при виконанні функціонального програмування.

Я рідко відчував бажання використовувати UML під час проектування системи, і в першу чергу використовую UML, щоб виконати призначене домашнє завдання або швидкий ескіз донести контур архітектури. Навіть для системи OOP UML не надає достатнього значення, щоб постійно її використовувати - фактичний код говорить більше тисячі діаграм. Я міг би уявити використання діаграм, схожих на UML, для пояснення залежностей між різними функціями та структурами даних у програмі FP, але до цього часу я не маю цього робити - мій особистий стиль надає перевагу поєднанню OOP та FP, де методи FP використовуються в локальному масштабі, але не впливають на загальну архітектуру.