Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

История [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функциональная декомпозиция [ править ]

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

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

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

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

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

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

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

Функциональная блок-схема системы электроники ориентации и маневрирования космического корабля "Джемини" . Июнь 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 была разработана Business Process Management Initiative (BPMI) и в настоящее время поддерживается Object Management Group после слияния двух организаций в 2005 году. Текущая версия BPMN - 2.0. [29]

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

Эталонная бизнес-модель [ править ]

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

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

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

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

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

См. Также [ править ]

  • Функциональная модель автобуса
  • Моделирование бизнес-процессов
  • Модель данных
  • Моделирование предприятия
  • Функциональная архитектура программного обеспечения
  • Модель полиномиальной функции
  • Модель рациональных функций
  • Научное моделирование
  • Единый язык моделирования
  • Посмотреть модель

Ссылки [ править ]

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

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

  1. ^ a b Публикация FIPS 183, заархивированная 27 февраля 2009 г. на Wayback Machine, выпущенная IDEFØ в декабре 1993 г. Лабораторией компьютерных систем Национального института стандартов и технологий (NIST).
  2. ^ Руководство для читателя по функциональным моделям IDEF0 . По состоянию на 27 ноября 2008 г.
  3. ↑ Бен Б. Грэм (2002). Подробная диаграмма процесса . п.2.
  4. ↑ Шлагер, Дж. (Июль 1956 г.). «Системная инженерия: ключ к современному развитию». Операции IRE . ЭМ-3 (3): 64–66. DOI : 10,1109 / ИРЭТ-EM.1956.5007383 . S2CID 51635376 . 
  5. ↑ Артур Д. Холл (1962). Методология системной инженерии . Ван Ностранд Рейнхольд. ISBN 0-442-03046-0.
  6. ^ Уильям Гослинг (1962) Проектирование инженерных систем . п. 23
  7. ^ Тим Вейлкиенс (2008). Системная инженерия с SysML / UML: моделирование, анализ, дизайн . Стр. 287.
  8. ↑ Гарольд Каштан (1967). Методы системного проектирования . Стр. 254.
  9. ^ Томас Dufresne и Джеймс Мартин (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. ^ a b Первая версия этой статьи полностью основана на РУКОВОДСТВЕ ПО РАЗРАБОТКЕ СИСТЕМЫ NAS РАЗДЕЛ 4.4 ВЕРСИЯ 3.1 06.06.06.
  15. ^ Инструменты анализа задач, используемые в процессе разработки . FAA 2008. Проверено 25 сентября 2008 г.
  16. Перейти ↑ FAA (2006). NAS SYSTEM ENGINEERING РУКОВОДСТВО РАЗДЕЛ 4.4 ВЕРСИЯ 3.1 06/06/06.
  17. ^ Корпорация IBM (1974). HIPO - средство проектирования и документация , номер публикации GC20-1851, IBM Corporation, Уайт-Плейнс, Нью-Йорк, 1974.
  18. ^ а б Сандийские национальные лаборатории (1992). Руководство по программному обеспечению Sandia, том 5 «Инструменты, методы и методологии». Архивировано 25 августа 2009 г. на Wayback Machine. ОТЧЕТЫ SANDIA 85–2348qUC – 32
  19. ^ Мэри Энн Гудвин и Чарльз С. Робертсон (1986). ПРОБЛЕМЫ ЭКСПЕРТНОЙ ПРОВЕРКИ СИСТЕМЫ В ЭКСПЛУАТАЦИОННОЙ СРЕДЕ . Документ НАСА N88-17234.
  20. ^ а б НАСА (1995). «Методы функционального анализа». В: Справочник по системной инженерии НАСА. Архивировано 17 декабря 2008 г. на 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. ^ a b Варун Гровер , Уильям Дж. Кеттингер (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 . Проверено 2 ноября 2008 .
  30. ^ Ричард С. Симпсон (2004). Представление XML для процедур экипажа . Заключительный отчет Программа стипендий факультета НАСА - 2004. Космический центр Джонсона.
  31. ^ С. А. Уайт, "Нотация моделирования бизнес-процессов (BPMN)", В: Инициатива по управлению бизнес-процессами (BPMI), 3 мая 2004 г.
  32. ^ Модель функции оператора (OFM). Архивировано 21 января 2009 г. в Wayback Machine . По состоянию на 27 ноября 2008 г.