Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Рисунок 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» и «bar 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 РАЗДЕЛ 4.4 ВЕРСИЯ 3.1 06.06.06.

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

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