Функциональная модель
В системной инженерии , разработке программного обеспечения и информатике функциональная модель или функциональная модель — это структурированное представление функций ( действий , действий , процессов , операций ) внутри моделируемой системы или предметной области. [1]
Функциональная модель, аналогичная модели деятельности или модели процесса , представляет собой графическое представление функции предприятия в определенной области. Целями функциональной модели являются описание функций и процессов, помощь в выявлении информационных потребностей, помощь в выявлении возможностей и создание основы для определения стоимости продуктов и услуг. [2]
История [ править ]
Функциональная модель в области системной инженерии и разработки программного обеспечения зародилась в 1950-х и 1960-х годах, однако зарождение функционального моделирования организационной деятельности относится к концу 19 века.
В конце 19 века появились первые диаграммы, изображавшие деловую деятельность, действия, процессы или операции, а в первой половине 20 века появились первые структурированные методы документирования деятельности бизнес-процессов. Одним из таких методов была блок-схема процесса , представленная Фрэнком Гилбретом членам Американского общества инженеров-механиков (ASME) в 1921 году с презентацией, озаглавленной «Диаграммы процессов — первые шаги в поиске лучшего пути». [3] Инструменты Гилбрета быстро нашли применение в учебных программах по промышленному проектированию .
Возникновение области системной инженерии можно отнести к Bell Telephone Laboratories в 1940-х годах. [4] Необходимость идентифицировать и манипулировать свойствами системы в целом, которые в сложных инженерных проектах могут сильно отличаться от суммы свойств частей, побудила различные отрасли применять эту дисциплину. [5] Одним из первых, кто определил функциональную модель в этой области, был британский инженер Уильям Гослинг . В своей книге «Проектирование инженерных систем» (1962, стр. 25) он заявил:
- Таким образом, функциональная модель должна достигать двух целей, чтобы быть полезной. Он должен предоставить механику описания пропускной способности, способную полностью определить первое и последнее состояния пропускной способности и, возможно, некоторые из промежуточных состояний. Она также должна предлагать некоторые средства, с помощью которых любые входные данные, правильно описанные в терминах этой механики, могут быть использованы для создания выходных данных, которые являются столь же правильным описанием выходных данных, которые реальная система дала бы для соответствующих входных данных. Также можно отметить, что есть еще две вещи, которые может выполнять функциональная модель, но которые не обязательны для всех функциональных моделей. Таким образом, такая система может, но не обязательно, описывать пропускную способность системы, отличную от входной и выходной, а также может содержать описание операции, которую каждый элемент выполняет над пропускной способностью, но опять же, это не так. [6]
Одной из первых четко определенных функциональных моделей была блок-схема функциональных потоков (FFBD), разработанная оборонной компанией TRW Incorporated в 1950-х годах. [7] использовало его В 1960-х годах НАСА для визуализации временной последовательности событий в космических системах и полетных миссиях. [8] Кроме того, он широко используется в классической системной инженерии , чтобы показать порядок выполнения системных функций. [9]
Темы функционального моделирования [ править ]
Функциональная перспектива
В системной инженерии и разработке программного обеспечения функциональная модель создается с точки зрения функционального моделирования . Функциональная перспектива является одной из перспектив, возможных при моделировании бизнес-процессов ; другие перспективы являются, например, поведенческими, организационными или информационными. [10]
Функциональное моделирование концентрируется на описании динамического процесса . Основным понятием в этой перспективе моделирования является процесс, это может быть функция, преобразование, деятельность, действие, задача и т. д. Хорошо известным примером языка моделирования, использующего эту перспективу, являются диаграммы потоков данных .
Перспектива использует четыре символа для описания процесса, а именно:
- Процесс: иллюстрирует преобразование от ввода к выводу.
- Хранить: Сбор данных или какой-то материал.
- Поток: движение данных или материала в процессе.
- Внешняя сущность: внешняя по отношению к моделируемой системе, но взаимодействует с ней.
Теперь с помощью этих символов процесс можно представить как сеть этих символов. Этот декомпозированный процесс представляет собой DFD, диаграмму потока данных.
В динамическом моделировании предприятия подразделяются на модель управления , функциональную модель, модель процесса и организационную модель .
Функциональная декомпозиция
Функциональная декомпозиция в широком смысле относится к процессу разделения функциональных отношений на составные части таким образом, что исходная функция может быть восстановлена из этих частей путем композиции функций . В общем, этот процесс декомпозиции предпринимается либо с целью понимания идентичности составляющих компонентов, либо с целью получения сжатого представления глобальной функции - задача, которая выполнима только тогда, когда составляющие процессы обладают определенный уровень модульности .
Функциональная декомпозиция играет важную роль в компьютерном программировании , где основной целью является модульность процессов в максимально возможной степени. Например, система управления библиотекой может быть разбита на модуль инвентаризации, модуль информации о посетителях и модуль оценки оплаты. В первые десятилетия компьютерного программирования это проявлялось как «искусство подпрограмм», как его называли некоторые выдающиеся практики.
Функциональная декомпозиция инженерных систем – это метод анализа инженерных систем. Основная идея состоит в том, чтобы попытаться разделить систему таким образом, чтобы каждый блок блок-схемы можно было описать без «и» или «или» в описании.
Это упражнение заставляет каждую часть системы иметь чистую функцию . Когда система состоит из чистых функций, их можно использовать повторно или заменять. Обычным побочным эффектом является то, что интерфейсы между блоками становятся простыми и универсальными. Поскольку интерфейсы обычно становятся простыми, чистую функцию легче заменить связанной аналогичной функцией.
Методы функционального моделирования [ править ]
Функциональный подход расширяется за счет множества диаграммных методов и обозначений моделирования. В этом разделе дается обзор важных техник в хронологическом порядке.
Функциональная блок-схема [ править ]
Функциональная блок-схема — это блок-схема , описывающая функции и взаимосвязи системы . Функциональная блок-схема может отображать: [11]
- Функции системы, изображенной блоками
- Ввод блока, изображенного линиями, и
- Отношения между 9 функциями
- Функциональные последовательности и пути материи и/или сигналов [12]
Блок-схема может использовать дополнительные схематические символы для отображения определенных свойств.
Конкретная функциональная блок-схема — это классическая функциональная блок-схема и функциональная блок-схема (FBD), используемая при проектировании программируемых логических контроллеров .
Функциональная блок-схема [ править ]
схема функционального потока (FFBD) представляет собой многоуровневую, упорядоченную по времени, пошаговую блок-схему функционального потока системы Блок - . [14] Схема разработана в 1950-х годах и широко используется в классической системной инженерии . Функциональную блок-схему также называют функциональной блок-схемой , функциональной блок-схемой и функциональным потоком . [15]
Функциональные блок-схемы (FFBD) обычно определяют подробные, пошаговые последовательности операций и поддержки систем , но они также эффективно используются для определения процессов при разработке и производстве систем. также В процессах разработки программного обеспечения широко используются FFBD. В контексте системы этапы функционального потока могут включать в себя комбинации аппаратного обеспечения , программного обеспечения , персонала , средств и/или процедур.
В методе FFBD функции организованы и изображены в соответствии с их логическим порядком выполнения. Каждая функция показана с точки зрения ее логической связи с выполнением и завершением других функций. Узел, помеченный именем функции, отображает каждую функцию. Стрелки слева направо показывают порядок выполнения функций. Логические символы обозначают последовательное или параллельное выполнение функций. [16]
HIPO и oPO [ править ]
HIPO для иерархического ввода-вывода процесса - это популярное системного анализа 1970-х годов. средство проектирования и документирования [17] для представления модулей системы в виде иерархии и документирования каждого модуля. [18]
Он использовался для разработки требований, проектирования и поддержки внедрения экспертной системы для демонстрации автоматизированного рандеву. Затем проверка проводилась систематически в зависимости от метода проектирования и реализации. [19]
Общая конструкция системы документируется с помощью диаграмм HIPO или структурных диаграмм . Структурная диаграмма внешне похожа на организационную диаграмму, но была изменена для отображения дополнительных деталей. Структурные диаграммы можно использовать для отображения нескольких типов информации, но чаще всего они используются для диаграмм структур данных или структур кода. [18]
Н 2 График [ править ]
Затем 2 Диаграмма — это диаграмма в форме матрицы , представляющая функциональные или физические интерфейсы между элементами системы. Он используется для систематической идентификации, определения, табулирования, проектирования и анализа функциональных и физических интерфейсов. Это относится к системным интерфейсам , а также к аппаратным и/или программным интерфейсам. [14]
Затем 2 Диаграмма широко использовалась для разработки интерфейсов данных, в первую очередь в области программного обеспечения . Однако его также можно использовать для разработки аппаратных интерфейсов. Базовый Н 2 Схема представлена на рисунке 2. Функции системы расположены по диагонали; Остальные квадраты в матрице N × N представляют собой входы и выходы интерфейса. [20]
анализа и Техника проектирования структурированного
Техника структурированного анализа и проектирования (SADT) — это методология разработки программного обеспечения для описания систем как иерархии функций, схематической записи для построения эскиза программного приложения. Он предлагает строительные блоки для представления сущностей и действий, а также различные стрелки для связи блоков. Эти прямоугольники и стрелки имеют связанную с ними неформальную семантику . [21] SADT можно использовать как инструмент функционального анализа данного процесса с использованием последовательных уровней детализации. Метод SADT позволяет определить потребности пользователей в ИТ-разработках, которые используются в промышленных информационных системах, а также объяснить и представить производственные процессы и процедуры деятельности. [22]
SADT обеспечивает конкретное функциональное представление любого предприятия, описывая функции и их взаимоотношения в компании. Эти функции выполняют такие задачи компании, как продажи, планирование заказов, проектирование продукции, производство деталей и управление человеческими ресурсами. SADT может отображать простые функциональные взаимосвязи и отражать взаимосвязи данных и потоков управления между различными функциями. Формализм IDEF0 основан на SADT, разработанном Дугласом Т. Россом в 1985 году. [23]
IDEF0 [ править ]
IDEF0 — это методология функционального моделирования для описания производственных функций, которая предлагает язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем ; деловые процессы; или инженерный анализ программного обеспечения. [24] Он является частью семейства языков моделирования IDEF в области разработки программного обеспечения и построен на базе языка функционального моделирования SADT .
Метод функционального моделирования IDEF0 предназначен для моделирования решений, действий и деятельности организации или системы. [25] Он был основан на общепринятой методике структурного анализа и проектирования языка графического моделирования (SADT), разработанной Дугласом Т. Россом и SofTech, Inc. В своей исходной форме IDEF0 включает в себя как определение языка графического моделирования ( синтаксис и семантика ), так и описание комплексной методологии разработки моделей. [1] ВВС США поручили разработчикам SADT разработать метод функциональной модели для анализа и передачи функциональной точки зрения системы. IDEF0 должен помочь в организации системного анализа и способствовать эффективной коммуникации между аналитиком и заказчиком посредством упрощенных графических устройств. [25]
Аксиоматический дизайн [ править ]
Аксиоматическое проектирование — это иерархический процесс функциональной декомпозиции сверху вниз, используемый в качестве структуры синтеза решений для анализа, разработки, реинжиниринга и интеграции продуктов, информационных систем, бизнес-процессов или решений для разработки программного обеспечения. [26] Его структура математически подходит для анализа связи между функциями с целью оптимизации архитектурной устойчивости потенциальных моделей функциональных решений.
Сопутствующие типы моделей [ править ]
В области системной и программной инженерии были определены многочисленные конкретные функции и функциональные модели, а также близкородственные модели. Здесь будут объяснены лишь некоторые общие типы.
Модель бизнес-функции [ править ]
Модель бизнес-функции (BFM) — это общее описание или категория операций, которые регулярно выполняются для выполнения миссии организации. Они «обеспечивают концептуальную структуру для определения общих бизнес-функций ». [27] Он может показать критические бизнес-процессы в контексте функций бизнес-сферы. Процессы в модели бизнес-функции должны быть согласованы с процессами в моделях цепочки создания стоимости. Процессы — это группа взаимосвязанных бизнес-операций, выполняемых для производства конечного продукта или предоставления услуги. В отличие от бизнес-функций, которые выполняются на постоянной основе, процессы характеризуются тем, что у них есть определенное начало и конечная точка, отмеченная получением желаемого результата. На рисунке справа изображена взаимосвязь между бизнес-процессами, бизнес-функциями и эталонной бизнес-моделью бизнес-сферы. [28]
Модель бизнес- обозначения процесса и
Модель и нотация бизнес-процессов (BPMN) — это графическое представление для описания бизнес-процессов в рабочем процессе . BPMN была разработана Инициативой управления бизнес-процессами (BPMI) и в настоящее время поддерживается Object Management Group с момента слияния двух организаций в 2005 году. Текущая версия BPMN — 2.0. [29]
Спецификация модели и нотации бизнес-процессов (BPMN) предоставляет графическую нотацию для определения бизнес-процессов в диаграмме бизнес-процессов (BPD). [30] Цель BPMN — поддержать управление бизнес-процессами как для технических пользователей, так и для бизнес-пользователей, предоставляя нотацию, интуитивно понятную для бизнес-пользователей, но способную представить сложную семантику процессов. Спецификация BPMN также обеспечивает сопоставление графики нотации с базовыми конструкциями языков исполнения, в частности BPEL4WS . [31]
Эталонная бизнес-модель [ править ]
Справочная модель бизнеса — это эталонная модель, концентрирующая внимание на функциональных и организационных аспектах деятельности предприятия основной , обслуживающей организации или государственного учреждения . В проектировании предприятия эталонная бизнес-модель является частью структуры архитектуры предприятия или рамки архитектуры , которая определяет, как организовать структуру и представления , связанные с архитектурой предприятия .
Эталонная модель в целом — это модель чего-то, которая воплощает основную цель или идею чего-то и может затем рассматриваться как эталон для различных целей. Справочная бизнес-модель — это средство описания бизнес-операций организации независимо от организационной структуры , которая их выполняет. Другие типы эталонной бизнес-модели также могут отображать взаимосвязь между бизнес-процессами , бизнес-функциями и бизнес-области эталонной бизнес-моделью . Эти эталонные модели могут быть построены по уровням и служить основой для анализа компонентов услуг, технологий, данных и производительности.
Модель операторной функции [ править ]
Модель операторных функций (OFM) предлагается в качестве альтернативы традиционным методам анализа задач , используемым инженерами по человеческому фактору . Модель операторских функций пытается представить в математической форме, как оператор может разложить сложную систему на более простые части и координировать действия по управлению и конфигурации системы так, чтобы была достигнута приемлемая общая производительность системы. Модель представляет основные вопросы представления знаний, потока информации и принятия решений в сложных системах. Миллер (1985) предполагает, что сетевую структуру можно рассматривать как возможное представление внутренней модели системы оператора плюс структуру управления, которая определяет, как модель используется для решения проблем принятия решений, которые включают в себя функции операторского управления. [32]
См. также [ править ]
- Функциональная модель шины
- Моделирование бизнес-процессов
- Визуализация данных и информации
- Модель данных
- Моделирование предприятия
- Функциональная архитектура программного обеспечения
- Многоуровневое моделирование потоков
- Модель полиномиальной функции
- Рациональная функциональная модель
- Научное моделирование
- Единый язык моделирования
- Посмотреть модель
Ссылки [ править ]
Эта статья включает общедоступные материалы Национального института стандартов и технологий.
В этой статье использованы общедоступные материалы из Модель операторных функций (OFM) . Федеральная авиационная администрация .
- ^ Перейти обратно: а б Публикация FIPS 183. Архивировано 27 февраля 2009 г. на сайте Wayback Machine , выпущенном IDEFØ в декабре 1993 г. Лабораторией компьютерных систем Национального института стандартов и технологий (NIST).
- ^ Руководство читателя по функциональным моделям IDEF0 . По состоянию на 27 ноября 2008 г.
- ^ Бен Б. Грэм (2002). Подробная схема процесса . п.2.
- ^ Шлагер, Дж. (июль 1956 г.). «Системная инженерия: ключ к современному развитию». IRE-транзакции . ЭМ-3 (3): 64–66. дои : 10.1109/IRET-EM.1956.5007383 . S2CID 51635376 .
- ^ Артур Д. Холл (1962). Методология системной инженерии . Ван Ностранд Рейнхольд. ISBN 0-442-03046-0 .
- ^ Уильям Гослинг (1962) Проектирование инженерных систем . п. 23
- ^ Тим Вейлкиенс (2008). Системное проектирование с использованием SysML/UML: моделирование, анализ, проектирование . Страница 287.
- ^ Гарольд Честнат (1967). Методы системной инженерии . Страница 254.
- ^ Томас Дюфрен и Джеймс Мартин (2003). «Моделирование процессов для электронного бизнеса». Архивировано 20 декабря 2006 г. в Wayback Machine . INFS 770 Методы проектирования информационных систем: управление знаниями и электронный бизнес. Весна 2003 г.
- ^ Перспективы процесса . В: Метамоделирование и разработка методов , Минна Коскинен, 2000.
- ^ Джеймс Пероццо (1994) Полное руководство по устранению неполадок электроники . п. 72
- ^ Уильям Х. Фон Альвен (1964) Инженерия надежности объясняет: «Функциональные блок-схемы показывают функциональные последовательности и пути сигналов, а элементы, подключенные параллельно, рисуются параллельно» (стр. 286)
- ^ Основы системной инженерии. Архивировано 27 сентября 2007 г. в издательстве Wayback Machine Defense Acquisition University Press, 2001 г.
- ^ Перейти обратно: а б Первая версия этой статьи полностью основана на РУКОВОДСТВЕ ПО РАЗРАБОТКЕ СИСТЕМЫ NAS, РАЗДЕЛ 4.4, ВЕРСИЯ 3.1 от 06.06.06.
- ^ Инструменты анализа задач, используемые на протяжении всей разработки . FAA 2008. Проверено 25 сентября 2008 г.
- ^ ФАУ (2006). РУКОВОДСТВО ПО ПРОЕКТИРОВАНИЮ СИСТЕМЫ NAS, РАЗДЕЛ 4.4, ВЕРСИЯ 3.1, 06.06.06.
- ^ Корпорация IBM (1974). HIPO — средство проектирования и документирования , номер публикации GC20-1851, IBM Corporation, Уайт-Плейнс, Нью-Йорк, 1974.
- ^ Перейти обратно: а б Сандианские национальные лаборатории (1992). Рекомендации Sandia по программному обеспечению, том 5, инструменты, методы и методологии. Архивировано 25 августа 2009 г. в Wayback Machine. ОТЧЕТЫ SANDIA 85–2348qUC–32.
- ^ Мэри Энн Гудвин и Чарльз К. Робертсон (1986). ПРОБЛЕМЫ ПРОВЕРКИ ЭКСПЕРТНОЙ СИСТЕМЫ В СРЕДЕ ОПЕРАЦИОННОЙ ДЕЯТЕЛЬНОСТИ . Документ НАСА N88-17234.
- ^ Перейти обратно: а б НАСА (1995). «Методы функционального анализа». В: Справочник по системному проектированию НАСА. Архивировано 17 декабря 2008 г. в Wayback Machine, июнь 1995 г., стр. 142.
- ^ Джон Милопулос (2004). Концептуальное моделирование III. Методика структурного анализа и проектирования (SADT) . Проверено 21 сентября 2008 г.
- ^ SADT на Free-Logistics.com. Проверено 21 сентября 2008 г.
- ^ Гавриэль Салвенди (2001). Справочник по промышленной инженерии: технологии и управление операциями. . стр.508.
- ^ Основы системной инженерии. Архивировано 27 сентября 2007 года в издательстве Wayback Machine Defense Acquisition University Press, 1999.
- ^ Перейти обратно: а б Варун Гровер , Уильям Дж. Кеттингер (2000). Процессное мышление: выигрышные перспективы изменения бизнеса в век информации. стр.168.
- ^ Су (1999). Аксиоматический дизайн: достижения и приложения, Oxford University Press, 2001, ISBN 0-19-513466-4
- ^ Пол Грефен (2010) Освоение электронного бизнеса . п. 5-10
- ^ Министерство внутренних дел США (2000–2008) Анализ бизнеса и определение целевой бизнес-среды . По состоянию на 27 ноября 2008 г.
- ^ «Информация о BPMN» . Архивировано из оригинала 18 декабря 2008 г. Проверено 2 ноября 2008 г.
- ^ Ричард К. Симпсон (2004). XML-представление процедур экипажа . Заключительный отчет Программа стипендий преподавателей НАСА – 2004 г. Космический центр Джонсона.
- ^ С.А. Уайт, «Нотация моделирования бизнес-процессов (BPMN)», В: Инициатива управления бизнес-процессами (BPMI) , 3 мая 2004 г.
- ^ Модель операторских функций (OFM). Архивировано 21 января 2009 г. в Wayback Machine . По состоянию на 27 ноября 2008 г.
