Что такое функциональная декомпозиция?

Функциональная декомпозиция, для чего она нужна и каковы ее плюсы / минусы? Где есть несколько проработанных примеров того, как это используется?

Источник

5 ответов

Решение

Функциональная декомпозиция - это процесс принятия сложного процесса и его разбиения на более мелкие и простые части.

Например, подумайте об использовании банкомата. Вы можете разложить процесс на:

  1. Подойдите к банкомату

  2. Вставьте свою банковскую карту

  3. Введите свой пин

ну... вы поняли.

Вы можете думать о программировании так же. Подумайте о программном обеспечении, которое использует этот банкомат:

  1. Код для чтения карты

  2. Проверка PIN

  3. Обработка перевода

Каждый из которых может быть разбит дальше. Как только вы добрались до самых разложенных частей подсистемы, вы можете подумать о том, как начать кодирование этих частей. Затем вы соединяете эти маленькие части в большое целое. Проверьте эту статью в Википедии:

Разложение (программирование)

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

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

Лично я думаю, что это время того стоит.

Источник

Это то же самое, что и WorkBreakDown Structures (WBS), mindMapping и разработка сверху вниз - в основном разбивая большую проблему на более мелкие, более понятные части.

Pros

  • допускает упреждающий подход к программированию (устранение потребности в коде)
  • помогает определить сложные и / или рискованные области проекта (в примере с банкоматом безопасность, вероятно, является более сложным компонентом)
  • помогает идентифицировать ВСЕ компоненты проекта - причина № 1 сбоя проекта / кода (через Capers Jones) отсутствует - вещи, о которых не думали до конца в проекте (ну и дела, я не осознавал, что должен был проверить баланс человека до раздачи $)
  • позволяет разделить компоненты для лучшего программирования, совместного использования кода и распределения работы

Минусы - в разложении нет настоящих CONS, однако есть некоторые распространенные ошибки

  • не разбираясь достаточно далеко или не разбираясь слишком далеко - каждый человек должен определить счастливый уровень детализации, необходимый для того, чтобы дать ему представление о компоненте, не переусердствовав его (не разбивайтесь на программные строки кода...)
  • не использовать уже существующие шаблоны / программные модули (переработать)
  • не проверять с клиентами, чтобы убедиться, что объем правильный
  • не использовать разбивку при кодировании (например, проектировать дом, чем забывать о плане и просто начать склеивать доски)
Источник

Вот пример: ваш компилятор Си.

Сначала есть препроцессор: он обрабатывает #include а также #define и все макросы. Вы даете ему имя файла и некоторые опции, и он возвращает действительно длинную строку. Давайте назовем эту функцию preprocess(filename),

Тогда есть лексический анализатор. Он берет строку и разбивает ее на токены. Назови это lex(string), Парсер берет токены и превращает их в дерево, назовите его parse(tokens), Тогда есть функция для преобразования дерева в DAG из блоков, вызвать ее dag(tree), Позвоните код эмитента emit(dag), который берет DAG из блоков и выплевывает ассемблер.

Компилятор тогда:

emit(dag(parse(lex(preprocess(filename)))));

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

process_data(parse_input(), parse_config())

Это более типично; компиляторы - довольно глубокие программы, большинство программ по сравнению с ними широки.

Источник

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

Краткое описание различий между процедурно-ориентированным и объектно-ориентированным проектированием.

Источник

Функциональная декомпозиция полезна перед созданием документов функциональных требований. Если вам для чего-то нужно программное обеспечение, функциональная декомпозиция отвечает на вопрос "Какие функции должно обеспечивать это программное обеспечение". Разложение необходимо для определения мелкозернистых функций. "Мне нужно программное обеспечение для измерения энергоэффективности" является слишком общим. Вот почему мы разбиваем это на более мелкие фрагменты до тех пор, пока не будем четко понимать все функции, которые должны обеспечивать системы. Это может позже использоваться как контрольный список для полноты системы.

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

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

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

Источник
Другие вопросы по тегам