Что у нас в FP есть в плане анализа предметки

[metaclass]

и синтеза дизайна системы?
Тут народ вопросом задается: http://guamoka.livejournal.com/1047171.html

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

Comments

[dmzlj.livejournal.com]

Непонятно, в чем отличие от не-ФП.

[jakobz.livejournal.com]

Да тоже самое все подходит. Любителям фашизма можно даже UML-диаграммы рисовать.

[vit-r.livejournal.com]

Если брать Эрриксон, то они скорее всего документировали в виде CSD (call sequence diagram) и конечных автоматах. Диаграммы потоков данных и сообщений тоже полезны. А в остальном, те же яйца, только сбоку.

Прелесть функционального подхода в том, что DSL задачи пользователя ложится на него почти без изменений и осоой нужды переводить всё на птичий язык нет.

[guamoka.livejournal.com]

Я вот думаю, что не везде требуют соблюдать вуду-процессы с артефактами-uml-подробными спецификациями и прочим

Кстати, ребе, вы случайно не путает OO подход, моделирование, специфицирование и документирование c помощью, скажем UML? Чтобы использовать OO подход и даже использовать/знать РУП, не нужно ведь обязательно под страхом расстрела документировать каждую запятую в проекте на UML, утром получать документацию, а вечером сдавать? Ну, и "достаточность" тоже ведь не подразумивает, нарисовал две линии в юзкейзах, три- в моделях, четыре-пять- в спецификации имплементации?

[justy-tylor.livejournal.com]

Для data modeling есть разница в кошерных sum types. Палитра низкоуровневых архитектурных приёмов больше зависит от языка, чем от парадигмы. Например, design patterns заплатки для Java от GoF. Или type classes в Haskell vs. попытки навести что-то подобное в OCaml.

Что касается OOA/OOD, то хороших слов у меня нет. Попытки сделать толковое начались только в BORO Партриджа (Chris Partridge "Business Objects: Re-Engineering for Re-Use"), но это, фактически, отход от object-oriented (как и последовавшие ISO 15926-2, Gellish, HQDM). А "проверенное временем" вуду, будь оно архитектурного или организационного уровня, всё больше про говно и солому,