Функциональная модель - Function model

В системная инженерия, программная инженерия, и Информатика, а функциональная модель или же функциональная модель является структурированным представлением функции (виды деятельности, действия, процессы, операции ) в смоделированном система или предметной области.[1]

Пример функциональной модели процесса «Обслуживание ремонтопригодных запчастей» в IDEF0 обозначение.

Функциональная модель, похожая на модель деятельности или же модель процесса, является графическим представлением предприятие функция в определенной области. Целью функциональной модели является описание функций и процессов, помощь в обнаружении информационных потребностей, помощь в выявлении возможностей и создание основы для определения стоимости продуктов и услуг.[2]

История

Функциональная модель в области системной инженерии и разработки программного обеспечения возникла в 1950-х и 1960-х годах, но происхождение функционального моделирования организационной деятельности восходит к концу XIX века.

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

Возникновение области системная инженерия можно проследить до Bell Telephone Laboratories в 1940-е гг.[4] Необходимость идентифицировать и управлять свойствами системы в целом, которые в сложных инженерных проектах могут сильно отличаться от суммы свойств частей, побудила различные отрасли промышленности применять эту дисциплину.[5] Одним из первых, кто определил функциональную модель в этой области, был британский инженер. Уильям Гослинг. В его книге Проектирование инженерных систем (1962, с. 25) он заявил:

Таким образом, функциональная модель должна достигать двух целей, чтобы быть полезной. Он должен предоставлять механизм описания пропускной способности, способный полностью определять первое и последнее состояния пропускной способности и, возможно, некоторые из промежуточных состояний. Он также должен предлагать некоторые средства, с помощью которых любой ввод, правильно описанный в терминах этой механики, может быть использован для генерации вывода, который является столь же правильным описанием вывода, который фактическая система дала бы для рассматриваемого ввода. Также можно отметить, что есть две другие вещи, которые может выполнять функциональная модель, но которые не являются необходимыми для всех функциональных моделей. Таким образом, такая система может, но не обязательно, описывать пропускную способность системы, отличную от входной и выходной, а также может содержать описание операции, которую каждый элемент выполняет над пропускной способностью, но, опять же, это не так.[6]

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

Темы функционального моделирования

Функциональная перспектива

В системная инженерия и программная инженерия функциональная модель создается с функциональным перспектива моделирования. Функциональная перспектива - одна из возможных в моделирование бизнес-процессов другие точки зрения могут быть, например, поведенческими, организационными или информационными.[10]

Перспектива функционального моделирования сосредоточена на описании динамический процесс. Основное понятие в этой перспективе моделирования - процесс, это может быть функция, преобразование, действие, действие, задача и т. Д. Хорошо известным примером языка моделирования, использующего эту перспективу, является диаграммы потоков данных.

В перспективе используются четыре символа для описания процесса, а именно:

  • Процесс: иллюстрирует преобразование от ввода к выводу.
  • Магазин: Сборник данных или какой-то материал.
  • Поток: движение данных или материала в процессе.
  • Внешний объект: внешний по отношению к смоделированной системе, но взаимодействующий с ней.

Теперь с помощью этих символов процесс можно представить как сеть этих символов. Этот разложенный процесс представляет собой DFD, диаграмму потока данных.

Пример функциональной декомпозиции в системном анализе.

В Динамическое моделирование предприятия разделение происходит в Модель управления, Функциональная модель, Модель процесса и Организационная модель.

Функциональная декомпозиция

Функциональная декомпозиция в широком смысле относится к процессу разрешения функциональный отношения на его составные части таким образом, что исходная функция может быть восстановлена ​​из этих частей с помощью функциональная композиция. В общем, этот процесс декомпозиции предпринимается либо с целью получить представление об идентичности составляющих компонентов, либо с целью получения сжатого представления глобальной функции, задача, которая выполнима только тогда, когда составляющие процессы обладают определенный уровень модульность.

Функциональная декомпозиция играет важную роль в компьютерное программирование, где главная цель - модулировать процессы в максимально возможной степени. Например, система управления библиотекой может быть разделена на модуль инвентаризации, модуль информации о посетителях и модуль оценки платы. В первые десятилетия компьютерного программирования это проявилось как «искусство подпрограмм», как его называли некоторые выдающиеся практики.

Функциональная декомпозиция инженерных систем - это метод анализа инженерных систем. Основная идея состоит в том, чтобы попытаться разделить систему таким образом, чтобы каждый блок блок-схемы можно было описать без «и» или «или» в описании.

Это упражнение заставляет каждую часть системы иметь чистый функция. Когда система состоит из чистых функций, их можно использовать повторно или заменить. Обычным побочным эффектом является то, что интерфейсы между блоками становятся простыми и универсальными. Поскольку интерфейсы обычно становятся простыми, проще заменить чистую функцию связанной, аналогичной функцией.

Методы функционального моделирования

Функциональный подход расширен несколькими схемами и нотациями моделирования. В этом разделе дается обзор важных техник в хронологическом порядке.

Функциональная блок-схема

Функциональная блок-схема системы электроники ориентации и маневрирования Космический корабль Gemini. Июнь 1962 г.

А функциональная блок-схема это блок-схема, который описывает функции и взаимосвязи система. Функциональная блок-схема может изображать:[11]

  • Функции системы, изображенной блоками
  • Элементы ввода и вывода блока, изображенные линиями, и
  • Отношения между функциями
  • Функциональные последовательности и пути для материи и / или сигналов[12]

Блок-диаграмма может использовать дополнительные символы схемы, чтобы показать определенные свойства.

Конкретная функциональная блок-схема является классической функциональная блок-схема, а Схема функциональных блоков (FBD) используется в конструкции программируемые логические контроллеры.

Функциональная блок-схема

Функциональная блок-схема формат.[13]

В функциональная блок-схема (FFBD) - многоуровневый, последовательный, пошаговый схема из система Функциональный поток.[14]Диаграмма разработана в 1950-х годах и широко используется в классической системная инженерия. Функциональная блок-схема также упоминается как Функциональная блок-схема, функциональная блок-схема, и функциональный поток.[15]

Блок-схемы функциональных потоков (FFBD) обычно определяют подробные, пошаговые рабочие и вспомогательные последовательности для системы, но они также эффективно используются для определения процессы в разработке и производстве систем. В процессы разработки программного обеспечения также широко используют FFBD. В контексте системы этапы функционального потока могут включать в себя комбинации аппаратное обеспечение, программного обеспечения, персонал, помещения и / или процедуры.

В методе FFBD функции организованы и изображены в соответствии с их логическим порядком выполнения. Каждая функция показана с точки зрения ее логической связи с выполнением и завершением других функций. Узел, помеченный именем функции, отображает каждую функцию. Стрелки слева направо показывают порядок выполнения функций. Логические символы представляют собой последовательное или параллельное выполнение функций.[16]

HIPO и oPO

Расширенный Модель IPO.

HIPO за иерархический процесс ввода вывода это популярный 1970-е системный анализ помощь в проектировании и документация[17] для представления модулей система как иерархия и для документирования каждого модуля.[18]

Он использовался для разработки требований, построения дизайна и поддержки внедрения экспертной системы для демонстрации автоматизированного рандеву. Затем проверка проводилась систематически из-за метода разработки и реализации.[19]

Общий дизайн системы документируется с использованием диаграмм HIPO или структурные диаграммы. Структурная диаграмма внешне похожа на организационную диаграмму, но была изменена для отображения дополнительных деталей. Структурные диаграммы могут использоваться для отображения нескольких типов информации, но чаще всего используются для построения диаграмм. структуры данных или структуры кода.[18]

Диаграмма N2

Рисунок 2. Определение диаграммы N2.[20]

В Диаграмма N2 представляет собой диаграмму в виде матрица, представляющие функциональные или физические интерфейсы между элементами системы. Он используется для систематической идентификации, определения, табулирования, проектирования и анализа функциональных и физических интерфейсов. Это относится к системе интерфейсы и аппаратное обеспечение и / или программного обеспечения интерфейсы.[14]

Диаграмма N2 широко использовалась для разработки интерфейсов данных, в основном в программного обеспечения области. Однако его также можно использовать для разработки аппаратных интерфейсов. Базовая схема N2 показана на рисунке 2. Системные функции расположены по диагонали; остальные квадраты в матрице N x N представляют входы и выходы интерфейса. [20]

Структурированный анализ и методика проектирования

Базовый элемент SADT.

Структурированный анализ и методика проектирования (SADT) - это методология программной инженерии для описания системы как иерархия функций, схематический обозначение для построения эскиза программного приложения. Он предлагает строительные блоки для представления сущностей и действий, а также множество стрелок для связи прямоугольников. Эти прямоугольники и стрелки имеют связанный неформальный семантика.[21] SADT может использоваться как инструмент функционального анализа данного процесса с использованием последовательных уровней детализации. Метод SADT позволяет определить потребности пользователей в ИТ-разработках, которые используются в промышленных информационных системах, а также объяснить и представить производственные процессы и процедуры деятельности.[22]

SADT предоставляет конкретное функциональное представление о любом предприятии, описывая функции и их отношения в компании. Эти функции выполняют цели компании, такие как продажи, планирование заказов, проектирование продукции, изготовление деталей и управление человеческими ресурсами. SADT может отображать простые функциональные взаимосвязи и может отражать взаимосвязи между данными и потоками управления между различными функциями. В IDEF0 формализм основан на SADT, разработанном Дуглас Т. Росс в 1985 г.[23]

IDEF0

IDEF0 Пример диаграммы

IDEF0 это функциональное моделирование методика описания производство функции, предлагающие функциональные язык моделирования для анализа, разработки, реинжиниринга и интеграции информационные системы; деловые процессы; или программный инженерный анализ.[24] Это часть IDEF семейство языков моделирования в области программная инженерия, и построен на построении языка функционального моделирования SADT.

Метод функционального моделирования IDEF0 разработан для моделирования решений, действий и действий организации или системы.[25] Он был заимствован из устоявшегося языка графического моделирования структурированный анализ и методика проектирования (SADT) разработан Дуглас Т. Росс и SofTech, Inc.. В исходной форме IDEF0 включает в себя как определение языка графического моделирования (синтаксис и семантика ) и описание комплексной методологии разработки моделей.[1] Военно-воздушные силы США поручили разработчикам SADT разработать метод функциональной модели для анализа и передачи функциональной перспективы системы. IDEF0 должен помочь в организации системного анализа и способствовать эффективному общению между аналитиком и заказчиком с помощью упрощенных графических устройств.[25]

Аксиоматический дизайн

Аксиоматический дизайн представляет собой процесс иерархической функциональной декомпозиции сверху вниз, используемый в качестве основы синтеза решений для анализа, разработки, реинжиниринга и интеграции продуктов, информационных систем, бизнес-процессов или программных инженерных решений.[26] Его структура математически подходит для анализа взаимосвязи между функциями с целью оптимизации архитектурной устойчивости потенциальных моделей функциональных решений.

Связанные типы моделей

В области системной и программной инженерии были определены многочисленные конкретные функции и функциональные модели, а также близкие к ним модели. Здесь будет объяснено лишь несколько общих типов.

Модель бизнес-функции

А Модель бизнес-функции (BFM) - это общее описание или категория операций, выполняемых в плановом порядке для выполнения миссии организации. Они "обеспечивают концептуальную структуру для определения общих бизнес-функции ".[27] Он может показать критические деловые процессы в контексте функций бизнес-направления. Процессы в модели бизнес-функций должны согласовываться с процессами в моделях цепочки создания стоимости. Процессы - это группа связанных бизнес-операций, выполняемых для производства конечного продукта или предоставления услуги. В отличие от бизнес-функций, которые выполняются на постоянной основе, процессы характеризуются тем, что у них есть конкретное начало и конечная точка, отмеченная достижением желаемого результата. На рисунке справа показана взаимосвязь между бизнес-процессами, бизнес-функциями и эталонной бизнес-моделью бизнес-области.[28]

Модель и обозначение бизнес-процесса

Обозначение моделирования бизнес-процессов Пример.

Модель и обозначение бизнес-процесса (BPMN) - это графическое представление для уточнения деловые процессы в рабочий процесс. BPMN была разработана Инициатива по управлению бизнес-процессами (BPMI), и в настоящее время поддерживается Группа управления объектами поскольку две организации объединились в 2005 году. Текущая версия BPMN - 2.0.[29]

Спецификация модели и нотации бизнес-процессов (BPMN) предоставляет графическую нотацию для определения деловые процессы в Схема бизнес-процесса (БЛД).[30] Цель BPMN - поддерживать управление бизнес-процессами как для технических пользователей, так и для бизнес-пользователей, предоставляя нотацию, интуитивно понятную для бизнес-пользователей, но способную представить сложную семантику процесса. Спецификация BPMN также обеспечивает сопоставление графики нотации с базовыми конструкциями языков исполнения, в частности BPEL4WS.[31]

Эталонная бизнес-модель

Это ВЭД Эталонная бизнес-модель изображает взаимосвязь между бизнес-процессами, бизнес-функциями и эталонной бизнес-моделью бизнес-области.

А Эталонная бизнес-модель эталонная модель, в которой основное внимание уделяется функциональным и организационным аспектам основной бизнес из предприятие, сервисная организация или же государственное агентство. В корпоративной инженерии эталонная бизнес-модель является частью Структура архитектуры предприятия или же Архитектура Framework, который определяет, как организовать структуру и взгляды связанный с Архитектура предприятия.

А эталонная модель в общем, это модель чего-то, которая воплощает основную цель или идею чего-либо и может затем рассматриваться как эталон для различных целей. Справочная бизнес-модель - это средство для описания деловые операции организации, независимой от организационная структура которые их выполняют. Другие типы справочной бизнес-модели также могут отображать взаимосвязь между деловые процессы, бизнес-функции и сфера бизнеса Справочная бизнес-модель. Эта эталонная модель может быть построена по слоям и служить основой для анализа компонентов службы, технологий, данных и производительности.

Модель функции оператора

В Модель функции оператора (OFM) предлагается как альтернатива традиционным анализ задачи методы, используемые человеческие факторы инженеры. Модель операторной функции пытается представить в математической форме, как оператор может разложить сложную систему на более простые части и координировать управляющие воздействия и конфигурации системы, чтобы достичь приемлемой общей производительности системы. Модель представляет основные вопросы представления знаний, информационного потока и принятия решений в сложных системах. Миллер (1985) предполагает, что структуру сети можно рассматривать как возможное представление оператора внутренняя модель системы плюс структура управления, которая определяет, как модель используется для решения задач принятия решений, которые включают функции управления оператором.[32]

Смотрите также

Рекомендации

Эта статья включаетматериалы общественного достояния от Национальный институт стандартов и технологий интернет сайт https://www.nist.gov.

Эта статья включаетматериалы общественного достояния от Федеральная авиационная администрация документ: «Модель операторных функций (OFM)».

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