Анализ и дизайн для функционального программирования

Question

Как вы справляетесь с этапами анализа и проектирования, когда планируете разработать систему с использованием функционального языка программирования, такого как Haskell?

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

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

• Вы все еще будете использовать анализ вариантов использования или, возможно, структурный анализ и дизайн?
• Как разработчики программного обеспечения определяют высокоуровневый дизайн системы, чтобы разработчики следовали ей?
• Что вы показываете своим клиентам или новым разработчикам, когда должны представить дизайн решения?
• Как вы документируете картину всего этого, не имея сначала писать все это?
• Есть ли что-нибудь сопоставимое с UML в функциональном мире?

Answer 1

Я не профессионал, но я попробую ответить на некоторые из этих вопросов.

Вы бы все еще использовали анализ варианта использования [?]

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

или, возможно, структурированный анализ и дизайн вместо этого?

Я не знаком с таким подходом, но из того, что я почерпнул из вики-статьи, похоже, что он будет работать просто отлично.

Как разработчики программного обеспечения определяют высокоуровневый дизайн системы, чтобы разработчики следовали ей?

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

Что вы показываете своим клиентам или новым разработчикам, когда должны представить дизайн решения?

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

Как вы документируете картину всего этого, не имея сначала писать все это?

Картинка"? Просто определив сигнатуру типа для важных функций, а затем оставьте реализацию как undefined, Где-то есть пакет, который дает вам лучшие заглушки, которые напомнят вам во время компиляции, какие части вам еще нужно реализовать.

Есть ли что-нибудь сопоставимое с UML в функциональном мире?

Эм... нет?

Answer 2

Давайте рассмотрим это утверждение:

UML по своей природе связан с объектно-ориентированным способом работы программного обеспечения.

Прежде всего, это не совсем так. Вы по-прежнему можете моделировать взаимодействия, варианты использования, состояния и модели данных в UML, какой бы ни была реализация.

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

Так что, да, если вы действительно хотите продолжать использовать UML, продолжайте.