Подтвердить что ты не робот

Что такое функциональное разложение?

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

4b9b3361

Ответ 1

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

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

  • Подходите к банкомату

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

  • Введите свой контакт

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

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

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

  • Проверка PIN-кода

  • Обработка передачи

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

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

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

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

Лично я считаю, что количество времени стоит того.

Ответ 2

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

Доводы

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Затем компилятор:

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

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

process_data(parse_input(), parse_config())

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

Ответ 5

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

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

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

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