Принять

исправления

 

Рис. 3.6.3. Связь типа «временное предшествование» между действиями 1.1 и 1.2

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

Рис. 3.6.4. Объектная связь между действиями 1.1 и 1.2

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

Рис. 3.6.5. Связь типа «нечеткое отношение»

Наиболее часто нечеткие отношения используются для описания специальных случаев связей предшествования, например, для описания альтернативных вариантов временного предшествования. На рис: 3.6.6. вертикальные линии показывают начало; и окончание действий 1.1 и 1.2, имеющих предшественную связь. В соответствии с порядком действий, показанным на рис. 3.6.3, внесение исправлений в работу начинается после принятия всех замечаний от рецензентов.

Рис. 3.6.6. Временная шкала выполнения действий для рис. 3.6.3.

Связь нечеткого отношения, альтернативная предшественной связи на рис. 3.6.3, представлена на рис. 3.6.7. В этом примере внесение исправлений начинается по мере получения замечаний от рецензентов, т.е. до непосредственного окончания действия по принятию замечаний.

Рис. 3.6.7. Альтернативная связь предшествования

На рис. 3.6.8 приведена соответствующая этой ситуации временная шкала.

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

Рис. 3.6.8. Альтернативная временная шкала

Начало А1.2 Окончание А1.2

Рис. 3.6.9. Вариант альтернативной временной шкалы

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

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

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

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

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

В табл. 3.1.2 объединены три типа соединений.

Таблица 3.1.2. Типы соединений

Графическое обозначение	Название	Вид	Правила инициации
&	Соединение «и»	Разворачивающее	Каждое конечное действие обязательно инициируется
Сворачивающее	Каждое исходное действие обязательно должно завершиться
X	Соединение «эксклюзивное “или”»	Разворачивающее	Одно и только одно конечное действие инициируется
Сворачивающее	Одно и только одно исходное действие должно завершиться
O	Соединение «или»	Разворачивающее	Одно или несколько конечных действий инициируются
Сворачивающее	Одно или несколько исходных действий должны завершиться

 

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

Рис. 3.6.10. Два вида соединений

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

Соединение «эксклюзивное “или”». Вне зависимости от количества действий, связанных со сворачивающим или разворачивающим соединением «эксклюзивное “или”», инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое действие, следующее за сворачивающим соединением «эксклюзивное “или”», сможет начаться. Если правила активации соединения известны, они обязательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения, как показано на рис. 3.6.12.

Рис.3.6.11. «И»-соединения

 

Рис. 3.6.12. Соединение «эксклюзивное “или”»

Соединение «или» предназначено для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений. Аналогично связи нечеткого отношения соединение «или» в основном определяется и описывается непосредственно системным аналитиком. На рис. 3.6.13 соединение J2 может активизировать проверку данных чека и/или проверку суммы наличных. Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных – при оплате наличными. И то, и другое действие инициируются при частичной оплате как чеком, так и наличными.

Рис. 3.6.10. Соединение «или»

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

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

Таблица 3.1.3. Виды синхронных соединений

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

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

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

Рис.3.6.14

. Синхронное соединение

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

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

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

 

 

Рис. 3.6.16. Диаграмма IDEF3 с комбинацией соединений

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

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

Таблица 3.1.4. Указатели и их назначения

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

На рис. 3.6.18 показан пример отображения важного для данной модели отношения между действием и объектом.

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

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

Рис. 3.6.17. Указатель ОБЪЕКТ Рис.3.6.18. Указатель ОБЪЕКТ

ссылается на действие

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

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

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

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

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

Поскольку модели IDEF3 могут одновременно разрабатываться несколькими командами, IDEF3 поддерживает простую схему резервирования номеров действий в модели. Каждому аналитику выделяется уникальный диапазон номеров действий; что обеспечивает их независимость друг от друга. В табл. 3.1.5 номера действий выделяются каждому аналитику большими блоками. В этом примере аналитик 1 полностью использовал данный ему вначале диапазон номеров и дополнительно получил второй.

Таблица 3.1.5. Резервирование номеров действий

Аналитик	Диапазон номеров IDEF3
	1–99
	100–199
	200–299
	300–399

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

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

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

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

Наиболее часто IOEF0 применяется как технология исследования и проектирования систем на логическом уровне. По этой причине IDEF0, как правило, используется на ранних этапах разработки проекта до IDEF3-моделирования, для сбора данных и моделирования процесса "как есть". Результаты IDEF0-анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных.

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

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

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

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

Синтаксис графического языка IDEF0 включает блоки, стрелки, диаграммы и правила.

Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование (см. ниже). Стрелки представляют данные или материальные объекты, связанные с функциями. Правила определяют, как следует применять компоненты; диаграммы обеспечивают формат графического и словесного описания моделей. Формат образует основу для управления конфигурацией модели.

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

Рис. 3.6.20. Пример блока

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

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

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

 

Рис.3.6.19а. Пример такой контекстной функции

Рис. 3.6.19 б. Пример диаграммы IDEF0

Рис. 3.6.19 в. Пример диаграммы IDEF0
Рис.3.6.19 а Пример такой контекстной функции

Рис. 3.6.19 г. Пример диаграммы IDEF0

В IDEF0 также моделируются управление и механизмы исполнения. Под управлением понимаются объекты, воздействующие наг способ, которым блок преобразует вход в выход. Механизм исполнения – объекты, которые непосредственно выполняют преобразование входа в выход, но остаются неизменными.

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

I (Input) – вход – то, что потребляется в ходе выполнения процесса;

С (Control) – управление – ограничения и инструкции, влияющие на ход выполнения процесса;

О (Output) – выход – то, что является результатом выполнения процесса;

М (Mechanism) – исполняющий механизм – то, что используется для выполнения процесса, но остается неизменным.

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

Рис. 3.6.21. Каждый тип стрелки соединяется с определенной стороной функционального блока

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

Дадим подробное назначение каждой стрелки.

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

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

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

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

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

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

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

Комбинированные стрелки. В IDEF0 существует пять основных видов комбинированных стрелок: 1) выход – вход, 2) выход – управление, 3) выход – механизм исполнения, 4) выход – обратная связь на управление и 5) выход – обратная связь на вход.

1) Стрелка выход – вход применяется, когда один из блоков должен полностью завершить работу перед началом работы другого блока. Так, на рис. 3.6.22 формирование счета должно предшествовать приему заказа.

Рис. 3.6.22. Комбинация стрелок выход – вход

2) Стрелка выход – управление отражает ситуацию преобладания одного блока над другим, когда один блок управляет работой другого. На рис. 3.6.23 принципы формирования инвестиционного портфеля влияют на поведение брокеров на бирже.

Рис. 3.6.23. Комбинированная стрелка выход – управление

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

4) Обратные связи на вход и на управление применяются в случаях, когда зависимые блоки формируют обратные связи для управляющих ими блоков. На рис. 3.6.25 получаемая от брокеров информация о текущих биржевых курсах применяется для корректировки стратегии игры на бирже.

Рис. 3.6.24. Комбинированная стрелка выход – механизм исполнения

Рис. 3.6.25. Комбинированная стрелка выход – обратная связь на управление

5) Стрелка выход – обратная связь на вход обычно применяется для описания циклов повторной обработки чего-либо (рис. 3.6.26). Кроме того, связи выход – обратная связь на вход могут применяться в случае, если бракованная продукция может заново использоваться в качестве сырья, как это происходит, например, в процессе производства оконного стекла, когда разбитое стекло перемалывается и переплавляется заново вместе с исходным сырьем.

Рис. 3.6.26. Комбинированная стрелка выход – обратная связь на вход

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

Рис.3.6.27. Разъединенная на две части и переименованная стрелка

На IDEF0-диаграммах есть еще стрелки вида (¯). Такие стрелки называют туннелями. Они связаны с понятием связанных стрелок, которое используется для управления уровнем детализации диаграмм. На рис. 3.6.28, например, стрелка "корпоративная информационная система" – важный механизм исполнения для данной диаграммы, но, возможно, она более нигде не используется в модели. Туннель в данном случае используется как альтернатива загромождению родительских диаграмм помещением на них несущественных для их уровня стрелок.

Рис. 3.6.28. Пример применения туннеля

Кроме того, туннели применяются для отражения ситуации, когда стрелка, присутствующая на родительской диаграмме, отсутствует в диаграмме декомпозиции соответствующего блока. На рис. 3.6.29 туннель у стрелки "модуль производственного отдела" обозначает, что на диаграмме декомпозиции производственного отдела отсутствует стрелка механизма управления с соответствующим наименованием.

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

Все элементы заголовка диаграммы перечислены в табл. 3.1.6.

Рис. 3.6.29. Пример применения туннеля

Таблица 3.1.6. Элементы заголовка диаграммы IDEF0

Поле	Назначение
USED AT	Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вручную)
Author, date, project	Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась
Notes 1 ... 10	При ручном редактировании диаграмм пользователи могут зачеркивать цифру каждый раз, когда они вносят очередное исправление
Status	Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализации формального процесса публикации с шагами пересмотра и утверждения
Working	Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы
Draft	Диаграмма достигла некоторого приемлемого для читателей уровня и готова для представления на утверждение
Recommended	Диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся
Publication	Диаграмма готова для окончательной печати и публикации
Reader	ФИО читателя
Date	Дата знакомства читателя с диаграммой
Context	Набросок расположения функциональных блоков на родительской диаграмме, на котором подсвечен декомпозируемый данной диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в поле помещается контекст ТОР

Все элементы "подвала" диаграммы перечислены в табл. 3.1.7.

Таблица 3.1.7. Элементы "подвала" диаграммы IDEF0

Поле	Назначение
Node	Номер диаграммы, совпадающий с номером родительского функционального блока
Title	Имя родительского функционального блока
Number (еще называют С-Number)	Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия данной диаграммы будет иметь новое значение в этом поле. Как правило, С-Number состоит из инициалов автора (которые предполагаются уникальными среди всех аналитиков проекта) и последовательного уникального идентификатора, например SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быть заключен в скобки – SDO005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели

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

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

Формально механизм рецензирования и модификации диаграмм поддерживается полями Status и нумерацией диаграмм, контроль истории изменений – полем Field (см. табл. 3.1.6).

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

• Почему моделируется данный процесс?

• Что выявит данная модель?

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

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

• Каковы задачи менеджера?

• Каковы задачи клерка?

• Кто контролирует работу?

• Какая технология нужна для выполнения каждого шага? и т.п.

3.2.3.1. Точка зрения

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

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

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

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

Чтобы облегчить правильное определение границ моделирования при разработке IDEF0-моделей, существенные усилия затрачиваются на разработку и рецензирование контекстной диаграммы IDEF0 (диаграммы "самого верхнего" уровня). Иногда даже прибегают к построению дополнительной диаграммы для отображения уровня более высокого, чем контекстный для данной модели, что позволяет обозначить систему, внутри которой располагается объект для моделирования. Существенные затраты на разработку контекстной диаграммы вполне оправданы, поскольку она является своего рода "точкой отсчета" для остальных диаграмм модели, и вносимые в нее изменения каскадом отражаются на все лежащие ниже уровни.

Когда границы моделирования понятны, также становится ясным, какие объекты системы по тем или иным причинам не вошли в модель.

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

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

3.2.4. Определение стрелок на контекстной диаграмме

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

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

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

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

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

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

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

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

• Подходит ли выбранный уровень детализации стрелок для контекстного блока? (Обычно на контекстной диаграмме рекомендуется рисовать не более шести стрелок каждого типа.)

3.2.5. Нумерация блоков и диаграмм

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

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

3.2.6. Связь между диаграммой и ее родительским функциональным блоком

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

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

На концах граничных стрелок (начинающихся или заканчивающихся за пределами диаграммы) детских диаграмм помещаются коды ICOM, чтобы показать, где находится соответствующая стрелка на родительской диаграмме (рис. 3.6.30). Они нужны для проверки целостности модели и могут быть полезны, когда порядок расположения стрелок на детской диаграмме отличается от порядка их размещения на родительской диаграмме. Код ICOM состоит из латинской буквы I, С, О или М и числа, показывающего расположение стрелки на родительской диаграмме в порядке сверху вниз или слева направо.

Рис. 3.6.30. ICOM-коды на граничных стрелках

3.2.7. Два подхода к началу моделирования ("в ширину" и "в глубину")

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

3.2.8. Когда остановиться?

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

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

3.2.9. Другие диаграммы IDEF0

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

Дерево модели. Дерево модели – обзорная диаграмма, показывающая структуру всей модели. На рис. 3.6.31 приведен фрагмент такой диаграммы. Обычно вершина дерева соответствует контекстному блоку, под вершиной выстраивается вся иерархия блоков модели.

Рис. 3.6.31. Фрагмент дерева модели

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

Презентационные диаграммы. Презентационные диаграммы (For Exposition Only diagrams – FEO diagrams) часто включают в модели, чтобы проиллюстрировать другие точки зрения или детали, выходящие за рамки традиционного синтаксиса IDEF0. Диаграммы FEO допускают нарушение любых правил построения диаграмм IDEF0 в целях выделения важных с точки зрения аналитика частей модели. Естественно, если диаграмма FEO включена в модель исключительно для отображения другой точки зрения на систему, она, скорее всего, внешне будет выглядеть как обыкновенная IDEF0-диаграмма, удовлетворяя всем ограничениям IDEF0.

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

Кроме того, встречаются следующие виды презентационных диаграмм:

• копия IDEF0-диаграммы, которая содержит все функциональные блоки и стрелки, относящиеся только к одному из функциональных блоков, – это позволяет отразить взаимодействие между этим блоком и другими объектами диаграммы;

• копия IDEF0-диаграммы, которая содержит все функциональные блоки и стрелки, непосредственно относящиеся только ко входу и/или выходу родительского блока;

• различные точки зрения, как правило, на глубину одного уровня декомпозиции.

Рис. 3.6.32. Диаграмма FEO для выделения функционального блока и его стрелок

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

3.2.10. Структурный анализ средствами IDEF-моделирования

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

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

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

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

Рис. 3.6.33. Функциональный блок

элемента – блока (рис. 3.6.33). Блоки – это основной структурный элемент функциональной
Рис. 3.6.34. Модифицированный функциональный блок

модели, графическим представлением которой является диаграмма.

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

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

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

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