Выбор наименования контекстного блока

Рекомендуемой последовательностью действий при построении модели «с нуля» являются: формулирование цели моделирования, выбор точки зрения, определение границ моделирования. Наименование контекстного блока – функционального блока самого высокого уровня – обобщает определение границ моделирования.

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

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

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

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

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

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

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

Определение управления. Должно быть определено управление, контролирующее ход работы функционального блока. Все функциональные блоки в IDEF0 должны иметь хотя бы одно управление. Например, функциональному блоку «Сформировать отчет» может в качестве управления быть стрелка «Правила оформления отчета». В случаях, когда не ясно, относить ли стрелку к входу или к управлению, следует ее рисовать как управление. Важно помнить, что управление можно рассматривать как особую форму входа функционального блока.

Когда контекстная диаграмма представляется завершенной, попробуйте задать следующие вопросы:

Обобщает ли диаграмма моделируемый бизнес-процесс?

Согласуется ли диаграмма с границами моделирования, точкой зрения и целью моделирования?

Подходит ли выбранный уровень детализации стрелок для контекстного блока?

!	Правило. Обычно на контекстной диаграмме рекомендуется рисовать не более шести стрелок каждого типа.

Нумерация блоков и диаграмм.Все функциональные блоки IDEF0 нумеруются. В номерах допускается использование префиксов произвольной длины, но в подавляющем большинстве моделей используется префикс А. Номер блока проставляется за префиксом. Контекстный блок всегда имеет номер АО.

Префикс повторяется для каждого блока модели. Номера используются для отражения уровня декомпозиции, на котором находится блок. Блок АО декомпозируется в блоки А1, А2, A3 и т.д. А1 декомпозируется в А11, А12, А13 и т.д. А11 декомпозируется в А111, А112, А113 и т.д. Для каждого уровня декомпозиции в конец номера добавляется одна цифра.

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

При моделировании IDEF0 важно иметь в виду, что граница дочерней диаграммы есть граница родительского функционального блока. Это означает, что вся работа выполняется блоками самого нижнего уровня. В отличие от иерархии, применяемой в структурном программировании, блоки верхнего уровня не являются субъектами управления для блоков нижнего уровня. Это означает, что в IDEF0 «дети» – это те же объекты, что и их «родители», только показанные с большей детализацией.

При необходимости дальнейшей детализации отдельных процессов могут быть использованы диаграммы IDEF3.

Другие диаграммы IDEF0.В дополнение к контекстным диаграммам и диаграммам декомпозиции при разработке и представлении моделей могут применяться другие виды IDEF0-диаграмм.

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

Итак, методология функционального моделирования IDEF0 – это технология описания системы в целом как множества взаимозависимых действий, или функций. IDEF0 имеет функциональную направленность. Однако в технологии IDEF0 – функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. Одной из основных идей моделей IDEF0 является построение двух видов моделей: "как есть" и "как должно быть". Это нужно при проведении реинжиниринга бизнес-процессов организации. Кроме того, IDEF0 обеспечивает удобный язык обмена информацией о моделируемой системе. Моделировать деловой процесс в IDEF0 можно исходя из различных перспектив и временных рамок. С функциональной точки зрения можно абстрагироваться от проблем физической реализации модели.

4.4 Методология описания бизнес-процессов IDEF3

IDEF3 – способ описания процессов, позволяющий описать процесс в виде упорядоченной последовательности действий, событий с учетом объектов, имеющих непосредственное отношение к процессу.

Технология IDEF3 позволяет качественно проводить структурный анализ системы, что очень важно при системном анализе системы или процесса. Эта технология показывает временную последовательность действий в процессе, что не отражается в других технологиях. Технология хорошо приспособлена для сбора данных, требующихся для проведения того или иного действия. Также ее отличает от большинства технологий моделирования бизнес-процессов отсутствие жестких синтаксических или семантических ограничений, которые влияют на описание неполных или нецелостных систем. «Кроме того, автор модели (системный аналитик) избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области» [29]. На рис. 7 изображен пример описания процесса с использованием методологии IDEF3.

Рисунок 7 – Описание процесса в методологии IDEF3

4.4.1 Синтаксис и семантика моделей IDEF3

Основой модели IDEF3 служит сценарий процесса, который описывает последовательность действий или подпроцессов анализируемой системы. Поскольку сценарий определяет назначение и границы модели системы, необходимо тщательно проводить подбор наименования для обозначения действий. Для подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных существительных. Например, "Изготовление декораций для спектакля" или "Изменить топологию интеграционной системы нового поколения". Как уже указывалось ранее, важно определить, через кого, через какое «действующее лицо» будет рассматриваться процесс. Точка зрения для большинства моделей должна быть явным образом документирована. Обычно это название набора должностных обязанностей человека, являющегося источником информации о моделируемом процессе.

Для системного аналитика также важно понимание цели моделирования – набора вопросов, ответами на которые будет служить модель, границ моделирования (какие части системы войдут в модель, а какие не будут в ней отображены) и целевой аудитории (для кого разрабатывается модель) [29].

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

Единица работы. Действие. Аналогично другим технологиям моделрфования действие, или в терминах IDEF3 "единица работы" (Unit of Work – UOW) – другой важный компонент модели. В диаграммах IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер.

!	Правило: идентификационный номер не используется повторно, даже если в процессе построения модели действие удаляется.

Рисунок 8 – Изображение и нумерация действия в диаграмме IDEF3

В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 8).

Связи. Связи определяют существенные взаимоотношения между действиями.

!	Правило: Все связи в IDEF3 являются однонаправленными.

Стрелка связи может начинаться или заканчиваться на любой стороне блока, обозначающего действие. Но следует помнить, что диаграммы IDEF3 обычно организовываются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В табл. 4.3 приведены три возможных типа связей.

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

Таблица 4.3. Типы связей в модели IDEF3

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

1 Разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других.

2 Сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения только одного другого действия.

В таблице 4.4 приведены три типа соединений и их описания.

Таблица 4.4. Типы соединений в модели IDEF3

Графическое обозначение	Название	Вид	Правила инициации
&	Соединение "И"	Разворачивающее	Каждое конечное действие обязательно инициируется
Сворачивающее	Каждое исходное действие обязательно должно завершиться
Х	Соединение "Эксклюзив-ное ИЛИ"	Разворачивающее	Одно и только одно конечное действие инициируется
Сворачивающее	Одно и только одно исходное действие должно завершиться
О	Соединение "ИЛИ"	Разворачивающее	Одно (или более) конечное действие инициируется
Сворачивающее	Одно (или более) исходное действие должно завершиться

Примеры разворачивающих и сворачивающих соединений приведены на рис. 9.

Рисунок 9 – Два вида соединений

Таблица 4.5. Синхронные соединения модели IDEF3

Графическое обозначение	Тип	Вид	Правила инициации
	И	Разворачивающее	Все действия начнутся одновременно
Сворачивающее	Все действия закончатся одновременно
	ИЛИ	Разворачивающее	Может быть, несколько действий начнутся одновременно
Сворачивающее	Может быть, несколько действий закончатся одновременно
	Эксклюзивное ИЛИ	Разворачивающее	Одновременное начало действий невозможно
Сворачивающее	Одновременное окончание действий невозможно

!	Правило: синхронное разворачивающее соединение не обязательно должно иметь парное себе сворачивающее соединение.

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

!	Правило: все соединения на диаграммах должны быть парными.

!	Правило: типы соединений вовсе не обязательно должны совпадать.

Из этого правила следует, что любое разворачивающее соединение имеет парное себе сворачивающее.

На рис. 10 разворачивающее "И"–соединение имеет парное сворачивающее "ИЛИ"–соединение. Соединение J2 интерпретируется следующим образом: после включения пожарной сигнализации и (или) вызова пожарных и (или) начала тушения производится запись в журнал.

Рисунок 10 – Пример комбинации двух типов соединений

Рисунок 11 – Диаграмма IDEF3 с комбинацией соединений

Комбинации соединений. Соединения могут комбинироваться для создания более сложных правил ветвления (рис. 11). Комбинации соединении следует использовать с осторожностью, поскольку перегруженные ветвлением диаграммы могут оказаться сложными для восприятия.

Указатели – это специальные символы, которые ссылаются на другие разделы описания процесса. Они выносятся на диаграмму для привлечения внимания читателя к каким-либо важным аспектам модели.

Указатель изображается на диаграмме в виде прямоугольника, похожего на изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ, UOB и т.п.) и идентификатор.

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

Таблица 4.6. Типы указателей модели IDEF3

Тип указателя	Назначение
ОБЪЕКТ (OBJECT)	Для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект
ССЫЛКА (GOTO)	Для реализации цикличности выполнения действий. Указатель ССЫЛКА может относиться и к соединению
ЕДИНИЦА ДЕЙСТВИЯ (Unit of Behavior – UOB)	Для помещения на диаграмму дополнительного экземпляра уже существующего действия без зацикливания. Например, если действие "Подсчет наличных" выполняется несколько раз, в первый раз оно создается как действие, а последующие его появления на диаграмме оформляются указателями UOB
ЗАМЕТКА (NOTE)	Для документирования любой важной информации общего характера, относящейся к изображенному на диаграммах. В этом смысле ССЫЛКА служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах
УТОЧНЕНИЕ (Elaboration – ELAB)	Для уточнения или более подробного описания изображенного на диаграмме. Указатели УТОЧНЕНИЕ обычно используются для описания логики ветвления у соединений

Для корректной идентификации действий в модели с множественными декомпозициями схема нумерации действий расширяется и наряду с номерами действия и его родителя включает в себя порядковый номер декомпозиции. Например, в номере действия 1.2.5: 1 – номер родительского действия, 2 – номер декомпозиции, 5 – номер действия.

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

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

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

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

!	Таким образом, методология IDEF3 – это методология моделирования, предназначенная для обеспечения структурированного подхода к описанию бизнес-процесса как упорядоченной последовательности событий одновременно с описанием любых участвующих в бизнес-процессе объектов и относящихся к ним правил.

Создание диаграмм потоков работ – техника, хорошо подходящая для сбора данных о системе и применяющаяся как часть структурного подхода к анализу и проектированию системы. В отличие от других методов моделирования бизнес-процессов, IDEF3 требует строгого использования синтаксиса и семантики во избежание получения неполного или противоречивого описания системы.

Диаграммы IDEF3 применяются:

- для улучшения понимания результатов моделирования бизнес-процессов;

- для определения момента окончания моделирования;

- для сбора информации о схеме работы моделируемой компании.

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

4.5 Структурный анализ потоков данных (DFD – Data Flow Diagrams)

4.5.1 Назначение диаграмм потоков данных

Диаграммы потоков данных моделируют систему как набор действий, соединенных друг с другом стрелками. Диаграммы потоков данных могут содержать два новых типа объектов:

объекты, собирающие и хранящие информацию – хранилища данных;

объекты, моделирующие взаимодействие с теми частями системы (или другими системами), которые выходят за границы моделирования – внешние сущности.

На рис. 12 приведен внешний вид диаграммы потоков данных.

Рисунок 12 – Пример диаграммы DFD вставить рисунок пришлю вместо этого

В отличие от стрелок в IDEF0, которые иллюстрируют отношения, стрелки в DFD показывают, как объекты (включая и данные) реально перемещаются от одного действия к другому. Это представление потока вместе с хранилищами данных и внешними сущностями обеспечивает отражение в DFD-моделях физических характеристик системы:

- движение объектов (потоки данных),

- хранение объектов (хранилища данных),

- источники и потребители объектов (внешние сущности).

4.5.2 Синтаксис и семантика диаграмм потоков данных

В отличие от IDEF0, рассматривающего систему как множество взаимопересекающихся действий, в названиях объектов DFD-диаграмм преобладают имена существительные. Контекстная DFD-диаграмма может представлять собой один функциональный блок и нескольких внешних сущностей. Тогда функциональный блок обычно имеет имя, совпадающее с именем всей системы (рис. 13).

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

Рисунок 13 – Контекстная диаграмма DFD

Функциональные блоки. Функциональный блок DFD моделирует некоторую функцию, которая преобразует какое-либо сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Хотя функциональные блоки DFD и изображаются в виде прямоугольников с закругленными углами, они почти идентичны функциональным блокам IDEF0 и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения как IDEF0.

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

!	Правило: одна внешняя сущность может быть размещена на одной и той же диаграмме в нескольких экземплярах.

Этот прием полезно применять для сокращения количества линий, соединяющих объекты на диаграмме.

Стрелки (потоки данных). Стрелки описывают передвижение (поток) объектов от одной части системы к другой. Поскольку все стороны обозначающего функциональный блок DFD прямоугольника равнозначны (в отличие от IDEF0), стрелки могут начинаться и заканчиваться в любой части блока. В DFD также используются двунаправленные стрелки, которые нужны для отображения взаимодействия между блоками (например, диалога типа приказ – результат выполнения). На рис. 14 двунаправленная стрелка обозначает взаимный обмен информацией между департаментами информационного сопровождения и маркетинга и рекламы.

Рисунок 14 – Двунаправленный поток между блоком и внешней сущностью

Хранилища данных. В то время как потоки данных представляют объекты в процессе их передвижения, хранилища данных моделируют их во всех остальных состояниях. При моделировании производственных систем хранилищами данных служат места временного складирования, где хранится продукция на промежуточных стадиях обработки. В информационных системах хранилища данных представляют любой механизм, который поддерживает хранение данных для их промежуточной обработки. На рис. 15 приведен пример обозначения хранилищ данных на DFD-диаграммах.

Рисунок 15 – Обозначение хранилища данных на DFD-диаграмме

Ветвление и объединение. Стрелки на DFD-диаграммах могут быть разбиты (разветвлены) на части, и при этом каждый получившийся сегмент может быть переименован таким образом, чтобы показать декомпозицию данных, переносимых данным потоком (рис. 16).

Рисунок 16 – Разветвление стрелки, иллюстрирующее декомпозицию данных

Стрелки могут и соединяться между собой (объединяться) для формирования так называемых комплексных объектов.

4.5.3 Построение диаграмм потоков данных

В работе [29] рассматриваются два подхода к построению DFD-моделей. Диаграммы DFD можно строить с использованием подхода, аналогичного структурному методу анализа и проектирования, применяемому в IDEF0. Вначале строится модель физической реализации реальной системы, которая используется пользователями в настоящее время. Затем создается логическая модель текущего состояния системы для моделирования основных требований существующей системы. После этого создается новая логическая модель для отражения основных параметров предлагаемой разрабатываемой системы. Наконец, создается новая физическая модель, реализующая логическую модель новой системы.

В настоящее время при разработке информационных систем завоевывает все большую популярность альтернативный подход, известный как разделение событий, в котором для моделирования системы строится несколько моделей DFD. Вначале строится логическая модель, отображающая систему как набор действий и описывающая, что должна делать система. Затем строится модель окружения, описывающая систему как объект, отвечающий на события, порождаемые внешними сущностями. Такая модель обычно состоит из описания назначения системы, одной диаграммы контекстного уровня и списка событий. Контекстная диаграмма содержит один функциональный блок, представляющий систему в целом, и внешних сущностей (окружения), с которыми система взаимодействует [29].

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

Итак, диаграммы потоков данных (DFD) обеспечивают удобный способ описания передаваемой информации как между частями моделируемой системы, так и между системой и внешним миром. Это качество определяет область применения DFD – они используются для создания моделей информационного обмена организации, например модели документооборота. Кроме того, различные вариации DFD широко применяются при построении корпоративных информационных систем.

Стрелки в DFD показывают, как объекты (данные) фактически взаимодействуют между собой. Это представление, объединяющее хранимые в системе данные и внешние для системы объекты, дает DFD-моделям большую гибкость для отображения физических характеристик системы, таких, как проблемы обмена данными, разработка схем их хранения и обработки.

Методология IDEF3 – это методология моделирования, предназначенная для обеспечения структурированного подхода к описанию бизнес-процесса как упорядоченной последовательности событий одновременно с описанием любых участвующих в бизнес-процессе объектов и относящихся к ним правил.

Создание диаграмм потоков работ – техника, хорошо подходящая для сбора данных о системе и применяющаяся как часть структурного подхода к анализу и проектированию системы. В отличие от других методов моделирования бизнес-процессов, IDEF3 требует строгого использования синтаксиса и семантики во избежание получения неполного или противоречивого описания системы.

Диаграммы IDEF3 применяются:

- для улучшения понимания результатов моделирования бизнес-процессов;

- для определения момента окончания моделирования;

- для сбора информации о схеме работы моделируемой компании.

Построение моделей IDEF3 иногда позволяет упростить функциональное моделирование системы по методологии IDEF0 и получило заслуженное признание как довольно удобный способ анализа потенциальных усовершенствований системы. Диаграммы IDEF3 обеспечивают дискретность моделирования процесса, что может использоваться для контроля за ходом выполнения работ. Временная шкала использования разных методологий моделирования показана на рис. 17.

Рисунок 17 – Временная шкала использования разных методологий моделирования

4.6 Стандарт онтологического исследования IDEF5

Параграф написан по материалам работ Бабак В.Ф., Рыженко И.Н. Совершенствование методологии проектирования информационных систем. http://emanual.ru/download/1638.html; Верников Г. Стандарт онтологического исследования IDEF5 / http://www.itrealty.ru

Стандарт онтологического исследования IDEF5 (INTEGRATED DEFintion) представитель семейства государственных стандартов США IDEFx включающих 14 стандартов, представляющих методологии исследования систем в различных отраслях знаний [32].

Исторически, понятие онтологии появилось в одной из ветвей философии, называемой метафизикой, которая изучает устройство реального мира. Основной характерной чертой онтологического анализа является, в частности, разделение реального мира на составляющие и классы объектов (at its joints) и определение их онтологий, или же совокупности фундаментальных свойств, которые определяют их изменения и поведение. Таким образом, естественная наука представляет собой типичный пример онтологического исследования. Например, атомная физика классифицирует и изучает свойства наиболее фундаментальных объектов реального мира, таких как элементарные частицы, а биология, в свою очередь, описывает характерные свойства живых организмов, населяющих планету.

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

Методология IDEF5 обеспечивает наглядное представление данных, полученных в результате обработки онтологических запросов в простой естественной графической форме.

4.6.1 Основные принципы онтологического анализа

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

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

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

!	Таким образом, онтология представляет собой некий словарь данных, включающий в себя терминологию и модель поведения системы.

Процесс построения онтологии, согласно методологии IDEF5 состоит из пяти основных действий:

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

2. Сбор и накапливание данных. На этом этапе происходит сбор и накапливание необходимых начальных данных для построения онтологии

3. Анализ данных. Эта стадия заключается в анализе и группировке собранных данных и предназначена для облегчения построения терминологии.

4. Начальное развитие онтологии. На этом этапе формируется предварительная онтология, на основе отобранных данных.

5. Уточнение и утверждение онтологии – заключительная стадия процесса.

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

1. Создание и документирования словаря терминов.

2. Описание правил и ограничений, согласно которым на базе введенной терминологии формируются достоверные утверждения, описывающие состояние системы.

3. Построение модели, которая на основе существующих утверждений, позволяет формировать необходимые дополнительные утверждения.

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

Таким образом, онтология представляет собой некий словарь данных, включающий в себя и терминологию, и модель поведения системы.

4.6.2 Язык описания онтологий в IDEF5

Для поддержания процесса построения онтологий в IDEF5 существуют специальные онтологические языки: схематический язык (Schematic Language-SL)и язык доработок и уточнений (Elaboration Language-EL). SL является наглядным графическим языком, специально предназначенным для изложения компетентными специалистами в рассматриваемой области системы основных данных в форме онтологической информации. Этот несложный язык позволяет естественным обра