Функциональная модель
Функциональная модель или функциональная модель в системной инженерии и программной инженерии представляет собой структурированное представление функций (действий , процессов, операций ) в моделируемой системе или предметной области.
Функциональная модель, аналогичная модели деятельности или модели процесса, представляет собой графическое представление функции предприятия в определенной области. Целью функциональной модели является описание функций и процессов, помощь в выявлении информационных потребностей, помощь в определении возможностей и создание основы для определения затрат на продукцию и услуги.
История[править]
Функциональная модель в области системной инженерии и программной инженерии берет свое начало в 1950-х и 1960-х годах, но происхождение функционального моделирования организационной деятельности восходит к концу 19 века.
В конце 19-го века появились первые диаграммы, изображающие бизнес-деятельность, действия, процессы или операции, а в первой половине 20-го века появились первые структурированные методы документирования бизнес-процессов. Одним из таких методов была технологическая схема , представленная Фрэнком Гилбретом членам американского общества инженеров—механиков (ASME) в 1921 году с презентацией под названием “технологические схемы-первые шаги в поиске наилучшего способа”. инструменты Гилбрета быстро нашли свой путь в учебные планы промышленной инженерии.
Появление области системной инженерии можно проследить до Bell Telephone Laboratories в 1940-х годах. [4] необходимость выявления и манипулирования свойствами системы в целом, которые в сложных инженерных проектах могут существенно отличаться от суммы свойств деталей, побудила различные отрасли промышленности применять данную дисциплину. одним из первых, кто определил функциональную модель в этой области, был британский инженер Уильям Гослинг . В книге "проектирование инженерных систем" (1962, С. 25) он заявил::
- Таким образом, функциональная модель должна достигать двух целей, чтобы быть полезной. Он должен предоставлять механику описания пропускной способности, способную полностью определять первое и последнее состояния пропускной способности и, возможно, некоторые промежуточные состояния. Он должен также предложить некоторые средства, с помощью которых любой ввод, правильно описанный в терминах этой механики, может быть использован для создания вывода, который является столь же правильным описанием вывода, который фактическая система дала бы для соответствующего ввода. Можно также отметить, что есть две другие вещи, которые функциональная модель может сделать, но которые не являются необходимыми для всех функциональных моделей. Таким образом, такая система может, но не обязательно, описывать пропускные способности системы, отличные от входных и выходных данных, и она может также содержать описание операции, которую каждый элемент выполняет над пропускной способностью, но опять же это не так.
Одной из первых четко определенных функциональных моделей была функциональная блок-схема потока (FFBD), разработанная TRW, связанной с защитой, включенной в 1950-е годы. в 1960-х годах он был использован НАСА для визуализации временной последовательности событий в космических системах и полетных миссиях. это далее широко используется в классическом системном проектировании, чтобы показать заказ выполнения системных функций.
Функциональные темы моделирования[править]
Функциональная перспектива[править]
В системной инженерии и программной инженерии функциональная модель создается с перспективой функционального моделирования . Функциональная перспектива является одной из перспектив, возможных в моделировании бизнес-процессов, другие перспективы, например, поведенческие, организационные или информационные.
Функциональная перспектива моделирования концентрируется на описании динамического процесса . Основная концепция в этой перспективе моделирования-это процесс, это может быть функция, преобразование, активность, действие, задача и т. д. Хорошо известным примером языка моделирования, использующего эту перспективу, являются диаграммы потоков данных .
Перспектива использует четыре символа для описания процесса.:
- Процесс: иллюстрирует преобразование от входа к выходу.
- Хранилище: сбор данных или какой-либо материал.
- Поток: перемещение данных или материала в процессе.
- Внешний объект: внешний по отношению к моделируемой системе, но взаимодействует с ней.
Теперь, с этими символами, процесс может быть представлен как сеть этих символов. Этот разложенный процесс представляет собой диаграмму потока данных DFD.
В динамическом моделировании предприятия производится разделение на модель управления, функциональную модель, модель процесса и организационную модель .
Функциональная декомпозиция[править]
Функциональное разложение относится в широком смысле к процессу разрешения функционального отношения на его составные части таким образом, что исходная функция может быть восстановлена из этих частей по составу функции . В общем случае, этот процесс декомпозиции осуществляется либо с целью получения представления о тождестве составляющих компонентов, либо с целью получения сжатого представления глобальной функции, задача которого выполнима только тогда, когда составляющие процессы обладают определенным уровнем модульности .
Функциональная декомпозиция играет важную роль в компьютерном программировании , где главная цель состоит в том, чтобы максимально модулировать процессы. Например, система управления библиотекой может быть разбита на модуль инвентаризации, модуль информации о клиенте и модуль оценки платы. В первые десятилетия компьютерного программирования это проявилось как "искусство подгруппировки", как его называли некоторые видные практики.
Функциональная декомпозиция инженерных систем-метод анализа инженерных систем. Основная идея состоит в том, чтобы попытаться разделить систему таким образом, чтобы каждый блок структурной схемы мог быть описан без "и" или "или" в описании.
Это упражнение заставляет каждую часть системы выполнять чистую функцию . Когда система составлена чисто функций, их можно повторно использовать, или заменить. Обычный побочный эффект заключается в том, что интерфейсы между блоками становятся простыми и универсальными. Поскольку интерфейсы обычно становятся простыми, легче заменить чистую функцию связанной аналогичной функцией.
Методы функционального моделирования[править]
Функциональный подход расширен в многократных схематических методах и моделирующих примечаниях. В этом разделе дается обзор важных методов в хронологическом порядке.
Функциональная блок схема[править]
Функциональная блок-схема-блок-схема, которая описывает функции и взаимосвязи системы . Функциональная блок-схема может изобразить:
- Функции системы, изображенной блоками
- Входные и выходные элементы блока, изображенного линиями, и
- Отношения между функциями
- Функциональные последовательности и пути для материи и / или сигналов
Блок-схема может использовать дополнительные условные обозначения для отображения определенных свойств.
Специфическая блок-схема функции классическая функциональная блок-схема подачи, и блок-схема функции (FBD) используемая в конструкции programmable регуляторов логики .
Функциональная блок схема потока[править]
Функциональная блок-схема потока (FFBD) представляет собой многоуровневую, последовательную по времени, пошаговую блок-схему функционального потока системы. Схема разработана в 1950-х годах и широко используется в классической системной инженерии . Функциональная блок-схема потока также упоминается как функциональная блок-схема потока , функциональная блок-схема и функциональный поток .
Функциональные блок-схемы потока (FFBD) обычно определяют подробные, пошаговые последовательности операций и поддержки для систем , но они также эффективно используются для определения процессов разработки и производства систем. Процессы разработки программного обеспечения также широко используют FFBDs. В контексте системы этапы функционального потока могут включать в себя комбинации аппаратных средств , программного обеспечения , персонала , средств и/или процедур.
В методе FFBD функции организованы и изображены их логическим порядком выполнения. Каждая функция показана относительно ее логической связи с выполнением и завершением других функций. Узел, помеченный именем функции, отображает каждую функцию. Стрелки слева направо показывают порядок выполнения функций. Логические символы представляют последовательное или параллельное выполнение функций.
HIPO и oPO[править]
HIPO для иерархического ввода вывода процесса-популярная помощь системного анализа 1970-х годов и метод документации для представления модулей системы как иерархии и для документирования каждого модуля.
Он был использован для разработки требований, построения проекта и поддержки внедрения экспертной системы для демонстрации автоматизированного рандеву. Затем проверка проводилась систематически в соответствии с методом разработки и осуществления.
Общий дизайн системы документируется с использованием диаграмм HIPO или структурных диаграмм . Структурная диаграмма похожа по внешнему виду на организационную диаграмму, но была изменена, чтобы показать дополнительные детали. Структурные диаграммы могут использоваться для отображения нескольких типов информации, но чаще всего используются для построения структур данных или структур кода.
N2 диаграмма[править]
Диаграмма N2 представляет собой диаграмму в форме матрицы, представляющую функциональные или физические интерфейсы между элементами системы. Он используется для систематического определения, определения, табулирования, проектирования и анализа функциональных и физических интерфейсов. Оно применяется к интерфейсам системы и интерфейсам оборудования и/или програмного обеспечения.
Диаграмма N2 широко используется для разработки интерфейсов данных, прежде всего в области программного обеспечения. Однако его также можно использовать для разработки аппаратных интерфейсов. Базовая диаграмма N2 показана на рисунке 2. Системные функции располагаются по диагонали, остальные квадраты в матрице N x N представляют входы и выходы интерфейса.
Структурированный анализ и техника проектирования[править]
Structured Analysis and Design Technique (SADT) - методология разработки программного обеспечения для описания систем как иерархии функций, схематическое обозначение для построения эскиза программного приложения. Он предлагает строительные блоки для представления объектов и действий, а также различные стрелки для связывания ящиков. Эти коробки и стрелки имеют связанную неофициальную семантику .SADT можно использовать как инструмент функционального анализа данного процесса, используя последовательные уровни детализации. Метод SADT позволяет определить потребности пользователей в ИТ-разработках, используемых в промышленных информационных системах, а также объяснить и представить производственные процессы, процедуры деятельности.
SADT поставляет специфический функциональный взгляд любого предпринимательства путем описывать функции и их отношения в компании. Эти функции выполняют задачи компании, такие как продажи, планирование заказов, дизайн продукта, изготовление деталей и управление персоналом. SADT может изобразить простые функциональные отношения и может отразить отношения потока данных и управления между различными функциями. Формализм IDEF0 основан на SADT, разработанном Дугласом т. Россом в 1985 году.
IDEF0[править]
IDEF0-методология моделирования функций для описания производственных функций, которая предлагает язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем ; бизнес-процессов; или анализа разработки программного обеспечения. является частью семейства языков моделирования IDEF в области программной инженерии и построен на функциональном языке моделирования построения SADT .
Метод функционального моделирования IDEF0 предназначен для моделирования решений, действий и действий организации или системы.[25] он был получен из созданного языка графического моделирования Structured Analysis and Design Technique (SADT), разработанного Douglas T. Ross и SofTech, Inc.. В своем первоначальном виде IDEF0 включает в себя как определение языка графического моделирования ( синтаксис и семантика), так и описание комплексной методологии разработки моделей.[1] ВВС США поручили разработчикам SADT разработать метод функциональной модели для анализа и передачи функциональной перспективы системы. IDEF0 должен способствовать организации системного анализа и эффективной коммуникации между аналитиком и заказчиком посредством упрощенных графических устройств.[25]
Аксиоматический дизайн[править]
Аксиоматический дизайн-это иерархический процесс функциональной декомпозиции сверху вниз, используемый в качестве основы для синтеза решений для анализа, разработки, реинжиниринга и интеграции продуктов, информационных систем, бизнес-процессов или программных решений.Его структура подходит математически, чтобы проанализировать связь между функциями, чтобы оптимизировать архитектурную надежность потенциальных функциональных моделей решения.
Связанные типы моделей[править]
В области системной и программной инженерии определены многочисленные специфические функциональные и функциональные модели, а также тесно связанные с ними модели. Здесь будет объяснено лишь несколько общих типов.
Модель бизнес функции[править]
Модель бизнес-функции (BFM) является общим описанием или категорией операций, выполняемых регулярно для выполнения миссии Организации. Они "обеспечивают концептуальную структуру для идентификации общих бизнес-функций".[27] это может показать критические бизнес-процессы в контексте функций бизнес-зоны. Процессы в бизнес-функциональной модели должны соответствовать процессам в моделях цепочек создания стоимости. Процессы-это группа связанных бизнес-операций, выполняемых для производства конечного продукта или предоставления услуги. В отличие от бизнес-функций, которые выполняются на постоянной основе, процессы характеризуются тем, что они имеют определенное начало и конечную точку, отмеченную доставкой желаемого результата. На рисунке справа показана взаимосвязь между бизнес-процессами, бизнес-функциями и бизнес-эталонной моделью бизнес-области.
Модель бизнес-процесса и нотация[править]
Модель бизнес-процессов и нотации (BPMN) - это графическое представление для указания бизнес-процессов в рабочем процессе . BPMN был разработан инициативой по управлению бизнес-процессами (BPMI) и в настоящее время поддерживается группой по управлению объектами с момента слияния двух организаций в 2005 году. Текущая версия BPMN-2.0.
Спецификация модели бизнес-процессов и нотации (BPMN) предоставляет графическую нотацию для указания бизнес-процессов в диаграмме бизнес-процессов (BPD). целью BPMN является поддержка управления бизнес-процессами как для технических пользователей, так и для бизнес-пользователей путем предоставления нотации, интуитивно понятной для бизнес-пользователей, но способной представлять сложную семантику процесса. Спецификация BPMN также обеспечивает сопоставление между графикой нотации с базовыми конструкциями языков выполнения, в частности bpel4ws .
Бизнес эталонная модель[править]
Бизнес-эталонная модель представляет собой эталонную модель, концентрирующуюся на функциональных и организационных аспектах основной деятельности предприятия , обслуживающей организации или государственного учреждения . В enterprise engineering бизнес-эталонная модель является частью структуры архитектуры предприятия или структуры архитектуры, которая определяет, как организовать структуру и представления, связанные с архитектурой предприятия .
Эталонная модель в целом-это модель чего-то, что воплощает основную цель или идею чего-то, а затем может рассматриваться как ссылка для различных целей. Бизнес-эталонная модель является средством описания бизнес-операций организации, независимо от организационной структуры, которая их выполняет. Другие типы бизнес-справочной модели могут также отображать взаимосвязь между бизнес-процессами, бизнес-функциями и бизнес-областьюбизнес-эталонная модель. Эти эталонные модели могут быть построены слоями и служить основой для анализа компонентов, технологий, данных и производительности служб.
Функциональная модель оператора[править]
Модель операторной функции (OFM) предлагается в качестве альтернативы традиционным методам анализа задач, используемым человеческими факторами инженерные кадры. Функциональная модель оператора пытается представить в математической форме, как оператор мог бы разложить сложную систему на более простые части и скоординировать действия управления и системные конфигурации так, чтобы была достигнута приемлемая общая производительность системы. Модель представляет основные вопросы представления знаний, информационного потока и принятия решений в сложных системах. Миллер (1985) предполагает, что сетевую структуру можно рассматривать как возможное представление внутренней модели оператора системы плюс структура управления, которая определяет, как модель используется для решения задач решения, которые включают функции управления оператором.