В системной инженерии , программной инженерии и информатике функциональная модель или функциональная модель представляет собой структурированное представление функций ( деятельности , действий , процессов, операций ) в рамках моделируемой системы или предметной области. [1]
Функциональная модель, похожая на модель деятельности или модель процесса , представляет собой графическое представление функции предприятия в рамках определенной области. Цели функциональной модели — описать функции и процессы, помочь в обнаружении информационных потребностей, помочь в выявлении возможностей и установить основу для определения стоимости продуктов и услуг. [2]
Функциональная модель в области системной инженерии и разработки программного обеспечения берет свое начало в 1950–1960-х годах, однако истоки функционального моделирования организационной деятельности восходят к концу 19 века.
В конце 19 века появились первые диаграммы, изображавшие деловую активность, действия, процессы или операции, а в первой половине 20 века появились первые структурированные методы документирования действий бизнес-процессов. Одним из таких методов была диаграмма потока процесса , представленная Фрэнком Гилбретом членам Американского общества инженеров-механиков (ASME) в 1921 году с презентацией под названием «Схемы процессов — первые шаги в поиске наилучшего пути». [3] Инструменты Гилбрета быстро нашли свое место в учебных программах по промышленной инженерии .
Возникновение области системной инженерии можно проследить до Bell Telephone Laboratories в 1940-х годах. [4] Необходимость определения и манипулирования свойствами системы в целом, которые в сложных инженерных проектах могут сильно отличаться от суммы свойств частей, побудила различные отрасли промышленности применять эту дисциплину. [5] Одним из первых, кто определил функциональную модель в этой области, был британский инженер Уильям Гослинг . В своей книге «Проектирование инженерных систем» (1962, стр. 25) он утверждал:
Одной из первых четко определенных функциональных моделей была функциональная блок-схема потока (FFBD), разработанная оборонной компанией TRW Incorporated в 1950-х годах. [7] В 1960-х годах она использовалась NASA для визуализации временной последовательности событий в космических системах и летных миссиях. [8] Она также широко используется в классической системной инженерии для отображения порядка выполнения системных функций. [9]
В системной инженерии и программной инженерии функциональная модель создается с функциональной перспективой моделирования . Функциональная перспектива является одной из перспектив, возможных в моделировании бизнес-процессов , другие перспективы, например, поведенческие, организационные или информационные. [10]
Функциональная перспектива моделирования концентрируется на описании динамического процесса . Основной концепцией в этой перспективе моделирования является процесс, это может быть функция, преобразование, активность, действие, задача и т. д. Известным примером языка моделирования, использующего эту перспективу, являются диаграммы потоков данных .
В перспективе для описания процесса используются четыре символа:
Теперь, с этими символами, процесс может быть представлен как сеть этих символов. Этот разложенный процесс является DFD, диаграммой потока данных.
В динамическом моделировании предприятия проводится разделение на модель управления, функциональную модель, модель процесса и организационную модель.
Функциональная декомпозиция в широком смысле относится к процессу разрешения функциональной связи на ее составные части таким образом, что исходная функция может быть восстановлена из этих частей путем композиции функций . В общем, этот процесс декомпозиции предпринимается либо с целью получения понимания идентичности составных компонентов, либо с целью получения сжатого представления глобальной функции, задача, которая осуществима только тогда, когда составные процессы обладают определенным уровнем модульности .
Функциональная декомпозиция играет важную роль в компьютерном программировании , где главная цель — максимально возможное модулирование процессов. Например, система управления библиотекой может быть разбита на модуль инвентаризации, модуль информации о посетителях и модуль оценки платы. В первые десятилетия компьютерного программирования это проявилось как «искусство подпрограммирования», как его называли некоторые выдающиеся практики.
Функциональная декомпозиция инженерных систем — это метод анализа инженерных систем. Основная идея заключается в попытке разделить систему таким образом, чтобы каждый блок блок-схемы можно было описать без «и» или «или» в описании.
Это упражнение заставляет каждую часть системы иметь чистую функцию . Когда система состоит из чистых функций, их можно использовать повторно или заменять. Обычным побочным эффектом является то, что интерфейсы между блоками становятся простыми и общими. Поскольку интерфейсы обычно становятся простыми, проще заменить чистую функцию связанной, похожей функцией.
Функциональный подход расширен в нескольких схематических методах и нотациях моделирования. В этом разделе дается обзор важных методов в хронологическом порядке.
Функциональная блок-схема — это блок-схема , описывающая функции и взаимосвязи системы . Функциональная блок-схема может изображать: [11]
Блок-схема может использовать дополнительные схематические символы для отображения определенных свойств.
Конкретными функциональными блок-схемами являются классическая функциональная блок-схема и функциональная блок-схема (FBD), используемая при проектировании программируемых логических контроллеров .
Функциональная блок-схема потока (FFBD) представляет собой многоуровневую, последовательную во времени, пошаговую схему потока функций системы . [ 14] Диаграмма была разработана в 1950-х годах и широко используется в классической системной инженерии . Функциональная блок-схема потока также называется функциональной диаграммой потока , функциональной блок-схемой и функциональным потоком . [15]
Функциональные блок-схемы потока (FFBD) обычно определяют подробные, пошаговые операционные и вспомогательные последовательности для систем , но они также эффективно используются для определения процессов в разработке и производстве систем. Процессы разработки программного обеспечения также широко используют FFBD. В системном контексте шаги функционального потока могут включать комбинации оборудования , программного обеспечения , персонала , объектов и/или процедур.
В методе FFBD функции организованы и изображены в соответствии с их логическим порядком выполнения. Каждая функция показана в соответствии с ее логической связью с выполнением и завершением других функций. Узел, помеченный именем функции, изображает каждую функцию. Стрелки слева направо показывают порядок выполнения функций. Логические символы представляют последовательное или параллельное выполнение функций. [16]
HIPO для иерархического ввода/вывода процесса — это популярное в 1970-х годах средство проектирования и документирования системного анализа [17] для представления модулей системы в виде иерархии и для документирования каждого модуля. [18]
Он использовался для разработки требований, построения дизайна и поддержки внедрения экспертной системы для демонстрации автоматизированного рандеву. Затем систематически проводилась проверка из-за метода проектирования и внедрения. [19]
Общая конструкция системы документируется с использованием диаграмм HIPO или структурных диаграмм . Структурная диаграмма похожа по внешнему виду на организационную диаграмму, но была изменена для отображения дополнительных деталей. Структурные диаграммы могут использоваться для отображения нескольких типов информации, но чаще всего используются для диаграмм структур данных или структур кода. [18]
N 2 Chart — это диаграмма в форме матрицы , представляющая функциональные или физические интерфейсы между элементами системы. Она используется для систематической идентификации, определения, табулирования, проектирования и анализа функциональных и физических интерфейсов. Она применяется к системным интерфейсам и аппаратным и/или программным интерфейсам. [14]
Диаграмма N 2 широко использовалась для разработки интерфейсов данных, в первую очередь в области программного обеспечения . Однако ее можно использовать и для разработки аппаратных интерфейсов. Базовая диаграмма N 2 показана на рисунке 2. Функции системы размещены на диагонали; оставшиеся квадраты в матрице N × N представляют собой входы и выходы интерфейса. [20]
Метод структурного анализа и проектирования (SADT) — это методология разработки программного обеспечения для описания систем в виде иерархии функций, схематическая нотация для построения эскиза программного приложения. Она предлагает строительные блоки для представления сущностей и действий, а также различные стрелки для связи блоков. Эти блоки и стрелки имеют связанную неформальную семантику . [21] SADT может использоваться как инструмент функционального анализа заданного процесса, используя последовательные уровни детализации. Метод SADT позволяет определять потребности пользователей в ИТ-разработках, которые используются в промышленных информационных системах, а также для объяснения и представления производственных процессов, процедур деятельности. [22]
SADT предоставляет конкретное функциональное представление любого предприятия, описывая функции и их отношения в компании. Эти функции выполняют цели компании, такие как продажи, планирование заказов, проектирование продукции, производство деталей и управление человеческими ресурсами. SADT может отображать простые функциональные отношения и может отражать данные и потоки управления отношениями между различными функциями. Формализм IDEF0 основан на SADT, разработанном Дугласом Т. Россом в 1985 году. [23]
IDEF0 — это методология моделирования функций для описания производственных функций, которая предлагает язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем ; бизнес-процессов; или анализа программной инженерии. [24] Он является частью семейства языков моделирования IDEF в области программной инженерии и построен на языке функционального моделирования, создающем SADT .
Метод функционального моделирования IDEF0 предназначен для моделирования решений, действий и деятельности организации или системы. [25] Он был получен из устоявшегося языка графического моделирования, структурированного анализа и метода проектирования (SADT), разработанного Дугласом Т. Россом и SofTech, Inc. В своей первоначальной форме IDEF0 включает как определение языка графического моделирования ( синтаксис и семантика ), так и описание комплексной методологии разработки моделей. [1] Военно-воздушные силы США поручили разработчикам SADT разработать метод функциональной модели для анализа и передачи функциональной перспективы системы. IDEF0 должен помочь в организации системного анализа и способствовать эффективному общению между аналитиком и заказчиком с помощью упрощенных графических устройств. [25]
Аксиоматическое проектирование — это иерархический процесс функциональной декомпозиции сверху вниз, используемый в качестве структуры синтеза решений для анализа, разработки, реинжиниринга и интеграции продуктов, информационных систем, бизнес-процессов или решений по программной инженерии. [26] Его структура математически подходит для анализа связи между функциями с целью оптимизации архитектурной надежности потенциальных моделей функциональных решений.
В области системной и программной инженерии были определены многочисленные конкретные функциональные и функциональные модели, а также тесно связанные с ними модели. Здесь будут объяснены только несколько общих типов.
Модель бизнес-функции (BFM) — это общее описание или категория операций, выполняемых регулярно для выполнения миссии организации. Они «предоставляют концептуальную структуру для идентификации общих бизнес-функций ». [27] Она может отображать критические бизнес-процессы в контексте функций бизнес-области. Процессы в модели бизнес-функции должны соответствовать процессам в моделях цепочки создания стоимости. Процессы — это группа связанных бизнес-действий, выполняемых для производства конечного продукта или предоставления услуги. В отличие от бизнес-функций, которые выполняются на постоянной основе, процессы характеризуются тем, что у них есть определенная начальная и конечная точки, отмеченные поставкой желаемого результата. На рисунке справа изображена связь между бизнес-процессами, бизнес-функциями и эталонной бизнес-моделью бизнес-области. [28]
Модель и нотация бизнес-процессов (BPMN) — это графическое представление для описания бизнес-процессов в рабочем процессе . BPMN был разработан Business Process Management Initiative (BPMI) и в настоящее время поддерживается Object Management Group с момента слияния двух организаций в 2005 году. Текущая версия BPMN — 2.0. [29]
Спецификация Business Process Model and Notation (BPMN) предоставляет графическую нотацию для указания бизнес-процессов в Business Process Diagram (BPD). [30] Целью BPMN является поддержка управления бизнес-процессами как для технических пользователей, так и для бизнес-пользователей путем предоставления нотации, которая интуитивно понятна бизнес-пользователям, но способна представлять сложную семантику процесса. Спецификация BPMN также предоставляет сопоставление между графикой нотации и базовыми конструкциями языков исполнения, в частности BPEL4WS . [31]
Бизнес -эталонная модель — это эталонная модель, концентрирующаяся на функциональных и организационных аспектах основного бизнеса предприятия , сервисной организации или государственного учреждения . В корпоративной инженерии бизнес-эталонная модель является частью Enterprise Architecture Framework или Architecture Framework , которая определяет, как организовать структуру и представления, связанные с Enterprise Architecture .
Референтная модель в целом — это модель чего-либо, которая воплощает основную цель или идею чего-либо и может затем рассматриваться как ссылка для различных целей. Референтная бизнес-модель — это средство описания бизнес-операций организации, независимо от организационной структуры , которая их выполняет. Другие типы референтных бизнес-моделей также могут отображать взаимосвязь между бизнес-процессами , бизнес-функциями и референтной бизнес-моделью бизнес-области . Эти референтные модели могут быть построены по слоям и предлагают основу для анализа компонентов услуг, технологий, данных и производительности.
Модель функции оператора (OFM) предлагается в качестве альтернативы традиционным методам анализа задач , используемым инженерами по человеческому фактору . Модель функции оператора пытается представить в математической форме, как оператор может разложить сложную систему на более простые части и координировать действия управления и конфигурации системы так, чтобы была достигнута приемлемая общая производительность системы. Модель представляет основные вопросы представления знаний, потока информации и принятия решений в сложных системах. Миллер (1985) предполагает, что сетевую структуру можно рассматривать как возможное представление внутренней модели оператора системы плюс структуры управления, которая определяет, как модель используется для решения задач принятия решений, которые включают функции управления оператора. [32]
В статье использованы материалы, являющиеся общественным достоянием Национального института стандартов и технологий.
В статье использованы общедоступные материалы из Operator Function Model (OFM). Федеральное управление гражданской авиации .