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

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

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

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

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

analysis functional-programming software-design haskell purely-functional
person Edwin Dalorzo    schedule 12.04.2012    source источник
comment
возможный дубликат Существует ли методология разработки программного обеспечения для функционального программирования?   -  person sclv    schedule 12.04.2012
comment
Просто коснувшись одной вещи, которую вы упомянули, haddock является рекомендуемой формой документации. Мудрое создание модулей, функций и пакетов обычно делает пикшу достаточной для достаточного документирования кода (плюс описания пакетов клики).   -  person Dan Burton    schedule 13.04.2012

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

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

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

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

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

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

Um...no?

person Dan Burton    schedule 12.04.2012

arrow_upward
-7
arrow_downward

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

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

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

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

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

person Marcin    schedule 12.04.2012
comment
Классы типов Haskell не являются формой объектной ориентации. Они представляют собой форму специального полиморфизма, который вы обычно также получаете от объектных систем. Но они не объединяют данные и методы, что является отличительной чертой объектно-ориентированного подхода. - person sclv; 12.04.2012
comment
@sclv На самом деле они объединяют данные и методы - тип данных определяет, какая функция (или какая часть определения функции, если вы хотите рассматривать ее таким образом) вызывается. - person Marcin; 12.04.2012
comment
который связывает тип данных и методов! haskell.org/haskellwiki/OOP_vs_type_classes - person sclv; 12.04.2012
comment
@sclv прав; Классы типов Haskell намного ближе к ООП-интерфейсам, чем ООП-классы, но даже эта аналогия не идеальна. На самом деле, самое близкое к ООП-классам в Haskell — это просто данные типы, содержащие функции и монадические действия. - person ehird; 12.04.2012
comment
@sclv Да, и это характерно для объектно-ориентированных языков. Только меньшинство вообще связывает операции с экземплярами; в еще меньшем количестве это может быть описано как нормальная работа ОО-системы. - person Marcin; 12.04.2012
comment
@sclv Я не думаю, что это правда (хотя для детей это приемлемая ложь). Если вы не думаете о системе ограничений, классы типов — это всего лишь слегка ограниченная объектная система. В этих классах типов есть 1. подтипы 2. неявная ссылка на себя 3. заменяемая ссылка на себя (иначе наследование). Класс типов — это просто (параметризованный) абстрактный класс в oop, а экземпляр — это просто объект, который наследуется от этого абстрактного класса. С GHC 7.4 и некоторыми хитростями с использованием newtype, unsafeCoerce и неявных параметров это соответствие становится полным. - person Philip JF; 14.04.2012
comment
Я также думаю, что пара данных и методов действительно не зависит от ООП. Рассмотрим Go как пример языка, в котором методы отделены от структур, но это очень ООП. - person Philip JF; 14.04.2012
comment
С другой стороны, наивное представление о том, что классы типов эквивалентны интерфейсам, а типы данных в Haskell эквивалентны классам в ООП, которые реализуют эти интерфейсы, просто неверно. Система классов типов — это уровень, используемый для определения классов (в математическом смысле, также известных как предикаты) над типами Haskell. Это просто объектно-ориентированный слой для определения предикатов над типами Haskell. - person Philip JF; 14.04.2012
comment
@PhilipJF Мой ответ никоим образом не зависит от того, что OO может делать все, что могут делать классы типа Haskell. Он полагается на то, что система классов типов Haskell может делать все, что может ООП. - person Marcin; 14.04.2012
comment
@PhilipJF Не знаю, почему я отвечаю на эту ерунду, но классы типов не имеют подтипов, не имеют неявной ссылки на себя и не имеют наследования. В документе Haskell's Overlooked Object System есть хорошее обсуждение того, почему классы типов не выполняют эту работу (и, следовательно, что они предлагают вместо этого), и я думаю, что документ O'Haskell также достаточно хорошо мотивирует различия. В любом случае, неявные параметры не являются идиоматичными для Haskell в наши дни и вряд ли станут стандартом, и как только вы начнете использовать unsafeCoerce, вы явно не оговоритесь. - person sclv; 15.04.2012
comment
@sclv Я не уверен, какое отношение любой из этих документов имеет к моему заявлению. Кодировка класса за класс корявая, я согласен. Моя точка зрения более тонкая. Классы типов в Haskell — это классы над типами. Мы все здесь конструктивисты, поэтому для того, чтобы мы предположили, что тип является членом класса типов, требуется какой-то объект-свидетельство. Кроме того, язык предоставляет систему автоматического доказательства теорем в виде логического вывода и глобальных экземпляров. Я утверждаю только, что языком доказательства для этой логики является объектно-ориентированный, и знать об этом факте полезно для рассуждений о Haskell. - person Philip JF; 15.04.2012
comment
Тип свидетельства для членства в Ord является подтипом типа свидетельства для членства в Eq. Неявные ссылки this и наследование позволяют объявить m >> k = m >>= \_ -> k" in the definition of Monad`. Чтобы имитировать это поведение с помощью записей, требуется найти фиксированную точку (как указал Олег), которая должна подсказать вам, что что-то не так. Причина, по которой это не должно удивлять, заключается в том, что классы типов находятся по другую сторону проблемы выражения от абстрактных типов данных. Из работы Уильяма Кука мы знаем, что это означает, что они, вероятно, являются объектами. - person Philip JF; 15.04.2012
comment
Очевидно, что эта объектная система является ограниченной, но вам просто нужно взглянуть на работу Бруно Оливейры, чтобы понять, что это несущественный аспект (см. имплициты Scala). Моя точка зрения о unsafeCoerce заключается в том, что с некоторыми расширениями и небезопасными функциями вы действительно можете получить в свои руки объекты, которые свидетельствуют о членстве в классе типов, и с помощью неявных параметров вы можете создавать произвольные такие экземпляры во время выполнения (хотя это зависит от компилятора, а не соблюдая его документацию). - person Philip JF; 15.04.2012
comment
@PhilipJF тип свидетельства для членства в Ord (я полагаю, вы имеете в виду словарь) не является подтипом типа свидетельства для членства в Eq. Просто членство в Ord подразумевает членство в Eq. Экземпляр ord не может переопределять методы Eq. Я понятия не имею, что вы имеете в виду с примером монады - да, если вы кодируете монады с объектами, тогда кодировка является объектной, но это потому, что вы выбрали объектную кодировку для начала! Во всяком случае, этот тип доказательств не всегда существует. Другие реализации Haskell, такие как JHC, показывают, что без кодирования по словарю можно обойтись очень далеко. - person sclv; 15.04.2012
comment
@sclv Доказательство членства в Ord — это доказательство членства в уравнении. это то же самое, что и подтип. Пример Monad касается наследования (не подтипов, они являются отдельными), поскольку, если экземпляр Monad не переопределяет определение по умолчанию >>, он наследует общее, но это общее использует >>=, которое определено виртуально. Это то, о чем я говорил с точки зрения неявного параметра this и наследования. Тот факт, что у вас нет прямого доступа к этой объектной системе и что она не всегда реализуется напрямую, не имеет большого значения. Это объясняет семантику. - person Philip JF; 15.04.2012
comment
Но вы можете объяснить семантику без объектной системы. Означает ли тот факт, что я могу объяснить счет с помощью камешков, что натуральные числа являются разновидностью сбора камешков? - person sclv; 15.04.2012
comment
@sclv Объектная система - это все, что соответствует определенным критериям. Чего не скажешь о коллекции камешков. - person Marcin; 15.04.2012
comment
это хороший момент. Я обнаружил, что представление о классах типов как об объектах и ​​средстве доказательства теорем, подобном Прологу (где каждое правило начинается с символа «мило»), облегчает рассмотрение чего-то довольно сложного и дает мне доступ к большому количеству литературы и принципам проектирования, применимым к моей проблеме. . Думая о шаблонах C++ как о функциональном языке, подобном Haskell, также легче рассуждать о них. Обычно я пытаюсь понять странные грани математических систем, описывая их в терминах уже известных мне аксиом. Вам не нужна теория колец, чтобы объяснить целые числа. - person Philip JF; 15.04.2012