Из Википедии, бесплатной энциклопедии
  (Перенаправлено из функциональной блок-схемы )
Перейти к навигации Перейти к поиску
Рисунок 1: Формат функциональной блок-схемы. [1]

Функциональная блок - схема потока ( FFBD ) является многоуровневым, время секвенировало, шаг за шагом схемой , потока из системы «ы функционально потока. [2] Термин «функциональный» в этом контексте отличается от его использования в функциональном программировании или математике, где сочетание «функциональный» и «поток» было бы неоднозначным. Здесь «функциональный поток» относится к последовательности операций, а стрелки «потока» выражают зависимость от успеха предыдущих операций. FFBD могут также выражать зависимости входных и выходных данных между функциональными блоками, как показано на рисунках ниже, но FFBD в основном ориентированы на последовательность.

Обозначение FFBD было разработано в 1950-х годах и широко используется в классической системной инженерии . FFBDs являются одним из классических моделирования бизнес - процессов , методологий, а также блок - схемы , поток данных диаграммы , схемы управления потоком , диаграммы Ганта , PERT диаграммы и IDEF . [3]

FFBD также называют функциональными блок-схемами , функциональными блок-схемами и функциональными потоками . [4]

История [ править ]

Первый структурированный метод документирования технологического процесса - блок-схема - был представлен Фрэнком Гилбретом членам Американского общества инженеров-механиков (ASME) в 1921 году в виде презентации «Диаграммы процессов - первые шаги в поиске наилучшего пути». [5] Инструменты Гилбрета быстро вошли в учебные программы по промышленной инженерии .

В начале 1930-х годов промышленный инженер Аллан Х. Могенсен начал обучать деловых людей использованию некоторых инструментов промышленного проектирования на своих конференциях по упрощению работы в Лейк-Плэсиде , штат Нью-Йорк . Арт Спинангер, выпускник класса Могенсена в 1944 году, вернул инструменты компании Procter and Gamble, где разработал их Программу сознательного изменения методов. Другой выпускник 1944 года, Бен С. Грэм , директор по разработке форм в Standard Register Industrial, адаптировал блок-схему процесса для обработки информации с его разработкой многопоточной схемы процесса для отображения нескольких документов и их взаимосвязей. В 1947 году ASME принял набор символов в качестве стандарта ASME для рабочих и технологических схем, заимствованный из оригинальной работы Гилбрета. [5]

Современная функциональная блок-схема была разработана компанией TRW Incorporated, связанной с обороной, в 1950-х годах. [6] В 1960-х годах он использовался НАСА для визуализации временной последовательности событий в космических системах и полетах. [7] FFBD стали широко использоваться в классической системной инженерии, чтобы показать порядок выполнения системных функций. [3]

Разработка функциональных блок-схем [ править ]

Рисунок 2: Разработка функциональных блок-схем [8]

FFBD могут быть разработаны на нескольких уровнях. FFBD показывают те же задачи, идентифицированные посредством функциональной декомпозиции, и отображают их в их логической, последовательной взаимосвязи. Например, вся задача полета из космического аппарата может быть определена в FFBD верхнего уровня, как показано на рисунке 2. Каждый блок в первой диаграмме уровня затем может быть расширен на ряд функций, как показано на второй диаграмме уровня для «выполнять операции миссии». Обратите внимание, что на диаграмме показаны как ввод (переход на рабочую орбиту), так и вывод (переход на орбиту космической транспортной системы), что инициирует процесс идентификации и управления интерфейсом. Каждый блок на диаграмме второго уровня можно постепенно развить в ряд функций, как показано на диаграмме третьего уровня на рисунке 2.[8]

Эти диаграммы используются как для разработки требований, так и для определения прибыльных торговых исследований. Например, принимает ли антенна космического корабля спутник слежения и ретрансляции данных (TDRS) только тогда, когда должны передаваться данные полезной нагрузки, или она постоянно отслеживает TDRS, чтобы обеспечить прием аварийных команд или передачу аварийных данных? FFBD также включает в себя запасные и аварийные операции, которые повышают вероятность успеха миссии. Блок-схема дает представление о работе системы в целом, служит основой для разработки операционных и аварийных процедур и определяет области, в которых изменения в операционных процедурах могут упростить работу системы в целом. В некоторых случаяхальтернативные FFBD могут использоваться для представления различных средств выполнения конкретной функции до тех пор, пока данные не будут получены, что позволяет выбирать среди альтернатив.[8]

Строительные блоки [ править ]

Ключевые атрибуты [ править ]

Обзор основных атрибутов FFBD: [1]

Графическое объяснение «функционального блока», используемого в этих схемах. Течение слева направо. [4]
  • Функциональный блок : каждая функция в FFBD должна быть отдельной и представлена ​​одним прямоугольником (сплошная линия). Каждая функция должна обозначать определенное, конечное, дискретное действие, которое должно выполняться элементами системы.
  • Нумерация функций : каждый уровень должен иметь последовательную схему нумерации и предоставлять информацию о происхождении функции. Эти номера устанавливают идентификацию и взаимосвязи, которые будут использоваться во всех действиях по функциональному анализу и распределению и облегчат отслеживаемость от нижнего до верхнего уровней.
  • Функциональная ссылка : каждая диаграмма должна содержать ссылку на другие функциональные диаграммы с использованием функциональной ссылки (рамка в скобках).
  • Связь потока : строки, соединяющие функции, должны указывать только на выполнение функции, а не на промежуток времени или промежуточную активность.
  • Направление потока : диаграммы должны быть расположены так, чтобы направление потока обычно было слева направо. Стрелки часто используются для обозначения функциональных потоков.
  • Суммирующие ворота : круг используется для обозначения суммирующих ворот и используется, когда присутствует И / ИЛИ. И используется для обозначения параллельных функций, и для продолжения должны быть выполнены все условия. ИЛИ используется, чтобы указать, что альтернативные пути могут быть удовлетворены для продолжения.
  • Дорожки GO и NO-GO : «G» и «полоса G» используются для обозначения условий «идти» и «нет». Эти символы помещаются рядом с линиями, оставляя определенную функцию для обозначения альтернативных путей.

Символика функций [ править ]

Функция должна быть представлена ​​прямоугольником, содержащим название функции (глагол действия, за которым следует именная фраза) и ее уникальный десятичный номер с разделителями. Горизонтальная линия разделяет этот номер и заголовок, как показано на Рисунке 3 выше. На рисунке также показано, как представить ссылочную функцию, которая обеспечивает контекст в рамках конкретного FFBD. См. Рисунок 9 для примера использования функции ссылки. [9]

Рисунок 3. Функциональный символ
Рисунок 4. Направленные линии

Направленные линии [ править ]

Линия с единственной стрелкой должна отображать функциональный поток слева направо, см. Рисунок 4. [9]

Логические символы [ править ]

Должны использоваться следующие основные логические символы. [9]

  • И: условие, при котором требуются все предшествующие или последующие пути. Символ может содержать один вход с несколькими выходами или несколько входов с одним выходом, но не может содержать несколько входов и выходов вместе (рисунок 5). Прочтите рисунок следующим образом: F2 И F3 могут начинаться параллельно после завершения F1. Точно так же F4 может начаться после завершения F2 И F3.
Рисунок 5. Символ «И»
Рисунок 6. Символ «Исключающее ИЛИ»
  • Исключающее ИЛИ: условие, при котором требуется один из нескольких предшествующих или последующих путей, но не все. Символ может содержать один вход с несколькими выходами или несколько входов с одним выходом, но не может содержать несколько входов и выходов вместе (рисунок 6). Прочтите рисунок следующим образом: F2 ИЛИ F3 может начаться после завершения F1. Аналогично, F4 может начаться после завершения либо F2, либо F3.
  • Включающее ИЛИ: условие, при котором требуются один, некоторые или все из нескольких предшествующих или последующих путей. На рисунке 7 изображена логика включающего ИЛИ с использованием комбинации символа И (рисунок 5) и символа исключающего ИЛИ (рисунок 6). Прочтите рисунок 7 следующим образом: F2 ИЛИ F3 (исключительно) может начинаться после завершения F1, ИЛИ (опять же исключая) F2 И F3 могут начинаться после завершения F1. Аналогичным образом, F4 может начаться после завершения либо F2 ИЛИ F3 (исключительно), ИЛИ (снова исключая) F4 может начаться после завершения как F2, так и F3.
Рисунок 7. Логика «включающего ИЛИ»

Контекстные и административные данные [ править ]

Каждая FFBD должна содержать следующие контекстные и административные данные: [9]

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

На рисунках 8 и 9 представлены данные в FFBD. Рисунок 9 представляет собой декомпозицию функции F2, содержащейся на рисунке 8, и иллюстрирует контекст между функциями на разных уровнях модели.

Рис. 8. Иллюстрация функции 0 FFBD.
Рисунок 9. Иллюстрация функции 2 FFBD

См. Также [ править ]

  • Диаграмма деятельности
  • Блок-схема
  • Отображение бизнес-процессов
  • Поток данных
  • ДРАКОН
  • Схема
  • Схема технологического процесса
  • Функциональная модель
  • Функциональная блок-схема
  • IDEF0
  • Диаграмма N2
  • SADT
  • Поток сигнала
  • График потока сигналов

Примечания [ править ]

  1. ^ a b Основы системной инженерии. Архивировано 28 июля 2011 г., издательство Wayback Machine Defense Acquisition University Press, 2001 г.
  2. ^ Первая версия этой статьи полностью основана на РУКОВОДСТВЕ ПО РАЗРАБОТКЕ СИСТЕМЫ NAS РАЗДЕЛ 4.4 ВЕРСИЯ 3.1 06.06.06.
  3. ^ a b Томас Дюфрен и Джеймс Мартин (2003). «Моделирование процессов для электронного бизнеса». Архивировано 20 декабря 2006 г. на Wayback Machine . INFS 770 Методы инженерии информационных систем: управление знаниями и электронный бизнес. Весна 2003 г.
  4. ^ a b Инструменты анализа задач, используемые в процессе разработки . FAA 2008. Проверено 25 сентября 2008 г.
  5. ^ а б Бен Б. Грэм (2004). «Подробная диаграмма процесса: говоря на языке процесса». стр.1
  6. ^ Тим Вейлкиенс (2008). Системная инженерия с SysML / UML: моделирование, анализ, дизайн . Стр. 257.
  7. ↑ Гарольд Каштан (1967). Методы системного проектирования . Стр. 254.
  8. ^ а б в НАСА (2007). Справочник НАСА по системной инженерии, декабрь 2007 г. с.53.
  9. ^ а б в г FAA (2006). NAS SYSTEM ENGINEERING РУКОВОДСТВО РАЗДЕЛ 4.4 ВЕРСИЯ 3.1 06/06/06.

Дальнейшее чтение [ править ]

  • DAU (2001) Основы системной инженерии. Издательство Defense Acquisition University Press.
  • FAA (2007) Руководство по проектированию систем . Федеральное управление гражданской авиации Вашингтона.