Аис1

UOW. Например, описанием может быть «расчет и вычерчивание деталей редуктора»;

CONSTRAINTS (ограничения) - часть документа, содержащая ограничивающие данные, накладываемые на функцию, и представляющие собой факты о UOW, обеспечивающие существование UOW до их выполнения, во время и после их окончания. Ограничениями обычно являются условия, оговаривающие сроки начала процесса, его продолжения или окончания. Например, "автоматизированное проектирование редуктора требует наличие установленного ПО: AutoCAD, версии не ниже 2000 и APM Win Machine".

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

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

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

IDEF3 позволяет внести информацию в модель различными способами. Например, логика взаимодействия может быть отображена графически в виде комбинации перекрестков. Та же информация может быть отображена в виде объекта ссылки типа ELAB (Elaboration). Это позволяет аналитику вносить информацию в удобном в данный момент времени виде. Важно учитывать, что модели могут быть реорганизованы, например, для их представления в более презентабельном виде. Выбор формата для презентации часто имеет важное значение для организации модели, поскольку комбинация перекрестков занимает значительное место на диаграмме и использование иерархии перекрестков затрудняет расположение UOW на диаграмме.

Связи (стрелки)

СВЯЗИ (стрелки). Возможный порядок или очередность выполнения действий описыва-мого процесса в IDEF3 задается связями. Связи используются, чтобы непосредственно описать отношения между функциональными блоками. Эти отношения, в зависимости от описываемого процесса, могут быть постоянными, временными, логическими, причинными, условными, природными и другими.

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

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

101

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

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

Связи старшинства подразделяются на простые связи старшинства (Simple Precedence Links) и принуждающие связи старшинства (Constrained Precedence Links).

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

Все связи IDEF3 описания нумеруются. Подобно процессам, нумерация стрелок производится последовательно согласно порядку, в котором они добавлены. Номера стрелок содержат префикс "L" и назначенного, последовательного номера. При этом, связи старшинства обозначаются символом PL (от «precedence link») и порядковым номером, а связи неопределенного типа символом DL (от «dashed link») и своим порядковым номером. В диаграммах IDEF3 между элементами используются три типа стрелок представляющих отношения между элементами в моделируемой системе: старшинства, объектного потока и относительная.

Стрелки типа PRECEDENCE выражают временные отношения старшинства между единицами UOW диаграммы. Показывает, что UOW-источник должен закончиться прежде, чем UOW-цель начнется. Графически стрелка старшинства рисуется слева направо или сверху вниз сплошной линией с одиночной стрелкой.

Пример простой связи старшинства приведен на рис. 3. В данном примере модуль А является источником связи, а модуль В её местом назначения. Также говорят, что модуль А является предшественником модуля В, а модуль В является преемником модуля А.

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

элементу А должен предшествовать элемент В;

элементу В должен предшествовать элемент A;

любой элемент должен сопровождаться элементом B, и что элементу B должен предшест-вовать элемент A.

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

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

102

верхней схеме рисунка 4 задают правило – действие модуля 1 должно предшествовать действию модуля 2. Средняя схема на рисунке 4 задает правило предшествования действий модуля В действиям модуля А. Последняя схема определяет, что модули А и В должны предшествовать друг другу. Таким образом, принуждающие связи старшинства добавляют нормативный компонент описанию схемы процесса, определяя не как выполняются действия модулями, а как они должны выполняться.

Использование стрелок относительной связи RELATIONAL LINK указывает на тот факт, что между взаимодействующими элементами диаграммы описания процесса существует отношения неопределенного типа. Используется для изображения связей между единицами UOW, а также между единицами UOW и объектами ссылок. Отношение показывает, что стрелка является альтернативой стрелке Precedence или потоку объектов (Object Flow) в смысле задания последовательности выполнения UOW - UOW-источник не обязательно должна закончиться, прежде чем UOW-цель начнется. Более того, UOW-цель может закончиться прежде, чем закончится UOW-источник. Относительные связи графически показываются пунктирными линиями.

Стрелки потока объектов. Тип связи OBJECT FLOW наследует все свойства простой связи старшинства и выражает перенос одного или нескольких объектов от одного функционального элемента к другому. Связь применяется для описания того факта, что объект используется в двух или более еди-ницах UOW, например, когда объект порождается в одной UOW и используется в другой. Значение связи потока объектов: между UOW элементов происходит передача объек-та/объектов, причем первый элемент UOW должен завершиться прежде, чем начнет выполняться следующий. Графически стрелки этой связи показываются сплошная линия с двойной стрелкой (см. Рис. 6 Представление связи поток объектов).

Тип связи поток объектов предложен разработчиками CASE-средств, поддерживающих моделирование в стандарте IDEF3.

JUNCTION

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

103

требуется, чтобы один или несколько следующих процессов были запущены;

Synchronous OR - синхронное "ИЛИ". При слиянии требуется, чтобы один или несколько предшествующих процессов завершались одновременно. При разветвлении требуется, чтобы один или несколько следующих процессов запускались одновременно;

Exclusive OR - исключающее "или". При слиянии требуется, чтобы только один

предше-ствующий процесс завершен. При разветвлении требуется, чтобы запускался только один следующий процесс.

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

каждому перекрестку для слияния должен предшествовать перекресток для разветвления;

перекресток для слияния "И" не может следовать за перекрестком для разветвления типа синхронного или асинхронного "ИЛИ";

перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ";

перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И";

перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной

105

стрелки на другой.

Для описания отношений между модулями UOB в IDEF3 используется термин активизация (activation). Под активизациями понимается возможный набор состояний части или всех модулей UOB, удовлетворяющих временным или логическим условиям, заданным схемой, при которых активизируется один или несколько изображенных на схеме модулей. Для наглядного представления во времени очередности включения и выключения модулей UOB сложных схем рекомендуются так называемые планы активизации (activation plots) – графики запуска, на которых во времени изображается очередность выполнения действий. На следующих рисунках приведены примеры использования комбинаций перекрестков в виде сценариев IDEF3 и соответствующих им планов активизации. Обратите внимание, каким образом изменение асинхронных узлов (рис. 4) на синхронные изменяет временную диаграмму выполнения операций модулями UOB.

OSTN-диаграммы

Диаграмма сети изменения состояний объектов (OSTN) отражает объектный взгляд на процесс. Она пронизывает все диаграммы процессов и объединяет в себе все возможные переходы.

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

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

Состояние объекта описывается фактами и ограничениями, которые должны выполняться для нахождения объекта в данном состоянии. Условия входа определяют требования для перехода объекта в заданное состояние. Условия выхода говорят о ситуации, в которой объект выходит из заданного состояния. Эти ограничения описываются в списке свойств. Кривые переходов состояний задают возможные способы изменения состояний объектов. Часто удобно подчеркивать участие процессов в изменении состояний объектов. Смысловое содержание понятия объекта определяется самим пользователем. Если под объектами понимаются отдельные детали, узлы, модули, блоки и агрегаты, то диаграммы OSTN могут быть использованы, например, для описания процесса сборки готового изделия на промышленном предприятии.

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

На рис.3 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в данном случае детали) и изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOW, в результате которого произошло отображаемое ей изменение состояния объекта.

106

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

Как инструмент моделирования IDEF3,фиксирует следующую информацию о процессе:

роли, которые выполняют эти объекты (например, агент, транспорт и т.д.);

отношения между UOW в ходе выполнения сценария процесса;

состояния и изменения, которым подвергаются объекты;

время выполнения и контрольные точки синхронизации UOW;

ресурсы, которые необходимы для выполнения UOW.

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

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

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

Чтобы отобразить различные варианты детализации действий или событий в IDEF3 предусмотрена возможность многократной декомпозиции одного функционального модуля. Как видно на рис. 1, в диаграмме декомпозиции первая цифра номера модуля указывает номер д-композируемого, то есть родительского модуля, а вторая цифра порядковый номер декомпозиции. Третья цифра указывает порядковый номер модуля в диаграммах описания процесса. На рисунке 2 представлен пример двух вариантов декомпозиции родительского модуля.

109